Fix Subscription Activation by automatically Removing Secondary Work or School Accounts.

Patch My Pc | install & update thousands of apps

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 quickly, ensuring your devices can upgrade 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 to be 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.

the workplacejoin registry keys hold the  join info keys which refer to  a possible

By comparing the UserEmail value in the HKCU 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 the device is entra joined it will check out the useremail in the clouddomainjoin registry key

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 Updated Remediation Script

Once I identified the cause, I developed an updated remediation script to clean up these leftovers. This enhanced script now searches the tbacct files specifically for the extra work or school account. When found, it removes only those files, ensuring the primary account remains unaffected, without impacting the account picture or other settings.

uploading the powershell script that contains the subscription activation fix to deal with the Extra Work/School Accounts

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).
  • If the CloudDomainJoin path exists, it proceeds to extract the relevant UserEmail values for domain comparison.

3. Extract UserEmail from WorkplaceJoin\JoinInfo:

  • For each GUID-based subkey under WorkplaceJoin\JoinInfo, it checks if a UserEmail 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 from WorkplaceJoin\JoinInfo with the domain part of UserEmail from CloudDomainJoin.
  • 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:

  • Collects User Emails from the Registry:
    The script starts by listing all user profiles (SIDs) under the HKEY_USERS registry hive. For each user SID, it checks the JoinInfo path to locate GUID-based subkeys and retrieves the UserEmail associated with each subkey. These UserEmail values are stored in a hashtable for reference.
  • Searches for .tbacct Files in User Profiles:
    For each user profile located under C:\Users, the script navigates to the Microsoft.AadBrokerplugin TokenBroker\Accounts folder where .tbacct files are stored. It checks the content of each .tbacct file to see if it matches any UserEmail found in the registry.
  • Deletes Matching .tbacct Files:
    If a .tbacct file contains a UserEmail associated with a conflicting account, the script deletes the file. This step ensures that any cached account information related to that email is removed from the TokenBroker folder.
  • Removes Conflicting Registry GUID Keys:
    After deleting the .tbacct file, the script goes back to the JoinInfo registry path under the corresponding user SID. It then locates the GUID-based subkey associated with the conflicting UserEmail and deletes the entire GUID subkey, effectively removing the conflicting data from the registry.
  • Completes Cleanup for Conflicting Data:
    By wiping both the AAD Broker Plugin data from the user folder (TokenBroker\Accounts) and the relevant GUID-based subkey in the registry, the script ensures that any secondary IDs or conflicting accounts tied to different tenants are removed. This cleanup prevents issues caused by multiple tenant associations in JoinInfo.
automatically Removing Secondary Work or School Accounts.
automatically Removing Secondary Work or School 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.

The remediation detection output showing that the detectin script encountered the secondary work or school account and now it will  Automatically Remove the Secondary work or School Account

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.

0x803f7001 number of aad tickets 0 because we deleted the whole token broker folder

After a reboot, everything will come back to life, and the LicenceAcquisition will also be 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

Teams will ask to stay signed in to all your apps. and to allow my organization to manage my device. This is turned on by default and we need to disable this prompt. To do so we need to implement the BlockAADWorkplaceJoin registry key

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.

13 thoughts on “Fix Subscription Activation by automatically Removing Secondary Work or School Accounts.

  1. Any reported issues with the remediation besides the user’s picture blowing away? In my testing the profile picture goes away and you have to re-add it? Would there be a way to also force the reboot? Present the user with a toast notification (snooze option, but eventually force)? Wouldn’t want the system running too long after running remediation without having a reboot.

    1. Yesterday morning i updated the remediation script to only delete the tbacct files that corrosponded with that additional work or school account to make sure the account picture stayed alive
      Which is also better of course for the primary account and the tokens 🙂

  2. hello,

    nice investigation i will test it also in our environment .
    but we are facing also other case where some users saved their admin accounts which are from the same tenant.
    can we somehow adapt the script to keep only the logged in user and delete the others ?

    Thanks
    Aurelian

    1. Well, you could get rid of this part:

      # Compare the domain with CloudDomainJoin UserEmail domain
      if ($cloudDomainEmailDomain -and ($userDomain -ne $cloudDomainEmailDomain)) {
      Write-Host “Mismatch detected: $userEmail domain ($userDomain) does not match CloudDomainJoin domain ($cloudDomainEmailDomain)”
      exit 1

      and add an exit just after the Write-Host “Found WorkPlace Account with UserEmail: $userEmail for user: $($user.PSChildName)”

      1. thanks , i will try

        i just found something ,maybe you would like to try also :
        i knew about dsregcmd /listaccount, i am using it to identify the users with multiple accounts logged in .
        now i discovered that dsrecmd has also /cleanupaccounts and i just tried it and it removed my admin accoutn which was saved (curently device entra joined, i will test also on hybrid joined tomorrow to see the results)

        thanks

        aurelian

          1. haha ok
            one more question , something unclear for me.
            Ok if we have 2 accounts from same tenant but one of it not having license e5 or f3, we will have the same error and the account needs to be removed.
            but if the both accounts are the same tenant and both licensed, the licensing process should work or or will be the same problem ?

            thanks

          2. also something i found is that if my admin account is saved, under HKCU ..\Workplacejoin i dont have any JoinInfo , just AADNGC .(also for the main user no JoinInfo is found)

          3. There should be an additional workplace join registry key with that additional user info in it.. if you earch through the registry for that additional user name, in which keys does it show up?

          4. sorry for that many replies , ok i checked on some hybrid joined machines with logged in accounts from other tenant and i found the workplacejoin\joininfo folder
            but what about entra joined devices , will be the same thing ? or this is designed just for hibrid joined?

            thanks

  3. Hi Rudi,
    awesome work (as expected 😉 ), thanks.
    I ran the detection on our machines and found a few non-compliant devices which kind of should be compliant. So far, this seems to happen for some (not all) users, who’s primary domain was changed after the device got clouddomainjoined. But so far, I’m not sure why exactly. Because if this was a general problem, I should have way more machines than I actually have.

  4. Hey!
    Great post, thank you for investigating this.
    After testing it locally on my machine, everything looked good. After I added my second Work or School Account to Teams however, it again was added to Windows, even though
    HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, “BlockAADWorkplaceJoin”=dword:00000001
    is set.
    Do you have any idea how this could happen?

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  6  =  7

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.