A lot of SharePoint Administrators will be well aware of this message in SharePoint 2010 but for those that are not, this post is for you.
While attempting to access any Service Application the following error is returned:
The specified user or domain group was not found
Everytime a security principal is stored in SharePoint 2010, the information is held as a literal string with the Subject Alternative Name. Removing or renaming these accounts associated with a Service Application will result that service to fail.
There are a few steps to correct this problem:
- Firstly, we should verify the issue. Open an elevated Management Shell and execute the following cmdlet
- Now open IIS and have a look in the SharePoint Web Services site, make a note of all those lovely Service Application GUIDs
- Using the Management Shell from earlier, execute the following cmdlet to identify the correct Service Account associated with the Service Application
Get-SPServiceApplicationSecurity [Pop a GUID here]
- Once the correct Service Application has been identified, head back to IIS and select the relevant virtual directory and click Basic Settings. Have a look at the Path value, for example
C:Program FilesMicrosoft Office Servers14.0WebServicesProfile
- Open SQL Management Studio and open a new query against the SharePoint_Config database. Execute the following, replacing the LIKE value with whatever Service Application you are targetting:
SELECT [Name], [Version], CAST([Properties] as xml)
From [SharePoint_Config].[dbo].[Objects] with (nolock)
Where [Name] LIKE '%Profile%'
- In the result window, have a look for the correct Service Application name then open the XML result
- Find the key that has a value of “SerializedAcl”
- Use the XML output below as an example and you will see two accounts are identified; DOMsa_sps_farm and DOMsa_sps_serviceapp. If any of these accounts have been modified the changes will need to be reverted or restored. Once restored the effected service will become operational
<sFld type="String" name="m_SerializedAcl">
<ace identityName="i:0#.w|DOMsa_sps_farm" displayName="0#.w|DOMsa_sps_farm" sid="" allowRights="18446744073709551615" denyRights="0" />
<ace identityName="i:0#.w|DOMsa_sps_serviceapp" displayName="0#.w|DOMsa_sps_serviceapp" sid="" allowRights="18446744073709551615" denyRights="0" />
- Once the services are operational, head over to Central Administration and manage the accounts assigned to this service from Application Management > Manage Service Application. Highlight the offending Service Application and select Manage from the ribbon. Simply change the security for the Service Application
I can’t recommend to dive straight in and do this on a Production environment and in any case, you should always seek guidance from Microsoft when cracking open the SQL databases directly.
This fix was tested and working in the environment it was intended to be used in. This information is provided “as is” without warranty, be it expressed or implied.