---
title: "Office 365 sign-in: “Oops, something went wrong”"
description: "You sign in to activate Office or set up Outlook, and right after the password the window says \"Something went wrong\", often with a code such as 1001 or CAA50021. The cause is almost always the Windows sign-in broker or the device's Entra ID registration. Here is how to tell which, and how to fix each."
url: "https://keh-tech.net/kb/office-365-sign-in-oops-something-went-wrong/"
updated: "2026-09-21"
category: Troubleshooting
tags:
  - Entra ID
  - Microsoft 365
  - "Sign-in"
  - Windows
---

# 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:

```
HKLMSOFTWAREPoliciesMicrosoftWindowsWorkplaceJoin
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:windirSystemAppsMicrosoft.AAD.BrokerPlugin_cw5n1h2txyewyAppxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown
Add-AppxPackage -Register "$env:windirSystemAppsMicrosoft.Windows.CloudExperienceHost_cw5n1h2txyewyAppxmanifest.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:LOCALAPPDATAMicrosoftOneAuth" -Recurse -Force
Remove-Item "$env:LOCALAPPDATAMicrosoftIdentityCache" -Recurse -Force
Remove-Item "HKCU:SoftwareMicrosoftOffice16.0CommonIdentity" -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>AppDataLocalPackagesMicrosoft.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 Patch Panel](/community/help/) so the article gets better.*