Introduction
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!
Snapshots
As you probably know, Microsoft Hyper-V includes some very useful and powerful snapshot abilities. These snapshots enable you to save the state of a domain controller at any point in time. Typically you would take these snapshots when things are working the way you want them to work. You can then restore the snapshot when things go sideways in your datacenter and you need a quick fix. Restoring the snapshot discards all changes that have been made since the time you took the snapshot and in operating systems prior to Windows Server 2012, it forced the domain controller to quarantine itself using a method called “USN rollback protection”.
What does USN Rollback Protection do? What happens is that once USN rollback protection is in place, the domain controller will no longer replicate again and therefore must be either manually demoted or manually restored non-authoritatively. Both are manual processes so not the best of all possible worlds for a private cloud, which lives or dies based on the ability to automate. Another problem with restoring the snapshots of the domain controllers is that in cases where the domain controller has sourced changes since the time the snapshot was taken, it can also lead to lingering objects in the Active Directory database.
Now with Windows Server 2012 you can get the help of the operating system so that it detects rollbacks that take place when you restore a snapshot. The virtualized domain controller will non-authoritatively synchronize all of the changes between a domain controller and its partners for AD DS and SYSVOL. This enables you to use snapshots without having to worry about bad things happening as you did in the past. You won’t have to deal with concerns over permanently breaking domain controllers and having to carry out manually forced demotions, metadata cleanup, and promoting them again. Unfortunately, these new features don’t solve all the problems with virtualized domain controllers and restoring snapshots.
For example, there are some other potential problems you might run into when restoring from snapshot – such as inconsistent databases for other technologies and applications. However, when it comes to restoring the domain controllers themselves and the Active Directory DS technologies, things are a lot better now with Windows Server 2012.
Cloning
What does Windows Server 2012 have to offer the Active Directory admin when it comes to cloning domain controllers? Windows Server 2012 implements cloning by adding more capabilities to the existing virtualization and domain controller promotion processes. Now, with Windows Server 2012 you can create a DcCloneConfig.xml file that contains the particular server configuration settings and copy it into the DSA Working Directory (the location where the Active Directory DS database resides which is C:\Windows\NTDS, by default) instead of creating sysprepped copies of workgroup computers and then manually promoting them (by using Server Manger or by using PowerShell).
You can now take the domain admin-authorized virtual machine offline and copy its drive or export the machine. Then you can create a new virtual machine – using the copied or exported computer – without any other changes and the server will automatically promote it as a unique domain controller, using the previous domain controller data as source media. Does it get any better than that?
Another approach you can take to clone your domain controllers is to mount an offline disk and add the XML files – which makes it possible to create the type of automation required for a true private cloud. Of course, you’ll have to use Windows PowerShell options included in Windows Server 2012 to achieve this, so it’s not going to be easy or fast; but the good news is that if you don’t need that kind of automation, the ability and process of cloning a DC is very easy and fun!
Troubleshooting
The process is also great for looking for potential problems such as name or IP address collisions on the network that could lead to sadness. For example, if there is duplication of a computer name or IP address the process will block promotion and the cloned domain controller will change over to DS Restore Mode to determine the source of the problem. However, you can configure things so that you don’t run into these kinds of problems and make cloning entirely automatic, which includes correct name generation and IP addressing by using DHCP.
Benefits of virtualizing domain controllers with Windows Server 2012
So what do you get when you virtualize a domain controller using Windows Server 2012? Here are a few:
- Deploy domain controllers in domains and forests faster than ever
- Use automation to dynamically scale domain controllers in an elastic private cloud fashion to meet network requirements for domain services
- Disaster Recovery and Business Continuity planning and execution is easier to carry out because all you need is a single surviving domain controller to enable you to quickly restore a datacenter at any location in the world
- Get test labs up that require Active Directory Domain Service running faster than ever
Role separation
A big change that you’re probably going to like in Windows Server 2012 is that there is a very separate and distinct role separation between domain administrators and virtualization administrators related to the cloning process. In the Windows Server 2012 Hyper-V model, cloud infrastructure admins cannot simply deploy replica domain controllers by just copying the virtual machines from one location to another. Instead, the domain admins need to authorize selected domain controllers for cloning before they can be copied and cloned. At this point, the virtualization infrastructure admins then deploy the authorized clones. This is critical from a security point of view because it ensures that non-domain admins cannot create new rogue domain controllers. Creating domain controllers needs to be limited to only domain admins in a secure deployment.
Of course, you must always be aware and cognizant that anyone that has permission to admin the virtualization infrastructure (cloud infrastructure) must be trusted, vetted and audited as a matter of course. There are many reasons for this, one of which is that they still have the power to create copies of domain controllers that can be used to perform an offline attack or be given or sold to malicious insiders or outsiders.
Safe restore
So you might be wondering: how does Windows Server 2012 safe restore of virtualized domain controllers work? The short story is that Windows Server 2012 virtualized domain controller safe restore resets the domain controller’s Invocation ID. After this reset takes place, the other domain controllers will not recognize the new Invocation ID and they will conclude that they have not already seen these USNs and accept the updates, allowing the directory to converge. This solves the convergence problem we mentioned earlier. In addition, the domain controller discards the now-duplicated local Relative Identifier (RID) pool and non-authoritatively restores the SYSVOL folder. This means that accidentally restoring a snapshot is no longer an unsafe operation on domain controllers.
