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?

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.

Hyper-V doesn't need the domain to be reachable in order to start up and start the virtual machines. Make sure you have a local administrator user account on the host that you can log onto the host with if needed.

I've seen plenty of each scenario and personally, I don't find it to be a big deal.

Not having more than one Domain Controller is a bigger issue to me then whether or not the Hyper-V host is joined to the domain.

The domain scenario makes management easier, but the idea of the domain controller going down seems problematic.

Nope, totally not. It actually is a supported scenario that was introduced in one of the earlier versions, even for clustering (and THAT was problematic as the cluster could not start without an AD controller - now they can).

There is absolutely nothing on that that is not supported as standard configuration for years now.

I saw one case where the DC VM wasn't set to always start up automatically.

Some people are idiots. And not setting up a DC as autostart without a good reason is in that category. That is not an argument. I once saw a car burning out - that does not mean that it was not a technical issue.

Most small sites don't have the budget to buy a second physical server

Sorry, that is as bad an argument as it goes. Those are the same sites that whine like mad - the moment the first server fails, and hardware DOES fail. If your business depends on a server, how fast is second server more expensive than paying people or rent for a non-business? Same level of argument like "we do not do backups" - nothing to do with corporate (THOSE have plenty of spare) but with common sense.

I can either turn away their business or make some compromises to do the best I can with what they can afford.

Turn away their business. Unless YOUR business depends on it, refusing to do reckless work has no implication for your financial health.

Is the above situation with the DC as a VM a serious issue?

I am sorry, but given it is a documented standard scenario.... that burns down to "how much do you know of machines that you work with". It once was a hack, it has since then been standardized.,

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?

If you are not careful enough and disable the local admin password which can serve as an emergency access point (and which should not ever be disabled on a scenario without plenty of backups) and that DOES exist the moment you do not run AD on the machine.... there is no risk.