Troubleshooting Windows activation failures on Azure VMs

Azure uses the following KMS endpoints for Windows product activation of Azure Virtual Machines:

  • Azure public cloud regions - kms.core.windows.net:1688
  • Azure China national cloud regions -  kms.core.chinacloudapi.cn:1688
  • Azure Germany national cloud regions - kms.core.cloudapi.de:1688
  • Azure US Gov national cloud regions - kms.core.usgovcloudapi.net:1688

Azure VMs will activate using the Azure KMS service if all of the following are true:

  1. Windows is configured with the appropriate KMS client setup key for that version of Windows.
  2. Windows is configured to use the Azure KMS service, e.g. kms.core.windows.net:1688 for VMs in Azure public cloud regions.
  3. VM has network connectivity to the KMS endpoint, e.g. kms.core.windows.net:1688 for VMs in Azure public cloud regions. For example, if the guest OS firewall or an Azure network security group (NSG) rule does not allow TCP port 1688 outbound, the activation request will be blocked.
  4. Source IP address of KMS activation requests from the VM must be an IP address within the Azure IP ranges. This is necessary because the Azure KMS service only allow requests through if the source IP is within the Azure IP ranges. If you are using ExpressRoute, please see Azure VM may fail to activate over ExpressRoute. If you are using site-to-site VPN please see Use Azure custom routes to enable KMS activation with forced tunneling.

Windows activation works the same way regardless if the VM is using Azure Hybrid Use Benefit (HUB) or not.

Note that while using an Automatic Virtual Machine Activation (AVMA) key may work on some Azure VMs, the use of AVMA keys is not supported because not all Azure hosts are guaranteed to support it. So while it may work initially, when the VM moves to a different Azure host when deallocated and started, when the Redeploy option is used, or when planned maintenance occurs, it may end up on an Azure host that does not support AVMA.

Run slmgr.vbs /dlv from within the VM to check #1 and #2 above. In the example below, VOLUME_KMSCLIENT is what tells you a KMS client setup key was used, and Registered KMS machine name: kms.core.windows.net:1688 is what confirms that it is configured to activate against the Azure KMS service. Note that the KMS endpoint differs for public versus national cloud regions as listed at the beginning of this article.

 C:\>cscript c:\windows\system32\slmgr.vbs /dlv
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

Software licensing service version: 10.0.14393.351

Name: Windows(R), ServerDatacenter edition
Description: Windows(R) Operating System, VOLUME_KMSCLIENT channel
Activation ID: 21c56779-b449-4d20-adfc-eece0e1ad74b
Application ID: 55c92734-d682-4d71-983e-d6ec3f16059f
Extended PID: 03612-03764-000-000000-03-1033-14393.0000-1642017
Product Key Channel: Volume:GVLK
Installation ID: 009858430382850574122213203392636030969202304948320740858134404
Partial Product Key: 8XDDG
License Status: Licensed
Volume activation expiration: 258206 minute(s) (180 day(s))
Remaining Windows rearm count: 1000
Remaining SKU rearm count: 1000
Trusted time: 6/14/2017 6:24:25 PM
Configured Activation Type: All

Most recent activation information:
Key Management Service client information
 Client Machine ID (CMID): 54653727-addd-4b5f-bde9-824359786b75
 Registered KMS machine name: kms.core.windows.net:1688
 KMS machine IP address: 23.102.135.246
 KMS machine extended PID: 06401-00206-001-010007-03-1033-9600.0000-2322016
 Activation interval: 120 minutes
 Renewal interval: 10080 minutes
 KMS host caching is enabled

If slmgr.vbs /dlv shows RETAIL channel, run the following commands to set the KMS client setup key for the version of Windows Server 2016 being used, and force it to retry activation.

 cscript c:\windows\system32\slmgr.vbs /ipk <KMS client setup key>
cscript c:\windows\system32\slmgr.vbs /ato

For example, for Windows Server 2016 Datacenter, you would run:

 cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG

This step is not necessary for VMs created from the Windows Server 2016 gallery image, as the gallery image has the appropriate KMS client setup key already configured.

For activation issues involving Windows Server 2016 VMs failing to activate despite having the KMS client setup key configured, or for activation issues with Azure VMs using other versions of Windows, please review the remaining steps below.

Windows VMs should be configured with the KMS client setup key for the version of Windows being used, and have connectivity to port 1688 at kms.core.windows.net in order to activate successfully.

If you are using site-to-site VPN with forced tunneling, please see Use Azure custom routes to enable KMS activation with forced tunneling.

If you are using ExpressRoute with a default route published, please see Azure VM may fail to activate over ExpressRoute.

If your Azure VM experiences Windows activation failures, please try the following steps to resolve the issue. An example of an error message you may see is:

 Error(s):  Activating Windows(R), ServerDatacenter edition
 Error: 0xC004F074 The Software Licensing Service reported that the computer could not be activated. No Key Management Service (KMS) could be contacted. Please see the Application Event Log for additional information.

Note that when the grace period has expired and Windows is still not activated, Windows Server 2008 R2 and later versions of Windows will show additional notifications about activating, the desktop wallpaper remains black, and Windows Update will install security and critical updates only, but not optional updates. See also the Notifications section at the bottom of the Licensing Conditions TechNet page.

Steps to Troubleshoot Activation

  1. Download and extract the Psping tool to a local folder in the VM that is failing to activate.https://technet.microsoft.com/en-us/sysinternals/jj729731.aspxTo download the file, first go to Server Manager, Configure this local server, select IE Enhanced Security Configuration, and select Off under Administrators.
  2. Go to Start, search on Windows PowerShell, right-click Windows PowerShell and select Run as administrator.
  3. Make sure the VM is configured to use the Azure KMS server by running the following command. This is set at VM creation, so running this command is just a troubleshooting step to make sure the proper configuration is set.iex "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms kms.core.windows.net:1688" The command should return:Key Management Service machine name set to kms.core.windows.net:1688 successfully.  Note that the KMS endpoint differs for public versus national cloud regions as listed at the beginning of this article, so if the VM is in a national cloud region (e.g. China, Germany, or US Gov), replace kms.core.windows.net:1688 with the relevant KMS endpoint for the region where the VM resides.
  4. Verify with Psping that you have connectivity to the KMS server. Switch into the folder where you extracted the Pstools.zip download, then run: .\psping.exe kms.core.windows.net:1688In the second-to-last line of the output, make sure you see:Sent = 4, Received = 4, Lost = 0 (0% loss) If Lost is greater than 0, the VM does not have connectivity to the KMS server. In that case, if the VM is in a virtual network and has a custom DNS server specified, you must make sure that DNS server is able to resolve kms.core.windows.net. Or, change the DNS server to one that does resolve kms.core.windows.net. Note that if you remove all DNS servers from a virtual network, VMs will then use Azure's internal DNS service, which is able to resolve kms.core.windows.net.Aside from DNS issues, verify the guest firewall has not been configured in such a way that would block activation attempts. Note that the KMS endpoint differs for public versus national cloud regions as listed at the beginning of this article, so if the VM is in a national cloud region (e.g. China, Germany, or US Gov), replace kms.core.windows.net:1688 with the relevant KMS endpoint for the region where the VM resides.
  5. After verifying successful connectivity to kms.core.windows.net:1688 (or the respective KMS endpoint for the national cloud region where the VM is running) run the following command from that elevated PowerShell prompt. This command attempts activation multiple times in a row.1..12 | % { iex "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato" ; start-sleep 5 } Successful activation will return:Activating Windows(R), ServerDatacenter edition (12345678-1234-1234-1234-12345678) ...
    Product activated successfully.
  6. If activation still failed, and the VM is running Windows Server 2012 R2 Datacenter, Standard, or Essentials, try the command below for the specific SKU. You can verify the OS version by going to Start, searching on Msinfo32, double-clicking Msinfo32.exe, and looking at the OS Name in the right pane.For Windows Server 2012 R2 Datacenter, run the following from the elevated PowerShell prompt:iex "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ipk W3GGN-FT8W3-Y4M27-J84CP-Q3VJ9" For Windows Server 2012 R2 Standard, run the following from the elevated PowerShell prompt:iex "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ipk D2N9P-3P6X9-2R39C-7RTCD-MDVJX" For Windows Server 2012 R2 Essentials, run the following from the elevated PowerShell prompt:iex "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ipk KNC87-3J2TX-XB4WP-VCPJV-M4FWM" After entering the specific command above for the SKU of Windows Server 2012 R2 the VM is using, try activating again:iex "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato"
  7. At this point if you are still unable to activate the VM, check the Application event log for events from source Microsoft-Windows-Security-SPP to help understand why activation is failing.

If you are still unable to activate after attempting the above steps, let us know in the comments or contact Azure support.