The KB5036980 breaks the Windows 11 Enterprise Subscription Activation.

Last Updated on June 21, 2024 by rudyooms

Are you experiencing problems with the automatic upgrade from Windows 11 Pro to Windows 11 Enterprise during Autopilot on the latest Windows build? Or are your current Windows 11 Enterprise devices reverting to Windows Pro? If so, this blog is for you!

I will divide this blog into multiple parts

  1. Introduction
  2. The Issue
  3. Taking A closer look
  4. Existing Devices
  5. The Fix
  6. The Exe Code behind it
  7. The Fix from Microsoft

1. The introduction: 

While on vacation, a lot happened. Some of the things are way NDA, except maybe this one. I noticed some weird subscription activation issues during my vacation with the latest Windows 11 Update KB5036980 and build (22631.3447 2024-04).

Many people were contacting me, and they all mentioned the same issue.

Afbeelding met tekst, schermopname, Lettertype

Automatisch gegenereerde beschrijving

If you have a Microsoft 365 E3/E5 license, you are entitled to a “free” upgrade to Windows 11 Enterprise. This subscription upgrade should happen automatically when the user signs in to the device. This upgrade flow relies on the subscription activation process.

This process could cause issues and prevent the device from upgrading to enterprise. I posted a blog some time ago explaining how to fix this problem. With an easy one-liner, you can ensure that Windows 11 Pro has been upgraded to Enterprise.

Windows Pro doesn’t upgrade to Enterprise with E5 license (call4cloud.nl)

Unfortunately, that one-liner from the blog above doesn’t work with this issue. Shall we zoom in on the issue and fix it?

2. The Issue

After wiping my notebook, which I use for testing, and ensuring it had the latest Windows 11 KB5036980 Updates installed (22631.3447), I kicked off the Autopilot Enrollment.

Once the device was enrolled and the user logged in, I noticed it was still on Windows 11 Pro, which SHOULD have been upgraded to Enterprise!

Afbeelding met tekst, Lettertype, algebra

Automatisch gegenereerde beschrijving

While determining what was happening, it became clear that a specific scheduled task responsible for uplifting the license to Windows Enterprise didn’t do its job. This scheduled task has been called: licenseacquisition

Afbeelding met tekst, Lettertype, lijn, nummer

Automatisch gegenereerde beschrijving


This task launches the executable cliprenew.exe but is failing with the error: access denied: (0x80070005) 

If that scheduled task fails, the Windows License is NOT upgraded to Enterprise, and with it all off, the security-related features that are only applicable to Enterprise builds are not going to be applied

When looking closer again… it’s becoming more obvious what’s going on

3. Taking a closer look


To find out what was happening, I installed Procmon and just tried to kick off that task. With the proper filtering in place (Cliprenew and access denied), it became evident that the Cliprenew executable was attempting to create/set a new registry key called mfarequiredcliprenew.

Afbeelding met tekst, schermopname, software, Lettertype

Automatisch gegenereerde beschrijving

Cliprenew fails to create the mfarequiredcliprenew registry key. The License Acquisition is configured to run as the “Interactive” user (logged in user)

When the scheduled task is configured to run as the interactive user account, it will execute ClipRenew in the context of the logged-in user. So, in my case AzureAd\RudyOoms

As shown above, the logged-in user is NOT permitted to create registry keys within the HKLM registry keys. If that registry key is not made, the subscription activation fails. That’s weird? What happens when I manually create that key? The first attempt ended up with the same error: Access denied. To fix this, I added “everyone” with full access to this group

Afbeelding met tekst, schermopname, software, lijn

Automatisch gegenereerde beschrijving

After adding everyone with full access, it now had the power to create an additional dword in that registry node.

Afbeelding met tekst, schermopname, Lettertype, software

Automatisch gegenereerde beschrijving

As shown above, the licenseacquisition scheduled task created this dword: Verify multifactor authentication in Cliprenew with a value of 0 

Afbeelding met tekst, Lettertype, schermopname, lijn

Automatisch gegenereerde beschrijving


With this key getting manually created, the scheduled task finishes successfully, and the license is upgraded to Windows 11 Enterprise on the fly

Afbeelding met tekst, Lettertype, schermopname, algebra

Automatisch gegenereerde beschrijving

4. Existing Devices

Typically, a 90-day rearm period is in place to manage license checks and renewals on existing devices.

However, a mechanism verifies and attempts to renew the license every 30 days for devices upgraded through subscription activation.

With the installation of KB5036980, existing devices will eventually drop from Windows Enterprise to Windows Pro, depending on their update ring. This update causes the scheduled task responsible for renewing the license to fail due to a permission issue with creating necessary MFA registry keys. As a result, the device cannot maintain its Enterprise status.

With the device dropping down from Enterprise to Pro, all the security features, such as credential guard, that were working with Enterprise will stop working with Windows Pro!! If this isn’t going to cause a sh.t show…. and I event talked about the Policies only applicable to Enterprise yet…

5. The PowerShell fix option 1

If you want to fix it before Microsoft does, you must push this PowerShell script to your device during Autopilot to ensure the license acquisition scheduled task can be launched.

# Define the registry key path and value
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew"
$registryValueName = "Verify Multifactor Authentication in ClipRenew"
$registryValueData = 0  # DWORD value of 0
$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-4")  
# or SID S-1-5-4 for the interactive group

# Check if the registry key already exists
if (-not (Test-Path -Path $registryPath)) {
    # If the key doesn't exist, create it and set the DWORD value
    New-Item -Path $registryPath -Force | Out-Null
    Set-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -Type DWORD
    Write-Output "Registry key created and DWORD value added."
} else {
    Write-Output "Registry key already exists. No changes made."
}

# Add read permissions for SID (S-1-5-4,interactive users) to the registry key with inheritance
$acl = Get-Acl -Path $registryPath
$ruleSID = New-Object System.Security.AccessControl.RegistryAccessRule($sid, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($ruleSID)
Set-Acl -Path $registryPath -AclObject $acl
Write-Output "Added 'Interactive' group and SID ($sid) with read permissions (with inheritance) to the registry key."

#Start the scheduledtask
Get-ScheduledTask -TaskName 'LicenseAcquisition' | start-scheduledtask
#Start-Process "$env:SystemRoot\system32\ClipRenew.exe"

This PowerShell script will ensure that the corresponding MfaRequiredInClipRenew registry key is created with full access to the interactive user group.

If you want to fix this on existing devices that already went through Autopilot, you also need to trigger that scheduled task to acquire the proper license for the device. You can do so by adding this command to the script above!

Start-Process “$env:SystemRoot\system32\ClipRenew.exe”

6. The code behind it

Even while fixing it, it got me curious. I opened cliprenew.exe with IDA, and started digging around a bit… and it seems that it was indeed added to the cliprenew.exe in the mainhr function

Afbeelding met tekst, lijn, software, nummer

Automatisch gegenereerde beschrijving

When getting a better view by using the pseudocode, it looks like it is indeed trying to create or open the mfarequiredkey just at the first steps of the licenceactivation

Afbeelding met tekst, schermopname, Lettertype, lijn

Automatisch gegenereerde beschrijving

This part of the licenceactivation will check if a specific feature related to Multi-Factor Authentication (MFA) is enabled. If this MFACheckinClipRenew feature is enabled, it proceeds with additional actions.

The code attempts to create or open a specific registry key related to MFA: SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew.

If the registry operation is successful, it sets a DWORD value (Verify Multifactor Authentication in ClipRenew) under the specified registry key to 0.

This mfacheckincliprenew (38124097) feature was added in the Windows Insider build and now being activated in the latest Windows April Build

Afbeelding met tekst, schermopname, Lettertype

Automatisch gegenereerde beschrijving

That got me curious if I could come up with a different fix. I downloaded the Vivetool and manually disabled that feature.


After disabling it, Cliprenew was now able to uplift the license to Windows enterprise.

7. Waiting for the Fix From Microsoft

After getting more feedback, it seems that Microsoft is now aware of this issue for some time and already has a fix.

This fix will be released as a security update in the last week of June or on the second Tuesday of July (Patch Tuesday). Until then, we must watch out for this issue on new or existing devices.

Let me tell you why with two excellent reasons:

Reason 1: When all your devices are 100% up to date, suddenly, one device gives you issues. Most likely, you will send a remote wipe to that device. Guess which Windows Build it has when it needs to enroll again with Autopilot?

Reason 2: If your device has been upgraded to Enterprise using the subscription activation, it must regularly check in to keep it Enterprise. If that scheduled task cannot be executed successfully, the grace period will end, and with it, your device will be downgraded!

Once Microsoft releases the fix, I will update this blog and show you how Microsoft fixed it!

Conclusion

With the insider build, a function was added to require MFA for the subscription activation (part of the DMA SSO?), but somehow, it failed to create that registry key.

Can we give the user local admin permissions to fix it (just like the developers who wrote that code?), or will we deploy a PowerShell script that creates the required keys?

43 thoughts on “The KB5036980 breaks the Windows 11 Enterprise Subscription Activation.

  1. this may help if needing to check machines remotely.

    Get-WinEvent -FilterHashtable @{LogName=’Microsoft-Windows-TaskScheduler/Operational’} | Where-Object -Property Message -Match ‘ClipRenew.exe’ | FL

  2. Good find, thanks for the detailed write up! Got caught with this one for an hour yesterday thinking it was a license assignment issue. I can confirm the registry permission change works. Although I would rather an official fix. Is there a ticket number or similar I can reference when raising this with Microsoft?

    1. Hi.. Thanks :)… AN official fix would be very nice… but the last thing i heard about the fix was: NO eta… ..
      You can nag about it on x and tagging the Windows Team.. as there isnt an ticket number or official case number for this

  3. Well done thanks for help 🙂 We’ve had a call logged with Microsoft for over a week with no resolve

  4. I’m not sure if its related, but I suspect it could be based on the timing. We’ve started seeing issues with using Fresh Start when testing Entra Joined Autopilot profiles that Windows detects some kind of hardware change and refused to activate Windows, much less upgrade to Enterprise. I found that using Wipe instead seems to fix it. Have you noticed this or hear it from other admins? I was hoping the Microsoft fix for subscription activation was going to be in the May update, but I didn’t see anything in the release notes.

    1. Hi… mmm i didnt hear that one before.. let me test it to find out what happens.. and yeah .. its nog going to be in the may update 🙂

  5. Is it possible that this is related to the changes to LSA that were released around the 20th or 21st of march?

    I’ve been getting a lot of elevation errors, where all kinds of processes are being prevented to elevate their permissions and getting access denied on all kinds of registry settings.

  6. Is there any reason not to uncomment the ClipRenew.exe line also for use during Autopilot?

  7. From Mexico, Hi Rudy

    Thank you for the information, It´s Works in a non-Autopilot scenario, I had the problem with license activation Pro/Enterprise in some devices, I run the Powershell script Fix Option 1 and line in Powershell and works fine.

    $(Get-WmiObject SoftwareLicensingService).OA3xOriginalProductKey | foreach{ if ( $null -ne $_ ) { Write-Host “Installing”$_;changepk.exe /Productkey $_ } else { Write-Host “No key present” } }

    1. Hi.. Yep.. that a fix i was mentioning in the older blogs about subscription activation issues… but that wouldnt work with this latest kb installed unfortunately

  8. Thanks so much for saving the day again! MS could not even tell me this with a critical ticket. Any idea when we can expect an official MS patch via Win Update?

  9. Hi Rudy,

    Great article – came across the issue yesterday so glad I have found this. Scripts works a treat.

    Just a quick question if you have the answer – if a device is on a previous build (22631.2861 for example) and the April KB is installed – will the device be affected by this issue? Or since the relevant reg entry has already been created, will this be fine and keep the Enterprise status?

    1. If the device already was uplifted to enterprise no worries 🙂 only if you reset that device and enroll it with the same windows build again

  10. hi, is it possible to make a remediations script out of this? somehow combine it with this:
    detection:
    # Check Windows Activation Status
    $activation = Get-CimInstance -ClassName SoftwareLicensingProduct | ? { $_.PartialProductKey -ne $null }

    if ($activation.LicenseStatus -eq ‘1’) {
    # Windows is activated, check PartialProductKey
    if ($activation.PartialProductKey -like “3V66T”) {
    Write-output “Subscription”
    exit 0
    }
    else {
    Write-output “KMS or other method”
    exit 1
    }
    } else {
    Write-output “Not activated.”
    exit 0
    }
    remediation:
    # Check Windows Activation Status
    $activation = Get-CimInstance -ClassName SoftwareLicensingProduct | ? { $_.PartialProductKey -ne $null }

    if ($activation.LicenseStatus -eq ‘1’) {
    # Windows is activated, check PartialProductKey
    if ($activation.PartialProductKey -like “3V66T”) {
    Write-output “Subscription”
    exit 0
    }
    else {
    Write-output “KMS or other method”
    # Define the registry key path and value
    $registryPath = “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew”
    $registryValueName = “Verify Multifactor Authentication in ClipRenew”
    $registryValueData = 0 # DWORD value of 0
    $sid = New-Object System.Security.Principal.SecurityIdentifier(“S-1-5-4”)
    # SID for the Everyone group
    # or SID S-1-5-4 for the interactive group

    # Check if the registry key already exists
    if (-not (Test-Path -Path $registryPath)) {
    # If the key doesn’t exist, create it and set the DWORD value
    New-Item -Path $registryPath -Force | Out-Null
    Set-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -Type DWORD
    Write-Output “Registry key created and DWORD value added.”
    } else {
    Write-Output “Registry key already exists. No changes made.”
    exit 0
    }

    # Add read permissions for SID (S-1-1-0, Everyone) to the registry key with inheritance
    $acl = Get-Acl -Path $registryPath
    $ruleSID = New-Object System.Security.AccessControl.RegistryAccessRule($sid, “FullControl”, “ContainerInherit,ObjectInherit”, “None”, “Allow”)
    $acl.AddAccessRule($ruleSID)
    Set-Acl -Path $registryPath -AclObject $acl
    Write-Output “Added ‘Interactive’ group and SID ($sid) with read permissions (with inheritance) to the registry key.”

    #Remove the # below to make sure it will kick off the scheduled task on already enrolled devices
    Start-Process “$env:SystemRoot\system32\ClipRenew.exe”
    exit 0
    }
    } else {
    Write-output “Not activated.”
    exit 0
    }

    1. Yes. Detection:

      # https://call4cloud.nl/2024/05/kb5036980-breaks-upgrade-windows11-enterprise/
      # Define the scheduled task path
      $taskPath = “\Microsoft\Windows\Subscription\*”
      $taskName = “LicenseAcquisition”

      # Retrieve the last run result of the scheduled task
      $lastRunResult = (Get-ScheduledTask -TaskPath $taskPath -TaskName $taskName | Get-ScheduledTaskInfo).LastTaskResult

      # Check the last run result of the task
      # 267011 – task never ran
      if ($lastRunResult -eq 0) {
      # Task ran successfully, exit with code 0
      Write-Host “Task ran successfully, exit with code 0”
      exit 0
      } elseif($lastRunResult -eq 267011) {
      # Task never ran, exit with code 0
      Write-Host “Task never ran, exit with code 0”
      exit 0
      }
      else {
      # Report the error code
      Write-Host “Error: Scheduled Task Last Run Result is $lastRunResult”

      # Define the registry key path
      $registryPath = “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew”

      # Check if the registry key exists
      if (Test-Path -Path $registryPath) {
      # If the key exists, return zero indicating compliance
      exit 0
      } else {
      # If the key does not exist, return 1
      exit 1
      }
      }

      Remediation:

      # Define the registry key path, value, and SID
      # https://call4cloud.nl/2024/05/kb5036980-breaks-upgrade-windows11-enterprise/

      $registryPath = “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew”
      $registryValueName = “Verify Multifactor Authentication in ClipRenew”
      $registryValueData = 0 # DWORD value of 0
      $sid = New-Object System.Security.Principal.SecurityIdentifier(“S-1-1-0”) # SID for the Everyone group

      # Check if the registry key already exists
      if (-not (Test-Path -Path $registryPath)) {
      # Create the registry key if it doesn’t exist and set the DWORD value
      New-Item -Path $registryPath -Force | Out-Null
      Set-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -Type DWORD
      Write-Output “Registry key created and DWORD value added.”
      } else {
      Write-Output “Registry key already exists. No changes made.”
      }

      # Add read permissions for SID (S-1-1-0, Everyone) to the registry key with inheritance
      $acl = Get-Acl -Path $registryPath
      $ruleSID = New-Object System.Security.AccessControl.RegistryAccessRule($sid, “FullControl”, “ContainerInherit,ObjectInherit”, “None”, “Allow”)
      $acl.AddAccessRule($ruleSID)
      Set-Acl -Path $registryPath -AclObject $acl
      Write-Output “Added ‘Everyone’ group and SID ($sid) with read permissions (with inheritance) to the registry key.”

      1. I added Start-Process “$env:SystemRoot\system32\ClipRenew.exe” to the end of Remediation, but it wont activate before i run it manually after. can it be included somehow?

        1. Well.. the cliprenew must be executed in user context… and the script itself to change the permissions on that key etc, must be run in system context..

  11. Does anyone know when exactly the downgrade will take place? I’m using a Remediation Script to check which ones have already been downgraded, and also checking the last return code of the Scheduled Task. Almost all computers running Windows Enterprise have 0x80070005 (not 0x80004005) as the last return code. I am now wondering if and when they will be downgraded.

    $LastTaskResult = (Get-ScheduledTaskInfo -TaskName “\Microsoft\Windows\Subscription\LicenseAcquisition” -verbose | select -exp CimInstanceProperties) | Where {$_.Name -eq “LastTaskResult”}
    $LastTaskResult = $LastTaskResult.Value.ToString(‘X’)

  12. Rudy,

    Thank you so much. I am able to successfully run the script manually from an Administrative Powershell prompt. I have been unable to deploy the script successfully as a Win32 app via Intune. The install behavior is set to System. Install command: powershell.exe -noprofile -executionpolicy bypass -file RudyFix.ps1. The script does not appear to run at all. I have been unable to isolate the issue. Admittedly my basic powershell knowledge does not help.

    Thank you

  13. Hi, after applying the powershell script fix, I then see the following error message for the scheduled task:

    “CLiP license device ID does not match the device ID in the bound device license. (0xC0EA000A).:

    I then run this from your other post:

    net stop clipsvc
    rundll32 clipc.dll,ClipCleanUpState
    net start clipsvc

    And I now see the following error:

    CLiP device license not found. (0xC0EA0003)

    What could I be dealing with here?

    1. I got the same one on one of my devices, another device works fine. And it’s not a PowerShell script, I believe, it could be the new May path. Interestingly, I don’t see this issue on other devices, only on one. Same AAD account.

    2. I’m seeing the same. LicenseAcquisition keeps failing with 0xC0EA0003 as if there was some hardware change with the device. I’m seeing this on multiple devices. I can confirm from AAD sign-in logs that Store authentication is successful and MFA key is created. I have escalated to Microsoft, but not getting concrete updates from them yet.

  14. Hi Rudy, very detailed and helpful. Thank you for creating and sharing this.
    However, this command: Start-Process “$env:SystemRoot\system32\ClipRenew.exe”
    doesn’t seem to be running the License Acquisition task and I even tried running in user context. But no luck.
    So after adding the registry, once the device is getting rebooted, the License Acquisition task scheduler runs and activates the device to Windows 11 Enterprise.

    Any idea how we can make this work , that will eliminate the need for reboot.
    Start-Process “$env:SystemRoot\system32\ClipRenew.exe”

  15. Hi Rudy,

    Is there any news from MS for a proper fix for this. Just installed June updates and that has not resolved 🙁

    Was hoping not to have to run this script on all devices, but now they are starting switching back to Windows Pro.
    Thanks,

    Alex

    1. It should be getting fixed in the june oob update (and the end of june) otherwise its going to be in the july update

  16. I think it is important to also point out, that this issue is the same for “Microsoft 365 E3” that is also upgrading to Enterprise in the article.
    Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

2  +  1  =