User Profile Synchronization seems to be a headache for everybody that tries to set it up. There is a great write up on how to get it working found here  Since the author did such a good job I will not try and duplicate it here. Rather I will summarize the process with the steps and point out a few snags to watch out for (they are mentioned in the link above as well) But then also point out a post implementation problem that I have run into and haven’t seen anywhere how to fix.

To Setup User Profile Synchronization Service in SharePoint 2010 first create the service accounts you will need.

  1. At minimum this will be the account with permission to AD to replicate the changes (ProfSync) and the service account to run the service itself (SPFarm)
  2. Grant the ProfSync account the replicate changes permission in the Active Directory Forest you are looking to sync with.
  3. The SPFarm account is your farm administrative account. unfortunately this will go against best practice (and the SharePoint Health Monitor rules) as it will require you to add it to local administrators group AND it will be used to run the service. You don’t have a choice. While we are at it also grant it the Allow Log On Locally permission.
  4. Create a New User Profile Service Application
  5. Start the User Profile Synchronization Service. This will take 10 minutes or so to start. After it starts if Central Administration is running on the same server reboot (IISRESET is enough but reboot anyway)
  6. Configure connections to actually sync.


The post implementation problem is if you are using a SQL named instance. Profile Synchronization works following the tutorial however if you stop the service after its running or reboot for that matter, it doesn’t start again! It sits in the starting state. This has been addressed in the SharePoint 2010 CU released yesterday unfortunately that was too late to save me all of the trouble figuring it out. The problem is that when the UPS service is stopped it is unprovisioned by design. The problem is that when starting again the service wipes out the value for the SQLInstance key located in the registry. This forces the service to try and connect on the default instance rather than the named instance which obviously isn’t going to work and results in the service not starting. So how do you fix it? Well the patch (I haven’t tested and confirmed yet) should fix it. SharePoint 2010 CU released

The way I got around it was by adding a SQL alias on the server running the synchronization service to point the default instance to the named instance. To do this navigate to system32 folder on the appropriate server and run cliconfig.exe. Once in there click on the alias tab, select ADD, then make sure TCPIP radial is selected and type in servername at the top box and add the instance name to the box on the right hand side.


Save and then try and restart your User Profile Synchronization Service and it will start.