The Subscription Activation Journey: Stuck on Pro

The May update broke Windows Subscription Activation, causing devices to drop from Enterprise to Pro. The primary culprit was a breakdown in Multi-Factor Authentication (MFA). Microsoft addressed this issue with an August update, introducing the HandleAccessDenied mechanism, which partially fixed the problem by moving MFA-related registry keys from machine-level to user-specific paths.

This change allowed many devices to renew their subscriptions and upgrade back to Enterprise, but the fix wasn’t comprehensive, particularly for environments with multiple linked work or school accounts from different tenants on the device.

How Multiple Work or School Accounts Cause Problems

In some environments, users accidentally associate multiple AAD accounts from different tenants with a device, often when adding a second account to apps like Microsoft Teams.

If they don’t select “Sign in to this app only,” the user will get an additional work or school account and, with it, become workplace joined. As shown below, the moment we added that account, dsregcmd /status will show within the User State that is WorkplaceJoined

If we scroll down a bit, we will also notice the additional work account.

With this additional work or school account added, the LicenseAcquisitiontask may error out (0X87E10BF2)

When this LicenseAcquisitiontask gives you the 0x87010bf2 error, one thing is for sure! You may have a conflict with subscription activation. Let me show you why it creates a conflict, but first, I need to explain again the role of the LicenseAcquistion task in it.

The Role of ClipRenew and LicenseAcquisition

The LicenseAcquisition task and ClipRenew play a vital role in subscription activation. Once the task is triggered, it works to:

1. Create the License Request Body: This request contains critical data, including information about the users associated with the device. The request body holds all the user its identities, types, and other essential details.
2. Communicate with Microsoft’s Subscription Service: After generating the license request, ClipRenew sends it to Microsoft’s licensing server to validate and issue the license.
3. License Uplift: If the request succeeds, the device is uplifted to Enterprise. If not, as is the case in multi-tenant environments, the device remains stuck in Pro mode.

Now comes the funny part! Devices with multiple AAD accounts remain stuck in Pro, unable to uplift to Enterprise. This happens because the License Request Body—the JSON structure that the system sends to Microsoft’s servers, expects only one AAD tenant. It doesn’t expect multiple AAD accounts from different tenants when requesting the license!

The JSON License Request Body

To understand the problem better, let’s look at a simplified version of the License Request Body generated by ClipRenew:

The “users” section lists all the AAD accounts linked to the device in this request. When multiple AAD accounts are present, the ClipRenew process seems to attempt to request a license for all AAD accounts. If more work or school accounts are connected to the device, the service will tell us that it got a bad request and will give us this error in the response.

As shown above, the response is giving us a bad request. If we zoom into the details, we will spot a nice error code: SingleTenantIDExpectedforAadusers.

The Impact of Multiple Work or School Accounts

When multiple AAD accounts are linked to a device, the ClipRenew process fails to handle the conflicting accounts. The License Request Body includes the users part, which lists all AAD users associated with the device. However, ClipRenew expects only one AAD tenant, and when multiple are detected, the task fails with the error:

• Service Fault: status 400 code: SingleTenantIdExpectedForAadUsers:
• description: All AAD users provided in the request are expected to be associated with a single Tenant.
• Number of AAD Tickets: 2

This failure prevents the device from being uplifted back to Enterprise, leaving it stuck in Pro mode despite having valid licenses.

The Solution: Managing Multiple Work or School Accounts

The most effective way to resolve this issue is to manually disconnect any extra work or school accounts from Settings > Accounts > Work or School Accounts. This step removes the additional AAD accounts, allowing the LicenseAcquisition task to proceed with only one account, which successfully generates the license request and uplifts the device to Enterprise.

Step-by-Step Guide to Disconnect Extra Accounts:

1. Open Settings: Navigate to Settings on your Windows device.
2. Access Accounts: Click on Accounts.
3. Work or School Accounts: Select Work or School Accounts from the sidebar.
4. Identify Extra Accounts: Look for any additional accounts that shouldn’t be linked to the device.
5. Disconnect: Click on the unwanted account and select Disconnect.
6. Confirm: Follow the prompts to remove the account from the device.

By ensuring that only one AAD account remains linked, the LicenseAcquisition task can successfully process the license request, enabling the device to uplift back to Enterprise.

For the people not believing me

When you don’t want to do all that manual labor to fix the subscription activation issues when there are multiple work or school accounts connected to your user, please take a look at this additional blog:

Conclusion: A Partial Fix and What’s Next

While the August update addressed the core MFA issues from the May cliprenew issue, devices with multiple work or school accounts configured from different AAD Tenants, continue to struggle with subscription activation, and the ClipRenew process remains unable to handle these complexities. The result of these complexities is that the device will be stuck on Windows Pro.

Until Microsoft releases a more comprehensive fix, IT administrators will need to manually disconnect the AAD accounts. This ensures that devices can be uplifted properly from Pro to Enterprise, even in complex environments.