Hyper-V servers joined to a domain

All my clients are small businesses just trying to get by. No corporate budgets to do things the completely right way without a lot of arm-twisting and some time to build trust.

A common scenario is to inherit a site with a single physical server running a few virtual servers. This Hyper-V host is usually in a workgroup. Other times it is joined to the domain, with the DC running as one of its VMs.

The domain scenario makes management easier, but the idea of the domain controller going down seems problematic. I saw one case where the DC VM wasn't set to always start up automatically. I caught this before shutting down the host for extended maintenance. I also realized that the domain admin password had been recently changed, so there might be an issue logging into the host if the DC wasn't running and there were no cached credentials.

Most small sites don't have the budget to buy a second physical server and have me set up DCs on both, even though I recommend it. I can either turn away their business or make some compromises to do the best I can with what they can afford. But I really don't like the random domain/workgroup status of the physical hosts from site to site.

Is the above situation with the DC as a VM a serious issue? Could extended DC downtime create a situation like I mentioned where you couldn't even log into the host in order to start or repair the DC?

Solution 1:

The only domain controller can be a guest on a Hyper-V VM, and the host can be a domain member.

A more fundamental question: can the organization accept this level of availability in the worst case scenario. Perform a business continuity exercise demonstrating AD DS can be restored, and the impact of such an outage.

• Confirm local administrator credentials on the host.
• Shut down the DC and pretend it is broken.
• Create a test DC guest, from whatever extra hardware is handy, a desktop if necessary. Isolate it completely from the network, per AD DS best practice for a test lab.
• Restore the DC, from whatever backups are available, to the test DC.
• Test applications on the real DC, inventory what broke. Cached passwords should work, but not user changes or directory lookups. If DNS is down, many things will not work.
• Power down test DC, power up production DC.

One guest DC might be fine. Easy to manage. Cost savings. A few hours down if the worst happens and the domain is trashed, assuming backups are good.

Should the impact not be acceptable, the price for high availability is another DC. Of course that increases the costs for hardware, software, and complexity.