Domain Controller Virtualization Options
One of the most frequent questions on virtualization forums that deal with server deployments is the question of how should one deploy their Active Directory domain controllers. Should they be deployed on stand-alone separate servers, should they be kept on separate physical servers, or should they be run inside virtual machines that are hosted on servers that are part of the same domain? Why do people struggle to find a solution to this question? Why is it a dilemma in the first place? Shouldn’t domain controllers be just placed on regular physical servers, just like you used to do before the advent of virtualization products?
A few days ago I bumped on a great blog entry written by Ben Armstrong – the Virtual PC Guy. Let me talk a bit about the options listed in his blog entry.
So, what’s the basic problem with domain controllers? Well, to make it short, it’s basically the “What comes first? The egg or the hen?” dilemma. If you virtualize all of your servers, including the domain controllers, how do you handle the domain controllers which control the domain used by your Hyper-V servers? What happens if a host server that hosts a virtual machine running a DC fails? What will happen if the VM itself fails? What will assure the continuity of your Active Directory in cases of a disaster? What’s the best approach to virtualizing DCs?
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Basically, there are a few options that you can consider:
- Keep the root domain controller on physical hardware – By keeping the root DC on separate physical hardware you can avoid many potential problems. However you also miss some of the major benefits of virtualization for the server running the domain controller, which are better hardware utilization, hardware mobility, easier backup and so on. Naturally, you will need to treat that DC as you did up to a few years ago, when ALL the servers used to be separate physical servers.
- Keep the Hyper-V servers out of the domain, i.e. leave it in a workgroup, and virtualize the DCs – This will mostly work for small deployments where you can consider leaving the Hyper-V servers as part of a workgroup and then running all domain controllers inside virtual machines, just like any other VM. There are 2 problems in this approach: First, you lose the security advantages of running Hyper-V servers in a domain environment; and second, when more than a couple of Hyper-V servers need to be managed in this manner, it is hard to have multiple administrators in such an environment. Another drawback of this approach is that you will not be able to use all the functionality of SCVMM 2008.
- Establish a separate (physical) domain for Hyper-V servers – This approach is a compromise between the first two approaches. Here you maintain a small domain environment for your Hyper-V servers using a physical server acting as a DC for this domain. Then, running as virtual machines, you deploy the DCs for the main/production domain. The advantage to this approach is that you get all the benefits of having your Hyper-V servers in a domain, but your primary domain environment benefits from being virtualized (better hardware utilization, hardware mobility, easier backup and so on). The problem with this approach is that you still have one or more underutilized server (the DCs for the Hyper-V domain).
- Run the domain controllers inside Hyper-V – You can take a fourth approach, where you run your domain controllers in virtual machines, and then join the parent Hyper-V environment to the same domain (i.e. the one that is managed by these virtualized DCs). This setup sounds a bit problematic, but it can be accomplished with some careful planning.
In any case, since domain controllers are the most important machines in a Microsoft-based environment, and having failed DCs hanging out there can have adverse effects on many network services, devices and applications, you should really consider carefully planning your setup, just like you would for physical servers. For example, here are some important considerations:
- If you virtualize your DCs, you should configure the VMs running the domain controllers to always start when the parent starts, no matter what their running state was (this is configurable in the virtual machine settings).
- If you virtualize your DCs, configure any other virtual machines to start automatically but with a delayed start time to allow the domain controllers to start up prior to the other virtual machines.
- If you virtualize your DCs, you should configure the domain controller virtual machines to shutdown (and not save state) if the physical computer is shutdown.
- Plan and test managing of the Hyper-V environment in case all the virtual domain controllers fails to start.
- You should NEVER use saved state/snapshots with domain controllers, unless there’s only one DC.
- Just like in physical servers, ALWAYS have more than one domain controller.
- Spread the domain controllers across separate physical machines. There’s no point running all DCs on the same Hyper-V host server if it fails for some reason.
- Disable time synchronization for the domain controllers. They are supposed to be the source of time in the domain, and you don’t want them to take the time from their host, which then takes the time from the domain controller.
- Make sure you plan, text and implement a good and working System State backup for at least some of your DCs. This is mostly true for Global Catalogs and FSMO Role holders.
- If you have more than one Hyper-V server hosting virtual machines running domain controller roles, you might want to plan a method of quickly transferring these VMs between the physical Hyper-V hosts. This can be accomplished by using Power Shell scripts or VM management tools such as SCVMM 2008.
Hopefully, this made sense and got you all thinking.