Hyper-V Server 2012 R2
In this final post we’ll cover the Configuration of Network Settings and setup of Remote Management for a Hyper-V 2012 R2 Server which will be managed from a Windows 10 Enterprise PC.
There are quite a few steps to go through for this part of the configuration of the Hyper-V deployment however a number of these steps can be applied to the servers through Group Policy and thus removing the need to repeat them again.
First up we will configure the management network adapter and domain join the Hyper-V host…
In this post I’ll be going through the installation of Hyper-V Server on our Dell T430 hosts. Remember you can download and use Hyper-V Server 2012 R2 for free (link) however you must still license the guest Operating Systems.
I’ll be configuring a 80GB partition for the OS with the remainder of the storage set aside for the virtual machines – remember this is a UEFI based system so you can have single partitions over 2TB in size (in this case we will have a 2.7TB data partition) on the same disk as the boot partition.
An interesting quirk of running Virtual Machines for this post… the background is my ‘main work PC’ is currently running Windows 7; in order to remotely manage a Hyper-V Server 2012 R2 machine I had installed Oracle VirtualBox onto my main PC and inside that had setup a Windows 8.1 VM to remotely manage the Hyper-V Server instance.
However after setting up remote management I found that I could connect to all of the remote management tools on my Hyper-V machine with the exception of Disk Management and Hyper-V Manager with the following error message generated in Hyper-V Manager.
RPC Server unavailable. Unable to establish connection between <Hyper-V Host> and <Client PC>.
After much investigation into this issue (and after following a number of dead ends relating to firewall settings, the hosts file and COM security) it transpires that the issue was related to the way that I had setup the network adapter within VirtualBox.
In particular the adapter had been set to NAT mode, now given the properties of NAT it seems plausible that some vital information might have been mangled in the process – if anyone feels like doing some Wireshark on this to discover the cause then please do!
The resolution was simple – setting the adapter to bridged mode instead which allowed the traffic to pass through the virtual adapter just fine.