When subscription activation gets stuck, it could be due to a secondary work or school account. This blog dives into how to fix the subscription activation issue by automatically Removing Secondary 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 they agree to the next screen and allow my organization to manage my device.
When you select that option, conflicting work or school account information is added to the device’s authentication token. The device now holds details from multiple Azure AD tenants. These identities are referenced during the license validation process, and because of this, the License Request is invalid.
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 when we are authenticating it would also pass the token of the additional Workplace Joined Account from the different AAD Tenant. (which causes the issue)
If one UserEmail 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 happened, I built a remediation script to clean up these leftovers.
Please Note: I am trying to figure out how to NOT break the account picture while fixing it, so bear with me 😉
Detection Script Summary:
1. Retrieve User Profiles:
- The script starts by retrieving a list of all user profiles (SIDs) under the
HKEY_USERS
registry hive.
2. Check for the Presence of Registry Keys:
- For each user SID, the script checks for the presence of two registry paths:
- WorkplaceJoin\JoinInfo under
HKEY_USERS
(specific to each user). - CloudDomainJoin under
HKEY_LOCAL_MACHINE
(system-wide).
- WorkplaceJoin\JoinInfo under
- If the
CloudDomainJoin
path exists, it proceeds to extract the relevantUserEmail
values for domain comparison.
3. Extract UserEmail from WorkplaceJoin\JoinInfo:
- For each GUID-based subkey under
WorkplaceJoin\JoinInfo
, it checks if aUserEmail
value is present. - If found, the script extracts the domain part of the
UserEmail
(the part after the@
symbol).
4. Extract UserEmail from CloudDomainJoin:
- The script checks each GUID-based subkey under the
CloudDomainJoin\JoinInfo
path. - If a
UserEmail
value is found, it extracts the domain part of this email for comparison.
5. Compare Domains:
- The script then compares the domain part of each
UserEmail
fromWorkplaceJoin\JoinInfo
with the domain part ofUserEmail
fromCloudDomainJoin
. - If a domain mismatch is detected between these values, it logs the mismatch, displays a warning, and exits with a failure code (
Exit 1
).
6. Exit with Success or Failure:
- If no mismatching domains are found across all user profiles, the script logs a success message and exits with a success code.
- If no
JoinInfo
entries are found for any user, the script outputs a message indicating this
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 from the user folder: (TokenBroker\Accounts)
Results: Automatically Removing Secondary Work or School Accounts
After building the detection and remediation scripts, I ran multiple tests to confirm they correctly identified and removed all mismatched IDs.
Please ensure the device reboots afterward so the scheduled task to upgrade the license can kick off. As shown below, if you don’t reboot the device, it won’t have any AAD tickets (as we deleted the whole token broker folder) and will give us the 0x803f7001 error.
After a reboot, everything will come back to live, and the LicenceAcquisition is also able to find the AAD Ticket.
We Are not done yet! BlockAADWorkPlacejoin
As mentioned in this article Subscription Activation | Multiple Work or School Accounts, all of this behavior is caused by this prompt when you are adding Teams Account
Enable the following registry setting to prevent users from adding additional work accounts on corporate domain-joined, Microsoft Entra-joined, or Microsoft Entra hybrid-joined Windows 10/11 devices. This policy also helps prevent domain-joined machines from unintentionally becoming Microsoft Entra registered with the same user account.
$RegistryLocation = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin"
$keyName = "BlockAADWorkplaceJoin"
# Check if the key is already in place; if so, exit
$existingKey = Get-ItemProperty -Path $RegistryLocation -Name $keyName -ErrorAction SilentlyContinue
if ($existingKey -and $existingKey.$keyName -eq 1) {
Write-Output "Registry key is already in place."
Exit 0
}
# Create the registry path if it is missing
if (!(Test-Path -Path $RegistryLocation)) {
Write-Output "Registry location is missing. Creating it now."
New-Item -Path $RegistryLocation -Force | Out-Null
}
# Set the key value
New-ItemProperty -Path $RegistryLocation -Name $keyName -PropertyType DWord -Value 1 -Force | Out-Null
# Verify the key has been created successfully
$checkKey = Get-ItemProperty -Path $RegistryLocation -Name $keyName -ErrorAction SilentlyContinue
if ($checkKey -and $checkKey.$keyName -eq 1) {
Write-Output "Registry key has been successfully set."
Exit 0
} else {
Write-Error "Failed to create registry key!"
Exit 1
}
With this BlockAADWorkPlacejoin, users could still add the additional Teams account but it will prevent adding the additional work or school account (which breaks the subscription activation uplift)
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 work or school 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, returning your devices to 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.