A while ago, after a failed attempt to P2V a domain controller an environment I was working with was getting the following error messages when trying to delete and create AD objects. Before we delve in, let me explain why the P2V of the DC was even done. The VMware KB outlining the best practices in regards to virtualizing domain controllers, clearly states and I quote “VMware does not recommend converting a Windows NT domain controller if at all possible.” The reason that the attempt to virtualize the DC without standing up a fresh VM was legacy unsupported unwarrantied SSO and Biometric software that was installed and could not be modified or reinstalled on a new server. During the P2V the server was rolled back to the physical DC after the virtual one came up, because the SSO software wasn’t functioning after the migration. Let’s look at the error messages that presented afterwards. Error messages when creating user objects:
Windows cannot set the password for <Objectname> because: The requested object has a non-unique identifier and cannot be retrieved.
Windows cannot remove the newly created object automatically. Remove it manually or contact your system administrator
Event ID 16646 The computed account identifier is not valid because it is out of the range of the current account-identifier pool belonging to this domain controller. The computed RID value is %1. Try invalidating the account identifier pool owned by this domain controller. This will make the domain controller acquire a fresh account identifier pool.
The first thing I ran was a dcdiag /V, and headed to the section highlighting the RIDmanager test. RIDs are variable length numbers that are assigned to new objects at the time of creation which helps ensure that a unique SID is created for each new object. The RID Master role is responsible for doling out pools of 500 unique RIDs to domain controllers, so that they each can create objects with unique SIDs. RID pools are distributed by the RID Master, which is one of the FSMO (Flexible Single Master Operations) roles.
Here is a sample output of of the RidManager test when running dcdiag /V:
Starting test: RidManager
* Available RID Pool for the Domain is 61103 to 1073741823
* dc1.contoso.com is the RID Master
* DsBind with RID Master was successful
* rIDAllocationPool is 51103 to 51602
* rIDPreviousAllocationPool is 51103 to 51602
* rIDNextRID: 51103
……………………. DC1 passed test RidManager
The bolded underlined sections show which pool is allocated, which pool was previously allocated. At first glance with the diagnostics, it appeared that all the RID pools were properly assigned unique pools of 500. Examining the event logs and finding the event ID 16646 SAMMSG_INVALID_RID was the give away. This was caused by what is called USN rollback, which microsoft has a great article on called “How to detect and recover from USN rollback“. One of the potential root causes is you guessed it, reverting to an old snapshot of a DC.
We ended up fixing the problem by running the vbscript iRIDPool.vbs included in this technet article on each of the affected DCs. The script invalidates the RID pool currently assigned to the DC and forces it to get a new one the next time an object needs to be created. Once the RID pools were invalidated, we attempted to create a new user from each of the DCs. The first create attempt failed and forced the DC to get a new RID pool. As a result, the second attempt was successful. Also, subsequent dcdiags revealed that the pools had been updated and were now using assigning from new RID pools.
The moral of the story is don’t P2V domain controllers, but if there is no way around it pay very close attention to VMware’s and Microsoft’s recommendations for the process.
elgwhoppo's vNotebook 
Thank you. This was a life saver.