The Virtual Domain Controller on Hyper-V “Chicken-and-Egg” MythUsing domain controllers in a virtual environment is a contentious and confusing issue. I’m going to start this subject by saying that there is no single correct answer. No one piece of advice is going to work for everyone in every environment. The purpose of this article series is to explain the facts so that you can make an informed decision for your own domain.

One big issue with virtualized domain controllers is that often, the advice given on the subject comes from people who have never actually attempted to use them and have no actual first-hand knowledge. I have tried all of the scenarios that I will write about in this series and can therefore attest to their veracity. I want to begin by dispelling the common myths that are delivered from assumptions.

The basic form of this myth is that if a Hyper-V host is the parent for its own domain controller, then it can’t start. This myth comes in many variants. In some, the host can start, but none or only some of the guests can. In others, you can never log in to the Hyper-V console because it can’t talk to a DC until you log in. There might even be a few in which the Hyper-V host steals Zeus’ thunderbolt and slays the DC outright. Fortunately, none of these are true. To ensure that my mythbusting could be backed by hard facts, I did what many will claim is impossible. I took one of my test hosts, evacuated all of its guests, removed it from the domain, and isolated it from the rest of the network through a simple IP change. Then, I designed a new DC from scratch on that host. Finally, I joined the host to that new domain. In case it’s not obvious, there were no other DCs anywhere. When the Hyper-V host requested to be rebooted to complete the domain join, I let it happen. The disastrous results were: none. Everything worked just fine. I logged in as the domain administrator. It was at that point that I realized I had neglected to set the DC VM to start automatically. The DC wasn’t even reachable, yet everything was fine! How can this be!?!! There’s no magic here; AD has worked this way for years. I used Set-VM to fix the issue with automatic start, then  Start-VMto get my DC going. That’s it. If for some reason your domain credentials don’t work, those for the local administrator account will. Just like any other server, be sure you keep track of these.

Dealing with Domain Credentials

There are two reasons that this isn’t a problem. The first is that computers don’t really have a pressing need to log in to a domain. They mostly log in to receive group policy updates, to authenticate to other computers, and to participate in authentication for domain accounts that try to access local resources and/or log in locally. The inability to perform these functions doesn’t render the computer inoperable. Most importantly: there is no need to contact a domain controller in order for a Windows-based operating system to start. Furthermore, and this is especially important for Hyper-V, the inability to contact a domain controller only impacts functions and services that are dependent upon domain services. Hyper-V is not one of those services.

The second reason this isn’t a problem is due to cached credentials. When you log on, your system processes your username and password in a fashion that allows it to verify against the domain controller. It then stores the data for that verification locally. Any time those credentials are needed locally in the future, the machine can use its cached copy to authenticate you if a domain controller is unreachable. In some domains, cached credentials are restricted. The value of doing so is a debate that’s beyond the scope of this article. The point is that they’re available and enabled by default. In general, these won’t cause problems for the typical Hyper-V host, as Hyper-V is a type one hypervisor. It is not even aware of the existence of a domain because it is fully functional before the networking stack even starts. Its management service (Hyper-V Virtual Machine Management — VMMS.EXE) runs under the Local System context and any modifications to that are unnecessary and unsupported. If, for some reason, this behavior is modified, you still have the ability to log in with a local account and manage everything, including re-assigning the service to run under the proper security context.

The following diagram shows the normal operation for a virtualized domain controller that a guest of a Hyper-V host that is a member of the same domain:

Where you might run into issues is third-party applications. It’s not uncommon to have their services run under domain accounts. As previously stated, cached credentials should take care of these. If that turns out to be insufficient, you may need to reconfigure those third-party applications to run as Local System or set up mechanisms that can start their services after the domain controller becomes reachable.

“Physical DC’s are a Necessity” Myth

It’s always a good idea to have multiple DCs. That’s just an axiom. However, there’s no requirement that any of them be physical. This myth originates from a basic fear of some unspecified problem in the virtualization stack. When virtualization was still relatively new and untested, this was a rational precaution. Now, virtualization is a known, predictable entity. If you’ve got a physical DC to hold on to, there’s no need to rush to get rid of it. But, if keeping or creating a physical DC will cause undue stress, don’t do it. One fear is what will happen to other computers in the domain if the physical host containing the DC goes down. The answer is: the same thing that happens when a physical DC goes down. You must accept it as a possibility and plan for it, but it’s hardly the end of your domain. This is part of the reason that cached credentials exist.

“Time Drift is Uncontrollable” Myth

There is a kernel of truth in this myth. Virtualized systems can lose time, sometimes dramatically. Since the DC that holds the PDC emulator role is normally the authoritative time source for a domain, it could just be that it causes everyone to lose time. What makes this a myth is that the problem is addressable. Doing so will be part of the topic of the next post in this series.

What’s in Part 2

In the next part of this article series, I’ll cover some real concerns with virtualizing domain controllers.

 

Have any questions or feedback?

Leave a comment below!

Backing up Hyper-V VMs

If you’d like to make backing up your Hyper-V (and VMware!) VMs hassle-free, effective and affordable, check out Altaro VM Backup. It’s free for up to 2 VMs per host, forever!

Download your copy (free OR a 30-day trial of our Unlimited Edition) here: http://www.altaro.com/vm-backup/.

     25