How We Got Here:
Sigh.
Enterprise Activation is a topic I have now spent the past year writing about…
April 2024, Enterprise Activation Broken by Windows Update.
Retired article: September 2024, Work or School Accounts Break Enterprise Activation Part 1
Retired article: November 2024, Work or School Accounts Break Enterprise Activation Part 2
Retired article: December 2024, Work or School Accounts Break Enterprise Activation Part 3
Retired article: February 2025, Work or School Accounts Break Enterprise Activation Part 4
…And yet, it has managed to rear it’s ugly head in my life again. At this point I’ve had to make a category just for it!
To recap the above, Microsoft broke Subscription Activation in the April 2024 update, and fixed that issue in late summer (August or September, see above links). This was a big problem because it meant that all Enterprise-only policies (like blocking the M$ store so users can’t install Candy Crush) stopped enforcing and/or applying.
However, even after the fix, we noticed many of our devices were still not upgrading. After investigation and working with Microsoft, this turned out to be due to having secondary Work or School accounts on the machines (resulting in an Entra Registered machine), which broke this process. To this day, I am getting conflicting answers as to how this came to be. Some claim a change was made in early 2024, and indeed, the February and April updates made changes to subscription activation, but others say it was always like this. Some say that if the secondary accounts are licensed, it will work. Others claim any secondary account breaks it, and others seem to be saying that only secondary accounts from other tenants break it.
This resulted in a very long and frankly not fruitful case. Ultimately, I ended up creating my own scripts (see above articles) to detect/report on Work or School accounts, prevent adding additional accounts, and remove existing accounts (thanks once again to Rudy Oooms for coming to my rescue). Those were deployed, and ta-da, we had a functioning Enterprise Activation system once again. Hurray!
Update 6/11/25:
Regarding the above crossed-out text, and any other crossed-out text in this article, I now know the full story on this and am working to put together an article to get all the ducks in a row. That should be available soon and will be linked here once posted.
Take a look at my new article on Everything I Know on Subscription Activation.
Let’s Give Edge Another Try…
Recently, I’ve been working from a new machine and, as I manage multiple tenants, I decided I wanted to use Edge with separate Edge profiles signed into the accounts I have for each tenant. What would be better than favorite syncing, SSO, and all that good jazz on my different accounts with different needs?
To be clear, this is an entra-joined machine. I have my primary Edge profile signed into the primary account on my machine, let’s say Max@Contoso.com. I also have secondary Edge profiles signed into accounts in different tenants, Max@Contoso-Bank.Net for example.
Well, I quickly found two things.
- Edge will consistently SSO me into the Windows connected account, Max@Contoso.com, even when using the profile under Contoso-Bank.net. For example, I’ll go into Entra, Intune, etc, under my Contoso-bank.net Edge profile, with the purpose of administering Contoso-bank.net. Instead, Edge chooses to SSO me in with my Contoso.com Windows connected account. I then have to either log out or switch accounts, something which isn’t easy in every M365 portal, and then log in to the right account. What a pain!
- On top of the above, SSO doesn’t work for the profile connected account, and I instead have to manually login each time.
This is very frustrating. Why do I have a secondary profile, signed explicitly into a different account, and still I get forced into my primary account each time?? This even happens when I just try to open other tabs, so I’m constantly switching accounts or logging in and out just to administer the tenant that profile was specifically set up for.
It Turns Out That Actions Have Consequences.
Warning: This is going to get a little muddy. As often is the case with troubleshooting like this, the road isn’t clear sometimes until you reach the end, so take this with a grain of salt. This is all very fresh information, and some of what I’m getting is conflicting, so I’m distilling out the truth as best I can.
I opened a case with Microsoft over this issue really not expecting much. I figured it was some checkbox somewhere I just needed to flip about how accounts are handled or what takes the primary control.
Well, what I’m being told is that…
- Edge choosing to use the Windows connected account, despite the difference in profile account, is just a thing, and there is not a way to prevent a given Edge profile from doing this.
- The reason SSO isn’t working on my profile accounts is that the account needs a Primary Refresh Token (PRT). The way to get a primary refresh token… Is by Entra Registering the device, by adding a Work or School account.
Edge SSO Experience or Enterprise Activation?
This means you either get profiles on Edge with working SSO, or Enterprise Activation and all the policies you really need to use as an Enterprise…
Obviously, Enterprise Activation wins that fight (if you think otherwise, I’d be very curious why). But, it begs the question, what else is broken by not being able to get a PRT and/or add Work or School accounts?
I asked some trustworthy sources who have helped me find other elusive information, and the response was effectively that there is no way of knowing. How each individual product group may or may not leverage or require a PRT or Entra Registering for various functionality is unknown, or at least not something tracked centrally, and thus not capable of being reverse searched as I am trying to ask.
What Next?
Unfortunately, either the Edge team (and whatever other products are impacted) need to make changes to allow this to function again without a Work or School account, or the better answer is for Microsoft to fix the Work or School accounts subscription activation issue. I’m not responsible for anyone who chooses to hold their breath.
If any news comes out that is very Edge-specific, I will update this article. Otherwise, be on the lookout for new articles.
Update 5/27/25:
I’ve been in discussion with the Edge team, as well as the Windows Activation team, about this topic.
The Edge team has confirmed that Edge will always spot the Windows-connected account; you can’t stop this on a given profile. In an ideal world, the secondary account is Work or School, thus SSO can work, and the result is a pop-up to the effect of “Do you want to use account X or Y?” when logging into a portal, rather than just being dumped into the Windows connected account.
With SSO broken due to the lack of a workplace-joined account, Edge SSOs into the only other account, the Windows connected account. However, it seems that once you sign into the other account, Edge will now have an active token for the profile account, allowing that session to instead do the more helpful “Account X or Y” prompt going forward, at least until that token dies.
The Windows Activation team has confirmed that, well, I’m not even going to try and paraphrase this…
Please note that the initial sentence seems to indicate there is some problem with Work or School accounts from different tenants, but the rest goes on to clarify that in itself isn’t an issue, and the testing I’ve been working on seems to agree.
I wrote several annoyance-fueled paragraphs about this but it all really boils down…
- There’s no way to report on what accounts are where (Luckily I solved that)
- There’s no way to remove accounts that are there (Luckily I solved that too)
- There’s no way of knowing how an account is currently licensed if it’s not at an org you control
- There is no way to control what accounts are signed into (accounts in your org, out of your org, in a trusted org, that are licensed, etc)
- Plenty of accounts only need something like Office 365 Online, and it’s crazy to tell me to go knock on another organization’s doors and say, “Hey, yeah, they need Enterprise Windows licensing.”
- And most important of all – There is no good reason that anyone should be paying more than once for the same license, just so one singular device can step up to enterprise.
The excuse behind this I have been handed in other communications, is that the activation task (ClipRenew.exe) just can’t tell which account is right, so it picks from a hat or always picks the same account, which could be wrong. Not only do I believe that is an incredibly poor excuse if even true (It’s not that hard to find the primary account), but I also call BS.
As we saw last summer (see the linked articles at the top), activation lasts 90 days before dropping off due to failure. If this task runs at every startup, and it picks from a hat, surely even with a dozen joined accounts, it will eventually randomly choose the right one once in those 90 days. But it doesn’t, or at least didn’t, which tells me the problem isn’t it being confused and randomly picking. We also saw zero devices with multiple accounts succeeding to upgrade, which tells me the problem isn’t that it always picks a given account, and could be wrong. Instead, it seems to outright say no if any account isn’t licensed, meaning it’s checking every single account, not getting confused and looking at the wrong one.
That all said, I am working to re-test some of these claims as I personally recall seeing accounts that were licensed that broke it, but I’m actually having a hard time breaking it. I can add unlicensed accounts in other tenants, and, at least as of now, the task still reports success. I don’t know if this is some delay, or needs some X number of reboots, or what. In any case, without being able to replicate the issue even with the confirmed steps that should absolutely break it, it’s making testing very hard. I would love to believe this actually means it got fixed, but I’m not holding my breath. I’ll update when I can.
Disclaimer:
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 