In Part 1 on DC health, I described the symptoms of a DC that has fallen ill, preventing it from replicating with its partner DCs.
So how do you nurse a sick DC back to health? Triage your actions depending on the symptoms.
Symptom: Schema Version Mismatch
As I stated in the previous article, this may not necessarily be a symptom of illness but the normal process of DCs making sure that they have the latest copy of the AD building code (schema) before replicating from a partner DC. In other words this is a normal behavior that occurs when the schema is updated and it takes time to replicate the schema changes throughout the AD Forest. The only action required is to wait for a normal replication cycle to take place or if you are not the patient sort, force AD replication to occur.
To find out the Schema version of the Forest, use either ADSIEDIT.MSC or DSQUERY from the Schema Master DC.
1. Using "ADSIEdit.msc " or/and "LDP.exe" tools:
Navigate to: "CN=Schema,CN=Configuration,DC=domain,DC=local" and review the current "objectVersion" attribute.
2. Using "DSQuery" command line:
The following is a list of the schema versions broken down by operating system release but all DCs in the same forest, regardless of OS, should be at the same schema level.
13 -> Windows 2000 Server
30 -> Windows Server 2003 RTM, Windows 2003 SP1, Windows 2003 SP2
31 -> Windows Server 2003 R2
44 -> Windows Server 2008 RTM
47 -> Windows Server 2008 R2
Symptom: Lingering Objects
You have basically two options when a DC comes down with a case of lingering objects: either remove the lingering objects or allow the lingering objects to “re-replicate” to the other domain controllers. Which action you take depends on a registry value “Strict Replication Consistency” that is set on each DC.
Think of “Strict Replication Consistency” as a country club restaurant where you would like to take your family for brunch on Sunday. When you call the club restaurant to make a reservation, the Maître D will ask for your name. If the club has strict rules for who is allowed to brunch there and you are not already on the club membership list, you will be re-directed to the nearest Waffle House. If the club has loose rules, and allows anyone to eat at the club restaurant, then your name will be added to the reservation list and you will be welcomed. Similarly a DC either takes a strict or loose stance against allowing lingering objects (non-club members) to replicate to it.
Windows 2000 DCs up until SP4 were always loose and crazy guys, never taking a snob approach when detecting a lingering object. They had a big heart and let anyone in the doors.
Windows 2003 DCs and later are the snobs of the family where strict replication consistency is enabled by default and if a lingering object is detected, they will refuse to replicate it.
Now, being a snob can be beneficial at times. In the case of lingering objects you are preventing objects that have been purposely deleted from coming back. Wouldn’t you feel a little irked if you kicked a member out of your country club because they couldn’t play nice but then you have to sit next to the guy at Sunday brunch because of loose club restaurant rules?
Imagine now that your predecessor was a bad boy admin and was fired and escorted from the building and their AD user object deleted. You probably don’t want to reintroduce the bad admin user account back into AD where they could logon and wreak havoc. Strict replication rules do have their place under the sun.
Enforcing strict replication consistency is the default and the only time you would want to disable it is to purposely reintroduce lingering objects back in the directory like reinstating a club member you previously booted out. In most circumstances, lingering objects should be removed as they were intentionally deleted for a reason.
If you go against your better judgment and want to turn of Strict Replication Consistency, you can do so with REPADMIN.EXE.
As you can see in the following graphic, you can enable or disable strict consistency on all DCs at the same time.
Before you decide on your next action step, you should first determine why lingering objects are present to begin with. The two primary reasons lingering objects show up are because a DC was restored using an unsupported method (i.e. a virtual machine snapshot causing USN rollback) or the DC failed to replicate for longer than Tombstone Lifetime (TSL). The latter is not so bad, as the DC like Rip Van Winkle is stuck in a time warp that is going to require some “reeducating” while the former is a much more serious problem that involves “zapping” the DC with a “Men in Black” neuralizer.
If it is a TSL issue and you need to erase from the Van Winkle DC, knowledge of objects long since deceased, you can remove the lingering objects with either REPADMIN.EXE or REPLDIAG.EXE.
REPLDIAG.EXE is the preferred tool as it can clean all Naming Contexts (NCs) from all DCs with one command REPLDIAG /RemoveLingeringObjects. You can download REPLDIAG.EXE from Codeplex at http://activedirectoryutils.codeplex.com/releases/view/18287
If using Repadmin.exe:
1. First find the GUID of the DC with the known good replica with REPADMIN /SHOWREPL DCname.
a. So if DC1 has the good replica:
2. Then run Repadmin /removelingeringobjects DcNameThatMayHaveLingeringObjects GUIDofDCthatHasAKnownGoodReplica DomainNamingContext
3. Check the Directory Service log of the DC that may have the lingering objects for events 1937 and 1939 to see what was removed.
4. Repeat for each NC (Schema, Configuration, Domain, etc.)
After removing the lingering objects, you will need to restart replication by setting the following registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Create or modify if exists: Allow Replication With Divergent and Corrupt Partner
DWORD: 1
Once replication has successfully occurred, then set the same value to 0.
If the lingering objects are present because of USN rollback, you should take the far more drastic approach of demoting the DC that was improperly restored and promoting it back into the domain from scratch. Just point your neuralizer at it and administer the MIB eye exam ala DCPROMO.
Keep in mind however, that you will have to forcibly remove the DC as a normal demotion will fail (see graphic below) since the other DCs refuse to replicate from it. DCPROMO /FORCEREMOVAL will do the job.
Post Op Evaluation
I hope you have learned some DC first aid techniques that will nurse your DCs to their rosy- cheek healthy selves and back in full replication shape. While you are at it, proactively monitor your DCs more closely so that the ailments don’t come back.
No comments:
Post a Comment