Office 2016/2019 Licenses Dying Overnight: How to Scope Fleet-Wide Impact With RMM Scripts Before Your Helpdesk Floods

Monday, 9:04 AM: "My Word Says Product Deactivated"

The Register recently reported that IT admins running the perpetual-license versions of Office 2016 and Office 2019 — the versions that everyone keeps meaning to "eventually sunset" — are blaming a recent Microsoft update for mass license deactivations. Red title bars. "UNLICENSED PRODUCT" banners. Users locked out of editing the very documents they were working on Friday afternoon. And Microsoft, in classic form, is refusing to confirm whether the update is actually at fault.

If you support either of these versions at scale — as an internal IT team, or worse, as an MSP across a dozen client environments — you already know how the morning plays out. The helpdesk inbox fills before 9:15. Users who can't edit contracts and invoices escalate to department heads, who escalate to your boss. And through all of it, your monitoring console sits there, green and smug, because none of your tools were watching Office activation state in the first place.

Let's be blunt about the real failure here: a vendor shipped something that broke licensing across legacy Office builds, and you found out from your users, not from your systems. That's not just a Microsoft problem. That's an RMM gap. And it's one you can close permanently — this week, with the scripts below.

Why This Bug Is Uniquely Painful for the Teams Holding On to Perpetual Office

Office 2016/2019 holdout estates are the most heterogeneous, least-observed corners of any environment, and this incident exploits exactly that:

• They're not M365, so your update telemetry is thin. Your patch compliance reports almost certainly track Windows builds and maybe C2R channels for M365 Apps. Nobody's dashboard shows you the Click-to-Run build number of Office 2019 Standard on the finance floor.
• Activation state is invisible to classic monitoring. Nagios checks, perf counters, service monitors — none of them look at ospp.vbs output. Licensing isn't a CPU spike; it fails silently until a user screams.
• The estate is a mix of install types. Office 2016 MSI volume-licensed, Office 2019 MSI, Office 2019 Click-to-Run — each with different activation paths (KMS, MAK, digital license) and different file locations for the licensing tooling. Your remediation isn't one script; it's three.
• MSPs get multiplied pain. If client A's 2019 deployment breaks, client B's 2016 deployment might not — and without a per-client fleet script, you're RDPing into machines one by one to find out.

What Your Current Tooling Gets Wrong Here

If you run a standalone RMM next to a separate helpdesk next to a separate monitoring stack, this incident turns into a manual triage marathon:

• Your RMM can run scripts, but the results go nowhere. You export a CSV, paste it into the ticket, and it's stale in an hour.
• Your helpdesk floods with duplicate tickets that no one correlates against the actual scope of the outage. You're answering "is it just me?" forty times.
• Your monitoring tool never raises an alert because "Office license deactivated" isn't a check it knows how to run.
• Nobody owns the C2R version pin, so when a bad build lands, it lands everywhere at once.

The Real Cost, in Numbers a Sysadmin Will Recognize

Take a realistic mid-size scenario: 400 endpoints, roughly 55% on Office 2016 or 2019.

• ~70–90 tickets in two hours, mostly duplicates of the same root cause.
• 15–20 minutes per machine to triage manually: RDP in, open Word, check File → Account, run ospp.vbs /dstatus, screenshot, document. Two technicians doing nothing else for a full day, minimum.
• SLA blown on resolution even if first-response targets were met — you can acknowledge tickets fast and still not know the blast radius until 4 PM.
• Real business impact: anyone who needs to edit a document is dead in the water. For an MSP, that's a client calling your account manager before lunch.

The killer detail: the technical information you needed — "which machines, which builds, licensed or not" — takes one script run to collect. The gap isn't knowledge. It's that your tools can't execute and correlate that answer in one place.

How AlertMonitor Turns This From a Day of Chaos Into a 10-Minute Scoped Response

This is precisely the scenario AlertMonitor's built-in RMM exists for — because the script engine, the inventory, the monitoring, and the helpdesk live in the same platform, on the same timeline.

The AlertMonitor workflow vs. the fragmented one:

No tab-switching between a monitoring console, an RMM tool, and the helpdesk. Script results feed back into the monitoring data, so automated remediations and a technician's manual actions are visible on one timeline. When the CFO asks "how many machines were affected and how long to fix," the answer is a filter, not a reconstruction.

The time math: scoping goes from "a day of RDP sessions across 200 machines" to "one script run, ten minutes, a per-machine table of exactly who's unlicensed and what build they're on." For an MSP, that run executes against every client simultaneously — you know all twelve environments' status before your second coffee.

Practical Steps: Scope This Exact Bug From Your Console Today

Here's the actual tooling. Run each of these through your script engine against a device group of Office 2016/2019 endpoints — and if you're on AlertMonitor, save them as reusable script library entries, because there will be a next time.

Step 1 — Build the device group: identify every Office 2016/2019 machine and its exact build

# Office version inventory: handles both Click-to-Run and MSI installs
$cfgPaths = @(
    'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Office\ClickToRun\Configuration'
)

$found = $false
foreach ($path in $cfgPaths) {
    if (Test-Path $path) {
        $cfg = Get-ItemProperty -Path $path
        [PSCustomObject]@{
            ComputerName = $env:COMPUTERNAME
            InstallType  = 'Click-to-Run'
            Product      = $cfg.ProductReleaseIds
            Version      = $cfg.VersionToReport
            Channel      = $cfg.UpdateChannel
        }
        $found = $true
    }
}

if (-not $found) {
    Get-ItemProperty \
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*', \
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' \
        -ErrorAction SilentlyContinue |
        Where-Object { $_.DisplayName -match 'Office 1[69]' } |
        Select-Object @{n='ComputerName';e={$env:COMPUTERNAME}},
                      @{n='InstallType';e={'MSI'}},
                      @{n='Product';e={$_.DisplayName}},
                      @{n='Version';e={$_.DisplayVersion}}
}

Run this fleet-wide and you now have a per-machine build table. Any machine on a build that changed right before the deactivations started is a prime suspect.

Step 2 — Check activation status and get structured results back

# Office activation status check — JSON output feeds cleanly into RMM results
$osppCandidates = @(
    'C:\Program Files\Microsoft Office\Office16\ospp.vbs',        # MSI x64
    'C:\Program Files (x86)\Microsoft Office\Office16\ospp.vbs',  # MSI x86
    'C:\Program Files\Microsoft Office\root\Office16\ospp.vbs'    # Click-to-Run
)

$ospp = $osppCandidates | Where-Object { Test-Path $_ } | Select-Object -First 1

if (-not $ospp) {
    [PSCustomObject]@{ ComputerName = $env:COMPUTERNAME; State = 'OSPP_NOT_FOUND' } | ConvertTo-Json
    return
}

$raw      = cscript //nologo $ospp /dstatus
$licensed = ($raw | Select-String 'LICENSE STATUS.*---LICENSED---')

if ($licensed) {
    [PSCustomObject]@{ ComputerName = $env:COMPUTERNAME; State = 'LICENSED' } | ConvertTo-Json
} else {
    [PSCustomObject]@{ ComputerName = $env:COMPUTERNAME; State = 'UNLICENSED' } | ConvertTo-Json
}

In AlertMonitor: run this across the device group, and the results table is your work queue — every UNLICENSED row is an affected endpoint, already attached to its machine record. Wire the output into an alert rule and an auto-ticket gets raised per affected machine, so scope and ticket queue are the same artifact.

Step 3 — Remediate: force reactivation, and pin C2R to a known-good build

# Attempt forced reactivation, then verify
$ospp = 'C:\Program Files\Microsoft Office\root\Office16\ospp.vbs'
cscript //nologo $ospp /act
cscript //nologo $ospp /dstatus

If reactivation doesn't stick and the machines are Click-to-Run, roll them back to the last known-good build while Microsoft figures out what they broke:

# Pin Click-to-Run to a known-good build (replace with YOUR last-known-good version)
$c2rClient = 'C:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeC2RClient.exe'
& $c2rClient /update user updatetoversion=16.0.10402.20013

Two notes from hard experience: pinning stops the C2R service from taking any new builds until you clear it, so document the pin and set a calendar follow-up to remove it. And run the /act + /dstatus pair as a two-step verification — pushing a fix without a verification run is how "I fixed it" tickets get reopened at 4:45 PM.

Step 4 — Schedule the check so you never learn this from users again

Set the Step 2 license check as a nightly scheduled script across your Office device group, with an alert threshold on any UNLICENSED result. If activation state silently degrades again — from any cause, Microsoft or otherwise — your console flags the machine before a human ever sees a red title bar. On AlertMonitor, that alert lands in the same system where the fix gets pushed and the ticket gets tracked, so the whole cycle is one closed loop.

The Takeaway

Microsoft may never publicly confirm the update caused this. It doesn't matter, because your job was never to win the postmortem — it's to compress the time between "something broke fleet-wide" and "every machine verified fixed." A vendor update will silently break something in your estate again; the only variable is whether you find out from a dashboard or from forty angry users. If the answer to "which machines are affected?" requires an RDP session per endpoint, the problem isn't Office licensing. It's that your RMM, monitoring, and helpdesk don't talk to each other — and that's a fixable problem this week.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources