FAQ: Windows Server 2016 and Hyper-V Integration Services

I’m frequently receiving questions about what’s wrong with Windows Server 2016 and how to manage Hyper-V IS. I’d like to discuss it in a FAQ manner. If your question is not answered, just feel free to leave a comment

Where is the integration services setup disk (VmGuest.iso)?

All of us remember times when we had to insert ISO which was available on Hyper-V host , run it on each VMs and check it’s version from time to time for keeping them up-to-date (yes, vmguest.iso was updated via Windows Update).

The process of Hyper-V IS upgrading has been changed since Windows Server 2016. Now VMs get IS updates directly from Windows Update (WU). ISO is not included and it’s not needed anymore.

It’s completely true if you have new OS inside VMs (Windows 2012 R2/Windows 8.1 and later). Hyper-V IS automatically get updates from WU in these OSes. No actions required.

We have another picture for older OSes (Windows Server 2012/Windows 8 and older). For such OSes, you need to verify that Data Exchange Service (DES) is turned on and running.

DES provides shared registry values (HostSystemOSMajor and HostSystemOSMinor under the hive HKLM\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters) between host and VMs for determining IS applicability. These values should be existed in VM in order to get IS updates from WU. If DES has never been enabled on VMs – IS won’t be provided.

hypervregs

Hack: you can edit/add these parameters and set values manually (of course, it’s unsupported)

Example of outdated IS in VM with WS2012R2 on WS2016 host (DES provided values from VM, compared them with host’s and they are not the same):

image

Linux Guests? Built-In or  Linux Integration Services are required

Unsupported Windows Server 2003? Integration services setup disk is required. Can be copied from WS2012R2 (download link is below). Better option: plan migration to newer OS

How to install IS manually?

Use this KB if DES can’t be enabled or WU is unavailable:

Hyper-V integration components update for Windows virtual machines that are running on a Windows 10 or Windows Server 2016-based host (IS  ver. 6.3.9600.17903) + IS update for Windows Server Guest OSes (IS ver. 6.3.9600.18080)

Update: IS was updated by the June’s month rollup to version 6.3.9600.18692

Note: To install this update, you must have April 2014, update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 (2919355) installed in Windows 8.1. Or, install Service Pack 1 for Windows 7.

To install IS (CAB-file) use PowerShell:

Add-WindowsPackage -PackagePath pathtocab -Online

If you want to do offline VM servicing : read guide from Sarah Cooley

TIP: IS with later version is available from uploaded VMGuest.iso below (use it to simplify overall process)

Where can I find ISO if I haven’t got Windows Server 2012 R2 installed?

I’ve uploaded Hyper-V Integrations Services ISO for you. It was taken from Windows Server 2012 R2 (up-to-date, 02/20/17 . IS version: 6.3.9600.18398). You can use this ISO to install Integration Services in “prehistoric” guest OSes (but again..migration to newer OS is better option for such VMs) on Windows Server 2016 or with hosts running on Windows 2012 R2/Windows 8.0/8.1 Download link for VMGuest.ISO

Update: here is a link for the latest Hyper-V Integration Services (version 6.3.9600.18692), taken from Server 2012 R2 + November updates: VMGuest.ISO (November, 2017)

Update: if you are running 2008 R2/2012R2 guest VMs on Windows 10/Server 2012R2/2016 hosts, there is a special update available at KB4072650 (6.3.9600.18907) 

I’m querying Integration Services version from PowerShell but it shows me 0 for all VMs. What’s wrong?

I’ve provided example of outdated IS in a VM SQL01 above. Cluster validation report generates a warning. PowerShell shows 0 in IntegrationServicesVersion

By default, PowerShell loads Hyper-V module with version 2. I tried to remove that module, import one with 1.1 version and query again IS versions. In that case, I received actual IS versions and  “Update required”  in IntegrationServicesState. It seems like something wrong with Hyper-V 2.0 module. Waiting for official fixes or confirmations.

hyperv

Update: this behavior is normal. VM support is based on the having critical updates and reporting IS version is no longer needed.

TOTD: How to manually move Azure VMs to another subscription

Here is a new tip of the day. We’ll discuss only the Azure Resource Manager. Azure Service Management (ASM or classical) won’t be covered.

Azure portal has a simple built-in tool to migrate resources between subscriptions/resource groups and it’s available under Resource Group – Move

azure move in portal

Or using PowerShell :  Move-AzureRmResource

It’s also well described @MSDN and there are some main limitations that we need to consider:

  • Move in Azure Portal works only for subscriptions/resources groups in the same tenant (the most important!)
  • Not any resources can be migrated. For example, it’s not supported to move VPN Gateway or Recovery vaults. So we need to create and configure the new ones in the target subscription.
  • There are different limitations for ASM (classical deployments) and ARM. Check them before migration.

If the tenant IDs for the source and destination subscriptions are not the same, you can attempt to change the directory for the subscription. This operation requires Service Administrator which sometimes are not available for user. For example, migration from CSP to EA.
In this case, manual migration is required.

To get list of subscriptions and TenantIDs associated with them use PowerShell:

get azure subscriptions and tenants

In this example, the first two subscriptions are in the same tenant and migration between them can be done through Azure portal using Move option.

However, moving resources between the subscriptions “Visual Studio Premium..” and “Microsoft Azure Sponsorship” requires manual migration steps (look at the TenantID..they are different).

So, how to move? It’s quiet simple if you are familiar with AzCopy and Azure PowerShell.

The process of migration consists of several simple steps:

  • Prepare your target subscription (general services like storage accounts and networks)
  • Download and install AzCopy, stop VMs, copy VHDs of each VM to the target
  • Install AzureRM module, create VMs using the copied VHDs
  • Add additional resources such as VPN Gateways/S2S connections and Recovery vaults (optional)

Some details

1) To copy (asynchronously) VHDs use the following command

AzCopy /Source:<Source URI>  /Dest:<Dest URI>  /SourceKey:<Source Key> /Pattern:<sorcevhdname.vhd>

<Source Key>  is one of the access keys (Storage Account – Access Keys or use PowerShell):

List of all storage accounts in the source subscription


Get-AzureRmStorageAccount|Ft ResourceGroupName,StorageAccountName

list of azure storage accounts

List of source storage account keys (example). Use one of the keys value with AzCopy

Get-AzureRmStorageAccountKey -ResourceGroupName <resource group name> -Name <storage account name>|ft -AutoSize

azure storage account keys

To get URIs and VHDs name (Storage Account – Containers – <name of container>):

(Get-AzureRmStorageAccount -Name <stor acc name> -ResourceGroupName <rg name>|Get-AzureStorageContainer|Get-AzureStorageBlob).ICloudBlob.uri.AbsoluteUri

azure uri and vhds

Stop VM or VMs and run copy in AzCopy then. Wait while AzCopy finishes initiated process.

Tip: prepare script for all VMs before stopping them. simultaneous copies are allowed.

2) Open PowerShell ISE with installed AzureRM module, replace values (variables and subID) with yours and run:

#Open new Azure session
Login-AzureRMAccount

#Target subscription details
$sub=(Get-AzureRMSubscription -SubscriptionName "your subscription name" ).TenantId
Select-AzureRmSubscription -SubscriptionId $sub

#Variables
$rgname = "your rg name"
$vmsize = "required VM size <Example:Standard_A4>"
$vmname = "your vm name"
$locName="location (example:East US)"
$nicName="VMName_Nic"
$vnetName="Virtual Network Name"
$SubName = "Subnet Name"
$osDiskName = "vmdiskname"
$osDiskVhdUri = "https://destination.blob.core.windows.net/vhds/name.vhd"

#New VM config
$newvm = New-AzureRmVMConfig -VMName $vmname -VMSize $vmsize

#Get virtual network
$vnet=Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $rgName

#Get subnet
$subnet = $vnet.Subnets | Where-Object { $_.Name -eq $SubName}

#New Public IP
$publicip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic

#New nic for VM
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $subnet.Id  -PublicIpAddressId $publicip.Id

#Update VM config
$newvm = Add-AzureRmVMNetworkInterface -VM $newvm -Id $nic.Id

#Attach copied disk to VM (sample. just one OS disk)
$newvm = Set-AzureRmVMOSDisk -VM $newvm -VhdUri $osDiskVhdUri -name $osDiskName -CreateOption attach -Windows

#Create VM
New-AzureRmVM -ResourceGroupName $rgname -Location $locName -VM $newvm

Verify that VM is running in the target subscription and all disks are attached.

Note: latest AzureRM (3.5.0) module doesn’t output status of VM creation (it’ll be corrected in future releases). Use Azure Portal instead.

FAQ

How to run synchronous copy in AzCopy?

Place /SyncCopy parameter to the end of the AzCopy command above. It ensures that the copy operation will get consistent speed. AzCopy performs the synchronous copy by downloading the blobs to copy from the specified source to local memory, and then uploading them to the Blob storage destination. It’s recommended to prepare VM in the source subscription and run AzCopy from there to avoid egress cost

Should I pay for traffic during migration?

If you are moving data within the same region, you don’t have to pay for it. It’s free. Additional costs required only for moving data between different regions.

What’s the maximum speed of data transferring?

It depends on VM and storage types. Basically, for standard accounts it’s up to 60 Mb/s. Premium storage accounts can provide throughput up to 200 Mb/s. In the real world throughput can vary widely.
Example: about 1 Tb were migrated in 14 hours between subscriptions with standard accounts, VMs with Ax size and within the same region