Are you curious how Microsoft plans to fix the Windows subscription activation issue? Patch My PC was, too! We examined the latest Windows Insider preview and the June/July Windows Updates and noticed some improvements.
If you want to know more, keep on reading!
The Subscription Activation Issue
If you’re encountering issues with the automatic license upgrade from Windows Pro to Windows Enterprise, particularly after installing the latest Windows 11 update KB5036980, you are at the correct address!
In a previous blog, Rudy explained how the KB5036980 Windows update has caused subscription activation issues, preventing devices from upgrading their license from Windows Pro to Windows Enterprise. This issue also causes existing devices to drop from Windows Enterprise to Windows Pro, which could cause some serious security issues! All the security policies that only work with Windows Enterprise will stop working when the license is reverted to Windows Pro.
In that blog, he identified a scheduled “license acquisition” task responsible for the subscription activation issues.
This license acquisition task failed because it failed to create the MFA Required in ClipRenew registry key, blocking the upgrade process. This issue could be easily fixed by creating those registry keys yourself!
As shown below, Microsoft is aware of the subscription activation issue and is actively working on a solution.
When a fix is in the works, it’s usually released to the Windows Insider canary channel first. The same happened with the subscription activation issue. Microsoft added a new feature in the Windows insider preview build 26227.5000
Windows Insider Preview 26227.5000
With the Windows Insider Build 26227.5000, Microsoft attempted to fix the access denied error that could occur when the license acquisition task is launched to upgrade your Windows License. We noticed something funny when looking at the added features in this insider canary release.
Microsoft added a nice new feature called MFACheckingClipRenew_HandleAccessDenied.
By the looks of it, Microsoft will address the “Access Denied” message we encountered when attempting to add the MFA-required registry key.
After noticing that this feature was added to the Windows Insider Preview, we installed the 26227.5000 Canary build to see if it would resolve the issue. I executed the scheduled license task post-installation but found that it still resulted in the “Access is denied” (0x80070005) error.
What is going on? I was really expecting the handleAccessDenied feature to start handling the Access denied message. The cliprenew.exe is responsible for the subscription upgrade, so I decided to peek at its code.
The Updated ClipRenew
After opening the ClipRenew executable with the IDA tool, we noticed that the main code had an additional feature.
The code now holds an additional feature called MFACheckinCliprenew_HandleAccessDenied. It sounds as if Microsoft added a feature to handle the access denied error.
In addition to this new feature, which will handle the access denied error, we also spotted an additional feature in the code that checks if that access denied feature is enabled.
Inside the handle access denied feature, it also checks if the UxSettingTest feature is enabled. After spotting these features, I downloaded the VIVE tool and manually enabled the Windows features.
UxSettingTest: 48433706
MFACheckInClipRenew_HandleAccessDenied: 49577403
Enabling only one of them will still result in the scheduled task failing, so you will need to enable both!
After enabling them and rebooting my device, I almost began to cheer! (well, almost)
As shown above, the license acquisition task was completed successfully, and I no longer received an access denied error! Great! Well, almost. With the access denied error gone, I decided to open the registry to check out the MFA-required registry key.
Exactly …. The MFA-required registry key was still not created!!! Let’s add Procmon to it to find out what is happening, as I expected the MfaRequiredInClipRenew key to be created with this handle access denied feature.
As shown above, ClipRenew tries to create the mfarequiredincliprenew registry key, but it fails. It will retry again, but it will fail again.
This time, it doesn’t error out but continues doing its job. It seems like ClipRenew is now handling the access denied error. How does that work?
Handle Access Denied
Let’s examine how ClipRenew handles this access denied error. I started by opening the Procmon trace and comparing it with the ClipRenew code. Both Procmon and the ClipRenew code seem to tell me the same thing.
If HandleAccessDenied is enabled, the code attempts to create or open the MFA required registry key and set its value.
If HandleAccessDenied is not enabled, the code still tries to create or open the registry key and set its value but uses a different approach.
This different approach seems to be a graceful exit because the moment Procmon tells me that ClipRenew isn’t allowed to create the registry keys, it contacts licensing.mp.microsoft.com to discuss the subscription activation status.
This is way more than it was doing at first, but still without the MFA required created. It looks like this feature to handle access denied was just the first step to fixing the MFA-required access denied issue. Let’s move on, shall we? I was curious if the latest preview update of June was taking a different approach.
June KB5039302
This part of the blog can be pretty short: Yes!!! Microsoft added the same ” workaround” from the insider canary build into the June Preview update. When we enable the same two features with the Vive tool, the scheduled task can be executed successfully!
As shown above, the scheduled task could be run successfully with the two features enabled!
However, the “real fix” for creating and handling the MFA required key is still missing and hasn’t been addressed yet. Hopefully, we will see a solution in a future Windows update.
July KB5040442
With the July Patch Tuesday, I was wondering if this KB5040442 will hold the actual fix. After I updated my device with the 2024-07 July update, I was curious if the LicenceAcquisition would show me that it completed successfully.
As shown above, I guess not! I decided to compare the Cliprenew.exe code from the July build with the previous Cliprenew.exe from the June OOB update.
Comparing them showed me that there were not that many changes! I guess we all know what that means! The July KB5040442 Update is not going to fix your subscription activation issues! Hopefully, the August update will. In the meantime, we still need to manually create the MfaRequired registry keys and change the permissions to fix it ourselves.
Or…..
The ViveTool Fix
With the possibility to enable the features with the Vivetool, we could also enable those two features on our own
UxSettingTest: 48433706 and MFACheckInClipRenew_HandleAccessDenied: 49577403
With the PowerShell script below, we will download the ViveTool, enable the 2 features, query if they are enabled, and clean up afterward.
Please make sure that you reboot your device afterward!
# Define variables
$downloadUrl = "https://github.com/thebookisclosed/ViVe/releases/download/v0.3.3/ViVeTool-v0.3.3.zip" # URL to download ViVe tool
$tempPath = "C:\Windows\Temp"
$viveToolZip = "$tempPath\ViVeTool.zip"
$viveToolDir = "$tempPath\ViVeTool"
$logFile = "$tempPath\ViveToolLog.txt"
$featureIds = @(49577403, 48433706)
# Function to log messages
function Write-Log {
param (
[string]$message
)
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
"$timestamp - $message" | Out-File -FilePath $logFile -Append
}
# Start logging
Write-Log "Script started."
# Download ViVe tool
Write-Log "Downloading ViVe tool from $downloadUrl."
Invoke-WebRequest -Uri $downloadUrl -OutFile $viveToolZip
# Extract ViVe tool
Write-Log "Extracting ViVe tool."
Expand-Archive -Path $viveToolZip -DestinationPath $viveToolDir
# Enable features
foreach ($featureId in $featureIds) {
Write-Log "Enabling feature with ID $featureId."
& "$viveToolDir\ViveTool.exe" /enable /id:$featureId
}
# Query status of features
foreach ($featureId in $featureIds) {
Write-Log "Querying status of feature with ID $featureId."
$queryresult = & "$viveToolDir\ViveTool.exe" /query /id:$featureId
Write-Log $queryresult
}
# Clean up
Write-Log "Cleaning up."
Remove-Item -Path $viveToolZip -Force
Remove-Item -Path $viveToolDir -Recurse -Force
# End logging
Write-Log "Script completed. To apply the changes you need to reboot the device"
July Preview Update KB5040527
With the June update, Microsoft added the Handle_access_denied feature in clip-renew to ensure the licence acquisition scheduled task won’t error out. This feature wasn’t enabled in the June update. With the release of the July KB5040527 update, Microsoft enabled the feature in Windows.
With this feature now enabled by default, the handle_access_denied feature is going to take care of the errors and ignores the outcome. For now this is the fix we all have been waiting for!!!
Somehow, it doesn’t feel like the ultimate fix. With this handle_access_denied feature, the MFARequiredincliprenew registry key has still not been created. This was the reason why we started having issues with the April build. I am going to assume that another update is coming our way to also deal with this registry key. If we spot it, we will update this blog!
Conclusion
You’re not alone if you’ve faced subscription activation issues upgrading from Windows 11 Pro to Enterprise due to update KB5036980. Microsoft is aware of this and is working on a fix.
Unfortunately, the June update (KB5039302) and the July update (KB5040442) did not resolve the issue despite including the handle access denied feature. Hopefully, future updates will adequately address the access denied issue.