Trying to view timer jobs results in "the specified user or domain group was not found" after domain change

Question

Some time ago I changed the SP domain from OldDomain to NewDomain but now when trying to access some sites, such as 'CA -> Monitoring: Timer Jobs -> Review job definitions', I get this error:

The specified user or domain group was not found.

even though I'm logged in as a farm admin 'NewDomain\Admin' and everything else seems to be ok. From the error logs, it seems that SP is for some reason trying to look for 'OldDomain\Admin' account (which no longer exists) instead of 'NewDomain\Admin'.

I tried re-running configuration wizard but it would at the end throw the same error. I tried to manually fix the database as described here (and mentioned in this similar question: "The specified user or domain group was not found on SharePoint Server 2010") - no success, even after deleting records containing old account names.

I'm trying to see if changing service accounts will do any good, but when I click on "Configure service accounts" under Security, I get Access denied error, even though I'm a farm admin with full permissions! I have removed all references to 'OldDomain*' from Managed Accounts and also from Security/Users directly on the config database in SQL Server Management Studio. AD doesn't contain the old domain accounts anymore as well. Still, I keep getting the error when trying to view job definitions.

Here's the full error log after trying to view job definitions:

SPAce PrincipalName OldDomain\Admin cannot be resolved. This ACE will not be effective. System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.     
at System.Security.Principal.SecurityIdentifier.Translate(IdentityReferenceCollection sourceSids, Type targetType, Boolean forceSuccess)     
at System.Security.Principal.SecurityIdentifier.Translate(Type targetType)     
at Microsoft.SharePoint.Administration.SPAce`1.get_PrincipalName()   


The SPPersistedObject with Name User Profile Service Application ... failed to initialize with the following error: Microsoft.SharePoint.SPException: 
The specified user or domain group was not found. ---> System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.     
at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)     
at System.Security.Principal.NTAccount.Translate(Type targetType)     
at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(String encodedSuffix)     
--- End of inner exception stack trace ---     
at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(String encodedSuffix)     
at Microsoft.SharePoint.Utilities.SPUtility.GetFullUserKeyFromFullName(String fullName)     
at Microsoft.SharePoint.Administration.SPAce`1.GetBinaryId(UTF8Encoding encoding)     
at Microsoft.SharePoint.Administration.SPAce`1..ctor(String principalName, String displayName, Byte[] securityIdentifier)     
at Microsoft.SharePoint.Administration.SPAcl`1.Add(String principalName, String displayName, Byte[] securityIdentifier, T grantRightsMask, T denyRightsMask)     
at Microsoft.SharePoint.Administration.SPAcl`1..ctor(String persistedAcl)     
at Microsoft.SharePoint.Administration.SPIisWebServiceApplication.InitializeAcl()     
at Microsoft.SharePoint.Administration.SPPersistedObject.Initialize(ISPPersistedStoreProvider persistedStoreProvider, Guid id, Guid parentId, String name, SPObjectStatus status, Int64 version, XmlDocument state)  

What else could I try?

Answer 1

I managed to resolve it! Now, everything seems to be working fine. Here's how I did it, in case someone else encounters this. Mind that I did this in an isolated test environment and the approach is a bit raw, so use it at your own risk (ideally, make at least some kind of DB backup before you do it) - it worked for me. Note also that this procedure will result in an unsupported state as it alters the database directly.

First, I followed these instructions: http://techilatalk.com/remove-spmanagedaccount-not-working/ (this step alone didn't resolve the error for me, but it seems a good place to start).

Then, when all else failed, I executed an UPDATE on the config database that replaced all OldDomain\Admin values with NewDomain\Admin values in the [dbo].[Objects] table, xml column [Properties]. Here's how: first, open SQL Server Management Studio. On the SharePoint_Config database (or whatever it's named in your case), execute the following query:

UPDATE [SharePoint_Config].[dbo].[Objects] 
SET [Properties] = REPLACE( CAST( [Properties] as varchar(max) ), 'OldDomain\Admin', 'NewDomain\Admin')

This will replace old account names with the new ones. Note that in general, if you have multiple user accounts, you may need to replace values for all users, i.e. you'd replace 'OldDomain\' with 'NewDomain\', rather than limiting a query to a specific user.

Now make sure that the [Properties] xml column in [Objects] table doesn't have any more references to the old domain - the following query should return an empty result set:

SELECT Id,CAST([Properties] as xml)
From [SharePoint_Config].[dbo].[Objects]
WHERE Properties LIKE '%OldDomain\%'

If you don't get an empty result set, insepct the xml of the returned records and see if there are any more references to the old domain that need to be updated.

Do an iisreset after this, wait a minute or two and it should work (in my case this means that I can now view job definitions without getting an error + all other problems went away).

Answer 2

SharePoint does not support moving the server from one domain to another. Instead, build a new farm in the target domain and use a backup/restore method to move Service Application and Content Databases.

Answer 3

It's not supported to do SQL Updates on any of the SharePoint Databases. This leaves your farm in an unsupported state.