In this post, I’m going to explain how to deploy the Azure Server Management Tools solution (which is in preview at the time of writing) so that you can manage your on-premises Windows Server 2016 (WS2016) Hyper-V hosts securely from anywhere, and from pre-Windows 10 PCs, Macs, and non-Windows tablets.
The Server Management Tools solution will provide us with an Azure-hosted web interface for managing Hyper-V hosts that are running on-premises. We need to deploy two items:
We will start by deploying a new connection; this might seem a bit backward, but this process allows us to create a new gateway.
Note that the service was still in preview when this article was written, so:
Log into the Azure Console, click New and search for Server Management Tools. Select Server Management Tools from the list of results and click Create.
Enter the computer name; this can be a fully qualified domain name (FQDN or DNS name that is valid on your LAN), or an IPv4 or IPv6 address. My demo lab for this post is a workgroup, so I used an IPv4 address.
Select the subscription, if you have more than one subscription, and use an existing resource group or create a new one.
You will then have the option to create a gateway. You only need one gateway. Enter the name of the object that you want to create in Azure; this does not have to match the name of the server that will be your on-premises gateway server.
Click the Create button at the bottom of the blade when you have double-checked the entered information. You will have your gateway and connection objects in Azure after a few seconds.
The new connection will not work. You will be told that:
Gateway not detected. Click here to configure the gateway.
We need to deploy a gateway on the local network where the Hyper-V host is located. Follow the link; it’s the quickest path to completing the setup of your gateway.
A new blade called Gateway Configuration will appear. We are told that the desired on-premises gateway server must meet the following requirements:
There are two things that we must do in the Gateway Configuration Blade:
Extract the zip file on the on-premises gateway server and run the installation.
Note: The zip file contains an MSI installer and a JSON file; it is the JSON file that creates a unique connection between your on-premises gateway and your Server Management Tools gateway object in Azure.
The installation is a simple affair. You will be prompted to either use a self-signed certificate or use one that was previously deployed; I opt for the self-signed option because I do not have a PKI deployed on the network. The installation will complete in a few seconds.
Not long after the installation, the status of the gateway should be updated to show a connection.
The Connection will not function, which is the ability to manage your host, until you enter local or domain credentials with local administrative rights on the server.
Open the connection. You are told that:
Click the Manage as command to enter administrative credentials.
So the obvious thing to do is click Manage as. Enter the administrative credentials and decide if you want Azure to save them or not.
Click Refresh in the connection object to force a connection to be attempted. If all things are OK, then Azure will connect to your on-premises server and enable management from the Azure Portal. If you get a failure, then you either need to look at the above pre-requisites (especially WinRM and the Windows Firewall) or the change the supplied credentials.
Once your host is shown as connected you can start to manage Hyper-V using the Hyper-V toolset in Server Management Tools.
Workgroup servers are a nightmare to manage in all ways. Server Management Tools will require the following additional steps:
You need to add the server that will be managed to Trusted Hosts on the gateway server:
winrm set winrm/config/client ‘@{TrustedHosts=”172.16.200.164”}’
You are going to be using a local administrator for the Azure connection’s credentials. This requires the following registry update to be run at the command prompt on the host that will be managed:
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1
If the host and the gateway are on different subnets, then you need to modify the Windows Firewall on the host:
NETSH advfirewall firewall add rule name=”WinRM 5985” protocol=TCP dir=in localport=5985 action=allow