Tag Archives: Replication

So something that doesn’t seem to be getting much press is that Windows Server 2012 brings safe virtualization and protection from USN rollbacks. Yes, it does. All the docs say it, but Hyper-V 3.0 and PowerShell V3 get all the press.

Windows Server tried to detect USN rollbacks, but this error… which can kill a domain was really a real danger: and regularly occurred. The more common ways a USN rollback might not be detected are: a virtual hard disk may be selected on more than one machine or more commonly, a snapshot of a VM is restored and it has an USN that has increased past the last USN that the other domain controller has received.

So while the first scenario might lead to domain controllers not replicating changes… and make things unstable and unpredictable, and kill your forest; the second can be really bad. Lets just say bad. Best case is an Event ID 1988 in Event Viewer for a lingering object. Sometimes though you have corrupt data and wipe out the domain.

So, what mas my mantra again? Oh yeah. Let’s make the new modeus operendi: just say no to “blowing up” your Active Directory. So give Windows Server 2012 a spin and let’s hear some attempts to kill it.

An excerpt from Microsoft discusses the new feature. Don’t forget to follow the link and read the whole thing.

Excerpt from http://technet.microsoft.com/en-us/library/hh831734.aspx

“Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or Update Sequence Number) assigned to transactions on each domain controller. Each domain controller’s database instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN together serve as a unique identifier associated with every write-transaction performed on each domain controller and must be unique within the forest.

AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain controller’s awareness and a USN is reused for an entirely different transaction, replication will not converge because other domain controllers will believe they have already received the updates associated with the re-used USN under the context of that InvocationID.

For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication partner, which indicates that VDC2’s database has rolled back in time improperly.

A virtual machine (VM) makes it easy for hypervisor administrators to roll back a domain controller’s USNs (its logical clock) by, for example, applying a snapshot outside of the domain controller’s awareness. For more information about USN and USN rollback, including another illustration to demonstrate undetected instances of USN rollback, see USN and USN Rollback.

Beginning with Windows Server 2012, AD DS virtual domain controllers hosted on hypervisor platforms that expose an identifier called VM-Generation ID can detect and employ necessary safety measures to protect the AD DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. The VM-GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor that supports VM-GenerationID. This identifier can be sampled by services and applications running inside the virtual machine to detect if a virtual machine has been rolled back in time.”

Have you ever just been starring at your computer saying, “Come on already!” Or, “if you don’t hurry up, I am getting out a soldering iron and converting you into a toaster!” No? Are you lying to me? Am I just impatient? Well, if I am, I am not alone. However, experience has been kind enough (read: I am still alive) to teach me that sometimes, it just takes time.

In general, patience is hard learned in computer work. I remember coming up with the Starbucks rule. When creating VPN changes, make your changes and then go to Starbucks; when you get back it will be working. When it comes to Active Directory, it is actually worse. Patience isn’t needed just to get the things working: patience is required so that Active Directory isn’t damaged by troubleshooting.

You see, when doing Active Directory work, you sometimes need to slow down. Why? It all takes time. KCC, time synchronization and replication over however many links data has to go across. This is just how Active Directory works since it is a multi-master system. And before anyone gets any ideas… yes, we all want it to be a multi-master system and accept this as normal.

As a general rule, when doing a major Active Directory project, work at the pace of the slowest task. Let the changes matriculate. They need to. In fact, over time it appears that once everything is done and complete… give it a good twenty four hours and then double check it.

Twenty four hours? Am I insane? Nope.

Take the time and validate that the changes matriculated. Why? You see one of the biggest pains in Active Directory is when you don’t realize your environment has some KCC, replication or time errors… and the changes you think went through… didn’t. This does happen. So don’t rush it.

When you rush it, you make mistakes. Like not backing up every domain controller when doing a domain transitions or not documenting the changes you are making in a migration. Take the time that the job actually requires.

Oh, and since you’re now taking the time to do it right, how about we all try and remember to finish the job. Active Directory projects are left incomplete with epic proportions. Take the time, and finish it. Really finish it. Yes, even fill out sites and services. It is all important and makes it easier for those who come after you.

When working with Active Directory just take it methodically. Then make sure the replication is done. Rush and you may make a mistake and end up rebuilding your forest.