Well with my OS on a trusty thumb drive I plug it into the server and came back to my desktop. I finish the Lifecycle wizard and the server reboots. It boots right up from the thumb drive and begins the Microsoft Hyper-V Server 2019 installation. I create a 75GB partition for the OS. I am old dog and remember the days of gnashing your teeth over that OS drive being full and having no good options to remedy it. Since Microsoft recommends 32GB going double will alleviate my anxiety. The wizard goes through the installation process and then finally reboots to the new OS.

On to configuring the OS. I set an admin password and then documented it in my password manager. I changed the server name to match my naming scheme. Rebooting. I set the network settings for each NIC and document them in my networking scheme. I set the correct time zone and verified the server is set to sync time. Then I add the server to my domain. Rebooting again.

I’ve heard over the years two camps arguing over if your hypervisor should be part of the domain or not. It is argued that if you connect it to the domain and lose connectivity to the domain controllers you lose access to your hypervisor. The other side argues this never happens due to cached credentials and having the hypervisor part of the domain eases security and configuration concerns.

I can appreciate both sides of the argument. I have encountered an environment where there was an unknown time sync issue on the two hypervisor servers that spread to the domain controllers and all virtual machines. While physical and virtual machines still had connectivity due to the server’s time being so far off cached credentials were not working and authentication against the DCs was failing because the time was so far off. It certainly made for a very difficult situation to get around. These hypervisors were tied to the domain so it did not help in this situation but I believe this scenario is so far beyond what is reasonable it should not dissuade you. This environment was not originally configured correctly, and then it was not maintained properly. Even doing one of those two things would have prevented the scenario. I think assigning the hypervisors to your domain is definitely the way to go in most scenarios.

After connecting the OS to the domain and I ran updates on the OS. It ended up taking three rounds of updates with two reboots to get the brand new OS up to date. This was even an image I had just downloaded two days prior.

My next step is to set up my remote management tools to access the server. First I connect the server to Server Manager on my desktop. Done. Then I connect the server to Windows Admin Center. Straight forward. Oh nice! Windows Admin Center even points out there is an available extension for OpenManage. Since I’m here I start the installation of the extension. Finally I go to add the server to Hyper-V Manager on my desktop and get an error:

…Check that the Virtual Machine Management service is running and that you are authorized to connect to the server. You do not have the required permission to complete this task. Contact the administrator of the authorization policy for the computer…

Well that’s weird. While I’m logged in to my desktop as just a regular user I did tell Hyper-V Manager to connect as the domain administrator. Which is what I have been using to log in directly to the hypervisor. Well I’ve connected to the server from two out of three tools which isn’t too bad at this point. I think I’ll set this down for now and come back later.