Virtualize Active Directory? Is this madness? No, this is virtualization in the new age.
If there is one system in a Microsoft shop that could potentially cause the most damage for an enterprise if improperly managed, it would be Active Directory. I think this is one reason why there is so much resistance to virtualizing this very important piece of the infrastructure. But with the need to consolidate and cut costs, resistance is futile! Great care and research must be taken before even considering this for your enterprise. Those who do not truly understand virtualization and are only using virtualization in test environments or those whom work with VMware Workstation give an instant "NO" to the thought of virtualizing Active Directory. But this is a new age and admins need to consider the benefits of enterprise virtualization. I found it funny that Coach Culbertson in the Train Signal Windows 2008 R2 videos said "it is not considered best practice to virtualize AD, it is one of the most busy boxes on your network" and that he was only using it in HyperV for ease of use. Just because a server has a high workload means that I should not virtualize it? Rubbish!
Before I wrote this post I dove through numerous white papers, books and training videos. I used all of these resources in the past when defending the case to virtualize AD, even in production environments. I have not however virtualized AD in production environments using HyperV. This post contains my thoughts and strategies from pervious experiences in virtualizing AD.
The first thing you should ask yourself when considering virtualization of such a highly visible tier 1 app (along with any tier 1 app), is it supported? In the case of AD, yes it is according to KB 888794. But check out the fine print.
Let's first talk about the myths and scare tactics I hear most often when bringing up this subject.
1. Microsoft will require you to reproduce problems from a virtualized server on a physical server. This is actually a fact. But I cannot see calling Microsoft support and them just walking away from your issue just because your AD server is virtualized. If you have built your environment correctly and within best practice that works for your infrastructure, then this should not be a concern. If I call Microsoft support because I'm having a problem with DNS, they are not going to toss me in the ditch because my server is virtualized.
2. Virtualization cannot handle the work load of an Active Directory server. This is a myth and scare tactic. If your host server that contains your AD VM is over taxed on resources, of course you will see performance problems. Also check to see if maybe the problem existed in the physical environment. Remember, just because you virtualize something does not mean you will see a performance increase. Check to make sure your AD environment is properly designed, a poorly designed AD structure will not improve just because you virtualize it.
3. Virtualizing AD creates a security risk. This is a myth and scare tactic. The risks in the physical world are the same as the virtual world.
4. Our company says that Active Directory must be on physical hardware. 90% of the time, this turns out to be a scare tactic. When was this policy written (if it truly exists), when someone in 2004 tried a POC of AD on VM workstation or GSX server with an over taxed Windows XP desktop? I'm sure those tests went well.
5. Putting all your eggs in one basket spells disaster for the environment. This is a scare tactic, but a poorly designed infrastructure would spell disaster. If I'm running 16 AD VM's all on a 2 node cluster using a unstable storage strategy, I better have a resume ready to move on to the next job. But, if you've split out AD VM's across multiple clusters or larger clusters with good storage architecture on the back end, you may just receive employee of the month.
6. Active Directory is not a good candidate for virtualization because of time sync issues. This is a known issue and you should leave the forest root domain PDC FSMO role as a physical server. The problem most get into with this situation is synchronizing the AD VM with VMware Tools. You see, VMware Tools is designed to "catch up" with the correct time of the hosts system clock, there is no "slow down". So if the system clock is fast, your VM will not "slow down" to the proper time. If the PDC roles is virtualized, you must consider these three options to configure your time sync.
- Configure Group Policy and WMI Filtering for the Windows Time Service. This is my favorite because the GPO will apply to the correct server every time.
- Use VMware Tools for time synchronization, but configure the host servers to sync with a stratum-1 NTP source.
- Modify the Windows time service on the PDC emulator.
How about some Pro's and Con's?
1. VMware HA. This is a automatic restart of the VM on to another host server in a cluster. What happens in the physical world if one of my AD servers with a vital FSMO role goes down? It will stay down until someone physically goes out to the data center or some comes into work on the weekend to work on that box. Now, if the OS in the VM is corrupt, HA buys you nothing. Wouldn't it be nice to not have to worry about failures while your relaxing on the weekends?
2. VMware FT. This allows the server to run in lockstep on another host with practically ZERO downtime. You can use this only if you AD VM is running with 1 CPU. I have not used this for an AD VM yet because all of the AD servers I have built have at least 2CPU's. I don't think that a global catalog server with 1 CPU would be that critical to run in VMware FT, but it all depends on your infrastructure.
3. VMware DRS. Worried about your AD VM running out of resources on a host server while it is grouped together with other VM’s? VMware Distributed Resource Scheduling can move your AD server over to another host with available resources. This is more of a balancing act for all VM’s in a cluster.
1. I cannot think of any Cons. The only Cons that would exist would be due to an improperly designed architecture.
There is no “cookie-cutter” way to just flop out AD VM’s into your infrastructure. Just follow these highlights to help build out your virtualized AD infrastructure.
· Consider your disk layouts for your AD servers. One of the nightmare scenarios for an AD VM is to be rolled back to an old snapshot, which would cause all types of problems. Consider using independent persistent disks for your logs and AD database drives. These types of drives are not affected by snapshots. But, consider your backup strategy also! If you are using a snapshot based backup system like EMC’s Avamar, you may be out of luck for those drives. But then again, who in their right mind is going restore those drives from previous backups! That is not the proper way to restore AD. Make sure to review Microsoft’s backup and recovery guide!
· Make sure to review time synchronization methods for which would best fit your environment.
· NEVER EVER roll back an AD VM to an old snapshot!! It is alright to snapshot an AD VM for backup purposes (like using a snapshot technology based backup tool). But, if you mention to Microsoft during a support call that you snapshotted an AD VM, they will not show you very much love.
· Create roles in Virtual Center so that only authorized technicians can do VM level functions to your Active Directory servers. You don't want someone accidentally deleting your AD servers!
· Create VM restart priorities in your cluster in the event there is an HA failover.
· Consider increasing the Shares level for your AD VM’s or even some resource reservations.
And remember to PLAN PLAN PLAN!!