Resolving computer object replication conflicts

Today I had the opportunity to resolve a replication conflict on a computer object of one of our servers. Since it was quite a show I decided to share it with you all.

First some basic background information how AD handles objects and their replication. Objects in AD are uniquely identified by their distinguished name (DN). DN is formed by using a relative distinguished name (RDN, CN=computername) plus the names of container (OU=someOUname) and domain (DC=your,DC=domain,DC=com) that contain the object so the example DN is CN=computername,OU=someOUname,DC=your,DC=domain,DC=com. If the DN is required to be unique there cannot be two objects that share the same RDN in the same container, right?

Right. When ever a attribute is modified this modification is marked with a change stamp. The change stamp contains version number, last write time and originating server. When domain controllers receive conflicting updates DCs check change stamp and will accept the update with higher version number. If the version numbers are equal DCs examine the last write time and will accept the one with the more recent time stamp. Last thing to resolve which update is accepted if version number and time stamps are identical is the server database globally unique identifier (GUID). The change for coming from the higher GUID server will be accepted. When the DCs are added to the domain these GUIDs are assigned and the assignment is arbitrary.

But since AD supports multimaster directory object replication between domain controllers in the domain changing data at the same time (in the same replication interval) on different DCs can still result in having two objects with the same name (RDN) in the same container (RDN). This is most likely to happen in replication between different sites when the replication interval is 180 minutes by default or atleast the minimum of 15 minutes (unless tweaked from registry). How does AD cope with this?

When the RDN collision occurs DC will automatically change the relative distinguished name of the object with the lower GUID to a unique name. The object with higher GUID is kept with the original name. This event might be logged in the system event log with event ID 12292 or in directory service log with event id 1226. The unique name is formed by using the GUID of the object. The format for new RDN is <objectname>\0ACNF:<objectguid> where \0A is a reserved character representing a line termination character (Line Feed), CNF is the constant that indicates conflict and ObjectGUID a printable representation of the objectGuid attribute value. Our examples DN would then look like CN=computername\0ACNF:<objectguid>,OU=someOUname,DC=your,DC=domain,DC=com. But when you try to move that object in AD it tells you that you cannot move it because the attribute syntax specified to the directory service is invalid. That is caused by that reserved character which is not shown in RDN or name attributes but can be seen in DN attribute.

OK, now we know how these conflicts are born. Next we have to find out how to resolve them. If the renamed object is needed it can be renamed to somethinh different. However you cannot rename computer object using the Active Directory Users and Computers. One way is to manually delete AD objects and rename and rejoin computers to the domain:

1. First you should know or reset the local administrator password so that you can log in if something goes wrong and you cannot log in anymore with domain accounts.
2. Log in as admin, join the computer to a workgroup, do NOT restart the computer!
3. Delete conflicting AD objects and wait that deletion to replicate to all DCs in the domain.
4. Join the computer to domain and move the new AD object to OU where you want it to be located, do NOT restart the computer until you read further.
5. Now you have option to wait for replication of newly created (and moved) object in the domain
6. or just simply restart the computer. :)
7. Then verify that replication is working and evaluate your AD management procedures and processes. ;)

I played safe and waited for the replication to happen. Of course I could have manually triggered replication but I chose to wait since replication interval is set to 15 minutes in our environment.

The other way I know of and which I chose not to follow would be as described in KB 297083. Haven't tested it myself but I would image that it should still work on 2008 and 2008 R2 domains as well.

And now you want to check your own domain if it contains replication conflicts. You may wonder how can you identify those objects. You can find conflicting objects in your domain by running a dsquery looking for objects containing that \0ACNF: in objects name:

dsquery * forestroot -filter "(name=*\0ACNF:*)"

and then looking for the same DN without that CNF part for those objects that where not renamed.