Office Activation & Licensing

The first fact decides everything: Microsoft 365 Apps (subscription), volume-licensed (KMS
or MAK), or retail/OEM? Have the tech run ospp.vbs /dstatus (path varies by Office version
and bitness): LICENSE NAME and DESCRIPTION say Subscription, KMS_Client, MAK or
Retail(Grace), and File > Account names who is signed in. Two licenses at once, a retail
remnant beside a subscription, is a classic cause.

Climb the Troubleshooting Ladder base skill for the rest: past tickets for this user and
for the same banner across the client — many at once is tenant-side (lapsed subscription,
payment, a reassignment sweep), an account conversation, not a tech fix; then
documentation for the licensing standard, KMS host and shared-computer expectations.

1. Microsoft 365 Apps — check the server side first: the user holds a license with the
   Apps service plan enabled and the subscription is active. If clean, it is cached client
   state: sign out, clear stale Microsoft identities from the OS credential store, sign
   back in, then Microsoft's documented license-reset steps. "Maximum installs" means
   deactivating stale devices on the account page.

2. Shared computer activation on session hosts — confirm SCA is enabled; without it Office
   hits per-user install limits and fails oddly, a deployment error, not a user issue.
   With SCA on, the per-user token in %localappdata% may be stale or blocked: check it
   persists (FSLogix Office container roaming is the standard design) and isn't
   AV-blocked. SCA needs a qualifying business or enterprise plan.

3. Volume license (KMS_Client) — read the remaining grace and last activation. KMS needs
   the _vlmcs._tcp SRV record in internal DNS and the count threshold met; machines that
   never touch the KMS host expire at 180 days, so field laptops on KMS are a design
   smell. Exhausted MAK counts are a licensing-owner conversation.

4. Retail, OEM or mixed remnants — a leftover trial or preinstall key shadowing the real
   license, dstatus showing both. Remove the stray with ospp.vbs /unpkey for the partial
   key shown, then activate the intended one.

Stubborn client-side cases, in order: quick repair, online repair (a reinstall — schedule
it), then full removal with Microsoft's uninstall tool and a fresh install per the
client's standard.

Never remove a key or reset licensing state before capturing dstatus: it is the evidence
and the rollback map. Never assign a spare license off the client's SKU standard. No
activation workarounds ever: no KMS emulators, no trial tricks, no registry hacks masking
an unlicensed state. Under-licensing goes to the account owner; tenant-wide failures are
fixed at billing level.

Success is dstatus or File > Account showing the intended license activated, banner gone.
Note it (apply the PSA Note Discipline base skill): license type, branch, server-side
facts, actions, verification.