An error I’ve frequently encountered is the “Cannot access local farm” issue.  This can come up when attempting to run a PowerShell script or STSADM command, and looks something like this:

Get-SPWeb : Cannot access the local farm. Verify that the local farm is properly configured, currently available, and that you have the appropriate permission to access the database before trying again.

To work around this, run the following script in the SharePoint Management Shell, as a farm administrator.

Get-SPDatabase | Add-SPShellAdmin domain\username

This will grant the user access to both the configuration database and the content database.

To reverse the above command:

Get-SPDatabase | Remove-SPShellAdmin domain\username

Find the Search Administration Console (from central admin)

1. Select service applications
   
2. Select the search service application.

Find and set Crawl Rules

1. Crawl rules are located here
   
2. Crawl Rules can be used to Include or Exclude.  In the following example, there are three rules, used as filters (to exclude):
   

Force an incremental or full crawl

1. This can be a bit tricky to find. Select Crawl Sources
   
2. There should be only one content source present, unless you have set up others. Click the dropdown next to it – you’ll see options to crawl (which will be grayed out if a crawl is presently running):
   

At Synteractive, our SharePoint deployments often have both custom functionality AND a nice UI. So (in our most interesting projects) we’ll have designers working with developers. As a result, we used to end up with one of the following situations:

• Developers’ deployed WSP’s overwrite changes in asp, page layouts or master pages.
• Someone wants to back up all content or styles so it can be used in another project.
• People tiptoeing VERY CAREFULLY around each other’s code, so as not to overwrite it – but no process in place to prevent that.
• Some unlucky person gets to copy each file, one by one, from one environment to another.   Ugh.

I started wishing that SOMEONE had created a tool to pull down our customized SharePoint content (e.g. pages, master pages, xsl, css, js) en masse, so that I could reference it later, check it into Subversion or integrate it into a WSP for later deployment to a Production environment.

Introducing SPFileDownloader

Anyone who works with me knows that I love to automate things, and of course I wanted to save time.  So I created a small program which uses SharePoint Web Services to download the contents of lists or folders specified by the user.  It’s a command line utility, but the way it’s written, it could be retooled as Powershell, Windows Forms or whatever.

Since this is a command line utility, various arguments are necessary to tell it where to get the files, authentication information, etc.  If you invoke the program without arguments, you get the following help info:
Usage:
SPFileDownloader <web url> <list | list/folder/subfolder> <target dir local> <username> <password> [switches]
switches:
f   Use form-based authentication
r   Recursive - recurse through subfolders
o   Overwrite - overwrite local files
p   Pause - pause for user input after run


So a typical usage might look something like this:
> SPFileDownloader http://mysite "Style Library" c:\dev\test DOMAIN\username mypassword po


Once you get past this, the usage is self-explanatory. It can handle use form or basic authentication. You can recurse through directories (particularly useful if you want to back up the entire Style Library).

All source code is included here.   A couple of disclaimers: This code is provided as-is!  I won’t support it, though please leave comments if this has been useful to you, or if you have suggestions.   Finally, this code is, um, a bit sloppy.  It started out mostly as snippets compiled from elsewhere.  I’ve spent some time refactoring it, but it doesn’t pay to be perfectionistic here.  It works.

SPFileDownloader source code

Enjoy!

Everyone loves to see their name on a web page. It’s verification that the user is logged in properly, and perhaps validation of some sort? Well without getting into the psychology of it, I’d like to share a couple of approaches that I’ve taken to further personalize custom SharePoint pages.

The other day I was asked for a “quick script” to display the user’s login name elsewhere on the page. This assumes that you have not removed the login link located at the top right of the page. For this, you need to be using jquery. Thanks to Matt Huber’s blog for this idea, which I’ve taken a step further.

$(document).ready(function(){
     var name = $(".s4-trc-container-menu span a span").text();
     $("#myname").text(name);
});

And place this html wherever you want the name to appear.

<span id="myname"></span>

Similarly, here’s a slightly more sophisticated way to create a custom login link, complete with user name. This is a c# based approach, so the following code can go in the code-behind or inline code – perhaps in the override of OnLoad.

if (HttpContext.Current.User.Identity.IsAuthenticated)
{
    litName.Visible = true;
    //a bit of calisthenics to remove the domain. 
    string[] displayNameComponents = SPContext.Current.Web.CurrentUser.Name.Split(new char[] { '\\' });
    litName.Text = displayNameComponents[displayNameComponents.Length - 1];
}
else
{
    lnkSignIn.Visible = true;
}

Here’s the placeholder for the asp page:

<asp:Literal Visible="false" ID="litName" runat="server"/>
<asp:Hyperlink Visible="false" NavigateUrl="/_layouts/Login.aspx" ID="lnkSignIn" runat="server">Sign In</asp:Hyperlink>

<asp:Hyperlink Visible="true" onclick="STSNavigate2(event,'/_layouts/SignOut.aspx')" ID="lnkSignOut" runat="server">Sign Out</asp:Hyperlink>

That’s all, folks!