Windows Activation Watermark Persists on VMs: Troubleshooting & Solutions

Updated: 25 Jun, 2025 • 0 • min read

Table of Contents

This document provides guidance on troubleshooting and resolving the persistent Windows activation watermark issue encountered on Microsoft Azure virtual machines running specific Windows Server editions. The issue primarily affects Windows Server 2025 Datacenter Azure Edition and Windows Server 2022 Datacenter Azure Edition when they fail to maintain their activated state correctly within the Azure environment.

Resolving Windows Activation Watermark on Azure VMs

These specific editions are designed to leverage Azure’s infrastructure for validation, offering unique benefits tied to running within the Azure or supported Azure Stack environments. A failure in this validation process results in the operating system displaying activation warnings, despite seemingly being on a valid platform.

Applicable Editions¶

This troubleshooting guide applies to the following Azure VM operating systems:
- Windows VMs running Windows Server 2025 Datacenter Azure Edition
- Windows VMs running Windows Server 2022 Datacenter Azure Edition

Understanding that these editions rely on Azure-specific mechanisms for activation is crucial for diagnosing and resolving activation problems. The activation process is integrated with Azure’s platform services to ensure licensing compliance and enable platform-specific features.

Symptoms¶

Users operating Azure VMs with the specified Windows Server Datacenter Azure Edition versions may observe several symptoms indicating a problem with the Windows activation status. These symptoms typically manifest shortly after the VM is deployed or restarted, or after certain system changes are made.

A prominent symptom is the presence of a watermark overlay on the desktop. This watermark typically displays a message similar to:

Activate Windows. Go to Settings to activate Windows.
This persistent visual indicator signifies that the operating system’s validation against the Azure platform is failing, leading the system to believe it is in an unactivated state.

Navigating to the Windows Settings application provides further confirmation of the issue. Under Settings > System > Activation, the status displayed often indicates an activation failure. This screen provides a centralized location to view the current activation state and initiate troubleshooting, though manual attempts to activate through this interface may not resolve the underlying problem if it stems from platform integration issues.

Executing the slmgr.vbs script, a standard Windows tool for managing licensing, can sometimes provide misleading results in this scenario. Running cscript c:\windows\system32\slmgr.vbs /dlv from an elevated Command Prompt might report a successful Key Management Services (KMS) activation. While KMS is part of the standard Windows volume activation mechanism, the Azure Edition requires an additional layer of validation against the Azure platform, which the slmgr output might not fully reflect or may show as successful even if the Azure-specific validation is failing.

Another clear symptom is a pop-up notification that appears upon restarting the VM or signing in. These pop-ups explicitly state that the Windows Server Datacenter Azure Edition VM has been deactivated. The messages typically provide a reason related to not running on Azure or a supported Azure Stack hypervisor, or that Azure benefits have not been enabled. These messages directly point towards a failure in the Azure platform validation component of the activation process.

Messages like the following are common:
- “Your Windows Server 2022 Datacenter Azure Edition VM has been deactivated because you are not running on Azure or a supported Azure Stack hypervisor, or that you have not enabled Azure benefits on the supported Azure Stack. To enable Azure benefits, go to your cluster settings in Windows Admin Center > Enable Azure benefits.”
- “Your Windows Server 2025 Datacenter Azure Edition VM has been deactivated because you are not running on Azure or a supported Azure Stack hypervisor, or that you have not enabled Azure benefits on the supported Azure Stack. To enable Azure benefits, go to your cluster settings in Windows Admin Center > Enable Azure benefits.”
These messages highlight the critical dependency of Azure Edition VMs on the underlying Azure platform services for their activation status.

Cause 1: Azure Instance Metadata Service Connection Issue¶

One primary reason for the activation watermark to persist is the inability of the Azure VM’s guest operating system to establish a connection with the Azure Instance Metadata Service (IMDS). IMDS is a critical component within Azure that provides information about the running virtual machine instance, including its identity, configuration, and importantly for activation, a digitally signed attestation document.

The IMDS endpoint is accessible from within the VM at a specific, non-routable IP address: 169.254.169.254. This address is part of the link-local range and is only accessible from the VM itself, communicating directly with the Azure host infrastructure. Communication with IMDS never traverses the public internet or even the virtual network beyond the host node. The activation token for Azure Edition VMs is obtained through IMDS, and if this communication path is blocked or misconfigured, the VM cannot validate its environment and thus fails activation.

How to Determine if the VM Guest OS Can Successfully Communicate with IMDS¶

To diagnose whether the VM can successfully connect to and retrieve data from the IMDS endpoint, you can use PowerShell scripts. These scripts attempt to query the IMDS endpoint for instance metadata or an attested document, and a successful response indicates that the basic communication path is open.

For PowerShell 6 and later versions, you can use the Invoke-RestMethod cmdlet with the -NoProxy parameter to explicitly bypass any configured web proxies that might interfere with the connection to the link-local address.

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri http://169.254.169.254/metadata/attested/document?api-version=2020-09-01 | Format-List * | Out-File "IMDSResponse1.txt"

For PowerShell 5 and earlier versions, the -NoProxy parameter is not available. Instead, you need to explicitly configure the WebSession object to use a default proxy or no proxy, effectively bypassing system-wide proxy settings for this specific request.

$Proxy=New-object System.Net.WebProxy
$WebSession=new-object Microsoft.PowerShell.Commands.WebRequestSession
$WebSession.Proxy=$Proxy
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/instance?api-version=2021-02-01" -WebSession $WebSession

If the IMDS communication is successful, the script will return detailed metadata about the VM instance. This output confirms that the network path to 169.254.169.254 from within the VM is open and responsive. The metadata includes information like the VM’s location, name, offer type, and other configuration details, presented in a structured format.

Example of successful output:

compute
-------
@{azEnvironment=AzurePublicCloud; customData=; evictionPolicy=; isHostCompatibilityLayerVm=true; licenseType=; location=eastus; name=testWs; offer=WindowsServer; ...

If the command fails, times out, or returns an error indicating that the remote server could not be reached, it confirms that the connection to the IMDS endpoint (169.254.169.254) is blocked. This blockage could be due to various reasons, including firewall rules, misconfigured routing, or proxy settings within the guest operating system that do not correctly bypass the link-local address. Resolving this network connectivity issue is the focus of Solution 1.

The IMDS service provides an attested document which is a digitally signed JSON payload containing metadata about the VM. This signature is verifiable using a certificate chain issued by Microsoft Azure. The operating system needs to trust this certificate chain to validate the authenticity of the attested document received from IMDS. If intermediate certificates within this chain are missing, expired, or not trusted by the VM’s certificate store, the system cannot verify the signature, leading to a failure in the Azure-specific activation validation process.

Microsoft Azure uses specific Certificate Authorities (CAs) to issue certificates for services like IMDS attestation. Over time, root and intermediate CA certificates may change or require updates. If the VM’s certificate store is not up-to-date or if network restrictions prevent the VM from downloading necessary certificates or Certificate Revocation Lists (CRLs), the trust chain for the IMDS attestation certificate cannot be completed or validated.

How to Determine if Any Certificates Are Missing¶

You can use a PowerShell script to fetch the attested document from IMDS, extract the signature, and attempt to build the certificate chain used to sign it. If the chain cannot be built successfully, the script can identify which certificate in the chain is missing or untrusted.

The script fetches the attested document, decodes its signature (which contains the certificate chain), and then attempts to build an X.509 certificate chain object. If the Build method fails, it iterates through the chain elements (or just prints the issuer of the signing certificate if the build fails immediately) to show which certificate’s issuer is not found in the trusted stores.

# Get the signature
# Powershell 5.1 does not include -NoProxy
$attestedDoc = Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri http://169.254.169.254/metadata/attested/document?api-version=2018-10-01
#$attestedDoc = Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri http://169.254.169.254/metadata/attested/document?api-version=2018-10-01

# Decode the signature
$signature = [System.Convert]::FromBase64String($attestedDoc.signature)

# Get certificate chain
$cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]($signature)
$chain = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Chain

if (-not $chain.Build($cert)) {
   # Print the Subject of the issuer
   Write-Host $cert.Subject
   Write-Host $cert.Thumbprint
   Write-Host "------------------------"
   Write-Host $cert.Issuer
   Write-Host "------------------------"
   Write-Host "Certificate not found: '$($cert.Issuer)'" -ForegroundColor Red
   Write-Host "Please refer to the following link to download missing certificates: (Note: Original article link removed as per instructions)" -ForegroundColor Yellow
} else {
   # Print the Subject of each certificate in the chain
   foreach($element in $chain.ChainElements) {
       Write-Host $element.Certificate.Subject
       Write-Host $element.Certificate.Thumbprint
       Write-Host "------------------------"
   }

   # Get the content of the signed document
   Add-Type -AssemblyName System.Security
   $signedCms = New-Object -TypeName System.Security.Cryptography.Pkcs.SignedCms
   $signedCms.Decode($signature);
   $content = [System.Text.Encoding]::UTF8.GetString($signedCms.ContentInfo.Content)
   Write-Host "Attested data: " $content
   $json = $content | ConvertFrom-Json
}

If the script output indicates that a certificate is not found or the chain building fails with an untrusted root error, it confirms a certificate issue. A common output indicating a missing intermediate CA might look like this:

CN=metadata.azure.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US
3ACCC393D3220E40F09A69AC3251F6F391172C32
------------------------
CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US
------------------------
Certificate not found: 'CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US'
Please refer to the following link to download missing certificates: (Note: Original article link removed as per instructions)

This output shows that the certificate signing the IMDS data (Subject: CN=metadata.azure.com) was issued by ‘CN=Microsoft Azure RSA TLS Issuing CA 04’, and the VM’s system could not find or trust this intermediate CA or a subsequent CA in its chain. Resolving this requires ensuring the necessary Azure CA certificates are present and trusted in the VM’s certificate store, which is covered in Solution 2.

Solution 1: Bypass Web Proxies Within the VM¶

The Azure Instance Metadata Service is designed to be accessible directly from the VM guest operating system at the fixed IP address 169.254.169.254. This address is not routable outside the Azure host. Network requests directed to this IP should not go through traditional network gateways or web proxies configured within the VM or on the virtual network.

If a web proxy is configured (either via Internet Options, group policy, or application-specific settings), it must be configured to bypass the 169.254.169.254 IP address. Similarly, the VM’s network configuration should ensure a direct route exists to this address. The 169.254.169.254 IP should ideally be treated like the Azure DNS IP 168.63.129.16, which also requires a direct route.

To verify the network path and configuration within the VM, you can examine the local routing table and IP configuration.

Examine the Routing Table: Open Command Prompt or PowerShell as administrator and run the route print command. This command displays the active routes configured on the VM.
```
route print
```
Look for the IPv4 Route Table section and specifically examine the Active Routes. You need to find an entry where the Network Destination is 169.254.169.254 and the Netmask is 255.255.255.255. This entry dictates how traffic destined for the IMDS IP is routed. The Gateway and Interface columns for this route are particularly important.

Example route print output snippet:
```
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      172.16.69.1    172.16.69.7     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
      127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      168.63.129.16  255.255.255.255      172.16.69.1    172.16.69.7     11
    **169.254.169.254**  255.255.255.255      172.16.69.1    **172.16.69.7**     11
===========================================================================
```
In this example, the route for 169.254.169.254 points to 172.16.69.1 as the gateway, using the 172.16.69.7 interface. The gateway IP 172.16.69.1 in this context is the Azure host’s gateway address accessible via the VM’s primary network interface.
Verify Network Interface Configuration: Use the ipconfig /all command to view the detailed IP configuration of all network adapters on the VM.
```
ipconfig /all
```
Match the Interface IP address found in the route print output for 169.254.169.254 (e.g., 172.16.69.7) to one of the network adapters listed in the ipconfig /all output. Identify the network adapter that holds this IP address. Note its Physical Address (MAC address) and IPv4 Address.

Example ipconfig /all output snippet:
```
Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : xic3mnxjiefupcwr1mcs1rjiqa.cx.internal.cloudapp.net
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 00-0D-3A-E5-1C-C0
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::3166:ce5a:2bd5:a6d1%3(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.69.7(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 172.16.69.1
```
This confirms the VM’s primary network adapter (named “Ethernet”) has the IP 172.16.69.7 and MAC address 00-0D-3A-E5-1C-C0, matching the interface identified in the route table for IMDS traffic.
Compare VM Guest OS IP/MAC with Azure Configuration: It’s essential that the primary IP address and MAC address reported by the guest OS match what Azure expects for the VM’s primary network interface. You can get this information from the Azure portal or using Azure CLI.

Using Azure CLI (in a PowerShell script):
This script lists network interfaces attached to the VM and shows their primary status and MAC addresses.
```
# Placeholder variable definitions
$ResourceGroup = "<resource-group-name>"
$VmName = "<virtual-machine-name>"

# Code
$NicNames = az vm nic list --resource-group $ResourceGroup --vm-name $VmName | ConvertFrom-Json | Foreach-Object { $_.id.Split('/')[-1] }
foreach($NicName in $NicNames)
{
    az vm nic show --resource-group $ResourceGroup --vm-name $VmName --nic $NicName | ConvertFrom-Json | Format-Table -Property name, primary, macAddress
}
```
Example Azure CLI output:
```
name       primary macAddress
----       ------- ----------
wintest767    True 00-0D-3A-E5-1C-C0
```
This output shows the primary network interface named wintest767 with MAC address 00-0D-3A-E5-1C-C0.

Using Azure portal:
Navigate to the VM resource, go to the Overview page, and look under the Networking section for the Private IP address. This should match the IPv4 Address from ipconfig /all for the primary interface.

If the MAC addresses or primary IP addresses do not match between the guest OS and Azure’s configuration, there might be a networking misconfiguration, possibly related to static IP assignment within the guest OS conflicting with Azure’s DHCP, or changes made to the VM that were not fully reflected. Ensure the VM is configured to receive IP via DHCP from Azure for its primary interface. If there’s a mismatch, correcting the network configuration within the guest OS (e.g., ensuring DHCP is used or static settings match Azure exactly) and potentially restarting the networking service or the VM may be necessary. In rare cases, manual manipulation of the routing table using the route command might be considered, but it’s usually better to resolve the underlying IP configuration issue.

If web proxies are in use, configure them to bypass the 169.254.169.254 address. This can often be done in proxy settings exceptions lists.

Solution 2: Ensure Firewalls and Proxies Allow Certificate Downloads¶

The second major cause relates to the VM’s ability to validate the digital signature of the IMDS attested document. This validation requires access to the necessary Certificate Authority (CA) certificates that form a trust chain back to a root authority. These certificates are typically distributed via Windows Update or accessible online.

If firewalls (Windows Firewall, network security groups, or virtual network appliances) or proxies block access to the endpoints where Windows downloads certificate trust lists (CTLs) or Certificate Revocation Lists (CRLs), the VM cannot establish trust for the IMDS signing certificate.

Install Required Windows Updates: For Windows Server 2022, ensure that security updates, specifically those that might include updated certificate trusts or fix related issues, are installed. KB 5036909 was identified as relevant for Windows Server 2022 in the original article’s context. Check the Microsoft Update Catalog for this KB or ensure all recommended/important updates are applied via Windows Update. Applying the latest cumulative updates is often the easiest way to ensure necessary certificate components are present.
Configure Firewalls and Proxies: Verify that any firewalls (including the Windows Defender Firewall on the VM itself) and network proxies are configured to allow outbound HTTP and HTTPS traffic necessary for Windows to download certificates and CRLs. Microsoft provides documentation on the endpoints required for certificate downloads and revocation lists. Consult the official Microsoft Azure documentation regarding required firewall configurations for Azure services. Ensure your network security rules (NSGs) and any internal firewalls or proxies allow traffic to Microsoft’s certificate distribution points.
Manual Certificate Installation: As an alternative or supplementary step, you can manually download and install the required Azure CA root and intermediate certificates into the VM’s certificate store. Microsoft publishes these certificate authority chains. Download the necessary .cer or .crt files and install them. When installing, ensure you select the correct certificate store. For machine-wide trust, install the certificates for the Local Machine and place them in the appropriate stores (e.g., Intermediate Certification Authorities for intermediate CAs, Trusted Root Certification Authorities for root CAs).

Steps for manual installation:
- Download the certificate files from a trusted source (like Microsoft’s official CA details page).
- Open the Certificate Manager (certmgr.msc or certlm.msc - for Local Machine).
- Navigate to the relevant store (e.g., Intermediate Certification Authorities -> Certificates).
- Right-click, select All Tasks -> Import.
- Follow the wizard, select the downloaded .cer file, and ensure the destination store is correct (e.g., “Place all certificates in the following store” and browse to the correct one, like “Intermediate Certification Authorities”).
Run fclip.exe: After addressing the network connectivity to IMDS (Solution 1) and ensuring certificate trust (Solution 2), you need to trigger the Azure-specific activation process again. Open Command Prompt or PowerShell as administrator, navigate to c:\windows\system32, and run fclip.exe. This executable is associated with feature or platform licensing components and can help re-evaluate the activation state based on the current environment and IMDS data.
Restart or Sign In: For the activation status changes to fully take effect and for the watermark to be removed, restart the VM or sign out of the current user session and sign back in. The operating system desktop and Settings app should now reflect a successful activation status.

If both the IMDS connection and certificate validation are successful, the Azure Edition VM should correctly activate against the Azure platform, removing the watermark and resolving the activation failure messages in settings.

Additional Troubleshooting Information¶

If the issues persist after following the steps above, consider the following:
- Verify the VM is indeed running a supported Azure Edition SKU. Deploying standard Windows Server Datacenter might result in different activation behaviors.
- Check for any third-party security software or host-based intrusion prevention systems (HIPS) running on the VM that might be intercepting or blocking loopback connections or outbound network calls for certificate validation.
- Review Azure Network Security Group (NSG) rules applied to the VM’s network interface or subnet. While IMDS traffic is local to the host, NSG rules can affect general outbound connectivity needed for Windows Update or certificate downloads.
- Ensure the Windows Time Service is running and the system time is accurate. Significant time discrepancies can affect certificate validation.
- If using Azure Stack HCI, ensure the cluster is properly configured to enable Azure benefits as indicated in the activation error messages.

For more general Windows activation issues on Azure VMs, refer to broader Azure documentation on troubleshooting Windows activation problems.

Importance of Azure Edition Activation¶

Successfully activating Windows Server Datacenter Azure Edition on Azure is not just about removing a watermark. It ensures the VM is running in a properly licensed and supported configuration. Furthermore, these specific editions may unlock features or benefits that are only available when running on Azure infrastructure and validated via IMDS. Maintaining correct activation is key to a healthy and compliant Azure VM deployment using these specialized operating systems.

Conclusion¶

Troubleshooting Windows activation watermarks on Azure Edition VMs requires addressing potential issues with the VM’s ability to communicate with the Azure Instance Metadata Service and to validate the necessary security certificates. By verifying network connectivity to 169.254.169.254, ensuring web proxies are bypassed, and confirming that the VM can download and trust Azure CA certificates, you can resolve most instances of this problem. Remember to run fclip.exe and restart the session or VM after implementing fixes.

Have you encountered this issue? What steps helped you resolve it? Share your experiences and insights in the comments below.

Computacionvinchi

Windows Activation Watermark Persists on VMs: Troubleshooting & Solutions

Applicable Editions¶

Symptoms¶

Cause 1: Azure Instance Metadata Service Connection Issue¶

How to Determine if the VM Guest OS Can Successfully Communicate with IMDS¶

How to Determine if Any Certificates Are Missing¶

Solution 1: Bypass Web Proxies Within the VM¶

Solution 2: Ensure Firewalls and Proxies Allow Certificate Downloads¶

Additional Troubleshooting Information¶

Importance of Azure Edition Activation¶

Conclusion¶

Post a Comment

Windows Activation Watermark Persists on VMs: Troubleshooting & Solutions

Applicable Editions¶

Symptoms¶

Cause 1: Azure Instance Metadata Service Connection Issue¶

How to Determine if the VM Guest OS Can Successfully Communicate with IMDS¶

Cause 2: Certificate Related Issue¶

How to Determine if Any Certificates Are Missing¶

Solution 1: Bypass Web Proxies Within the VM¶

Solution 2: Ensure Firewalls and Proxies Allow Certificate Downloads¶

Additional Troubleshooting Information¶

Importance of Azure Edition Activation¶

Conclusion¶

Post a Comment