Which Came First? AD or VMware?

This was a particularly frustrating issue to solve on my home network. The answer to the question posed by the title of the post is obviously AD. But don’t tell that to my network. Sigh…

It all started with the untimely dying of a UPS battery. Investigation later showed that I got at least 3+ years of lifetime from the pack before it required replacement. Cannot complain there. But this particular UPS likes to notify me that it’s time for new batteries by shutting off entirely. The only two things getting power from this unit: (both) power supplies from the VMware server and the Dell gigabit managed switch. A recipe for disaster.

I’ll keep this post short. The whole reason why there was an issue was that the VMware server was not properly shut down. Oh, and in the process of trying to start up the server, the UPS died again. Joy… Anyway, because I have battery backup capability, I do not worry about sudden power failures. Therefore (and for other reasons too) I run my OS drive datastore in a RAID stripe array (without parity). Performance is great; redundancy, not so much. Upon starting up the AD controller, there were some issues. DHCP would not start at all. Who knows what else? So I made the decision to restore from backup. I use Veeam to routinely image the VMware guests through vCenter. Everything is happily married to Microsoft AD for security and easy authentication. Well, when you have to restore the AD controller which must be shut off, that makes it nearly impossible to authenticate the proper connectivity points through vCenter and Veeam to restore the guest. And this is why Microsoft (and VMware) always tell you to have a physical DC at every site.

The ultimate solution was to edit DNS of the services not properly authenticating to use an off-site DC. That worked like a charm. Pat myself on the back for that ability. Meanwhile after the dust has settled, I am starting a new experiment: virtualizing another DC as a guest on FreeNAS.

Leave a Reply

Your email address will not be published.