The case of the duplicate SID’s

SNAGHTML1ca684c

I encountered another interesting error during Exchange 2010 installation today. During the Organization Preparation I got the following error:

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

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 0

I 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:

check duplicate sid

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 gknetemann246

What 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
 ExchangeLegacyInterop

So 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:

image

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

Was once an enthusiastic PepperByte employee but is now working elsewhere. His blogs are still valuable to us and we hope to you too.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *