In this post, I will explain how Microsoft changed the process for upgrading the Hyper-V integration components (or integration services, depending on what you’re reading) in a Windows guest OS virtual machine.
Why Upgrading Is Important
I posted an article in 2014 that described the basic architecture of the Hyper-V hypervisor. In that post, I explained the role of the integration components; these are a set of drivers/services that enlighten the guest OS, enabling it to avail of the underlying services and performance that the hypervisor makes available to it.
Note: If you’re a VMware administrator, then the integration components are similar to VM Tools.
While the basic architecture has remained relatively unchanged since Windows Server 2008 Hyper-V, the integration components have continuously been updated by Microsoft:
- Each release of Hyper-V adds new features, and you need a current version of the integration components to use these features.
- Security and bug fixes update the integration components between major releases.
It is, therefore, important to keep the integration components up-to-date so:
- You have access to the latest Hyper-V features
- Your deployments get fixes for bugs
- Security vulnerabilities are patched
Why Upgrading Was Painful
There were two ways that Microsoft supplied integration components before Windows Server 2016 (and therefore, Windows 10):
- The latest version of the integration components was built into that version of Windows at the time of release.
- A file on the host, called VMGuest.ISO, was updated by Windows Updates.
The process of deploying updated integration services into a Windows guest after general availability was tiresome. The basic method was to use Hyper-V Connect to attach to each virtual machine, log in, and run an integration services update from VMguest.ISO, which required a reboot. This manual task would require a maintenance window for each virtual machine. Because this was a manual task and introduced downtime, I suspect that many just decided to live without the updates, possibly falling out of support and becoming vulnerable to any otherwise-fixed security problems.
The second option was to use System Center Virtual Machine Manager (SCVMM). This process allowed you to update all of your machines at once (or in batches), with the obligatory reboot. At least you could automate this process using PowerShell, but I believe only a very small percentage of Hyper-V customers have meaningfully deployed (although sales figures will differ) SCVMM.
Other MacGuver’ed solutions existed, including using System Center Configuration Manager to deploy the MSI file from VMGuest.ISO, or forcing the installer into the WSUS catalog. It’s the latter that became interesting.
How Updating Has Changed
After years of feedback, starting with Windows 10, and then with subsequently released Windows Server 2016, Microsoft changed the update process. You won’t be able to find a VMGuest.ISO in WS2016, and that’s because it’s not used anymore. Instead, Microsoft is updating the Hyper-V integration components in the guest OS via Windows Update. For most customers, this is going to be pretty simple: just deploy Hyper-V and your virtual machines and there’s nothing more to do. But for a few, they’ll need to understand the system requirements.
The first requirement is that the guest OS in your virtual machines must have access to Windows Update in some way, such as direct access, WSUS or System Center Configuration Manager.
The second requirement is dependent on the guest OS that you are running on WS2016 (or Windows 10).
If you are running any of the below in the guest OS, then Windows Update will work without anything special being done:
- Windows Server 2016
- Windows 10
- Windows Server 2012 R2
- Windows 8.1
If you are running an older OS, such as below, then you need to make sure that the Data Exchange integration service is running:
- Windows Server 2012
- Windows 8
- Windows Server 2012 R2 SP1
- Windows 7
- Windows Vista SP2
You might notice that Vista is listed above but I excluded Windows Server 2008 (W2008). That’s because W2008 is in extended support, so while it is supported, Microsoft will only back-port security fixes to it.
What about Windows Server 2003/R2? Folks, all support for this 14-year-old operating system stopped in 2015. If you really need to run these legacy machines on a modern hypervisor, then you can use the VMGuest.ISO from a WS2012 R2 host. While it won’t be supported, it will kind-of work, but I wouldn’t bet my house on the machines being reliable.
And if your virtual machines are isolated from Windows Update? There’s a workaround for that, too. You can download the latest version of the integration components (as a .CAB file) from the Download Center to your guest OS. Then you can run a PowerShell cmdlet to install the update:
Add-WindowsPackage -Online –PackagePath <path to .CAB file>