Windows Core Hyper-V Setup Using PowerShell

In a previous post I gave some sample powershell commands to get a Windows Core server configured with the Hyper-V role and with some base networking. Let’s have a look at that script and what it does.

install-windowsfeature -name Hyper-V, Data-Center-Bridging, FailOver-Clustering, multipath-IO, hyper-v-powershell, rsat-clustering-powershell, rsat-clustering-cmdInterface, rsat-datacenterBridging-lldp-tools

First up we need to install the features that we need for the server. Notice that we really need to install the powershell management tools to do much locally. Yes you can absolutely get away with running all commands remotely but there are some changes, like networking, that you might still want to be local for.

new-netlbfoteam -Name “Switch1”-TeamMembers “vNIC1”, “vNIC2” -loadbalancingalgorithm HyperVPort

Next we’re going to create a Load Balance and Failover Network Team. This is the older style Windows 2008/2012 network team and you could change this to the new style team if you really want to.

new-vmswitch -Name “VMSwitch1” -NetAdapterName “Switch1”

This part is easy. We need to create a Hyper-V switch which will be connected to the network team we created in the previous step.

add-vmnetworkadapter -name “HV-Mgmt” -switchname “VMSwitch1” -managementos
add-vmnetworkadapter -name “HV-CSV” -switchname “VMSwitch1” -managementos
add-vmnetworkadapter -name “HV-LM” -switchname “VMSwitch1” -managementos

Now we can create some virtual network adapters for the Hyper-V host to use. In this case we have a vNIC for Management, CSV Disk Management, and Live Migration. These adapters are all virtually plugged in to out virtual switch.

set-vmnetworkadaptervlan -vmnetworkadaptername “HV-CSV” -vlanid 2 -access -managementos
set-vmnetworkadaptervlan -vmnetworkadaptername “HV-LM” -vlanid 3 -access -managementos

We don’t want to have these three separate network cards just for the sake of it, they need to be on different networks to isolate the traffic. So here we configure them with different VLAN IDs. These need to have been configured on the network switch that the Hyper-V server plugs in to.

So why don’t we have a VLAN ID for the management vNIC? Well you really want to be able to perform bare metal build of the Hyper-V servers using VMM and while it’s possible to do this with VLAN tagging on the management adapter it’s far easier without this. By enabling the management network as the native VLAN on the Hyper-V server port any untagged traffic will be put into the Hyper-V Management VLAN. This will allow the server to PXE boot and load the WinPE environment without using a VLAN ID. The other side of this is that once you are in Windows you still don’t use the actual VLAN ID. Just leave it blank.

New-VMSwitch -Name “VM-Switch2” -NetAdapter “vNic3″,”vNIC4” -enableembeddedTeaming $true

Since we want to be fancy and use the new Windows 2016 Switch Embedded Networking for the VM networks the next team is created a different way. We don’t need to create the Network Team first it’s all managed in Hyper-V Networking.

Get-NetAdapterAdvancedProperty -DisplayName “Jumbo Packet” | Set-NetAdapterAdvancedProperty –RegistryValue “9014”

Almost at the end now. Hyper-V experiences significant performance increases if jumbo frames are enabled. This is particularly when machines are migrated between hosts but also around any other large network transfers. The problem is that all new network adapteds, including the ones we created above, default to having jumbo frames disabled. Turn these on whenever possible. In fact keep checking that these are still turned on. It’s a simple change which results in huge performance benefits.

mpclaim -r -i -a “”

Finally if you are using a SAN you’ll likely have multiple pathways and require MPIO to be enabled. If you don’t you’ll see multiple copies of the same disk and yet will only be using a single path. MPCLAIM will discover any MPIO devices and then will reboot the server to enable the configuration.

Now all you need to do is use sconfig to set the IP address for your new vNICs, change your server name and join the domain. Then you can use all your normal tools remotely.

Windows Core isn’t so scary after all.


Windows Server Core – Is it worth the hassle?

It’s been around for a long time now but how many environments are actually using Windows Server Core? It appears that it’s something that everyone knows they should be using but no one really wants to commit to.

Now Microsoft have made life harder with Windows 2016, by removing the ability to add and remove the GUI meaning you need to commit up front.

So should you commit or run to the safety of the desktop experience? As expected that will depend.

Most servers come with ample memory and CPU to enable you to run the Desktop Experience so there really is little requirement to run Core but if you want to squeeze that little bit more out of your servers then maybe it’s worth looking further. What else do you need to think about before taking the plunge?

What do you need the server for?

There are still a lot of services that rely on the desktop experience to work and I’m not just talking about remote desktop services. Some print services will still want the desktop for instance, and there are many application servers that will still want it too.

If you’re looking at a Hyper-V server then you just know that Microsoft want you to install core on it. Feeling guilty for hovering over the desktop experience option yet?

What is the driver support like?

This might sound like a strange question but one of the limitations of Core is around driver management. Device Manager is available externally, but only in read only mode.

You can install, remove and update drivers using the Core commands but what about if you want to modify settings? Hopefully there’s a registry key or a configuration file because it’s not guaranteed that their device management utility will run in core. Sometimes they will but….

You may think that this isn’t really an issue but just think about when you need to tweak network driver settings. Some of these, like Jumbo Frames, are accessible using PowerShell but not all.

How often do you need to log on to the server anyway?

This question needs to be answered in multiple ways. First what sort of admin staff are there? Do they install as much as they can on their own admin workstations or jump-boxes and do all their admin remotely or is everything done on the server itself? Do they have an aversion to PowerShell and all other command lines? If you try to force Core on the wrong staff it’s not going to end well.

The second part of this question is how often you need to use the server. Let’s face it a nice GUI is quite comforting and if you need to do some manual task on the server every day then you just know you’re going to be happier with a full desktop experience. But stop you say. Why aren’t you automating your daily task? If so then maybe you are ready for Core after all.

You’re taking the plunge. How bad is it really?

That all depends. How do you feel about seeing this when you log on?

Windows Core Desktop

If you’re a little concerned then let’s make you feel better.

Windows Core Powershell Desktop

So much better right. As long as you get drivers sorted the actual setup isn’t too bad now. Remember the bad old days of running VBScript and weird command lines that no one will ever remember to get a server up and running? Well they’ve all gone. Now just run sconfig and you’re presented with a fairly user friendly, albeit ASCII menu.

Windows Core SConfig

That will get you over the initial setup but what about if you need to tweak things. Please don’t tell me I have to use REG command lines to edit the registry!!!

Well no you don’t, and this is the not so dirty little secret about Core. It might be desktop experience-less but that doesn’t mean GUIless.

Windows Core with GUI

In fact the mistake that almost everyone makes is exiting the command prompt thinking it will log them off. Nope, that’s not how it’s done. You’re suddenly left with a session with no interface. Don’t worry though just use CTRL-ALT-DEL and you get the ASCII version of the LoginUI.

Windows Core LoginUI

From here you can bring up the GUI version of task manager and re-run explorer.

Windows Core Task Manager

As you can tell you may find that even if you do have some GUI tool that needs to run on the server it might still be fine. After all it is still Windows just with a little less than normal.

Are there any advantages to offset the hassle of running Core? Absolutely. One major advantage is that the server will be left alone to just do what it’s intended to do. Admins won’t be logging on to the server and using browsers or other programs built in to the Desktop Experience.

The size of the installation will be significantly smaller which will not only mean less disk space requirements but also less patching. Yes Microsoft are now using cumulative updates so you’re likely still going to be patching monthly but the time to install these updates and the potential impact will be smaller.

Boot time is also incredibly quick since it has so little to load on boot.

Finally it will change how you look at managing a server. It’s so easy to just have a process you follow for deploying a server but wouldn’t it be nice to instead have a scripted installer. how often do you find a small typo in configuration resulting in a slightly different configuration between servers. Core makes it so easy to create scripts for everything you do that can then be used in the future.

So as an example of this say you want to install a Hyper-V server. How hard is it to get a base level using a script? Well here’s a basic script to get you going.

install-windowsfeature -name Hyper-V, Data-Center-Bridging, FailOver-Clustering, multipath-IO, hyper-v-powershell, rsat-clustering-powershell, rsat-clustering-cmdInterface, rsat-datacenterBridging-lldp-tools

new-netlbfoteam -Name “Switch1”-TeamMembers “vNIC1”, “vNIC2” -loadbalancingalgorithm HyperVPort

new-vmswitch -Name “Switch1” -NetAdapterName “Switch1”

add-vmnetworkadapter -name “HV-Mgmt” -switchname “Switch1” -managementos
add-vmnetworkadapter -name “HV-CSV” -switchname “Switch1” -managementos
add-vmnetworkadapter -name “HV-LM” -switchname “Switch1” -managementos

set-vmnetworkadaptervlan -vmnetworkadaptername “HV-CSV” -vlanid 2 -access -managementos
set-vmnetworkadaptervlan -vmnetworkadaptername “HV-LM” -vlanid 3 -access -managementos

New-VMSwitch -Name “VM-Switch2” -NetAdapter “vNic3″,”vNIC4” -enableembeddedTeaming $true

Get-NetAdapterAdvancedProperty -DisplayName “Jumbo Packet” | Set-NetAdapterAdvancedProperty –RegistryValue “9014”

mpclaim -r -i -a “”

Simple right? So what does it all do? I’ll go through it in the next post.