You are browsing the archive for Windows Server 2012 R2.

Hyper-V: Automatic Virtual Machine Activation

8:25 am in Automatic Virtual Machine Activation, AVMA, Hyper-V, PowerShell, PowerShell Direct, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 by Wim Matthyssen


With the release of Windows Server 2012 R2 back in 2013, Microsoft introduced a feature called Automatic Virtual Machine Activation (AVMA). AVMA handles the activation process of any of your Hyper-V virtual machines (VMs) running on a physical Hyper-V host which is properly licensed with a Windows Server Datacenter license. In this way you do not have to deal with managing the product keys for each individual VM.

The VM activation process, which binds the VMs activation to the licensed Hyper-V host, takes place during the startup process of the VM. Because the activation takes place between the VM and the Hyper-V host it resides on, you are even able to license VMs in completely isolated environments or remote locations without any Internet connection. When the guest OS is activated, it only rechecks its activation against the host until the next VM reboot, or after 7 days.


Requirements for AVMA

  • A Hyper-V host running a Datacenter Edition of Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019. Keep in mind that if you migrate an AVMA licensed VM to a Hyper-V host which is not licensed with a Windows Server Datacenter license, the VM will become unlicensed. In this case you should replace the AVMA key in the VM with another valid non AVMA license key.
  • The Hyper-V Data Exchange Service (KVP), which is part of the Integration Services must be enabled on the VM.
  • In the VM itself the Microsoft Hyper-V Activation Component Driver should have an enabled device status and should be working properly.
  • AVMA does not work with other Virtualization Server technologies.


Supported Guest Operating Systems for AVMA

Only Windows Server guests are covered by AVMA. The below table shows which guests can be activated by each different Hyper-V host version. All server editions (Datacenter, Standard or Essentials) installed with Desktop Experience or Server Core can be activated.


*AVMA in Windows Server 2019 can also activate Windows Server version 1809, 1803 and 1709.



The following keys can be used to activated the specific guest operating system of a VM.

Windows Server 2019


Windows Server version 1809


Windows Server version 1803 and 1709


Windows Server 2016


Windows Server 2012 R2



Configure AVMA

1) First of all, you should verify that the Data Exchange option is enabled in the Integration Services for the VM.  To ensure this open Hyper-V Manager and right-click the VM and click on Settings…


2) On the Settings Windows, under Management select Integration Services and verify that Data Exchange is marked.


You can also use PowerShell to see if the Data Exchange service is enabled. To get a list of the running Integration Services of a VM, run the following command (replace the VM name by your own) in a PowerShell window (as Administrator) on the Hyper-V host hosting the VM:


To turn on the “Key-Value Pair Exchange” service when it is disabled you need to run the following command:


3) To install an AVMA key in a VM (in my example for a Windows Server 2019 VM), run the following command in a PowerShell window (as Administrator) on the VM.


*The AVMA key can also be provided during an Unattended setup using a unattend.exe setup file. In this way the key is already injected during the build phase of that particular VM.

You can also use PowerShell Direct from the Hyper-V host to activated a specific AVMA key for a VM running on the host. Open a PowerShell window (as Administrator) on the Hyper-V host and run following command:



4) You can verify the correct installation of the AVMA key, by opening All settings – Update & Security – Activation in the VM.


4) You can also verify the VM’s AVMA activation status on the Hyper-V host by opening the Event Viewer and searching for Event ID 12310.





I hope this blog post did learn you something about AVMA and that this feature eases your VM activation process. If you have any questions, always feel free to contact me through my twitter handle.

Wim Matthyssen (@wmatthyssen).

PowerShell: BgInfo Automation script for Windows Server 2012 R2

10:09 am in Bg, BgInfo, Hyper-V, PowerShell, PowerShell Script, scugbe, VM Template, Windows Server, Windows Server 2012 R2, Windows Sysinternals by Wim Matthyssen

Sometime ago I already wrote a PowerShell script to install the BgInfo tool in an automated way whenever you create a VM Template or a base image (also called golden image) for a Windows Server 2016 Virtual Machine (VM) or physical server, which can be donwloaded here. More information can be found int this previous blog post:

To return to the current blog post and like you can already figure out from the title, now I also wrote a script to automate the BgInfo installation and configuration for a Windows Server 2012 R2 server (VM or physical server).

This PowerShell script will do all of the following:

  • Download the latest BgInfo tool
  • Create the BgInfo folder on the C drive
  • Extract and cleanup the file
  • Download the logon.bgi file which holds the preferred settings
  • Extract and cleanup the file
  • Create the registry key (regkey) to AutoStart the BgInfo tool in combination with the logon.bgi config file
  • Start the tool for the first time
  • Set to start up automatically whenever a user logs on to the server



Windows PowerShell 4.0


PowerShell script

To use the script copy and save the above as BgInfo_Automated_WS2012_R2_v1.0.ps1, or whatever name you prefer. Afterwards run the script with Administrator privileges from the server you wish to use for your VM template or physical base image. If you want to change configuration settings, just open the logon.bgi file and adjust the settings to your preferences.

This PowerShell script can also found on the TechNet Gallery:






Hope this script comes in handy for you. If you have and questions or recommendations, please feel free to contact me through my twitter handle.

Wim Matthyssen (@wmatthyssen)

Azure IaaS: Troubelshooting Windows Update error 8024402F

3:31 pm in 8024402F, ARM, ASM, Azure, hybrid cloud, PowerShell, Windows Server 2012 R2, Windows Update, WSUS by Wim Matthyssen

Last week I was troubleshooting a Windows Update issue at several Azure IaaS VMs for a customer. All those Windows Server 2012 R2 servers were workgroup members and had no Network Security Group (NSG) attached which could block the connection to the Microsoft Update servers. But whenever starting Windows Update the below error was shown after a few minutes.


To get this error fixed I followed the below steps. Be aware that you can retry running Windows Update again after each step because it could be already working again.


Step 1

If the server has been configured to use WSUS to get its updates, first wipe out those registry keys by running the below command in a PowerShell window (with admin privileges). Press Y to delete all registry keys when asked:



This also may reset some Windows Update settings, for instance, the one that decides if updates should install automatically or after asking permission.  Therefore, you need to set your preferred settings afterwards.

Check for updates using Windows Update and see if the issue has been resolved, if not proceed to step 2.


Step 2

If you still receive the same error, run the following PowerShell Script to rename the SoftwareDistribution and catroot2 folder. These folders, which are maintained by the WUAgent (Windows Update Agent), are essential components for Windows Update. However, sometimes the content of these folders could prevent Windows Update from applying new updates to the server. When having trouble with Windows Update, it is safe to delete this folder. The server will always re-download all the necessary files, or re-create the folder and re-download all the components, if removed.


Now please check for updates using Windows Update to see if the issue has been resolved.


Step 3

If step 2 also does not fix the problem, you could try running the below command from an elevated PowerShell window. This command will import proxy information used by Internet Explorer in the Windows HTTP Services (WinHTTP). Several server roles, like the Microsoft Windows Update client, rely on WinHTTP to manage all HTTP and HTTPS traffic. Windows Update uses it mainly to scan for available updates.



Step 4

As a last solution, you could try running the Windows Update Troubleshooter tool. To download and startup this tool run the below PowerShell commands.


When the tool opens, go through all steps to get Windows Update fixed.

If all goes well, Windows Update should be working again by the use of one of the above steps. Hope it helps and if you have any questions feel free to contact me through my twitter handle.

Wim Matthyssen (@wmatthyssen)