slmgr.vbs Breaks the Day Microsoft Removes VBScript

Picture the 2 a.m. version of this. A new image build is rolling out, the task sequence hits the step that runs cscript slmgr.vbs /ipk followed by slmgr.vbs /ato, and instead of a clean activation you get a script-host error because the machine you’re deploying to no longer has a working VBScript engine. The device boots fine. It just doesn’t report as genuine, and now you’re reading a Petri article at your desk instead of sleeping.

That’s the shape of the problem Microsoft has quietly set in motion by deprecating VBScript. Nobody is deleting Windows activation. They’re deleting the language that the most common activation tool happens to be written in. And almost nobody notices the difference until it bites.

Two things that sound the same and aren’t

Let’s take this from the bottom, because the whole confusion lives in one sloppy assumption: that “activating Windows” and “running slmgr” are the same thing. They are not.

Windows activation is handled by a service that ships with the OS, called the Software Licensing Service. Think of it as the clerk behind a counter. It knows which product keys are installed, whether the machine is licensed, when the grace period runs out, and which activation server to phone. The clerk speaks a specific dialect — it exposes its functions through WMI (Windows Management Instrumentation), the built-in plumbing Windows uses so that tools can query and control the OS programmatically. The modern way to talk to that plumbing is CIM, which is just the newer, tidier protocol layer over the same thing.

Now, slmgr.vbs. This is not the clerk. It’s a customer at the counter who happens to only speak VBScript. When you run slmgr /ato, the script doesn’t activate anything itself — it translates your command into WMI calls, hands them to the Software Licensing Service, and prints back whatever the clerk says. It’s a wrapper. A convenient one that’s been in every copy of Windows since Vista, so it wormed its way into everything.

Here’s the load-bearing fact: the clerk isn’t going anywhere. Only the VBScript-speaking customer is. Everything slmgr.vbs does, it does by calling WMI classes that are still fully present and supported. So when VBScript disappears, you don’t lose the ability to activate Windows. You lose the specific .vbs file that’s been doing the talking, and you replace it by talking to the same service directly in PowerShell.

Where VBScript actually stands right now

Microsoft is retiring VBScript in phases, not with a single overnight cutoff — this matters, so don’t let anyone panic you into believing it’s already gone. In recent Windows 11 releases, VBScript has been reclassified as a Feature on Demand. In plain terms: it’s still installed and enabled by default for now, but it has been moved into the bucket of things that will first become optional, then default-off, then removed entirely. Each phase makes it less likely the engine is present on a given machine.

I’m not going to hand you a hard removal date, because Microsoft hasn’t published one you can build a change ticket around, and I’m not in the business of inventing deadlines to make a headline scarier. The point isn’t the date. The point is the direction — the engine is being pulled out from under you, and the moment it’s absent on even a subset of your fleet, any script that shells out to a .vbs file breaks on those machines. Your job is to be done migrating before that subset includes production.

What slmgr.vbs actually does, and why it’s buried everywhere

The reason this is a broad problem rather than a niche one is that slmgr.vbs shows up in the boring, unglamorous corners of an estate where nobody has looked in years:

• MDT and ConfigMgr/SCCM task sequences — a “Run Command Line” step calling cscript slmgr.vbs /skms and /ato for KMS clients, or /ipk to stamp a MAK key during OSD.
• GPO startup and logon scripts — the classic “make sure everything’s activated” script somebody wrote in 2014 and left in SYSVOL.
• Runbooks and scheduled tasks — compliance checks that parse slmgr /dlv or /xpr output and dump it into a report.
• Intune platform scripts and provisioning packages — less common, but people copy patterns, and old patterns call slmgr.

The handful of switches that show up in real automation: /ipk installs a product key, /ato triggers activation, /skms points a machine at a KMS host, /ckms clears that, and /dlv or /xpr report status. That’s roughly the entire surface area you need to replace.

The replacement is CIM, and it’s honestly cleaner

Two WMI classes do all the work. SoftwareLicensingService is the counter itself — it installs keys and sets the KMS host. SoftwareLicensingProduct is a per-product record; the Windows one is what you activate and query. Everything below reads state. Reading is safe, so start here to learn the objects before you touch anything that changes them.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Read-only: current activation status for the Windows product
$windowsAppId = '55c92734-d682-4d71-983e-d6ec3f16059f'
​
try {
    Get-CimInstance -ClassName SoftwareLicensingProduct -ErrorAction Stop |
        Where-Object { $_.ApplicationID -eq $windowsAppId -and $_.PartialProductKey } |
        Select-Object Name,
                      Description,
                      @{ n = 'LicenseStatus';   e = { $_.LicenseStatus } },
                      PartialProductKey,
                      @{ n = 'GraceMinutesLeft'; e = { $_.GracePeriodRemaining } }
}
catch {
    Write-Error "Could not query SoftwareLicensingProduct: $($_.Exception.Message)"
}

LicenseStatus is an integer, and it’s the one field auditors actually care about. Memorise these: 0 unlicensed, 1 licensed (the only one you want), 2 out-of-box grace, 3 out-of-tolerance grace, 4 non-genuine, 5 notification, 6 extended grace. That single number replaces most of what people were scraping out of /dlv text output — and parsing an integer beats regex-ing a localised string, which is a fight you were always going to lose in a non-English tenant.

Now the state-changing operations. These default to -WhatIf on purpose. Run them, read the output, then and only then remove the flag on reviewed input. Never wire this straight to a live query across a collection.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Install a product key (equivalent of slmgr /ipk)
# Feed $ProductKey from a reviewed, controlled source - never a bulk pull.
param(
    [Parameter(Mandatory)]
    [ValidatePattern('^([A-Z0-9]{5}-){4}[A-Z0-9]{5}$')]
    [string]$ProductKey
)
​
try {
    $service = Get-CimInstance -ClassName SoftwareLicensingService -ErrorAction Stop
    Invoke-CimMethod -InputObject $service `
        -MethodName InstallProductKey `
        -Arguments @{ ProductKey = $ProductKey } `
        -WhatIf
}
catch {
    Write-Error "InstallProductKey failed: $($_.Exception.Message)"
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# Point at a KMS host (slmgr /skms) then activate (slmgr /ato)
param(
    [Parameter(Mandatory)][string]$KmsHost,
    [int]$KmsPort = 1688
)
​
$windowsAppId = '55c92734-d682-4d71-983e-d6ec3f16059f'
​
try {
    $service = Get-CimInstance -ClassName SoftwareLicensingService -ErrorAction Stop
    Invoke-CimMethod -InputObject $service `
        -MethodName SetKeyManagementServiceMachine `
        -Arguments @{ MachineName = $KmsHost } -WhatIf
​
    Invoke-CimMethod -InputObject $service `
        -MethodName SetKeyManagementServicePort `
        -Arguments @{ PortNumber = [uint32]$KmsPort } -WhatIf
​
    $product = Get-CimInstance -ClassName SoftwareLicensingProduct -ErrorAction Stop |
        Where-Object { $_.ApplicationID -eq $windowsAppId -and $_.PartialProductKey }
​
    if ($product) {
        Invoke-CimMethod -InputObject $product -MethodName Activate -WhatIf
    }
    else {
        Write-Warning 'No installed Windows product found to activate.'
    }
}
catch {
    Write-Error "KMS activation flow failed: $($_.Exception.Message)"
}

Note there’s no pagination story here — this is local, per-machine state, one Windows product per box. Pagination matters when you fan this out across a fleet, which you do at the orchestration layer (ConfigMgr, Intune, a remediation script), not inside the activation call itself.

Find every slmgr call before it finds you

You can’t migrate what you can’t see. Start with SYSVOL, because that’s where the forgotten scripts rot:

1
2
3
4
5
6
7
8
9
10

$domain = $env:USERDNSDOMAIN
try {
    Get-ChildItem -Path "\\$domain\SYSVOL" -Recurse -File `
        -Include *.ps1,*.cmd,*.bat,*.vbs -ErrorAction SilentlyContinue |
        Select-String -Pattern 'slmgr' -List |
        Select-Object Path, LineNumber, Line
}
catch {
    Write-Error "SYSVOL scan failed: $($_.Exception.Message)"
}

Then the deployment tooling. In ConfigMgr, export your task sequences to XML and grep them — slmgr lives inside “Run Command Line” steps and won’t jump out at you in the console. Do the same for MDT’s CustomSettings.ini and any custom scripts in the deployment share. For Intune, check your platform scripts and Win32 app install commands. For automation, search your runbook repo and scheduled task actions. Anywhere a string contains slmgr, you have a dependency on a dying engine.

Not every activation path is affected the same

This is where blanket panic is wrong. The blast radius depends entirely on how your machines activate:

• KMS is the most exposed, because KMS clients are the ones people script with /skms and /ato during imaging. Good news: healthy KMS setups auto-discover the host via a DNS SRV record and activate on their own, so a lot of those slmgr calls were belt-and-braces you can retire outright rather than port.
• MAK gets stamped with /ipk and activated once against Microsoft. That’s real scripted work that needs the CIM rewrite above.
• Retail and OEM/firmware-embedded keys mostly activate through a digital license without anyone scripting anything. Low risk, but check your provisioning packages anyway — people copy-paste.
• Subscription Activation — the Entra-joined, Windows Enterprise E3/E5 flow where the license rides in on the user’s identity — doesn’t touch slmgr at all. If your fleet is cloud-joined and licensed through Microsoft 365, this whole article might be someone else’s problem. Confirm it; don’t assume it.

The work here is small. An afternoon of grepping, an afternoon of rewriting a handful of command-line steps into CIM calls, a test deployment to prove LicenseStatus comes back 1. What’s dangerous is the timing: this is invisible until an OS update quietly ships without the VBScript engine and a build night turns into an incident. Migrate on a Tuesday afternoon by choice, not at 2 a.m. by force.