Moving away from KMS Server when moving to Modern Device Management

Simplifying Windows Licensing During the Shift to Intune and Azure AD

Many organizations are transitioning away from traditional, device‑based Windows licensing models toward a more flexible user‑based licensing approach that aligns with Microsoft’s cloud‑first strategy. At the same time, IT environments are evolving from domain‑joined, on‑premises infrastructures to Intune‑managed, Microsoft Entra ID–joined devices.

While these changes bring clear benefits, they also expose legacy assumptions around Windows activation—particularly for environments that historically relied on Key Management Services (KMS).

Moving Away from KMS‑Based Activation

In traditional environments, Windows devices commonly activated through an on‑premises KMS server. This model worked well when devices were domain‑joined and had reliable network connectivity to the KMS host.

As organizations retire on‑premises infrastructure and move devices to Entra ID join with Intune management, those same devices can no longer reach the KMS server. When this happens, devices that still have KMS client configuration (GVLKs) installed remain in an unactivated state.

This often manifests as persistent “Activate Windows” messages—especially when local or non‑enterprise users sign in. Importantly, this is not a failure of modern licensing, but rather a result of legacy KMS configuration preventing Windows from using alternative activation paths.

Understanding the Modern Windows Licensing Model

It is important to separate base OS activation from Enterprise enablement, as they are often conflated.

Base OS Activation (Device‑Based)

• Windows Pro must be activated at the device level.
• Activation typically occurs using:
  • An OEM firmware‑embedded (digital) license, or
  • A MAK (in limited or special scenarios)

Enterprise Enablement (User‑Based)

• Windows Enterprise is enabled via subscription activation.
• When a user with a qualifying Windows Enterprise license signs in:
  • Enterprise features are unlocked for that session.
• When a non‑licensed or local user signs in:
  • The device remains activated as Windows Pro.

Windows does not change the installed OS image. Instead, the edition entitlement is dynamically enabled or disabled based on the signed‑in user.

This model provides flexibility and compliance—but only if the underlying Pro activation is healthy.

Why Devices Don’t Automatically “Fall Back” from KMS

A common assumption is that if a device can no longer reach a KMS server, Windows will automatically revert to the OEM Pro license. This does not reliably happen.

If a KMS client key (GVLK) is installed:

• Windows continues to expect KMS activation
• OEM activation is not attempted
• Subscription activation cannot occur

As a result, devices remain unactivated even though a valid OEM license may still exist in firmware.

Correcting Activation Issues

To restore proper activation behavior, the legacy KMS configuration must be removed so Windows can activate using its intended base license.

Key remediation steps typically include:

• Removing the existing KMS client key
• Clearing cached licensing information
• Allowing Windows to re‑activate using the embedded OEM license
• Verifying successful Pro activation before relying on Enterprise subscription activation

Important: In most modern OEM devices, the Windows Pro license is already embedded in firmware. In many cases, you do not need to retrieve or redeploy the OEM key manually—Windows will automatically read it once KMS is removed.

Retrieving the Embedded OEM Product Key (Optional)

If verification is required, the embedded OEM key can be queried directly from firmware:

powershell "(Get-CimInstance -query 'select * from SoftwareLicensingService').OA3xOriginalProductKey"

If a key is returned, the device already has a valid OEM entitlement.

Useful Activation Commands

The Software Licensing Manager (slmgr.vbs) remains the primary tool for inspecting and correcting Windows activation state.

Typical Remediation Flow

A standard remediation process for a single device might look like this:

slmgr /upk

slmgr /cpky

• Reboot (recommended)
• Allow Windows to re‑detect the OEM license automatically
  (Manual OEM key installation is only required if activation does not occur)

If needed:

slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

slmgr /ato

slmgr /dlv

Once Windows Pro is activated successfully:

• Local users remain on Pro
• Enterprise‑licensed users receive automatic Enterprise enablement via subscription activation

Preventing Reintroduction of KMS

As part of this transition, organizations should ensure that KMS is not unintentionally reintroduced through:

• Legacy imaging or task sequences
• Volume License media with GVLKs
• Startup scripts or scheduled tasks
• Residual Group Policy settings
• Autopilot or provisioning workflows that inject KMS keys

Modern, cloud‑native provisioning should never require KMS for Windows client activation.

Improving Intune and Deployment Workflows

Many organizations use this transition as an opportunity to review their broader Intune and device lifecycle strategy. Engaging OEMs or service providers—such as Dell or Microsoft—can help identify:

• Activation and provisioning optimizations
• Autopilot and enrollment improvements
• Policy simplification opportunities
• Legacy dependency cleanup

When paired with proper license remediation, these improvements help ensure a smooth and sustainable move to modern device management.

Summary

Retiring KMS is not just a licensing change—it’s a foundational requirement for modern, cloud‑managed Windows devices. By removing legacy KMS configuration and ensuring proper Pro activation, organizations enable Windows to function exactly as designed in an Intune‑ and Entra ID‑managed world.

References

• Slmgr.vbs Options for Obtaining Volume Activation Information | Microsoft Learn
• See Also my many other articles

See Also

• My other articles on Windows Autopilot and Modern Device Management