Everyday Virtualization

Blog archive

Time To Let Go of Your Physical Domain Controller

There was a time when it was taboo to virtualize critical applications, but that time has long passed. I speak to many people who are 100 percent virtualized, or very near that mark, for their datacenter workloads. When I ask about those aspects not yet virtualized, one of the most common answers is "Active Directory".

I'd encourage you to think a bit about that last mile. For starters, having a consistent platform for Hyper-V or vSphere is a good idea, rather than having just one system that isn't. Additionally, I'm convinced that there are more options with a virtualized workload. Here are some of my tips to consider when you take that scary step to virtualize a domain controller (DC):

  1. Always have two or more DCs. This goes without saying, but this accommodates the situation when one is offline for maintenance, such as Windows Updates or a hardware failure of the vSphere or Hyper-V host.

  2. Accommodate separate domains of failure. The reasoning behind having one physical domain controller is often to make it easier to pinpoint whether vSphere or Hyper-V is the problem. Consider, though: By having one DC VM on a different host, on different storage or possibly even a different site, you can address nearly any failure situation. I like to use the local storage on a designated host for one DC VM, and put the other on the SAN or NAS.

  3. Make sure your "out of band access" works. Related to the previous point, make sure you know how to get into a host without System Center Virtual Machine Manager or vCenter Server. That means having local credentials or local root access documented and available by IP (without DNS as well) is required.

  4. Set the DCs to auto-start. If this extra VM is on local storage, make sure it's set to auto-start with the local host's configuration. This will be especially helpful in a critical outage situation such as a power outage and subsequent power restoration. Basic authentication and authorization will work.
    [Click on image for larger view.] Figure 1. Setting auto start on a local host isn't a new trick, but it's important for virtualized domain controllers.

  5. Don't P2V that last domain controller -- rebuild it instead. The physical to virtual (P2V) process is great, but not for DCs. Technically, there are ways to do it, especially with the manageable services that allow DC services to be stopped; but it's not recommended.

    It's better to build a new DC, promote it and then demote and remove the old one. Besides, this may be the best way to remove older operating systems, such as Windows Server 2003 (less than one year left!) and Windows Server 2008 in favor of newer options such as Windows Server 2012 R2 and soon-to-be Windows Server 2016.

  6. Today it's easier, with plenty of guidance. The resources available from VMware and Microsoft for virtualizing DCs are very extensive, so there's no real excuse to not make the move. Sure, if it were 2005 we'd be more cautious in our ambitions to virtualize everything, but times have changed for the better.

Do you still hold onto a physical domain controller? If so, why? Share your logic as to why you still have it, and let's see if there's a reason to virtualize the last mile.

Posted by Rick Vanover on 07/01/2015 at 1:14 PM


Subscribe on YouTube