Windows 11 Enterprise Upgrade via Intune - Activation Fails with 0x8007007B

Hi all,

We are in the process of upgrading our fleet from Windows 11 Pro to Windows 11 Enterprise using Intune and our Microsoft 365 G3 and G5 licenses (Subscription Activation).

We created an “Edition upgrade and mode switch” configuration profile in Intune, specifying Windows 10/11 Enterprise as the edition and using the GVLK key (NPPR9-FWDCX-D2C8J-H872K-2YT43). The upgrade technically worked — the device shows as Windows 11 Enterprise — but Windows is not activating, and instead gives the following error:

“We can’t activate Windows on this device as we can’t connect to your organization’s activation server… Error code: 0x8007007B”

We now understand this is because the GVLK key triggers KMS-based activation, which we don’t use. Our environment is:

Azure AD-joined devices (not Hybrid)

• Users are licensed with Microsoft 365 G3 and G5

Internet access is available

We intend to use Windows Subscription Activation, not KMS or MAK

We removed the Intune edition upgrade profile, ran slmgr /upk, rebooted, and tried to force activation via slmgr /ato — still no change

We’ve confirmed that the users are correctly licensed for Windows Enterprise, and dsregcmd /status shows AzureAdJoined: YES and DeviceAuthStatus: SUCCESS.

At this point, the devices are stuck on Windows 11 Enterprise and won’t activate, and we’re not sure how to reset the activation mechanism to allow Subscription Activation to kick in.

Questions:

How can we force the device to use Subscription Activation instead of looking for a KMS host?

Is there a supported way to reset or re-trigger the subscription-based activation flow?

1. Should we downgrade the edition to Pro first, and then let Subscription Activation re-upgrade to Enterprise?
2. Anything else we need to try? Background: We have had G3 and G5 licenses assigned to users for a while now and have been running on Win 11 Pro with NO auto activation to Enterprise. We did not notice this until recently, when Intune configuration profiles were not properly applying to devices.

Any help would be greatly appreciated — we’re trying to ensure that this process works silently and automatically, without end-user involvement.

Thanks!