Domain controllers are very different from non-domain controller computers on your network and that makes duplicating or cloning them somewhat problematic. Domain controllers present important security considerations and virtualizing DCs is something that must be done with care. Windows Server 2012 makes it much easier to deploy and manage secure virtualized domain controllers. In this article, we will discuss some of the issues involved.

Issues and solutions

One example of the issues you might encounter is when you have two domain controllers in the same forest with the same name, invocation ID, and security identifier; this will definitely not work. In all in the operating systems that are older than Windows Server 2012, for each virtualized domain controller you were required to go through the manual process of promoting the machine as a purpose built virtual machine on your network.

In Windows Server 2012, you are now provided the option to perform domain controller cloning. What this means is that you will no longer have to manually deploy a server image virtual machine and disk file and then go through the manual processes to promote the machine to a domain controller. With Windows Server 2012, the cloned domain controller will perform a number of actions that sysprep would perform and promotes the virtual machine with the existing local Active Directory DS data as installation media, taking advantage of administrator-provided settings like the machine name and IP addressing information. This significantly accelerates deployment of new domain controllers in production or test labs, simpler disaster recovery, and the ability to scale out in hosting and branch office scenarios.

Another major issue you might have run into if you have tried to virtualize domain controllers related to clock-based replication schemes is the potential problems you encounter with roll-back of domain controller virtual machines. Virtualization surfaces some special issues that are related to distributed multi-master workloads that depend upon logical clock-based replication schemes. Active Directory DS replication takes advantage of an incrementing transaction number that is assigned to each transaction on each domain controller. This is known as an Update Sequence Number or USN. In the scenario where a domain controller "rolls back" time after you apply a snapshot to fix some kind of problem, an Update Sequence Number may be used again in an entirely different transaction.

The result of this is that Active Directory DS replication cannot converge because other domain controllers believe they already received the update. If you have ever had this happen to you, you know the results aren’t very pretty!

--> Please see the rest of the article on the site :