I encountered another interesting error during Exchange 2010 installation today. During the Organization Preparation I got the following error:
The setup.log doesn’t give us much more detailed info:
[06-22-2011 11:16:29.0614] [2] [ERROR] Active Directory operation failed on dc001.zorg.local. This error is not retriable. Additional information: The requested object has a non-unique identifier and cannot be retrieved.
Active directory response: 0000219D: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0
[06-22-2011 11:16:29.0630] [2] [ERROR] The server cannot handle directory requests.
[06-22-2011 11:16:29.0630] [2] Ending processing initialize-ExchangeUniversalGroups
[06-22-2011 11:16:29.0630] [1] The following 1 error(s) occurred during task execution:
[06-22-2011 11:16:29.0630] [1] 0. ErrorRecord: Active Directory operation failed on dc001.zorg.local. This error is not retriable. Additional information: The requested object has a non-unique identifier and cannot be retrieved.
Active directory response: 0000219D: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0
[06-22-2011 11:16:29.0630] [1] 0. ErrorRecord: Microsoft.Exchange.Data.Directory.ADOperationException: Active Directory operation failed on dc001.zorg.local. This error is not retriable. Additional information: The requested object has a non-unique identifier and cannot be retrieved.
Active directory response: 0000219D: SvcErr: DSID-031A0FC0, problem 5003 (WILL_NOT_PERFORM), data 0I remembered from a Tweet by Helge Klein recently that the Active Directory schema has no mechanism for enforcing uniqueness of an attribute.
My first assumption was a duplicate sAMAccountName but I couldn’t find any evidence for that.
Then I checked for duplicate SID’s, you can do this via NTDSUtil:
NTDSUtil creates a log file in the current directory (dupsid.log) and indeed I was having duplicate SID’s:
The SAM database has encountered a duplicate SID. The SAM account names are:
Public Folder Management and khoogeveen
The SAM database has encountered a duplicate SID. The SAM account names are:
Recipient Management and azamboni
The SAM database has encountered a duplicate SID. The SAM account names are:
View-Only Organization Management and jresink
The SAM database has encountered a duplicate SID. The SAM account names are:
UM Management and bmelgers
The SAM database has encountered a duplicate SID. The SAM account names are:
Help Desk and hvanpareren
The SAM database has encountered a duplicate SID. The SAM account names are:
Records Management and gknetemann200
The SAM database has encountered a duplicate SID. The SAM account names are:
Discovery Management and gknetemann224
The SAM database has encountered a duplicate SID. The SAM account names are:
Server Management and gknetemann248
The SAM database has encountered a duplicate SID. The SAM account names are:
Delegated Setup and gknetemann222
The SAM database has encountered a duplicate SID. The SAM account names are:
Hygiene Management and gknetemann246What made this very interesting is that the names listed here like Public Folder Management and Recipient Management are all created during Exchange 2010 installation.
This behaviour is described in Prepare Active Directory and Domains in a little note:
To verify that this step completed successfully, make sure that there is a new OU in the root domain called Microsoft Exchange Security Groups. This OU should contain the following new Exchange USGs:
Exchange Security Groups OU:
Exchange Organization Management
Exchange Recipient Management
Exchange Server Management
Exchange View-Only Organization Management
Exchange Public Folder Management
Exchange UM Management
Exchange Hygiene Management
Exchange Records Management
Exchange Discovery Management
Exchange Delegated Setup
ExchangeLegacyInteropSo what happened?
I did a P2V of 2 existing domain controller to test an AD upgrade in a Sandbox. After the AD upgrade I kept the sandbox and decided to test Exchange installation as well.
I first created a P2V of DC002, the least important domain controller, and put in online in the sandbox to test the P2V process.
Because the DC002 had the RID Master FSMO role it was possible to allocate a block (the same block) of relative ID’s in both the sandbox and the production environment.
A couple of days later I did the P2V of the other domain controller and placed it online as well. And this is where the duplicate block became a problem.
Because I am in a sandbox I could take the easy solution which is use the cleanup duplicate sid command in NTDSUtil:
Warning: the cleanup duplicate sid command will delete BOTH objects having the same sid!
Sidenote: It seems that the problem with the otherWellKnownObjects attribute I described earlier was actually caused by the Exchange Setup as well!
My recommendations for P2V of Domain Controllers:
- P2V all Domain Controllers at the same time.
- If you cannot p2v all Domain Controllers at the same time, do not bring a copy online before you finished all P2V's.
- Make sure the RID Master is brought online LAST
