Demystifying Virtualized Domain Controllers Part 1: Myths
21 Hyper-V ArticlesUsing 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 Virtual Domain Controller on Hyper-V “Chicken-and-Egg” Myth
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!
If you could (re)address the current status of the DC disk cache write issue, that would be great…
Thanks,
Stephen
Good tip. To the best of my knowledge, and the fact that my test labs DCs still work despite the fairly regular abuse I subject them to, this issue is currently resolved. I’ll research it further, of course, but if you know something I don’t, I’m all ears.
Eric,
Ignorance is bliss! I have been running virtualized DCs in three different enterprises for over 4 years now with no problems. I did it because I hadn’t heard that it was a bad idea, and it just worked. As I read and learned more I thought about adding physical DCs to the mix, but the old axiom of ‘If it ain’t broke, don’t fix it’ combined with time and money constraints kept the status quo.
I greatly appreciate your posts. I read each of them and continue to learn from them. I have been doing IT for 10 years longer than you, but am not ashamed to say that I don’t know it all. Keep up the good work!
Stan Anderton
Wow, thank you for the kind words, Stan! They are very appreciated!
Thanks for the great write up on debunking the myths of virtual DC’s. In planning for a hyper V 2012 R2 this has settled my personnel worry of no physical DC! We can start building offsite extended replica’s without too much of a concern as to loosing DC’s, as we will have 3!
There are time one has to ignore the so call ‘expert’ and just dig your hand into some stuff and that is the approach i took with virtualizing my dcd and it has been running for close to 4years now and nothing catastrophic has happened. I have a PDC which is a physical box and two virtual DCs as backup.
Though there was a time i had time related issues with my virtual servers on a particular hyper-v host which caused them to have the wrong time occasionally, that issue was resolved by removing the time synchronization from the integration service and every has been great ever since.
Thanks for your excellent post at all times.
Well, very nice and true so far. However it will not work out without a physical DC when running a Hyper-V Cluster.
That should be kept in mind.
It will work on 2012+. My test lab uses only virtualized DCs running on cluster members. The cluster and domain start fine from a full power-down. There are some things to be mindful of, but it most certainly does work without a physical DC.
A great article! I was planning to look into virtualizing our DC this year but some of my peers came out with exactly those myths. Virtualization plans are back on!
In response to my earlier comment, as you know with Server 2012, with virtualized DC’s you would get event log errors about how write caching should be turned off. But, this setting in disk properties was greyed out. It was never clear to me if disk caching of the DC system drive was properly disabled or not.
This year I’ve had several virtualized DC’s go down hard because of power failure, etc. Directory corruption almost always occurred.
With a 2012 “R2” Host and virtual DC I do not get the event log error messages anymore, but if you go into the properties of your DC’s virtual disk, write caching policy is enabled. If you uncheck it to disable it you get an error message “Windows could not change the write-caching settings for this device……”
So, what’s the story? I thought they were going to fix this issue with R2, but I can’t tell if they have.
Oh, and your advice for having more than one DC is sound and they can both be virtual – but they should be on separate hosts!
Thanks,
Stephen
It is a myth now. I remember having to patch through a fibre run of 800m through 4 racks to another site, using media converters so I could get a 10mb link to an AD server to keep the hyper-v servers happy and allow me to manage them so I could start machines. 2008 hyper-v, very finicky!
Fantastic article. I’m planning to move to Server 2012 R2 Hyper-V and this whole DC thing was bothering me. Like you I tried some experiments abd all worked fine, but all the prior reading really scared me. Even a Microsoft Technet article on DC Virtualization on Hyper-V (originally written before R2, but updated) advised having a physical DC on which to fall back and also for having hosts with different hardware in case of updates, etc causing a hardware /driver failure that would span across all similar hardware. But as you imply common sense and technical experience are the best tools. With respect to the Technet articles (which were quite detailed). I guess it was just CYA. Thank you so much. I feel much more confident now with my original plan.
Eric,
I’m using Hyper-V Server Tech Preview (server 10) and joining the hypervisor to the domain which I create on a guest server of it causes a failure of the host to be able to access the network storage (which is totally open) where the VHD and VMCX files are located. Once the DC isn’t available, I’m unable to use files on the NAS with any console operations (though I can browse and select the files in the same console).
I just moved the VHD to a secondary partition on the local HDD of the host and that is working fine.
Just thought its worth citing this case.
When you say that the network storage is “totally open”, can you explain what that means? What sort of connection to storage are you making? If it’s SMB, then this seems like reasonable behavior.
Is it ok to have one physical host running Hyper-V 2012 R2 and make two vm’s – one for the dc and the other for the app server. Is this a good practice? This would also be the only dc. Is it ok to only have one dc in a really small environment? We are replacing many old server environments using SBS as the only server. We will also be using Altaro Hyper-v Backup.
Please advise,
Thank you!
Yes, Craig, all of that is fine. I think this is the article that you were looking for: http://www.altaro.com/hyper-v/demystifying-virtualized-domain-controllers-part-2-practice/
I want to take a 2012 r2 and make it a hyper-v and build two vm’s. One vm would be a DC, not the primary. We have three physical DC’s one needs decomissioned. This VM DC will mostly be for redundancy for now. My main question is this… Can I also build a second VM to be a remote desktop?
The contents of one VM have no bearing on another. In abstract, yes.
But running Remote Desktop in Hyper-V sounds a lot like Remote Desktop Services/VDI. That is a non-trivial undertaking.
Thank you! That brings up another question. Can the server that I am building be a Remote Desktop server and a Hyper-V server with a VM that is a DC? I don’t want to a VDI.
Do not mix Hyper-V with other roles. Either make the physical unit into a virtualization host with all other roles running inside virtual machines or do not virtualize.
OK, thank you! I appreciate you confirming a few things.
So, my plan is to go ahead with creating 2 virtual machines. One a DC, the other a Terminal Services or RDP machine. I will face the VDI obstacle when I get there.