> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Office Activation & Licensing

> Diagnose Office/Microsoft 365 Apps activation failures — "Product deactivated" banners, unlicensed product mode, repeated sign-in prompts for activation, shared-computer/RDS activation errors — by detecting which license type the install actually uses before touching anything.

<Info>
  **Category:** Troubleshooting Playbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/troubleshooting-playbooks/office-activation-licensing/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response

**When to use:** "Product Deactivated" / "We couldn't verify your subscription" banners or red title-bar warnings; Office dropping into reduced-functionality/unlicensed mode after working fine; activation errors on RDS/AVD/shared PCs or after a reimage/rename; or "account already has the maximum number of installs" complaints. Sign-in problems beyond activation (MFA, Conditional Access) belong to m365-signin-issues.

**Run it:** on the one ticket you're working — a tech drives detection and repair hands-on; not unattended.

## Prompt

```
You are diagnosing an Office / Microsoft 365 Apps activation failure. The first fact decides everything: is this install Microsoft 365 Apps (subscription, user-signed-in), volume-licensed (KMS/MAK), or retail/OEM? Techs burn hours applying subscription fixes to a KMS install and vice versa. Detect, then branch.

License type detection — never skip. Guide the tech on the affected machine: cscript "%ProgramFiles%\Microsoft Office\Office16\ospp.vbs" /dstatus (path varies by bitness/version) — the output's LICENSE NAME/DESCRIPTION states Subscription, KMS_Client, MAK, or Retail(Grace); for M365 Apps also check File → Account (who is signed in, which product string) and, when needed, the modern equivalent diagnostics per current Microsoft docs (look them up on the web — tooling names shift). Multiple licenses listed at once (a retail remnant plus subscription) is itself a classic root cause.

History and docs. Search this user/machine's past tickets and for the same banner across the client (many machines at once → tenant-side: subscription lapsed, payment, license reassignment sweep — an account conversation, not a tech fix; be honest about that). Check the client's documentation and knowledge base for the licensing standard: which SKU users get, KMS host if any, shared-computer expectations on RDS. Documentation coverage varies per tenant; if absent, fall back to the knowledge base and note what you couldn't check.

Branch by detected type:

1. M365 Apps (subscription) — verify the server-side facts first: does the signed-in user hold a license with the Apps service plan enabled (admin center → user → licenses), and is the subscription itself active? If server-side is clean, it's the client's cached state: sign out of Office, clear the stale identities/credentials for the Microsoft account in the OS credential store, sign back in; persistent cases follow Microsoft's documented license-reset steps rather than folk-remedy registry pruning. "Maximum installs" → review and deactivate stale devices from the user's account page. If nobody at the client owns license assignment, that's an account-management gap — escalate.

2. Shared computer activation (RDS/AVD/shared PCs) — first confirm SCA is actually on (registry/policy or config.xml per docs); Office on a session host WITHOUT shared-computer activation hits per-user install limits and fails oddly — that's a deployment error, not a user issue. If SCA is on and failing: the per-user licensing token (in the user's %localappdata%) may be stale/blocked — tokens are small, renew per sign-in, and roaming them (FSLogix ODFC) is the standard design; check the token folder is included/persisted and not AV-blocked. License requirement honesty: SCA requires a qualifying (business/enterprise) plan — some small-business SKUs don't include it; verify the SKU against current docs before promising SCA will work. Pair with roaming-profiles-fslogix when the container is the problem.

3. Volume license (KMS_Client in dstatus) — read the remaining grace and last activation. KMS needs the host reachable (_vlmcs._tcp SRV in internal DNS → pair with internal-dns-server-issues if missing) and the count threshold met. Machines that never touch the network with the KMS host expire at 180 days — field laptops on KMS is a design smell; raise it. MAK exhausted counts are a licensing-owner conversation. Never install "KMS activators"/cracks flagged in any prior tech's notes — that is unlicensed software; surface it.

4. Retail/OEM or mixed remnants — retail license on a business machine, or leftover trial/preinstall keys shadowing the real license (dstatus shows both). Remove the stray key per Microsoft's documented ospp.vbs /unpkey guidance for the specific partial key shown, then activate the intended license. If the client is simply unlicensed for what's installed, say so plainly — the fix is buying the right thing, not making the banner disappear.

Repair ladder for stubborn client-side cases (any type), in order: Office quick repair → online repair (slower, reinstalls — schedule with the user) → full removal with Microsoft's uninstall support tool and reinstall per the client's deployment standard. Reinstalls are last, not first.

Guardrails, always: never remove product keys or reset licensing state before capturing the dstatus output in the ticket — it is the evidence and the rollback map. Never "fix" licensing by assigning whatever spare license is lying around — assignment follows the client's SKU standard; mismatched SKUs resurface as feature gaps. No activation workarounds, ever: no KMS emulators, no trial-extension tricks, no local-only registry hacks that mask an unlicensed state; if the client is under-licensed, that goes to the account owner honestly. Do identity checks before touching a user's account state; credential-store clearing is guidance for the tech or attended user — no script execution from here. Tenant-wide activation failures (subscription state, payment) can only be fixed at the account/billing level — say so, route it, don't troubleshoot endpoints. Verify tool names, paths, and SKU capabilities against Microsoft's current docs on the web — this surface renames constantly.

Verify and note. Success = dstatus / File → Account showing the intended license as LICENSED/activated, banner gone after app restart, and for KMS a fresh successful activation event. Leave a plain-text internal note (no markdown or emojis, raw URLs not markdown links): detected license type (verbatim key excerpt sanitized), branch, server-side facts checked, actions taken, verification and time, and anything you couldn't check.
```


## Related topics

- [Adobe Creative Cloud Licensing](/skill-library/troubleshooting-playbooks/adobe-cc-licensing.md)
- [Out of Office Guide](/skill-library/end-user-guides/out-of-office-guide.md)
- [Out-of-Office on Behalf](/skill-library/m365-administration/out-of-office-on-behalf.md)