Office 365 sign-in: “Oops, something went wrong”

A user is activating Office or setting up their account in Outlook on Windows. They type their email address and password, maybe approve the MFA prompt, and then, instead of finishing, the sign-in window says “Something went wrong” (older builds say “Oops, something went wrong”). Sometimes there is an error code, sometimes the window just goes blank or closes. Office stays unactivated, or Outlook never finishes creating the profile and keeps showing “Need password”. The same account signs in to office.com in a browser on the same PC without any trouble.

This article covers the two fixes that resolve most cases: repairing the device’s registration with Microsoft Entra ID (formerly Azure AD), and resetting the Windows sign-in broker. It assumes you have local administrator rights and, for some steps, access to the Entra admin center.

Why it happens

Office desktop apps do not sign in on their own. They hand the job to Windows, through a component called the Web Account Manager (WAM) and its Microsoft.AAD.BrokerPlugin app package. The broker signs the user in using the device’s identity in Entra ID and keeps a token, the Primary Refresh Token (PRT), that gives single sign-on to every Microsoft 365 app.

The password is checked first, which is why the error only shows up after the user signs in: the credentials were fine, and it is the next step, tying the sign-in to the device and saving the token, that fails. It is also why the browser still works when Office does not: the browser can sign in without the broker. When you see this error, one of two things is usually broken:

• The device registration. The computer’s record in Entra ID was deleted, disabled, duplicated or never finished registering, or the keys that prove the device’s identity no longer match (common after a motherboard or TPM change, or when a machine was imaged from a PC that had already registered).
• The broker itself. The Microsoft.AAD.BrokerPlugin package is missing or damaged for that user, or its cached account data is corrupt.

Step 1: Get the error code

In the error window, select More details or the … link if there is one, and write down the code. If the window gives you nothing, open Event Viewer and look at Applications and Services Logs > Microsoft > Windows > AAD > Operational around the time of the failure.

Code	What it usually means	Start with
1001	The sign-in broker failed to start or crashed. Often the BrokerPlugin package is not registered for the user.	Fix B
CAA50021	Device authentication was retried too many times. The device record and the local device keys do not agree.	Fix A
CAA20002, CAA20003	The token request was rejected. Often a device that is disabled, stale or not compliant.	Fix A
135011	The device is disabled in Entra ID.	Fix A (re-enable it)
700003	The device was deleted from Entra ID.	Fix A (re-register)
80090016, “TPM has malfunctioned”	The keys protecting the device or user identity cannot be read, typically after a hardware change.	Fix A, then Fix B

No code, or one that is not listed? Do Step 2 anyway. It tells you which fix applies.

Step 2: Check the device state

Sign in as the affected user, open a Command Prompt (not elevated, so that you see the user’s token state) and run:

dsregcmd /status

These are the lines that matter:

Section	Field	Healthy value
Device State	AzureAdJoined	YES for Entra joined and hybrid joined devices
Device State	DomainJoined	YES as well if the device is hybrid joined
Device Details	DeviceAuthStatus	SUCCESS. Anything else means Entra ID does not accept this device: deleted, disabled or mismatched keys.
User State	WorkplaceJoined	NO on a joined device. YES here together with AzureAdJoined : YES means the device is registered twice.
SSO State	AzureAdPrt	YES. NO means the user has no Primary Refresh Token, so Office cannot sign in silently.

• DeviceAuthStatus is not SUCCESS, or the device shows both joined and workplace joined: go to Fix A.
• The device state is healthy but AzureAdPrt is NO, or everything looks healthy and Office still fails: go to Fix B.

Also find the computer in the Entra admin center under Devices > All devices. Check that it exists, that it is enabled, that there is only one record for it, and that the join type is what you expect.

Fix A: Repair the device registration

First, if the device is merely disabled in Entra ID, enable it, have the user sign out of Windows and back in, and test. If it was deleted or the keys do not match, the device has to leave and register again. How you do that depends on the join type.

Hybrid joined (domain joined and registered in Entra ID)

1. Make sure the PC can reach a domain controller (on the network or on VPN).
2. Open an elevated Command Prompt and run dsregcmd /leave.
3. Delete any leftover records for this computer in the Entra admin center.
4. Restart. The join runs again from the scheduled task Task Scheduler Library > Microsoft > Windows > Workplace Join > Automatic-Device-Join, which fires at sign-in. You can also run it by hand.
5. Run dsregcmd /status again. If your organisation uses Entra Connect sync rather than federation, the computer object has to sync from Active Directory first, so the join can take a sync cycle (30 minutes by default) to complete. Until then the status shows the join as pending.
6. When AzureAdJoined is YES and DeviceAuthStatus is SUCCESS, have the user sign out and back in to Windows to get a fresh PRT, then open Office.

Entra joined (cloud only, no on-premises domain)

Stop and check first. On an Entra joined PC, dsregcmd /leave removes the join, and with it the ability to sign in with work accounts. Before you run it, confirm you can sign in with a local administrator account, and know that the user’s profile is tied to the join. Try Fix B first on these machines.

1. Sign in with a local administrator account.
2. Run dsregcmd /leave from an elevated prompt, or use Settings > Accounts > Access work or school > Disconnect.
3. Remove the old device record in the Entra admin center.
4. Restart, then join again from Settings > Accounts > Access work or school > Connect > Join this device to Microsoft Entra ID.

Registered twice (joined and workplace joined)

This happens when a user on a joined PC answers “Allow my organization to manage my device” or “Stay signed in to all your apps” in an Office prompt. The extra registration conflicts with the real one.

1. Go to Settings > Accounts > Access work or school.
2. Select the entry labelled Work or school account (not the one that says “Connected to … AD domain” or “Connected to … Microsoft Entra ID”) and choose Disconnect.
3. Delete the matching “Microsoft Entra registered” record for the device in the admin center.
4. Sign out and back in, and test Office.

To stop it coming back on domain joined machines, set this registry value by Group Policy or your management tool:

HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin
BlockAADWorkplaceJoin (REG_DWORD) = 1

Fix B: Reset the sign-in broker

1. Re-register the broker package

This is Microsoft’s documented fix for error 1001 and it is safe to run. It must run as the affected user, in a normal (not elevated) PowerShell window, because app packages are registered per user:

Get-AppxPackage Microsoft.AAD.BrokerPlugin

Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown
Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown

If the first command returns nothing, the package was not registered for this user, and that was your problem. Run the two Add-AppxPackage lines, close all Office apps, and try signing in again.

2. Clear the Office identity cache

If re-registering did not help, clear what Office itself has cached. Close every Office app, including Teams and OneDrive, then as the affected user:

Remove-Item "$env:LOCALAPPDATA\Microsoft\OneAuth" -Recurse -Force
Remove-Item "$env:LOCALAPPDATA\Microsoft\IdentityCache" -Recurse -Force
Remove-Item "HKCU:\Software\Microsoft\Office\16.0\Common\Identity" -Recurse -Force

The user will be asked to sign in to Office again. Nothing else is lost: mail profiles, documents and settings are not stored in these locations.

3. Last resort: rebuild the broker’s cache

Use with care. Microsoft does not recommend deleting the broker’s data folder, because other apps’ saved work accounts live there too and every one of them will have to sign in again. In practice it is the step that clears stubborn cases, so treat it as the last resort before rebuilding the Windows profile, and rename the folder rather than deleting it so you can put it back.

1. Have the affected user sign out of Windows completely (the folder is locked while they are signed in).
2. Sign in with a different administrator account.
3. Rename the folder below, for example by adding .old to the end.
4. Sign back in as the user, run the two Add-AppxPackage commands from step 1, then open Office and sign in.

C:\Users\<username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy

Still failing?

• Clock and network. A system clock that is off by more than a few minutes breaks token validation. A proxy, firewall or TLS inspection device that interferes with login.microsoftonline.com, device.login.microsoftonline.com or enterpriseregistration.windows.net breaks device authentication. Test from a different network if you can.
• Conditional Access. Check the user’s entry under Entra admin center > Monitoring > Sign-in logs. A policy that requires a compliant or hybrid joined device will block Office on a machine whose registration is broken, and the log tells you exactly which policy and why.
• Event logs. Besides the AAD Operational log, look at Microsoft > Windows > User Device Registration > Admin for join failures.
• New Windows profile. If another user can sign in to Office on the same PC, the damage is in the profile. If no one can, it is the device.

Preventing it

• Imaging: never capture a reference image from a machine that has already joined or registered with Entra ID. Every PC deployed from it inherits the same device identity and they fight over one record. Capture before the join happens, and let each machine register itself after deployment.
• Hardware repairs: after a motherboard or TPM replacement, expect this error. Plan a dsregcmd /leave and re-join as part of the repair.
• Stale device clean-up: if you delete or disable inactive devices in Entra ID on a schedule, a laptop that comes back after a long leave will hit this. Fix A brings it back.
• Block double registration on domain joined PCs with the BlockAADWorkplaceJoin value shown above.

Did one of these work for you, or did you find a cause that is not listed? Tell us in the Help forum so the article gets better.