This week, I was helping a colleague set up a more robust development environment for SharePoint. We got stuck while trying to provision the User Profile Service (UPS). It would change to â€œStartingâ€ and after 20-45 minutes, show â€œStoppedâ€ again.
Spence Harbarâ€™s (@harbars) blog post â€œRational Guide to implementing SharePoint Server 2010 User Profile Synchronizationâ€ is by far the best resource for setting up UPS. We deleted our User Profile Service Application and started from scratch, following Spenceâ€™s guide. Nothing changed and upon examining the ULS logs (using ULSViewer), we noticed the following error:
ILM Configuration: Error ‘ERR_CONFIG_DB’
This was obviously happening before, we just didnâ€™t notice. Spence has been kind enough to share common issues and resolutions with UPS on his follow up blog post: â€œStuck on Startingâ€: Common Issues with SharePoint Server 2010 User Profile Synchronization.
The blog post states this error is due to incorrect permissions on the Sync Database, so we checked and re-checked and even changed the settings to ensure the SharePoint Farm service account had permissions. No luck!
Eventually, I was led to a post by William Wolfe (link), where he had the same problem with a named instance. Our configurations are different. Iâ€™m using SQL Server 2008 R2 in a two-node cluster. In any case, we ARE in fact using named instances. This can be confusing because the Sync DB does get created, so communication between SharePoint and SQL is working. However, as William points out, the Forefront Identity Manager Synchronization Service (FIMSynchronizationService) tries to connect to the default instance.
The solution we used from Williams blog post worked. We created a SQL Alias called â€œClusterNameâ€ and pointed it to â€œClusterName\InstanceNameâ€ and restarted UPS. After 10 minutes, it â€œStartedâ€ and we could see all the databases and success notices in the ULS Viewer.
On Spenceâ€™s blog post, he does specify that UPS does not support Named Instances. However, the information was a bit misleading, at least in my case. Using any â€œAliasâ€ name does not work after youâ€™ve already installed SharePoint. You must specify the the SQL server name you used during the install, in my case, the name of the cluster. In any case, as a best practice, always use a SQL Alias.