I was recently asked to explain to a fellow SharePointeer how to dig a little deeper into an error message that occurred when an administrator was attempting to access Service Application from Central Administration:
The specified user or domain group was not found
On initial observation, is was not clear which account was causing the error, so I suggested we dissect things a little. All we need is an elevated Management Shell session and access to execute queries on the SharePoint Configuration database in SQL Server. Before proceeding though, be aware that accessing the databases is not supported so do this at your own risk. The actual target Service Application is not really relevant because the way SharePoint stores security information is the same so the process is the same for any Service Application.
- The first thing you’ll need is to verify the current Service Application configuration. To list all the Service Applications and their associated Service Accounts (or AccessRules), execute the following cmdlet. Make a note of the “AccessRules” against your target Service Application as you will need this later
Get-SPServiceApplication | ForEach-Object { $_.Id; Get-SPServiceApplicationSecurity –Identity $_.Id } | Format-List- Now grab the physical path for the target Service Application in IIS by locating it under the “SharePoint Web Services” container and clicking “Basic Settings” from the Action pane”. You will need the last directory in the path – for example if the full path is “D:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15WebServicesBdc”, we just want the “Bdc” part
- From SQL Management Studio, execute the following query replacing the value in the “where” block with the directory from the previous step
SELECT [Name], [Version], CAST([Properties] as xml) FROM [SharePoint_Config].[dbo].[Objects] with (nolock) WHERE [Name] LIKE ‘%Bdc%’
- From the results, locate the relevant Service Application and expand the row. You should see a “sFld” attribute with the name “m_SerializedAcl”. Make a note of the accounts defined in this attribute
- Using the results from the SQL query, match the entries to identify any inconsistency against the “AccessRules” from the first step. This will give you the problematic account that needs reverting or restoring against the Service Application to correct the issue
In the scenario that prompted this post, the Service Account that was associated with the Service Application was renamed, causing the Subject Alternative Name (SAN) to be stored as a literal string. I believe this behaviour could also occur if the associated Service Account were removed from Active Directory.
