Compartir a través de

Troubleshooting Windows activation failures on Azure VMs

  • Artículo

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.

Comments

  • Anonymous
    December 23, 2014
    The comment has been removed

  • Anonymous
    December 24, 2014
    HI Dave, With a vanilla environment, it doesn't sound like you have ExpressRoute configured, but if you do, make sure you have public peering enabled if you are advertising a default route. I've updated the blog post with that information. Otherwise, since the VMs are 2012 R2 Datacenter, you can run these commands to use the AVMA key: iex "$env:windirsystem32cscript.exe $env:windirsystem32slmgr.vbs /ipk Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW" iex "$env:windirsystem32cscript.exe $env:windirsystem32slmgr.vbs /ato" Or to run them from elevated CMD instead of PowerShell: %windir%system32cscript.exe %windir%system32slmgr.vbs /ipk "Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW" %windir%system32cscript.exe %windir%system32slmgr.vbs /ato Also, the step to loop the activation attempt multiple times has worked for many customers when a single manual activation attempt, and Windows own automatic attempts every 2 hours - did not work. So make sure you have tried that. We continue to investigate the issue internally, since activation should be automatic and should not require a manual attempt, let alone multiple manual attempts. 1..12 | % { iex "$env:windirsystem32cscript.exe $env:windirsystem32slmgr.vbs /ato" ; start-sleep 5 } Thanks, Craig

  • Anonymous
    December 24, 2014
    I did let that other script run 12 times as specified, but it failed each time. I did it a few times on multiple VMs, vNets, Cloud Services and Geographies and they all had the same issue. Fortunately, the AVMA key worked as you described and I can move forward with confidence that I won't have to redo this work. Thanks for taking the time to answer.

  • Anonymous
    December 24, 2014
    HI Dave, We did make a change just yesterday to address this issue of unexpected activation failures, so I suspect if you had retried the normal method today (slmgr.vbs /ato), it would have worked. Sorry for the frustrating experience, but glad you got it working and hope you have a good holiday. Thanks, Craig

  • Anonymous
    December 28, 2014
    I too am having the same problem with my VM.  However, msinfo reports that the OS is Windows Server 2012 Datacenter, but NOT R2.  Could that be why the product key above isn't working like it did for Dave? Nathan

  • Anonymous
    December 28, 2014
    The comment has been removed

  • Anonymous
    December 29, 2014
    The comment has been removed

  • Anonymous
    December 29, 2014
    Step 6 speaks to Windows Server 2012 R2.  What are the steps for 2012 R1 as I am running into that issue on R1? Also to Brian Rota's point why do you need to pay for support to spin up a server?

  • Anonymous
    December 29, 2014
    What we apparently need is the Azure key to vanilla Windows Server 2012 datacenter. So how about it support team?

  • Anonymous
    December 29, 2014
    MS confirmed KMS issues going on.  No work around at this time.  I have suggested they add the KMS Server to their Services Dashboard given everything looks green and yet they have issues going on at least a week.

  • Anonymous
    December 30, 2014
    The comment has been removed

  • Anonymous
    December 30, 2014
    for Windows Server 2012 Datacenter use in CMD %windir%system32cscript.exe %windir%system32slmgr.vbs /ipk "48HP8-DN98B-MYWDG-T2DCC-8W83P"

  • Anonymous
    December 30, 2014
    Found that key already on TechNet and used it. Still getting Key Server not located.

  • Anonymous
    December 30, 2014
    To be clear, expected behavior for Azure VMs regardless of Windows version is that they will automatically activate and do not require a product key be manually entered. The product key method, which has been suggested only as a troubleshooting step due to the current issue with KMS activation, only works for 2012 R2. It does not work for 2012 or 2008 R2. That is because it is using the Automation Virtual Machine Activation (AVMA) feature that is 2012 R2-only. The PowerShell command was suggested as an easy way to retry activation quickly multiple times, which we have seen work for the current issue that is being investigated. But it is no different than running cscript.exe %windir%system32slmgr.vbs /ato several times in a row. We apologize for the delay in getting this issue fully resolved so that all Windows versions automatically activate. Azure technical support options are detailed on the following page: azure.microsoft.com/.../options

  • Anonymous
    January 28, 2015
    Hello, I signed up with Azure Portal and provided my credit card info. After half an hour, i got an email saying that the system refused my application. Please help me with this. What do i need to do to open an Aruze account of Microsoft ? Thanks ( TraceyN2015@hotmail.com )

  • Anonymous
    February 01, 2015
    Hi Tracy, This page outlines the Azure support options. azure.microsoft.com/.../options Thanks, Craig

  • Anonymous
    August 13, 2015
    MSDN Windows 10 Enterprise RTM gallery images won't activate. Any help is appreciated. Was unable to use the support portal since I don't have the information that it is asking for to link to MSDN.

  • Anonymous
    December 16, 2015
    If you just created a new Windows 2012 R2 Azure VM and you are bugged by the fact that it says " Windows is not activated" - then just activate with the Datacenter Key used in this post : "W3GGN-FT8W3-Y4M27-J84CP-Q3VJ9". Issue resolved! If you are using "forced Tunneling" including the use of express routes - then clearly there are more ongoing issues as stated above.