Hi, David here again. Having worked numerous lingering object cases, I find a common misunderstanding about Windows Server 2003 (or later) and its ability to automatically enforce Strict Replication Consistency. Strict Replication Consistency is a registry value that prevents destination domain controllers (DC) from replicating in lingering objects. Lingering objects are objects that have been deleted on one DC but replication failures prevent a partner DC learning of the deletion. The result is those deleted objects remain “live” on the replication partners. If the replication failure persists for longer than tombstone lifetime but is later corrected, the DC that failed to inbound replicate the deletions will continue to have “live”/lingering objects in its copy of the AD database. When one or more attributes are modified on these “live” objects, that object must replicate outbound. DCs that don’t have Strict Replication Consistency enforced will replicate in these formerly deleted objects, re-animating them.
Note: for the sake of readability, when I say “Windows Server 2003” in the document, I mean Windows Server 2003 or later. Windows Server 2008 and Windows Server 2008 R2 behave the same in this respect.
A Windows Server 2003 server can automatically configure Strict Replication Consistency during the domain controller promotion process certain conditions have to be true. There are some myths and badly worded documents out there that imply Windows Server 2003 DC’s always configure themselves for strict replication , so this blog post aims to set the record straight.
Forests originally created on Windows 2000 Server – but later upgraded to Windows Server 2003 require an additional step to automatically enable strict replication consistency on newly promoted domain controllers. While Windows Server 2003 DCs tend to quarantine themselves if they have not replicated for greater than Tombstone Lifetime, failure to implement this step will leave all newly promoted Windows Server 2003 DCs configured for Loose Replication Consistency; leaving them at risk of re-animating lingering objects from Windows 2000 replica DCs or Windows Server 2003 DCs that have had Allow Replication With Divergent and Corrupt Partner set but have not been cleaned of lingering objects first.
If you want new domain controllers added to the forest to have strict replication consistency automatically enabled, you can import the Operational GUID cited below to the Configuration directory partition using Ldifde.exe. The presence of this object in the Configuration partition causes dcpromo.exe to enable Strict Replication Consistency on any Windows Server 2003 domain controller that is promoted into the forest.
1. Start notepad.exe and copy in the sample LDF text below. Edit both lines containing DC=<domain>,DC=<com> to match your forest root domain.
Example: If your forest root domain were contoso.com the DN would be DC=contoso,DC=com
2. Once the DN has been modified correctly save the file as StrictRepl.ldf.
3. Open a command prompt with Enterprise Administrator credentials and issue this command:
Ldifde.exe -i -f StrictRepl.ldf
It’s important to note that just adding this object to the CN=Operations container will not cause existing Windows Server 2003 DCs to configure themselves for Strict Replication Consistency. For existing DCs you must add the Strict Replication Consistency registry value and set it to 1 before they will enforce strict replication. The good news is this can be done remotely using repadmin.exe from a command prompt opened with Enterprise Admin credentials. The command to run is:
repadmin.exe /regkey <dcname> +strict
If you want to make certain this is configured on all DCs in the forest you can pass a wildcard to repadmin.exe like this,:
repadmin.exe /regkey * +strict
If you are running this against all DCs in the forest you should pipe this out to a text file and verify all DCs have been contacted and the value has been set correctly.
Warning: Before you implement this change forest-wide it is important to understand that all replication between the source DC and the destination DC will stop for any partition that has a lingering object in it. Replication will only be restored once the lingering object is removed. This could cause forest-wide authentication issues until replication is restored.
For more information about this operational GUID see Technet.
Hopefully this will clear up the common misconception that all Windows Server 2003 domain controllers will always enforce strict replication consistency and will lead to closer examination of current configurations before lingering objects start causing issues.
David “buster” Everett