Error Code 1001 in Microsoft Teams usually shows up during sign-in, not during chat, calls, or meeting media. When the browser version opens but the desktop app does not, the fault is often local to the Windows or macOS sign-in stack: Teams cache, identity cache, WAM, AAD.BrokerPlugin, security software, or a roaming profile rule that moved data that should have stayed on the device. Microsoft documents two recurring patterns behind Something went wrong [1001]: security software interfering with the WAM plug-in, and user profile management issues.
What usually fixes it fastest? Start with a full Teams quit, test Teams on the web, clear the correct cache for your client version, then move to the WAM side if the desktop app still fails. On managed devices, involve IT early when endpoint protection, WFP drivers, shared PCs, or VDI are part of the setup.
Table of Contents
What Error Code 1001 Usually Points To
This code is most often tied to the authentication layer. In plain terms, Teams cannot complete the desktop sign-in handoff. The visible app is Teams. The deeper moving parts are Web Account Manager, the AAD.BrokerPlugin, identity caches such as OneAuth and IdentityCache, and the local user profile where those components live.
Microsoft’s own troubleshooting for the 1001 family separates the issue into two main buckets:
- Security software or old filtering drivers interfere with the WAM plug-in, break it, or block the communication path it relies on.
- User profile management moves or roams identity-related data that should stay local, leaving token and device identity data in a bad state.
A useful clue: Microsoft notes that WAM plug-ins are installed in the context of the user profile. So one Windows user can fail with 1001 while another user on the same PC signs in without trouble. Local issue. Not always device-wide.
How to Narrow Down the Cause Fast
You do not need to guess. A short isolation pass usually tells you where to work next. Check these signals first, in order.
| Signal | What It Usually Means | What to Do Next |
|---|---|---|
| Teams on the web signs in, desktop app fails | Local desktop sign-in path is the likely fault | Clear Teams cache, then inspect WAM and identity caches |
| Only one Windows profile is affected | Per-user plug-in or profile state is more likely than a tenant-wide outage | Work inside the affected user profile, not only as admin |
| The issue started after endpoint security changes | Security software or WFP interference moves to the top of the list | Ask IT to test exclusions and inspect recent policy changes |
| The device is shared, pooled, or profile-managed | Roaming identity data can break sign-in state | Review profile roaming rules and VDI guidance |
| Classic Teams was replaced by new Teams recently | The wrong cache path may be getting cleared | Use the correct cache path for your Teams version |
That simple split matters because many generic articles stop at “clear cache.” Sometimes that works. Often it does not, because the damaged layer is below Teams itself. In practice, administrators often compare the behavior with other documented common Teams error scenarios to see whether the pattern points to identity components, cache corruption, or security software interference rather than the Teams UI.
Fixes in Order That Solve Most Cases
1. Restart the Device and Fully Quit Teams
Microsoft says a reboot can temporarily relieve the issue in some 1001 cases. Before doing anything else, fully quit Teams. Do not just close the window. Exit it from the taskbar or menu bar so cached files and sign-in helpers stop running.
2. Test Whether Teams on the Web Works
Open Teams on the web and try the same account. If the web client signs in normally, your Microsoft 365 account is usually fine and the fault is more likely in the desktop client path. That is the cleanest fork in the road.
3. Clear the Correct Teams Cache for Your Version
This step fixes corrupted client state, stale UI data, broken local preferences, and some token handoff problems. Use the right path, though. New Teams and Classic Teams do not store cache in the same place.
Windows Classic Teams %appdata%\Microsoft\Teams Windows New Teams %userprofile%\appdata\local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams macOS Classic Teams rm -r ~/Library/Application\ Support/Microsoft/Teams macOS New Teams rm -rf ~/Library/Group Containers/UBF8T346G9.com.microsoft.teams rm -rf ~/Library/Containers/com.microsoft.teams2
After the delete, launch Teams again and let it rebuild. The first start can take a bit longer. Normal, that is.
4. Repair the Microsoft 365 App Stack
If Teams is installed with the broader Microsoft 365 app set, a damaged Office component can keep the sign-in flow from finishing. Microsoft’s repair flow offers two routes: Quick Repair and Online Repair. Quick Repair is faster. Online Repair is more thorough because it replaces corrupted files more completely.
Practical order: run Quick Repair first if you need the least disruption. If 1001 comes back, move to Online Repair.
5. Inspect WAM and Re-Register the Plug-ins if Needed
This is where many 1001 cases are actually solved. Microsoft’s desktop sign-in troubleshooting says to check whether the two user-context plug-ins are present and callable. If they are missing, broken, or fail to open, re-register them.
PowerShell checks Get-AppxPackage Microsoft.AAD.BrokerPlugin Get-AppxPackage Microsoft.Windows.CloudExperienceHost Command Prompt launch tests explorer.exe shell:appsFolder\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy!App explorer.exe shell:appsFolder\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy!App PowerShell re-registration 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
Microsoft also advises monitoring for 48 hours after re-registration. If the error returns after security tools or filtering drivers load again, the environment likely needs package, folder, or process exclusions rather than repeated cache clears.
6. Review Security Software and Old WFP Drivers
Official Microsoft guidance is unusually direct here: in some cases, you may need to temporarily uninstall the third-party security software and any obsolete standalone Windows Filtering Platform drivers while testing. That is an IT task on managed machines. Disabling the product is not always enough if a driver still loads early in the session.
Folders and packages Microsoft highlights for exclusions include %localappdata%\Microsoft\TokenBroker, %localappdata%\Microsoft\OneAuth, %localappdata%\Microsoft\IdentityCache, plus the Microsoft.AAD.BrokerPlugin and Microsoft.Windows.CloudExperienceHost package families.
7. Run Microsoft’s Sign-in Troubleshooter
If you want an official guided pass before manual repair work, open Get Help in Windows and run the Microsoft 365 sign-in troubleshooter. Microsoft instructs users to search for sign in to Microsoft Office inside Get Help. This is useful when the issue spans Teams and other Microsoft 365 apps at the same time.
Technical Paths and Commands Worth Checking
These values are the ones that matter most in 1001 investigations. They give you a cleaner handoff to IT, too.
| Area | Value | Why It Matters |
|---|---|---|
| Classic Teams cache | %appdata%\Microsoft\Teams | Old client state lives here |
| New Teams cache | %userprofile%\appdata\local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams | New client uses a different local cache path |
| Identity cache folders | %localappdata%\Microsoft\OneAuth %localappdata%\Microsoft\IdentityCache %localappdata%\Microsoft\TokenBroker | These stores often explain desktop-only sign-in loops |
| WAM package families | Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy | Missing or broken packages can trigger 1001 |
| Primary repair commands | Get-AppxPackage … Add-AppxPackage -Register … | Used to verify and re-register the user-context sign-in components |
One more detail: Microsoft’s 1001 support article explicitly says that on both VDI and some physical devices, roaming data under %localappdata% can leave authentication components in a bad state. If your environment uses profile containers or migration tools, this is not a side note. It is often the root cause.
Why Desktop Fails While Teams on the Web Still Works
This pattern is common, and it tells you a lot. Teams on the web uses the browser path, while the desktop client relies more directly on local app state and user-context authentication components. So when the browser works, the account, license, and service are often still fine. The damaged layer tends to be local cache, WAM, a security product, or a profile rule.
Microsoft currently lists desktop browser support for Teams on the web as the latest three versions of Edge, Chrome, and Firefox, plus the latest two versions of Safari on macOS. Microsoft also notes that some third-party or line-of-business apps need third-party cookies enabled in the browser.
What Changes in Managed PCs, VDI, and Roaming Profiles
In shared desktops, pooled devices, and profile-managed environments, Error 1001 can become stubborn because identity data gets copied where it should not. Microsoft’s Entra guidance says roaming data under %localappdata% is not supported for these identity components. That includes paths for BrokerPlugin, CloudExperienceHost, TokenBroker, OneAuth, and IdentityCache.
There are also concrete operating numbers in Microsoft’s VDI guidance. For non-persistent VDI, Microsoft recommends staging device registration requests at 500 requests per 2 minutes and 30 seconds. It also recommends deleting stale non-persistent devices whose ApproximateLastLogonTimestamp is older than 15 days. Those figures matter when sign-in trouble appears across a pool instead of on one machine.
- Review profile container rules and migration tools for %localappdata% items.
- Do not assume a repeated cache clear will fix a roaming identity problem.
- Check whether the affected estate is persistent or non-persistent.
- On managed devices, ask IT to inspect both security exclusions and device identity hygiene.
FAQ
Does Error Code 1001 Mean My Microsoft Account Is Broken?
Usually no. If Teams on the web opens with the same account, the account itself is often fine. That pattern points more strongly to desktop sign-in components, local cache, or profile state.
Why Does Teams on the Web Work While the Desktop App Fails?
The browser and desktop app do not use the exact same local sign-in path. When the browser succeeds, the fault is often in WAM, AAD.BrokerPlugin, Teams cache, or a local profile issue. Desktop-only failure is a strong clue.
Which Cache Path Should I Clear for New Teams on Windows?
For new Teams, the Windows cache path is %userprofile%\appdata\local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams. Classic Teams uses %appdata%\Microsoft\Teams instead.
When Should IT Check Security Software or WFP Drivers?
Right away when 1001 started after a policy or endpoint protection change, when one user profile fails repeatedly on a managed machine, or when re-registering WAM helps only for a short time. That pattern often points to interference, not just stale cache.
Can VDI or Roaming Profiles Trigger Error 1001?
Yes. Microsoft’s guidance says roaming identity-related data under %localappdata% is not supported for these sign-in components. In shared or non-persistent environments, that can leave the desktop authentication state unusable.