Nano Server is a new headless installation option in Windows Server 2016. Nano Server is similar to Windows Server in the server core mode, but without logon capabilities and the support of only 64-bit applications, tools, and agent. It provides a small OS footprint, a quick restart, and a far fewer updates. Since there is no GUI and no logon capabilities on Nano Server, the management is made remotely using PowerShell, WinRM, WMI or MMC. To run Nano Server in production, you need the Software Assurance. Nano Server (shortlink http://bit.ly/2acV3Q2) supports a lot of features such as Hyper-V, Failover Cluster, storage, and so on.

However, the servicing model provided with Nano Server requires a lot of build upgrade in a year. Nano Server follows the same servicing model as Windows 10 in enterprise called Current Branch for Business (CBB). CBB should be updated at least twice a year and it will be applied to Nano Server. These updates must be activated manually but Microsoft supports only the current branch and its immediate predecessor.

Because of the CBB servicing model, I do not recommend that you use Nano Server in production for Hyper-V and storage features. These features require efficiency and stability and need to be operational as long as possible. This is the exact opposite of what is provided by the CBB servicing model.

To create an unattended.xml file, you can either start from scratch with a simple text editor or use a GUI. To leverage the second option, follow these steps:

Start by adding the most basic components by expanding the Components tree under the Windows Image section in the left-hand corner of the tool. Let's now add language and locale information, through following steps:

In Windows Server 2012 R2, the Standard and the Datacenter editions have exactly the same features. The main difference between the Standard and Datacenter editions is the virtualization rights. Each Windows Server Standard edition allows you to run two guest Operating System Environments (OSEs) with Windows Server editions, and a Datacenter edition allows you to run an unlimited number of Windows Server VMs on this particular licensed Hyper-V host. There is only one technical difference between the two editions-on a Datacenter edition, all Windows Server guest VMs will be automatically activated when provided with a corresponding key during setup. There is no need for a MAK or KMS-based OS activation anymore.

With Windows Server 2016, some features are not present in the Standard edition compared to the Datacenter edition. The mainly missing features in the Standard edition are related to Storage (as Storage Spaces Direct), networking stack, and Shield VMs. As of Windows Server 2012 R2, the Datacenter edition allows you to run unlimited guest OSEs (or Hyper-V containers) while the Standard edition allows you to run two of them.

If you want to leverage Automatic Virtual Machine Activation (AVMA), storage features, and unlimited number of Windows Server VMs, install a Datacenter edition on the host. It is easy to upgrade a Standard edition to a Datacenter edition later, but there is no option to downgrade.

If you are not sure which edition you are using, open a PowerShell window with administrative privileges and run the following command:

get-windowsedition -online

To find out which editions are available for upgrade, run the following command:

Get-WindowsEdition -online -target

Finally, to upgrade to the target edition, run the following command:

dism.exe /online /Set-Edition:ServerDatacenterCor /AcceptEula
    /ProductKey:   <ProductKey>

Upgrade from the Standard edition to the Datacenter edition

While it's suitable to install a Datacenter edition on a Hyper-V host, you should never do this inside a virtual machine, except if you need specific features only available in the Datacenter edition. For example, if you want to make a virtual Storage Spaces Direct lab, you need the Datacenter edition to deploy this feature. In most environment, the Datacenter edition is deployed because it enables you to run unlimited guest OSes while the Standard edition enables you to run just two guest OSes. The next step in building our unattended installation is to set up the installation target and the edition. Navigate to the ImageInstall string under the Microsoft-Windows-Setup node and add the following code:

<ImageInstall><OSImage><InstallFrom><MetaData wcm:action="add"><Key>/Image/Name</Key><Value>Windows Server 2016 Technical Preview 5 SERVERSTANDARD</Value></MetaData></InstallFrom><InstallTo><DiskID>0</DiskID><PartitionID>2</PartitionID></InstallTo></OSImage></ImageInstall> 

If you have chosen the UEFI-based setup, choose PartitionID 4 according to your disk setup. This will make sure that you install the Standard edition of Windows Server 2016 to the correct partition.

As the last step in Pass1, we will fill out the UserData tree under the Microsoft-Windows-Setup node and edit the following code:

<UserData><ProductKey><WillShowUI>OnError</WillShowUI></ProductKey><AcceptEula>true</AcceptEula><FullName>YourName</FullName><Organization>YourOrg</Organization></UserData> 

Fill in Name and Org Data with anything you like; however, these fields are mandatory. The product key field is optional. If you intend to use a 180-day trial version of Windows Server or are leveraging KMS Server activation capabilities, do not enter a product key. If you are using MAK-based OS activations, enter your product key. You can also install a MAK product key at a later time by opening a PowerShell window with administrative privileges and running the following command:

slmgr -upk #(this uninstalls the current product key)
slmgr -ipk <key> #(including dashes)

After adding the basic parameters, it's now time to add some comfort to our Zero-Touch installation.

In Windows System Image Manager, add amd64_Microsoft-Windows-Shell-Setup_neutral to Pass4 and Pass7.

Edit the XML file to set your time zone settings (run tzutil /l in a Shell to get a list of all the valid time zones) and your local administrator password. Don't worry about entering a password into Windows System Image Manager; it will encrypt the password while saving the file. The following code shows how to set the regional and user information:

<settings pass="specialize"><component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-Shell-Setup"><TimeZone>W. Europe Standard Time</TimeZone></component></settings><settings pass="oobeSystem"><component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-Shell-Setup"><UserAccounts><AdministratorPassword><Value>UABAAHMAcwB3ADAAcgBkAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value><PlainText>false</PlainText></AdministratorPassword></UserAccounts></component></settings> 

To allow a rapid deployment of hosts, I have not entered a computer name at this stage, so the setup will generate a random computer name for each node installed. If you want to enter a computer name, add the following code to your XML-specialized section:

<ComputerName>Hyper-V01</ComputerName> 

Another optional feature was selected right at the beginning of our XML creation-the GUI. By selecting the Windows Server Standard edition and not the Standard Core edition, we have included the complete GUI of Windows Server in our setup. Unlike Windows Server 2012 R2 version with Hyper-V, the GUI is now a feature that can't be activated or deactivated at a later stage. Note that the GUI is not available on the free Hyper-V Server 2016. The full GUI installation process offers the same great user experience we know from many versions of Windows Server and Windows Client operating systems, but Server Core is the installation method recommended by Microsoft for Windows Server 2016 and Hyper-V. The Core installation option offers a reduced attack surface with less patching efforts and fewer reboots. It even comes with a smaller resource footprint than its Full GUI equivalent. However, offering only a PowerShell Window as the single point of local administration discouraged many system administrators in the past, so Core setups aren't found often. Don't forget that all administrative APIs are active on a Core Server, so you can connect with your MMC consoles from other servers or clients without the need to use the PowerShell modules. Unfortunately, in Windows Server 2016 you can't switch from GUI installation to Core installation or vice versa.

The Minshell is also no longer available. In Windows Server 2012 R2, Minshell was a deployment option similar to the Core installation option but with Remote Server Administration Tools (RSAT).

GUI or Core installation

The basic operating system setup will now already be based on a Zero-Touch installation, but we want to achieve more than this and will include some additional options.

Add the amd64_Microsoft-Windows-TerminalServices-LocalSessionManager component to Pass4 and configure it to enable Remote Desktop Access to the server:

<?xml version="1.0" encoding="UTF-8"?> 
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TerminalServices-LocalSessionManager"> 
  <fDenyTSConnections>false</fDenyTSConnections> 
</component> 

To reach the Server via RDP, via its designated IP address, we will also set the basic network settings. Keep in mind that based on your converged network setup for Hyper-V, these might be overwritten at a later step (Chapter 5, Network Best Practices).

Add the amd64_Microsoft-Windows-TCPIP component to Pass4 and configure a static IP Address-in this case, based on the name of the interface. This is also possible using the MAC address. Configure the network as shown in the following code:

<?xml version="1.0" encoding="UTF-8"?> 
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TCPIP"> 
  <Interfaces> 
    <Interface wcm:action="add"> 
      <Ipv4Settings> 
        <DhcpEnabled>false</DhcpEnabled> 
        <Metric>10</Metric> 
        <RouterDiscoveryEnabled>true</RouterDiscoveryEnabled> 
      </Ipv4Settings> 
      <UnicastIpAddresses> 
        <IpAddress wcm:action="add" wcm:keyValue="1">192.168.1.41/24</IpAddress> 
      </UnicastIpAddresses> 
      <Identifier>Local Area Connection</Identifier> 
    </Interface> 
  </Interfaces> 
</component> 

Whether Hyper-V hosts should be added to an Active Directory domain is a topic that is often discussed. Having seen a lot of Hyper-V environments, either domain-joined or workgroup-joined, my answer to this is a strong yes. Windows Server 2016 Servers can boot up even clusters when domain-joined without an Active Directory domain controller available, so this chicken-or-egg problem from earlier Hyper-V versions is not a problem anymore. Hyper-V will run without an Active Directory domain; however, very basic capabilities such as live migration won't be available on workgroup environments. Huge Hyper-V installations or high-security companies even leverage their own management domain to place their Hyper-V hosts into an Active Directory domain.

There is little security consideration standing against a huge management benefit, through credential management, group policies, and so on, so you should domain-join all Hyper-V hosts to your existing Active Directory domain. If your Hyper-V hosts will be placed in high-security environments, join them to a dedicated management domain (within a separated Active Directory forest) and not to your production domain.

Add the amd64_Microsoft-Windows-UnattendedJoin component to Pass4 and configure it to join an existing Active Directory domain:

<?xml version="1.0" encoding="UTF-8"?> 
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-UnattendedJoin"> 
  <Identification> 
    <Credentials> 
      <Domain>int.homecloud.net</Domain> 
      <Password>Hannover96</Password> 
      <Username>joindomain</Username> 
    </Credentials> 
    <JoinDomain>int.homecloud.net</JoinDomain> 
    <MachineObjectOU>OU=Hyper-
    V,DC=int,DC=homecloud,DC=net</MachineObjectOU> 
  </Identification> 
</component> 

A typical configuration that is seen in this step is the disabling of the Windows Firewall. In my opinion, this is a bad practice. The Windows Firewall is a great layer of security and should be configured to your needs, but not disabled. For a central Firewall configuration, we'll use Group Policy settings, so we don't need to include any configuration in our unattended.xml.

After our operating system is prepared to host Hyper-V, it's time to activate the Hyper-V components. Add the following product packages and their roles and features to your unattended.xml file:

<?xml version="1.0" encoding="UTF-8"?> 
<servicing> 
  <package action="configure"> 
    <assemblyIdentity language="" publicKeyToken="31bf3856ad364e35"
    processorArchitecture="amd64" name="Microsoft-Windows-
    ServerStandardEdition" version="6.3.9600.16384" /> 
    <selection name="Microsoft-Hyper-V-Common-Drivers-Package"
    state="true" /> 
    <selection name="Microsoft-Hyper-V-Guest-Integration-Drivers-
    Package" state="true" /> 
    <selection name="Microsoft-Hyper-V-Server-Drivers-Package"
    state="true" /> 
    <selection name="Microsoft-Hyper-V-ServerEdition-Package"
    state="true" /> 
  </package> 
  <package action="configure"> 
    <assemblyIdentity language="" publicKeyToken="31bf3856ad364e35"
    processorArchitecture="amd64" name="Microsoft-Windows-ServerCore-
    Package" version="6.3.9600.16384" /> 
    <selection name="Microsoft-Hyper-V" state="true" /> 
    <selection name="Microsoft-Hyper-V-Offline" state="true" /> 
    <selection name="Microsoft-Hyper-V-Online" state="true" /> 
    <selection name="VmHostAgent" state="true" /> 
    <selection name="AdminUI" state="true" /> 
    <selection name="ServerManager-Core-RSAT" state="true" /> 
    <selection name="ServerManager-Core-RSAT-Feature-Tools"
    state="true" /> 
    <selection name="ServerManager-Core-RSAT-Role-Tools" state="true"
    /> 
  </package> 
</servicing> 

After adding these Hyper-V components, the creation of our unattended.xml file is completed. You can download the complete sample XML file from http://bit.ly/1xBIQb2. Place the file in the root folder on the USB drive and boot the Server system from your installation media. You will now experience a fully Zero-Touch Hyper-V installation. In Chapter 2, Deploying Highly Available Hyper-V Clusters, you will learn how to advance this even further into a Zero-Touch cluster installation.

Unattended.XML file for automatic Hyper-V setup

Be sure to remove the USB drive with the unattended setup file prior to moving the host to production. A host reboot could otherwise force a reinstallation, including a wipe of all hard drives, due to the trigger of another unattended installation.

Run Windows Update to make sure that you have installed all the available updates. Are there any Windows updates you should not install on Hyper-V hosts? Yes, drivers should not be installed over a Windows Update unless support tells you to do so. However, besides this, install every available Windows Update in all of your Hyper-V hosts.

The Hyper-V role is already enabled, and we are ready to create VMs. To ensure network connectivity and safe operations of our VMs, we will configure some additional parameters after the installation.

First of all, we need some basic network connectivity for our VMs. If you have a second NIC available in your host, run the following command in an elevated PowerShell session:

New-VMSwitch -Name SW-1G -NetAdapterName "Local Area Connection 2"

If you have only one NIC, run the following command:

New-VMSwitch -Name SW-1G-NetAdapterName "Local Area Connection" -
    AllowManagementOS $true

When the virtual switch is created, you can manage it from Hyper-V manager:

Virtual switch settings from Hyper-V manager

Now, your virtual machines can use an external Hyper-V switch named external to communicate over the network.

Ever wondered about the many errors your RDP-mapped printer can create on a Hyper-V host? I could not believe this for a long time, but recently, I have seen a Hyper-V Server with the blue screen due to improper printing drivers. Do you need to print from a Hyper-V host? Absolutely not! So, make sure that you disable RDP Printer Mapping through a Group Policy (or Local Policy).

Navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Printer Redirection | Do not allow client printer redirection and select Enable in a Group Policy.

Disable RDP printer mapping

Hyper-V uses some default paths to store virtual machine configuration and its hard disks. I find this very interesting, but it is definitely not suitable for a production environment. Make sure that you change the default paths, if possible to a nonsystem drive, by running the following commands in an elevated PowerShell window:

Set-VMHOST -computername localhost -virtualharddiskpath 'D:\VMs'
Set-VMHOST -computername localhost -virtualmachinepath 'D:\VMs'

I have not seen any issues in placing VM configuration files and virtual hard disks into the same folder structure. You have everything your VM configuration depends on in one place.

A Hyper-V host is a Hyper-V host and nothing else. Move all the other services into virtual machines that run on the Hyper-V host.

Moreover, also keep the following points in mind:

Another great topic for discussion is whether you should install an antivirus client on a Hyper-V host or not. Many companies have compliance rules stating that on every Server or every Windows machine, an AV client needs to be installed. If there is a rule like this in place, follow it and install an AV agent on your Hyper-V hosts. Make sure that you also implement the long list of files, which contain all the Hyper-V configuration files and virtual machine data, you have to exclude from your scans.

I have seen antivirus engines on Hyper-V hosts doing bad things such as breaking a virtual hard disk, deleting an essential system file, or just producing a very intense amount of storage IOs. Excluding all relevant files and folders regarding Hyper-V and its VMs, there is nothing left worth scanning on a Hyper-V host. If you are not bound by a compliance policy, I highly recommend that you do not install antivirus products on Hyper-V.

There are some approaches for Hyper-V-aware antivirus products; however, I have not seen one flawless working solution as of today, so you should protect your VMs from malware from inside the VM by installing your AV agents into the virtual machines.

One of the most frequent configuration tips around Hyper-V hosts is to manually configure the pagefile. The values described are sometimes quite creative.

After doing many tests with Hyper-V hosts with all different kinds of RAM configurations and deep technology-oriented exchanges with Microsoft Product Teams, including the Hyper-V Product Team itself, on how pagefile management work in Windows Server 2016, there is only one recommendation I have today-leave it alone.

The Windows pagefile is, by default, managed by Windows. If you have followed all other best practices described up to this point, and most importantly, you did not install other services on the Hyper-V host itself (management OS), you are all set. There is no way you can reach the same or even a better efficiency in pagefile management by manually altering this automatic configuration. I have not seen a single Hyper-V installation on Windows Server 2016 as of now that had problems with automatic pagefile management.

Again, this only affects the Hyper-V host and not the pagefile configuration of the virtual machines.

There are some more valuable post-installation tasks for performance management in Chapter 7, Hyper-V Performance Tuning. You can manage the pagefile as shown in the following screenshot:

Pagefile configuration