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:
- The Search service application is configured to use the Server Farm/Database Access account as the default content access account.
- 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.
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.