Active Directory Insights (Part 7) – More on using virtual domain controllers

If you would like to read the other parts in this article series please go to:

• Active Directory Insights (Part 1): Configuring DNS on domain controllers
• Active Directory Insights (Part 2): Digging into Trusts
• Active Directory Insights (Part 3): Re-examining read-only domain controllers
• Active Directory Insights (Part 4): More on read-only domain controllers
• Active Directory Insights (Part 5) – Domain controller hardware sizing
• Active Directory Insights (Part 6) – Domain controllers and NIC teaming
• Active Directory Insights (Part 8) – Virtual domain controllers and disaster recovery
• Active Directory Insights (Part 9) – Automating user account provisioning
• Active Directory Insights (Part 10) – DHCP and domain controllers
• Active Directory Insights (Part 11) – sIDHistory
• Active Directory Insights (Part 12) – MaxTokenSize
• Active Directory Insights (Part 13) – Digging into the Global Catalog
• Active Directory Insights (Part 14) – More about the Global Catalog

Introduction

In the previous article in this series we looked at what having a single point of failure can mean in an environment where all of your domain controllers are virtualized. This article looks at some other considerations when virtualizing Windows Server 2012 domain controllers and whether it’s still important to have at least one physical domain controller present in your environment. Note that unless otherwise indicated the recommendations in this article apply to both Windows Server 2012 and Windows Server 2012 R2.

Revisiting the issue of hardware/software diversity

In the previous issue of this series we described how ensuring diversity for both your system hardware (e.g. use servers of different types/models and/or different vendors) and virtualization software (e.g. combine Hyper-V with VMware or another virtualization platform) can help prevent a single point of failure from happening with your Active Directory infrastructure. But there’s another way such risks can be mitigated and this is described in the TechNet article Running Domain Controllers in Hyper-V which says the following:

“Maintain physical domain controllers in each of your domains. This mitigates the risk of a virtualization platform malfunction that affects all host systems that use that platform.”

So the tried-and-true approach of having one physical domain controller per domain while the others are virtualized may still often be the best approach to mitigating single-point-of-failure risk for your Active Directory infrastructure. That’s because this approach involves less management overhead than deploying and managing two separate virtualization infrastructures for your organization.

But while having a physical domain controller for each domain is a good idea, there’s an alternative you might explore which is described in the next section although the approach described below doesn’t entirely mitigate the risk of what could happen if your go-to virtualization platform should be compromised.

Employ at least one dedicated physical host machine

One Microsoft consultant I’ve talked to who has helped several large enterprises virtualize their environments recommends that while it’s possible to virtualize all of your Windows Server 2012 domain controllers, if you decide to do so you should make sure you have at least one dedicated virtualization host whose only purpose is to host a virtual domain controller using Hyper-V. In other words, the physical host has only one server role installed (Hyper-V) and hosts only a single virtual machine (a virtual domain controller).

The main reason for doing this is that it allows you to eliminate any possible dependency between the domain controller running on this dedicated host and your datacenter cluster. Although this is not as critical an issue with Windows Server 2012 as it was with clustering on earlier versions of Windows Server (see KB888794 for details) it allows you to simplify the configuration of your datacenter cluster. But there’s another reason for following this approach and this is explained in the next section.

Hardware-independent disaster recovery

An important reason for virtualizing your domain controllers is that it can greatly simplify and speed your organization’s recovery after a disaster. This is because rebuilding a virtual machine is simpler than rebuilding a physical server, the reason being that you don’t need to worry about making sure you have the latest device drivers for the server. A physical server usually requires vendor-specific drivers in order for its motherboard, storage, network adapter and other hardware components to function properly. A virtual machine however uses only a small set of standardized virtual device drivers.

So for example, let’s say you have physical domain controllers all running on a certain brand of Dell system hardware. A disaster then happens and all your physical domain controllers go up in smoke. Fortunately you have full backups of some of them (you need full backups because system state backups can’t be restored to a different instance of the underlying operating sytsem) but unfortunately you don’t have any spare system hardware of the type that was destroyed. So you try restoring one of your backups to a spare HP server you have laying around, but after performing the restore you find that your new physical domain controller fails to boot properly, the problem being that the Dell device drivers in your full backup won’t work with HP system hardware. If you have the necessary Dell drivers available you may be able to install them and get your new physical domain controller working, but needing different storage drivers such as RAID controller drivers can complicate things a lot.

Now let’s change the scenario and imagine that all of your domain controllers are virtualized with each one running on a different Hyper-V host. A disaster occurs and all your virtualization hosts go up in smoke. But you have full backups of some of them (and you made these full backups using good old Windows Server Backup) and you have a spare HP box sitting around so you install Windows Server 2012 R2 on the box, add the Hyper-V role, create a new virtual machine on the box and restore one of your backups onto the virtual machine to re-create one of your virtual domain controllers. Voila, you have your Active Directory infrastructure up and running again in almost no time at all. The detailed steps for recovering a virtual domain controller from its full backup are as follows:

1. Either use the existing virtual machine (if you have a copy of it) or create a new virtual machine.
2. If you create a new virtual machine, make sure it has the same number of disks as the original (backed up) virtual machine and that the disks in your new virtual machine are at least as big in size as the ones in your original virtual machine.
3. Use your Windows Server installation media to start your new virtual machine into the Windows Pre-installation Environment (WinPE).
4. Run Windows Server Backup to restore the virtual domain controller from the full backup you have of your original virtual machine.
5. The result will be an exact duplicate of the original virtual domain controller that was previously backed up.

What all this illustrates is that virtualizing domain controllers can enhance the continuity of your business by allowing you to recover more easily and quickly in the event of a disaster happening.

On whether your virtualization hosts should be domain-joined

Let’s say Contoso Ltd. plans on virtualizing all of its Windows Server 2012 domain controllers. You’ll be using diverse hardware for your Hyper-V host machines, and each virtual domain controller will be running on a dedicated host. Question: should you domain-join those hosts to the contoso.com domain? Or should you leave them as standalone hosts?

It’s a difficult question to answer as it seems like a chicken-and-egg scenario in terms of whether you may have any problems booting the hosts should your Active Directory go down. This article by Altaro, a well-respected vendor of Hyper-V backup solutions, suggest that the chicken-and-egg story is really just a myth and in reality isn’t a problem. But the reality is that it’s a good idea if at least one of the machines hosting your domain controllers can boot without any external requirements such as being able to successfully authenticate against Active Directory.

So it might be a good idea if you don’t join your virtualization hosts to your domain (i.e. to Active Directory which is being hosted in virtual machines on these hosts). Unfortunately if you take this approach then you add some management overhead since it’s messier to manage multiple machines in a workgroup than when they are domain-joined. Basically each organization will have to evaluate the risks and benefits of this issue before deciding which to choose.

What else can go wrong?

Lots, unfortunately. When we try and envisage what can go wrong during a disaster, we may come up with a list of 10 things that can go wrong. Then a real disaster happens and we find out there are really 20 things that can go wrong! The real world is always more complex than our imagination.

Should you host virtual domain controllers on blade servers that utilize Storage Area Network (SAN) as their storage? I heard about one case where the SAN admin applied a firmware update to their SAN and it reset everything to the defaults and all the virtual domain controllers stopped working. This was especially a problem because the SAN management software apparently needed Active Directory to function properly.

Should you have all of your domain controllers inside your datacenter for greater security? Sure, but then an electrician comes along and does some so-called “routine maintenance” that kills the power to the rack of servers hosting your virtual domain controllers.

Should you depend on your virtualization vendor to always get it right? I’ve heard of several enterprises that were hit by KB2853952 and there’s no guarantee that something like this might not happen again in the future.

And I’m sure you readers out there can think up (or remember) several other things that can go wrong.

Still got questions about Active Directory?

If you have any questions about domain controller hardware planning, the best place to ask them is the Active Directory Domain Services forum on TechNet. If you don’t get help that you need there, you can try sending your question to [email protected] so we can publish it in the Ask Our Readers section of our newsletter and see whether any of the almost 100,000 IT pro subscribers of our newsletter have any suggestions concerning your problem.

If you would like to read the other parts in this article series please go to:

• Active Directory Insights (Part 1): Configuring DNS on domain controllers
• Active Directory Insights (Part 2): Digging into Trusts
• Active Directory Insights (Part 3): Re-examining read-only domain controllers
• Active Directory Insights (Part 4): More on read-only domain controllers
• Active Directory Insights (Part 5) – Domain controller hardware sizing
• Active Directory Insights (Part 6) – Domain controllers and NIC teaming
• Active Directory Insights (Part 8) – Virtual domain controllers and disaster recovery
• Active Directory Insights (Part 9) – Automating user account provisioning
• Active Directory Insights (Part 10) – DHCP and domain controllers
• Active Directory Insights (Part 11) – sIDHistory
• Active Directory Insights (Part 12) – MaxTokenSize
• Active Directory Insights (Part 13) – Digging into the Global Catalog
• Active Directory Insights (Part 14) – More about the Global Catalog