What’s the deal with Virtualization and Domain controllers?

  • Article

virtual_team1 

We live in a virtual world. We interact virtually, our servers are virtual, even our presence at meeting is in a large part virtual.  In fact….  I’m not really here…  Winking smile

as always, if you’re looking to explore the topics discussed here:

The virtual environment have provided very large amounts of value and benefits to all of us for the management of our IT environments.  However, in some part it has introduced potential disasters.

I’m taking about virtualized Domain controllers. How do you handle the domain controllers which control the domain used by your Hyper-V servers? How do you deal with snapshots and replication….

As you know if you apply a snapshot in any virtualization platform, you’re basically putting your domain in a time-machine and rolling it back.  Because AD depend upon a logical clock-based replication schemes. AD DS replication uses a monotonically increasing value assigned to transactions on each domain controller (known as a USN or Update Sequence Number). 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 and must be unique within the forest. AD DS replication uses InvocationID and USNs to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time and a USN is reused for an entirely different transaction, replication will not converge since other domain controllers will believe they have already received the updates associated with the re-used USN. Virtual machines make 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.

so Windows Server 2012 has addressed this by detecting snapshot restoration and non-authoritatively synchronizing the delta of changes for AD DS and SYSVOL, making domain controller virtualization safer. This relies on the hypervisor platform to expose an identifier called VM GenerationID to detect if a virtual machine has been rolled back in time. The design uses a hypervisor-agnostic mechanism for surfacing the VM GenerationID in the virtual machine.

Before completing any transaction, AD DS first reads the value of this identifier and compares it against the last value stored in the directory. A mismatch is interpreted as a ‘rollback’ and the domain controller employs AD DS safeguards new to Windows Server 2012 comprised of resetting the InvocationID and discarding the RID pool. From this point forward, all transactions are associated with the domain controller’s new InvocationID. Since other domain controllers do not recognize the new InvocationID, they will conclude that they have not already seen these USNs and will accept the updates identified by the new InvocationID and USNs allowing the directory to converge.

you can find out more about this here.

Virtualization has also introduced another problem.  A lack of patience.  It used to be days if not weeks before you could deploy a server. (I know! it sound like the dark ages of computing.)  Now, if we can’t get it deployed immediately , people (managers) get upset.  In comes another great improvement in Windows Server 2012.  The ability to clone a Domain Controller.

Here are some of the benefits of virtualized domain controller cloning

  • Administrators can now promote a single virtual domain controller per domain and rapidly deploy all additional replica virtual domain controllers through cloning.
  • Administrators no longer have to repeatedly deploy a sysprepped server image, promote the server to a domain controller and then complete additional configuration requirements for every replica domain controller.
  • Rapid deployment of additional domain controllers in a new domain
  • Quickly restore business continuity during disaster recovery by restoring AD DS capacity via rapid deployment of domain controllers using cloning
  • Optimize private cloud deployments by leveraging elastic provisioning of domain controllers to accommodate increased scale requirements
  • Rapid provisioning of test environments enabling deployment and testing of new features and capabilities before production rollout
  • Quickly meet increased capacity needs in branch offices by cloning existing domain controllers in branch offices

Of course there are some requirements for cloning a domain controller.

  • A Windows Server 2012 server with the Hyper-V server role installed
  • You must be a member of the Domain Admins group or have the equivalent permissions assigned to it
  • All Windows PowerShell commands used in the process must be run from an elevated command prompt

There is much more information about this here.

By the way, creating a clone will be part of the Step-by-Step series, so subscribe to this blog for further info.

I hope you found this informative, as always, do not hesitate to contact us if there are scenarios you would like us to research for you.

 

Cheers!

 

Signature

Pierre Roman, MCITP, ITIL | Technology Evangelist
Twitter | Facebook | LinkedIn