Last Updated on May 16, 2024 by rudyooms

Are you having issues with the automatic upgrade from Windows 11 Pro to Windows 11 Enterprise during Autopilot with the latest Windows build? If yes, this blog is for you!

I will divide this blog into multiple parts

1. Introduction
2. The Issue
3. Taking A closer look
4. The Fix (option 1)
5. The Exe Code behind it
6. The Fix (option 2)
7. Microsoft their Response

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 reaching out to me, and they all mentioned the same issue.

If you have a Microsoft 365 E5 license, you are entitled to an 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!

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

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.

Cliprenew fails to create the mfarequiredcliprenew registry key. If that registry key is not created, 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 (yeah, I know…. Stupid)

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

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

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

4. 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-1-0")  # SID for the Everyone 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-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."

#Remove the # below to make sure it will kick off the scheduled task on already enrolled devices
Start-Process "$env:SystemRoot\system32\ClipRenew.exe"

This PowerShell script will ensure that the corresponding MfaRequiredInClipRenew registry key is created with slightly too high permissions.

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”

5. 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

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

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

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 enterprise

6. The fix (option 2)

A second option is to package the Vivetool and disable the feature, as I showed you before.

When you package the Vivetool you need to define a detection script. If you check this enabledstate key for the value of 1 (disabled) you are good to go (enabled is 2)

Please make sure that if you package and script the Vivetool to disable the function you also trigger the cliprenew executable afterwards to start the license uplift

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

7. Microsoft Their Response

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

Hopefully, this fix will make it to production soon, as it dramatically impacts the subscription activation because it also impacts existing devices. Let me tell you why. When all of 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?

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.

We can give the user local admin permissions to fix it (just like the devs that wrote that code?), or are we going to deploy a PowerShell script that creates the required keys