Some problems take five minutes. This one should have, and didn’t.
We had a client user who needed Excel on a Windows Server 2019 Remote Desktop host. Simple enough, since a number of other people on the same server were already using Excel without any trouble. But for this one user, Office refused to sign in, and every fix we tried just produced a different error. Here’s what was going on and how we sorted it out. We’ve also put together a script so you don’t have to do it by hand.
The Challenge
On a Remote Desktop Services (RDS) host, Microsoft 365 Apps runs in Shared Computer Activation mode. Instead of activating against the machine, Office gets a licence token for each user who signs in. That works well, but only if every user’s licence supports shared activation, and only if each user’s Windows profile is clean.
Our user hit both problems!
The Errors You Might See
Error 1: the licence doesn’t support a shared environment. The first time he opened Excel, Office told him his account couldn’t be used on a shared computer. The exact wording varies by build. That’s expected if the user has a licence without shared computer rights, like Microsoft 365 Business Basic or an Apps for Business plan on its own. The fix is to assign a licence that includes it, such as Microsoft 365 Apps for enterprise, Business Premium, or an E3/E5 plan.
Error 2: after fixing the licence, a new error appeared:
Another account from your organization is already signed in on this device. Try again with a different account.
This is the one that wastes an afternoon (To be fair the afternoon also entailed setting up a powershell script to make this easier in the future). The licence is now correct. Nobody else is signed into his profile. Other users on the same server are working fine. So what’s going on?
What’s Actually Happening
When that first sign-in attempt failed, Office and Windows didn’t throw away what they’d learned. They cached his identity in several places in his profile: the Office identity registry keys, the shared-computer licence token folder, the newer OneAuth and IdentityCache folders, and the Windows token broker (WAM) cache.
When he tried again with the corrected licence, Office found that leftover cached identity, decided it was “another account,” and blocked the sign-in. Everyone else on the server was fine because they’d started clean on a proper licence.
A useful first check is running dsregcmd /status as the affected user, in a normal (non-admin) prompt. If you run it elevated, you’ll see the admin’s state, not the user’s. If WorkplaceJoined shows NO and the server isn’t Entra joined, the problem is in the token caches, not a device registration.
How to Fix It
Everything below affects only the one user’s profile. Other people on the server can keep working.
- Have the user sign out completely. Disconnecting the RDP window isn’t enough. Check with
query userand log off any leftover session. - Clear the Office identity keys from the user’s registry hive:
Software\Microsoft\Office\16.0\Common\IdentitySoftware\Microsoft\Office\16.0\Common\LicensingSoftware\Microsoft\IdentityCRL
- Delete the cache folders under
C:\Users\<user>\AppData\Local\:Microsoft\Office\16.0\Licensing(the shared computer licence token)Microsoft\OneAuthMicrosoft\IdentityCache
- Clear the Windows token broker cache inside
Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy. - Have the user sign back in. Before opening Office, go to Credential Manager → Windows Credentials and remove anything starting with
MicrosoftOffice16_DataorSSO_POP. - Open Excel and sign in. If it asks whether to stay signed in to all your apps, choose “No, sign in to this app only.”
One snag to watch for: if the user is logged off, you edit their registry by loading NTUSER.DAT. If Windows hasn’t released the hive yet, that fails, and you need to edit it under HKEY_USERS\<their SID> instead. That’s exactly the kind of thing that turns five minutes into an hour.
We Scripted It
After doing this by hand once, we didn’t want to do it again, so we wrote a PowerShell script that handles the whole cleanup:
Reset-OfficeIdentity.ps1 on GitHub
Disclaimer: This script is provided as-is, without warranty of any kind, and you use it at your own risk. It modifies a user’s registry hive and deletes cached sign-in data from their profile. Read through it before running it, test it on a non-production server or a test account first, and make sure you have a current backup of the server or the user’s profile. It’s written for Microsoft 365 Apps on Windows Server RDS hosts and hasn’t been tested on every Windows or Office version. Aspyn Information Services isn’t responsible for any data loss, downtime or other issues resulting from its use. If you’re not comfortable working in the registry, reach out to us and we’ll take care of it for you.
Run it as an administrator on the RDS host:
powershell -ExecutionPolicy Bypass -File .\Reset-OfficeIdentity.ps1 -UserName stuartThe script:
- Asks for the username, or takes it as a parameter, and finds the user’s profile and SID
- Checks whether the user is still signed in, including disconnected sessions and leftover processes. If they are, it tells you which session to log off and stops without changing anything.
- Loads the user’s registry hive, or edits it in place if Windows is still holding it, removes the Office identity keys, and unloads it safely
- Clears the Office licence, OneAuth, IdentityCache and token broker caches
- Offers to set the server policy that stops this from happening again (below)
- Logs every run to
C:\ProgramData\OfficeIdentityReset\
Credential Manager entries are encrypted per user, so the script can’t safely remove them. It reminds you to have the user clear them at their next sign-in.
Stop It From Happening Again
On a shared RDS host, users should never be registering their work accounts to the server. Block it with this policy, either in the registry or through Group Policy:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin
BlockAADWorkplaceJoin = 1 (DWORD)It’s safe to apply while people are working and doesn’t sign anyone out.
And make sure every RDS user has a licence with shared computer activation before their first sign-in. Most of this mess comes from that first failed attempt.
One more thing worth saying: Microsoft ended support for Microsoft 365 Apps on Windows Server 2019 in October 2025. It still runs, but sign-in and activation issues like this one get more likely over time, and Microsoft won’t help. If your RDS host is on 2019, it’s time to plan the move to Server 2022 or 2025.
Need a Hand?
If your Remote Desktop server is giving your team grief, or you’d just rather not spend your evening in the registry, get in touch with us at Aspyn. We’ll get your users working and set things up so it doesn’t happen again. Let’s make your IT work for you, not the other way around.
