Finding your Way through the Configuration Maze

SharePoint has two basic configuration modes:

- SharePoint sets up "Everything" for you
- You set up "Everything" manually

There is precious little in between these two extremes. The good news is, if you let SharePoint configure everything, chances are everything will work. The bad news is, these settings rarely reflect best practices, and if (when?) you want to tweak some of those settings later you often find that one change has to lead to another, and another, and another in order to get back to working order. By the time you're done you may as well have done it manually in the first place.

Configuring SharePoint 2010 to do people search is one such area. The first half of the manual configuration (or reconfiguration) process is setting up the User Profile import. That is fairly well documented in several places. Probably the best is by fellow MVP Spencer Harbar in his article "A Rational Guide to Implementing SharePoint Server 2010 User Profile Synchronization".

The Bread of the Sandwich

Given how comprehensive Spencer's article is, you wouldn't think that there is anything more to say, and in truth, it is the meat of the issue and often the hardest part to get working. But as I said, that is only half of the story - getting user profile data into SharePoint. What my article is about is letting your users find the information. Since some of this comes before, and some comes after, the AD configuration in Spencer's article, you could think of this as the bread of the sandwich.

Once Central Administration is up and running, the first thing it offers is the opportunity to let another Wizard configure all of your service applications for you, and set up a default SharePoint web application. If you followed Spencer's advice, you said "No" to its kind offer. His article assumes you did, and gives instructions for setting things up completely manually. For this article, I'll assume you said "Yes" and want to fix things up. For completeness, I cover some of the same ground, and you can safely follow either set of instructions for creating the User Profile Sync service app.

Again, if you say "Yes", you'll get something that works. But if you look carefully, you'll discover two big things that violate good configuration practice for production environments:

1. The Search service application is configured to use the Server Farm/Database Access account as the default content access account.
2. My Sites and the Profile host site collection are configured to live within that first web application, which is named with the host name of your central administration server.

The first one is easy to address - on the surface. Create a suitable domain account, then in Central Administration, go to your Search service application and assign it to be the default content access account.

SharePoint will give it a default read policy on every web application associated with that service application. That's great as far as it goes, but hold that thought for a moment. I'll be coming back to it shortly.

As for the second issue, having the personal sites embedded in a content web application, you'll need to delete and re-create the User Profile Service application to resolve that. Or create the service application for the first time if you didn't invoke the wizard. Whether correcting from the wizard or creating the applications for the first time, other than the deletion, the steps (and some of the potential issues) are the same.

First, create a "normal" web application for your profiles and personal sites. Create a site collection at the root of the web application using either the "Blank" or "MySite Host" template.

Second, go to your Service Applications page and from the New button select User Profile Synchronization service application. Like most service applications, this one requires you to allocate an application pool and number of databases. The page suggests leaving them as the default names, which you can, though if you do make sure the databases from the original service application (if any) are deleted first. Otherwise, give them appropriate names for your environment.

Toward the end of the configuration page, specify the server in your farm that you want to host the profile sync service, and enter the web application you defined in the previous step.

After you accept your settings, wait for the service application to finish creating. (You will return to the UI before that process completes.) Now would be a good time to go read Spencer's article to see what you should have done to get to this point, and have your AD administrator set the permissions required for your profile import account.

By that time, you should be able to complete the User Profile service application configuration as instructed.

The Last Piece of Bread

In a perfect world, you would be done. Of course, we don't live in a perfect world. Chances are, you'll get a wonderful set of profiles imported, and you can navigate to them and see everything. If your users create MySites, you'll probably even be able to find their content. But do a people search, and you get a whole bunch of "nothing". That's because you're not actually crawling the profile store - at least not successfully.

Time to go back to Central Administration, and first look at your Search service application's management page. Click the Content Sources link on the left hand side, and open/edit your Local SharePoint Sites content source. In the Start Addresses section, you will see a box with entries similar to those below:

Notice the sps3: line. This is the protocol SharePoint uses to read profiles. (Note: It isn't a "protocol", per se. It just instructs SharePoint to call a specific web service hosted at that address.) If you ran the wizard to configure your service applications, it will be pointing at the original web application created by it. You'll need to change it to reflect your new profile web application, then save the changes to your content source definition. Also, if you deleted the original wizard-created web application (or aborted its creation), you'll need to delete the regular http: line referencing it.

You might think (again) that that's all there is, but again you'd probably be wrong. Once you make the change above, you'll probably start seeing access denied errors on that "server". Remember when we assigned a new default content access account way back in step one? Well, even though it has permission to read the contents of the web site, the service under the sps3 protocol leads right back to the User Profile Synchronization service application, and you didn't tell that application to let the new content access account in.

To do that, navigate to the Manage Service Applications page, and highlight your User Profile Service Application. Click the Administrators icon in the ribbon.

You'll need to add your default content access account to the list of "administrators". It won't really be an administrator - notice that there are an array of permissions available. Once you add the account, highlight it and ensure that the "Retrieve People Data for Search Crawlers" permission is checked, as shown below:

Click OK, and reset IIS on the profile import server. Maybe even reboot it.

Best Practices?

At last, you're done. You should now have functioning user profiles and people search, configured in accordance with "best" practices. (Yeah, "best" is relative...) Still, there are reasons for this kind of configuration. It gives you an easily manageable farm, with excellent control over My Sites - ensuring that personal content is in separate databases from your corporate portal data. The account used to crawl won't be the "all powerful" Farm account, and you can tell the difference through access and audit logs between administrative access to resources and the search crawler's.

Now, wasn't that a tasty sandwich?