Office 0x80070005: activation fails with an access denied error

Fix it now

0x80070005 is ERROR_ACCESS_DENIED, but on Microsoft 365 Apps it is usually the identity broker being blocked rather than a file permission. Microsoft’s documented causes are antivirus, a proxy or a firewall blocking the broker process, corrupted broker data, stale cached credentials, and a bad tokens.dat. Work those before touching an access control list.

net stop sppsvc
ren %SystemDrive%\Windows\System32\spp\store\2.0\tokens.dat tokens.old
net start sppsvc

1. Install outstanding Windows updates and restart. Microsoft’s list for this code starts there, and it is not filler.
2. Clear the credentials: Credential Manager, Windows Credentials, remove anything named MicrosoftOffice16. Then Settings, Accounts, Access work or school – disconnect the Office account if it is not the account you sign in to Windows with. Restart.
3. Check whether antivirus, a proxy, a firewall or a VPN is blocking Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy. Disable each temporarily to test.
4. If nothing is blocking it, delete the contents of %LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts and of the matching Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy folder, then restart.
5. Run the tokens.dat rename above, then perform an Online Repair of Office and restart.

On volume-licensed Office you can retry activation with cscript ospp.vbs /act from an elevated prompt. Microsoft states that script does not work for Microsoft 365 Apps or subscription Project and Visio – there, run .\vnextdiag.ps1 -action list instead.

If Office activates you can stop here. If it still reports access denied, the next section covers the permission case, which is real but is not where most of these end up.

Why it happens

The code is unambiguous about the symptom and silent about the cause. 0x80070005 is the Windows error ERROR_ACCESS_DENIED – access is denied – and it can be raised by anything in the activation path that was refused something. The instinct is to read it as a file or registry permission, and sometimes that is right. On Microsoft 365 Apps it usually is not, and Microsoft’s own troubleshooting page for this code says so by what it lists: Windows updates, cached Office credentials, the identity broker being blocked by antivirus or a proxy or a firewall, corrupted broker data, a bad tokens.dat, and finally a fresh Windows user account. Permissions do not appear until you reach the separate support article for the post-update case.

There is a second reason the permission instinct misleads on subscription installs. Microsoft 365 Apps moved off the Office Software Protection Platform at version 1910, and its licence is not machine-wide state guarded by an access control list – it is a per-user file under %localappdata%\Microsoft\Office\Licenses, with an ID beginning EWW. On the product most readers are running, this is a per-profile problem, and hunting machine-wide ACLs looks in a place the licence does not live.

Where permissions genuinely are the cause, Microsoft publishes an exact remedy for the case that follows a Windows update, and it is not the one people guess. The key is HKEY_USERS\S-1-5-20 – the NETWORK SERVICE profile hive, under HKEY_USERS rather than HKEY_LOCAL_MACHINE – and the documented steps grant Full Control there to the logged-on user and to NETWORK SERVICE, then replace all child object permission entries with inheritable entries from that key.

The companion codes separate two different situations from the access-denied one. 0x80070002 is ERROR_FILE_NOT_FOUND, the system cannot find the file specified, and 0x80070003 is ERROR_PATH_NOT_FOUND, the system cannot find the path specified. Those point at something missing rather than something locked, and the repair is different – restore the files rather than re-permission them.

Full reference

Which product you are on decides most of this

Getting this wrong wastes the most time of anything in this article. A subscription user who runs ospp.vbs gets a meaningless result and concludes the machine is broken. Look in the Office program folder: if ospp.vbs is not there, or vnextdiag.ps1 is, you are on the subscription product and the left-hand column applies.

The registry fix, exactly as Microsoft publishes it

1. Close all Office apps.
2. Open Registry Editor and allow it to make changes.
3. Expand HKEY_USERS and select S-1-5-20.
4. Right-click S-1-5-20 and select Permissions, then Add.
5. Type the logged-in user’s name, select Check Names, then OK.
6. Select Advanced. On the Permissions tab select the user you just added and select Edit.
7. Under Basic permissions select Full Control, then OK.
8. Back on the Permissions tab select NETWORK SERVICE, select Edit, and give it Full Control if it does not have it.
9. Tick Replace all child object permission entries with inheritable permission entries from this object, then OK.
10. Close Registry Editor and restart an Office app to try activating again.

This changes permissions on a system profile hive and applies them down the tree. Take a restore point first. It is the vendor’s own remedy for this code after a Windows update, and it is not a general-purpose fix – do not apply it to a machine whose failure has a different shape.

When it is file-not-found rather than access-denied

0x80070002 and 0x80070003 mean the licensing path could be reached and what was expected is not there. That is a restore problem, not a permission problem. Run sfc /scannow from an elevated prompt, then DISM /Online /Cleanup-Image /RestoreHealth, then an Online Repair of Office, which restores the Office licence files. Re-permissioning anything at that point achieves nothing, because the object you would be granting access to does not exist.

Codes that come along for the ride

0x8004E10D and 0x8004E10B turn up in the same exchange and Microsoft publishes no meaning for either. They are not a second problem and they are not a clue. Diagnose from 0x80070005 and from the two file-not-found codes, all three of which are documented Windows errors with unambiguous meanings, and ignore any page that offers you a confident definition for the other two.

What not to do

• Do not run the Office applications themselves as administrator. Elevating the activation command is a reasonable test; leaving Word running elevated breaks file associations and add-ins and solves nothing.
• Do not grant broad permissions on the licensing paths on a hunch. The documented change is specific, and a hand-made one leaves the machine in a state nothing else expects.
• Do not chase sppsvc on Microsoft 365 Apps. It has not been part of that product’s activation since version 1910.
• Do not reinstall Office as a first move. Nothing in Microsoft’s list is fixed by a reinstall, and an Online Repair does the useful part without removing anything.
• Do not leave antivirus, the proxy or the VPN disabled after testing. If one of them is the cause, the fix is an exemption for the named broker process, not a machine with its protection off.

Every code this article covers

Confirm the fix worked

1. On Microsoft 365 Apps, .\vnextdiag.ps1 -action list from the Office folder reports a licence, and a file exists under %localappdata%\Microsoft\Office\Licenses.
2. On volume-licensed Office, cscript ospp.vbs /dstatus from an elevated prompt reports the licence status as licensed.
3. Open an Office application as the affected standard user and confirm it is fully functional with no banner.
4. Restart and re-check, to confirm the state persists rather than reverting at the next policy refresh.
5. Confirm any antivirus, proxy or VPN disabled during testing is switched back on and activation still holds.

Questions people ask about this