Download code from GitHub
"Based on my slogan 'Keep It Smart and Simple (K.I.S.S.),' the planning phase is essential for a successful implementation of a Hyper-V environment." | ||
| --Andreas Baumgarten - MVP System Center Cloud and Datacenter Management | ||
This chapter provides an overview of how to automate the installation of the best practice Hyper-V host and its first running virtual machines (VMs). You will learn how to create unattended installations of Hyper-V with minimal effort. All the examples shown in this chapter are proven real-world best practice ones.
This chapter includes the following topics:
Planning the Hyper-V host
Unattended installation of Hyper-V through XML files
Rapid deployment of virtual machines
Nano Server
Before you start deploying your first production Hyper-V host, make sure that you have completed a detailed planning phase. I have been called in to many Hyper-V projects to assist in repairing what a specialist has implemented. Most of the time, I start by correcting the design because the biggest failures happen there, but are only discovered later, during implementation. I remember many projects in which I was called in to assist with installations and configurations during the implementation phases, because these were the project phases where a real expert was needed.
However, based on experience, this notion is wrong. Most critical to a successful design phase are two features-its rare existence and someone with technological and organizational experience with Hyper-V. If you don't have the latter, look out for a Microsoft Partner with a Gold Competency called Management and Virtualization on Microsoft Pinpoint (http://pinpoint.microsoft.com) and take a quick look at the reviews given by customers for successful Hyper-V projects.
Note
If you think it's expensive to hire a professional, wait until you hire an amateur. Having an expert in the design phase is the best way to accelerate your Hyper-V project.
Before you start your first deployment in production, make sure you have defined the aim of the project and its smart criteria and have done a thorough analysis of the current state. After this, you should be able to plan the necessary steps to reach the target state, including a pilot phase.
Besides the organizational skill needed for a successful Hyper-V project, there are some helpful tools that can help in most cases with the technical details. For answering questions such as how many hosts I will need for my Hyper-V setup, how many CPUs and how much RAM is needed, and what bandwidth is needed on my network, I commonly use the free Solution Accelerator, Microsoft Assessment and Planning Toolkit (MAP Toolkit) by Microsoft (downloadable at the shortlink http://bit.ly/1lzt2mJ). The MAP Toolkit is shown in the following screenshot:
Microsoft Assessment and Planning Tools
The easy-to-use MAP Toolkit does a full inventory of your existing environment, including performance counters over time. After running the wizards in your existing infrastructure, you will get an overview, a detailed report of the existing hardware and software infrastructure, and- most importantly -a measure of how these are used in your datacenter as of today, including used CPU cycles, memory, Storage I/O, and network usage. MAP even includes a planning wizard to plan the hardware requirements of your future Hyper-V hosts based on your current workloads and hardware configurations.
After having a basic understanding of the current usage and future needs of your hardware, it's time to choose the appropriate servers to run Hyper-V and its VMs. The good news is that all major server vendors have hardware in their portfolio that performs well for this task, so choose whatever vendor you like; there is just one thing you absolutely need to make sure of. The chosen hardware should be on the Windows Server Catalog and be certified for Windows Server 2016 (you can get more information here http://bit.ly/29W93Mg). This way, you are making sure that your hardware has undergone extensive testing for Windows Server 2016 with Hyper-V. You will be able to open a support call at Microsoft in case you ever run into problems using this hardware with Hyper-V. If you are going to use an older version of Hyper-V (which you should avoid, but licenses might force you to), select the corresponding host OS on the hardware catalog. Make sure that your host setup includes the necessary adapters to comply with your chosen storage (refer to Chapter 4, Storage Best Practices) and network designs (refer to Chapter 5, Network Best Practices).
The CPU vendor you choose won't make a huge difference; just make sure that you stick to one, because mixed CPU vendors won't allow you to use live migration between Hyper-V hosts. Be sure that the chosen CPU models have support for server virtualization (Intel VT/AMD-V) and Data Execution Prevention (XD/NX) enabled. I strongly recommend that you use hyperthreading-enabled CPUs for server virtualization with active Second Level Address Translation (SLAT). Both are hardware-accelerated CPU features that add more performance to Hyper-V. For best performance, make sure to buy CPU models from the newest certified Enterprise Server line of the vendor of your choice. Due to the current licensing of Windows Server 2016 Datacenter and several other products, I recommend that you choose CPUs to obtain at least 16 physical cores in a server. If you need more physical cores, you have to buy extra license packs for every two additional physical cores in the server.
To choose the right RAM for your Hyper-V hosts, make sure that it supports the Error Checking and Correction (ECC) RAM and choose modules large enough to fit with the amount designed into your hosts. As RAM is very inexpensive these days, you should choose the bigger modules in case of any doubts on ensuring growth in future.
For your storage and networking options, refer to the corresponding chapters of this book. However, to host the Hyper-V management partition, I strongly recommend that you use two local SSDs or HDDs in Raid 1 and not share the disks with VMs or other data. I have experienced the best results with these local hard drives, and have found some problems with remote boot scenarios due to the higher complexity of boot-from-SAN setups, which is also a possible and supported, but not a preferred scenario. You don't need high-performance disks for the OS; all I/O performance should be added to the VM storage.
It is also important to choose fewer bigger boxes over many small Hyper-V hosts. This enables more efficient management. However, while needing a failover resource in a cluster, a Hyper-V cluster should consist of at least three nodes; otherwise, 50 percent of your hardware is reserved for failover scenarios.
Refer to Chapter 7, Hyper-V Performance Tuning; it includes advanced hardware sizing guidelines for performance tuning.
Many Prepare Your System chapters start by asking you to update all your hardware and software components to the latest releases. This chapter doesn't make an exception to this rule. In no other technical area have I seen so many successfully fixed environments due to firmware and driver updates. Windows Server with Hyper-V has undergone a very rapid development cycle with many releases in a short timeframe. Most hardware vendors released firmware and drivers with greatly shortened testing periods and were forced to release several updates due to firmware and driver updates to their products. Before you start setting up your Hyper-V host, update BIOS, RAID Controller, and the Network Interface Card (NIC) firmware to their latest release. Use the home page of the server-vendor, not the vendor of the individual components, for reference to the latest certified releases. Only use downloads from the individual component's' vendor if you see those problems you encounter fixed by the corresponding release notes.
Note
A Hyper-V host is highly dependent on the underlying hardware. Be very careful with the implementation; try and test every hardware component, every driver and firmware. Do not add in the production before double checking every single part of your newly created Hyper-V host. Moreover, use only supported driver and firmware.
Other than this, you only need your Hyper-V installation media, the Windows 10 Assessment and Deployment Kit (ADK) (shortlink http://bit.ly/29Ub3G5), and a USB drive to prepare for rapid Hyper-V installations. Download either the full version of Windows Server 2016 with Hyper-V from your Volume License Portal or the 180-day Evaluation version of Hyper-V. In fact, it does not make any difference whether you use the Evaluation edition or the full version media- they are interchangeable -the only difference will be made by the product key you enter. All Hyper-V features are also supported by the free editions of Hyper-V Server 2016; all the screenshots and configurations you see in this book are created using the full version of Windows Server 2016 with Hyper-V and could vary slightly from the free edition. Hyper-V is very easy to install.
Windows Server 2016 comes with a new licensing model based on core. Microsoft sells the license pack to support two cores. You need to buy at least eight license packs that support 16 cores. If you have beyond 16 cores in the server, you will have to buy extra license packs. In the following table, you can find the features provided by each edition:
Comparison between both Windows server editions
To familiarize yourself with Hyper-V, just insert the installation media, select it as the boot device, and click through the various options in the setup wizard. If this will be the only Hyper-V host you will ever install, this will be a great installation experience. Most of the time you will not stick to just one host and, to speed things up, we will mainly use unattended installations of the Hyper-V hosts from now on. The unattended setup uses configurations saved in a precreated unattended.xml file, which can be either slipstreamed into the installation media or saved on a USB drive so that it's available to the host during installation. This enables a standardized and very rapid Hyper-V deployment with a onetime preparation.
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 the setup of the Windows ADK you downloaded earlier. At the setup prompt, select only Deployment Tools, as shown in the following screenshot.
After the completion of the installation, start Windows System Image Manager from the Start screen:
Windows ADK 10
After the tool is fully loaded, select the File menu, open the Select an Image wizard, and browse to the
Install.wimfile or your installation media in the source's subdirectory.Select the Windows Server 2016 SERVER STANDARD edition for your first unattended installation file and allow the creation of a new catalog file:
If you receive a warning message stating that you are unable to write the catalog file, open Windows Explorer, navigate to the
Install.wimfile, open its properties, and uncheck the read only checkboxIf you have your installation media on a physical read-only media, copy
Install.wimto a local hard drive first. Select the Server Standard Edition using GUI:
Select Windows Edition
After the catalog file is created, select the File menu again, create a New Answer File, and save it as
unattended.xmlto a place of your choice.Windows System Image Manager will then create the basic XML structure of your unattended file, as shown in the following screenshot:
Windows System Image Manager
Opening this XML file in Internet Explorer will show you the actual file contents. Every Windows Server 2016 setup will check for an existing
unattended.xmlfile at the start of every available drive letter, but it will only work if the XML structure is correct.We will now continue to fill this
unattended.xmlfile with contents specific to the Hyper-V setup to allow a Zero-Touch installation of your Hyper-V hosts.
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:
First, add the
amd64_Microsoft-Windows-International-Core-WinPEcomponents toPass1and fill the basic language options. The generated XML part with all the mandatory parameters will look like the following code:<?xml version="1.0" encoding="UTF-8"?> <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SetupUILanguage> <UILanguage>en-US</UILanguage> </SetupUILanguage> <InputLocale>en-US</InputLocale> <UILanguage>en-US</UILanguage> <SystemLocale>en-US</SystemLocale> <UserLocale>en-US</UserLocale> </component>If you prefer language settings other than US English, make sure that the language components are included in the installation media and refer to the correct locale IDs, which can be found on Microsoft MSDN (shortlink http://bit.ly/1gMNu2B).
Next, add
amd64_Microsoft-Windows-Setup_neutraltoPass1to configure some basic OS configurations such as Disk Layout. A generated sample XML part for a BIOS-based system is as follows:<?xml version="1.0" encoding="UTF-8"?> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DiskConfiguration> <Disk wcm:action="add"> <CreatePartitions> <CreatePartition wcm:action="add"> <Order>1</Order> <Size>350</Size> <Type>Primary</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Order>2</Order> <Extend>true</Extend> <Type>Primary</Type> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="add"> <Active>true</Active> <Format>NTFS</Format> <Label>Bitlocker</Label> <Order>1</Order> <PartitionID>1</PartitionID> </ModifyPartition> <ModifyPartition wcm:action="add"> <Letter>C</Letter> <Label>HostOS</Label> <Order>2</Order> <PartitionID>2</PartitionID> </ModifyPartition> </ModifyPartitions> <DiskID>0</DiskID> <WillWipeDisk>true</WillWipeDisk> </Disk> </DiskConfiguration> </component>This configuration will make sure that there are clean partitions that follow Microsoft's default deployment model. The small partition at the start of the disk is created to support Bitlocker. Microsoft's full disk encryption can be used with Hyper-V hosts and can also be activated later. The use of Bitlocker is only recommended in high-security environments.
If your host does not have BIOS anymore and uses an UEFI-based setup routine, the XML file will be edited to include the following code as well:
<?xml version="1.0" encoding="UTF-8"?> <component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DiskConfiguration> <Disk wcm:action="add"> <CreatePartitions> <CreatePartition wcm:action="add"> <Order>2</Order> <Size>100</Size> <Type>EFI</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Order>3</Order> <Extend>false</Extend> <Type>MSR</Type> <Size>128</Size> </CreatePartition> <CreatePartition wcm:action="add"> <Order>4</Order> <Extend>true</Extend> <Type>Primary</Type> </CreatePartition> <CreatePartition wcm:action="add"> <Size>350</Size> <Type>Primary</Type> <Order>1</Order> </CreatePartition> </CreatePartitions> <ModifyPartitions> <ModifyPartition wcm:action="add"> <Active>false</Active> <Format>NTFS</Format> <Label>Bitlocker</Label> <Order>1</Order> <PartitionID>1</PartitionID> </ModifyPartition> <ModifyPartition wcm:action="add"> <Letter>C</Letter> <Label>HostOS</Label> <Order>3</Order> <PartitionID>3</PartitionID> <Format>NTFS</Format> </ModifyPartition> <ModifyPartition wcm:action="add"> <Order>2</Order> <PartitionID>2</PartitionID> <Label>EFI</Label> <Format>FAT32</Format> <Active>false</Active> </ModifyPartition> </ModifyPartitions> <DiskID>0</DiskID> <WillWipeDisk>true</WillWipeDisk> </Disk> </DiskConfiguration> </component>
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>
Note
Downloading the example code:
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
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.
Note
Another important post-installation task is to follow the rule: do not install other roles on Hyper-V hosts except Storage and related features (Hyperconverged model, for example).
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:
Do not install any features other than Failover Clustering and Multipath I/O (MPIO) on a Hyper-V host
There are exceptions in an SMB3 scenario where you also want to install Datacenter Bridging (DCB) and SMB bandwidth limits.
Limit software installations to an absolute minimum, that is, backup and monitoring agents
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
You are all set, and it's time to create some virtual machines. To do a rapid deployment of virtual machines, we will rely on PowerShell.
Creating a new virtual machine with PowerShell is easy; just open an elevated PowerShell prompt, and run the following command:
New-VM
Without any additional parameters, this will create a new virtual machine with the default parameters. To create a new Generation 2 VM, run the following command:
New-VM -Generation 2
To create a new virtual machine with a specified name, a custom path to store the VM files, and a memory configuration, run the following command:
New-VM -Name VM01 -Path C:\VM01 -Memorystartupbytes 1024MB
Your newly created virtual machine doesn't have a hard disk yet. Create a new VHDX file by running the following command:
New-VHD -Path C:\vms\vm01\vm01_c.vhdx -SizeBytes 60GB -Dynamic
The VHD cmdlet
The created VHDX is not yet attached to a virtual machine. Do this by running the following command:
Add-VMHardDiskDrive -VMName VM01 -Path C:\vms\vm01\vm01_c.vhdx
To add a network adapter to our virtual machine, run the following command:
Add-VMNetworkAdapter -vmname "VM01" -switchname "external"
Then, start the VM by running the following command:
Start-VM -Name VM01
You will recognize that the virtual machine now has all the basic hardware parameters but fails to boot due to a missing operating system. There are multiple ways to create an operating system for a standard VM. The most granular way to achieve this is using Virtual Machine Manager templates (refer to Chapter 8, Management with System Center and Azure, for details), but there are great capabilities already included in Windows Server 2016. The approach that is seen most often is to manually install the first virtual machine and include everything you want in each of your virtual machines, such as operating system, updates, and backup agents. Then, sysprep the virtual machine by executing sysprep.exe present at C:\Windows\System32\sysprep\ with the Generalize and OOBE options and shut down the virtual machine. Copy it to a Template folder and mark this as read only. As of Windows Server 2016, you can even copy and export running virtual machines.
If you need a new virtual machine, just copy the Template folder, rename it with your machine name and a preinstalled operating system with all your previous created configurations are still available.
If you don't like patching all your images and archived VMs manually, you can use a solution to update these VHD/VHDx files offline with Apply-WindowsUpdate.ps1-just another gem from the TechNet Gallery (download this from the shortlink, http://bit.ly/1o4sczI).
As you have seen in this chapter, I have mainly used Generation 2 VMs. If your guest operating systems are Windows Server 2012 and higher, this should be your default option. Generation 2 VMs allow faster booting, better stability, and smaller attack surface through a greatly reduced set of legacy hardware.
With the tools from this chapter and the configuration files you have already created up to now, you will be able to deploy new Hyper-V hosts and VMs faster and in a more reliable way than ever before. Besides this, you learned valuable best practices to plan and configure your single Hyper-V host.
In Chapter 2, Deploying Highly Available Hyper-v Clusters, you will learn to create high-availability solutions based on your current setup to leverage additional capabilities of Hyper-V and virtualization.
