When subscription activation gets stuck, it could be due to conflicting work or school accounts. This blog dives into how to fix subscription activation by auto-removing extra work or school accounts. With a quick detection and remediation script, you can zap these conflicts in no time, ensuring your devices can upgrade back to Enterprise again.
Introduction
If you’ve ever experienced the “Subscription Activation Issue” that leaves devices stuck in limbo on Windows Pro, then you know how frustrating it can be. In a previous post, I outlined how the introduction of the MFAClipRequiredInClipRenew component ended up causing devices to get stuck on Windows Pro instead of upgrading to Windows Enterprise. The issue, which was thoroughly analyzed and eventually patched (detailed in this post), seemed like it was finally put to rest.
But as with many complex issues, the devil is in the details. Even after the core problem was resolved and devices were able to upgrade again from Pro to Enterprise, another roadblock emerged: devices with multiple work or school accounts from different tenants started failing to upgrade. The underlying issue? When devices tried to switch to the correct license, the ClipRenew process got tripped up by conflicting tenant information stored in the authentication token.
The Real Culprit: Adding a Second Account in Teams
It all starts with a seemingly harmless action: adding work or school accounts from a different Azure AD tenant in Microsoft Teams.
Sounds innocent enough, right? But here’s where things go sideways. When a second account is added in Teams, conflicting work or school account information is injected into the device’s authentication token. The conflicting entries create a scenario where the device holds details from multiple Azure AD tenants. These identities are referenced during the license validation process, but when ClipRenew kicks in, it can’t decide which tenant to use.
The end result? The license upgrade fails, and the device either stays stuck on Windows Pro or starts flip-flopping between licenses.
Tracking Down the Issue: Using JoinInfo and CloudDomainJoin as Clues
Here’s why this problem is so hard to pinpoint: the conflicting information is stored within the authentication token itself. However, since we can’t directly inspect the token without additional tools, we need to rely on a workaround to detect the issue. Enter the JoinInfo and CloudDomainJoin registry keys.
By comparing the UserEmail value in the JoinInfo registry path with the UserId value stored in the CloudDomainJoin (which dsregcmd /status uses) path, we can get a pretty good idea of whether the authentication token contains conflicting tenant data.
If one email belongs to contoso.com and the other to fabrikam.com, it’s a clear sign of a problem.
Cleaning Up the Mess: The Remediation Script
After figuring out what was going on, I built a remediation script to clean up these leftovers.
Download them here:
Here’s how it works:
Detection Script Summary:
- The script first gets a list of all user profiles (SIDs) under the HKEY_USERS registry hive.
- Check for the Presence of Registry Keys:
- For each user SID, it checks for the presence of two registry paths:
- WorkplaceJoin\JoinInfo
- CloudDomainJoin
- If both paths exist, it proceeds to the next step.
- Extract UserEmail from JoinInfo:
- For each JoinInfo subkey (GUID-based), it checks if the UserEmail value is present.
- If found, it extracts the domain part (after the @) from UserEmail.
- Search for the UserId in CloudDomainJoin:
- The script then searches for the UserId value in all CloudDomainJoin Subkeys (GUID-based).
- If found, it extracts the domain part of the UserId for comparison.
- Compare Domains:
- If the domain part of UserEmail (from JoinInfo) matches the domain part of UserId (from CloudDomainJoin), the script continues.
- If the domains are not the same, it logs the mismatch and exits with a failure (exit 1).
- Exit with Success or Failure:
- If no mismatching domains are found across all profiles, the script logs a success message and exits with a success code
Remediation Script Summary:
- It starts by listing all user profiles (SIDs) under the HKEY_USERS registry hive.
- It then checks the JoinInfo path for each user and inspects the UserEmail values.
- If a second ID is tied to a different tenant, the script deletes the entire GUID-based subkey to remove the conflicting data.
- Wiping AAD Broker Plugin Data:
- The script then targets the local Azure AD Broker Plugin data.
- Using a wildcard path, it locates the Microsoft.AAD.BrokerPlugin_* directories for each user and wipes the contents of the Accounts folder.
- This prevents the Broker Plugin from using the stale identity, ensuring that any future activation attempts are based on the correct tenant.
Please ensure the device reboots afterwards to ensure the scheduled task to upgrade the license could kick off.
Proactive Remediation: Automatically Remove Secondary work or School Account
After building the detection and remediation scripts, I ran multiple tests to confirm they correctly identified and removed all mismatched IDs.
But cleanup isn’t just a one-time event. Devices that are frequently re-enrolled or have changed tenants might keep accumulating stale tenant IDs over time.
To prevent this issue from popping up again, I recommend setting up a proactive remediation routine using Microsoft Endpoint Manager’s Proactive Remediation scripts. This way, the cleanup runs periodically, catching any new tenant conflicts before they cause activation failures.
With the proactive approach, you can ensure that your devices operate without hidden tenant conflicts. So, next time you think the subscription activation issue is resolved, double-check for those rogue secondary IDs. Because, as always, it’s the small, hidden details that end up causing the biggest headaches.
Conclusion
In the ever-evolving world of subscription activation, it’s easy to think a problem is fixed only to find out there’s still a gremlin lurking beneath. Conflicting tenant accounts are exactly that kind of hidden troublemaker. With the detection and remediation scripts outlined here, you’ve got the power to zap these conflicts right at the source, keeping your devices happily running on Windows Enterprise.
And let’s face it: nobody wants to troubleshoot the same issue twice. By setting up proactive remediation, you’re not just fixing today’s headaches—you’re future-proofing against tomorrow’s. So, keep those rogue accounts in check, stay ahead of tenant conflicts, and ensure smooth sailing on your path to Enterprise upgrades. Because as we’ve seen when it comes to subscription activation, it’s often the little things that make the biggest impact.