Provisioning shared services fails with user cannot be found error

  • Article

I was recently rebuilding one of my farms when I ran into the problem I describe below.

I logged onto the machine using my domain account. Then created local user accounts for use with my standalone farm on this machine and then ran SharePoint Post Installation Configuration Wizard. After creating a new farm with a new configuration database, it also created the SharePoint Central Administration site for me automatically. I then attempted to provision my Shared Services Provider and guess what I run into? After several minutes, I get a page with the following error:

Provisioning for Shared Services Provider 'My SSP' has failed and will be retried. Reason: User cannot be found. 

The error message is very odd! It doesn’t tell us which user it cannot find and what it wants to do. So I turn on our friendly diagnostic logging from the Operations tab in SharePoint Central Administration to get a verbose output of the actions. What I ended up finding was amusing. Although I didn’t completely understand why it works this way, here’s what I found in the ULS logs. I am including only the data in the message column for brevity:

Retrieved central administration site 'https://CASite:81'.
Central administration site owner is 'Domain\UserName'.
Creating shared services administration site 'My SSP'.
Creating site ssp/admin in content database MySite_Content_82
Error in resolving user 'Domain\UserName' :

System.ComponentModel.Win32Exception: Unable to contact the global catalog server    

at Microsoft.SharePoint.Utilities.SPActiveDirectoryDomain.GetDirectorySearcher()    

at Microsoft.SharePoint.WebControls.PeopleEditor.SearchFromGC(SPActiveDirectoryDomain domain, String strFilter, String[] rgstrProp, Int32 nTimeout, Int32 nSizeLimit, SPUserCollection spUsers, ArrayList& rgResults)    

at Microsoft.SharePoint.Utilities.SPUserUtility.ResolveAgainstAD(String input, Boolean inputIsEmailOnly, SPActiveDirectoryDomain globalCatalog, SPPrincipalType scopes, SPUserCollection usersContainer, TimeSpan searchTimeout, String customFilter)    

at Microsoft.SharePoint.Utilities.SPActiveDirectoryPrincipalResolver.ResolvePrincipal(String input, Boolean inputIsEm...    

Microsoft.SharePoint.SPException: User cannot be found.    

at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPContentDatabase database, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, String quotaTemplate, String sscRootWebUrl, Boolean useHostHeaderAsSiteName)    

at Microsoft.SharePoint.Administration.SPSiteCollection.Add(String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, Boolean useHostHeaderAsSiteName)    

at Microsoft.Sh...    

So it turns out that while provisioning the Shared Services, there is a lookup on who the Site collection administrator is for the Central Administration Website. This makes sense because it needs to update all these settings for SSP database. While provisioning the Central Administration site, it used my domain account for the site collection administrator. Now, during the provisioning of the Shared Services, it was trying to resolve the account specified in the Central Administration site’s site collection administrators list, but failed to do so as it could not contact the global catalog server, resulting in this behaviour.

Resolution:

  1. Open Central Administration and then click on Site Actions in top right corner, then site settings.
  2. Under users and permissions column, click on Site Collection Administrators.
  3. Removed my domain account from here and added the local Administrator account which I wanted to use for administering the local farm.
  4. Click OK and wait for the Shared Services to be provisioned automatically (SharePoint will periodically re-attempt a failed provisioning of SSP)