SharePoint 2010 User Profile Synchronization Service
As it turns out, the SPS 2010 User Profile Synchronization Service is something of a challenge. Lucky for us, our new best friend, Spencer, has pretty much covered all the details here.
First, he provides some great backrgound information and explains that the profile service is really the new Forefront Identity Manager service bundled into the SharePoint interface. We’ve got a few cycles through the old MS Identity Lifecycle Manager so the move to the FIM 2010 is likely to be reasonably painless.
Then he drops a bombshell:
[UPDATE: 01/11/2010] Also, I assume that you have not used a
Fully Qualified Domain Name or IP Address when specifying the
SQL Server when running the SharePoint Configuration Wizard
(PSConfig). Using either is strongly discouraged, and will lead
to failures with the provisioning of the User Profile Synchronization
service instance. Stick to a NetBIOS name, or a SQL Server Alias.
We, of course we used the FQDN for our database server. So we have to go back to our SharePoint Configuration Wizard and disconnect from our farm.
Then we run the wizard a second time and connect to our farm using the NetBIOS name for our database server, which is just DB01. The wizard finds the SharePoint_Config database on it and then, we reselect our details and the wizard runs and opens Central Admin.
Great.
Next, we’ll need a new service account. Spencer lets the cat out of the bag suggesting that our service accounts ought to go into the Managed Service Accounts folder in Active Directory. Now I never claimed to be an AD wizard, just an SPRobot so, I’m going to move all of our service accounts into that group and hope nothing breaks. Spencer talks about “implications” which we’ll ignore for now. I’ll put the new service account, SVC_SPUPSynch, in there.
Next, he says, our new account will need the Replicating Directory Changes permission. That’s where we meet the Delegation of Control Wizard by right clicking on the domain. We add the service account, and create a custom task. Two pages later, we select the appropriate permission and then Next and Finish.
Then, we’re running ADSIEDIT.msc. Now, Spencer says “Connect to the Configuration Partition” and I guess that’s accurate but what we need to do is right click on our Default Naming Context and select Settings.
Here, we get the Default naming context and we move down to the Select a well known Naming Context option and pull down the list and select Configuration and click OK. Then, we get the folder called CN=Configuration, DC=Domain, DC=com. We can right click on it and select Properties. On the Security tab, we add our SPUPSynch user and then check the “Allow” box for Replicating Directory Changes. We click Apply and OK.
Then, Spencer switches us to your SharePoint server and indicates that we have to let our “SPFarm” account log on locally. This is our SVC_SPDBAcces account. I presume that it can logon locally to our SharePoint server and Spencer is accounting for the possibility that our Profile Synch might run on a different server. All the same, we move to the SharePoint server and select Local Security Policy from Administrative Tools. Under Security Settings, we open the Local Policies | User Rights Assignment node and click on Allow Logon Locally.
We add our SVC_SPDBAccess account and click OK and do a Start | Run | GPUpdate.
Then we get some instructions to make our DB Access account a local administrator. No problem. And then suggests we reboot. No problem.
Now, Spencer says create two web applications, one for the portal and one for the My Sites.
Tags: