On September 10, 2026, Microsoft advised enterprises that automate Windows activation to move their dependence on slmgr.vbs to a new PowerShell module, OSLicense. VBScript is still enabled by default as an optional feature, but Microsoft plans to remove it from Windows entirely, at which point slmgr.vbs will no longer be available as a fallback. What disappears, however, is an administration tool written in VBScript, not Windows' activation infrastructure itself. Whether the migration succeeds depends less on swapping three command names than on verifying each device's availability status and whether existing automation can still rely on the same output, permissions, and execution paths.
What VBScript's removal stops: the management path that calls activation
slmgr.vbs is an administration script that runs on Windows Script Host and operates the Software Licensing Service. Beyond online activation and product key installation, it covers a wide range of operations, including KMS, Active Directory-based activation, and offline activation. Once the VBScript engine is gone, any process that calls this file from cscript.exe or wscript.exe will stop working.
The licensing service itself, though, is not implemented in VBScript. A user of the Windows Server vNext preview who ran slmgr.vbs on a virtual machine with VBScript removed got an error to the effect that the script engine could not be found, yet activation through the Settings app succeeded. A Microsoft employee also explained in the company's community forum that activation through the Settings app does not depend on VBScript. This is a report from a specific preview environment and not a guarantee for every configuration, but it supports treating the management entry point and the activation platform as separate things.
In enterprises, the impact is not limited to batch files that call slmgr.vbs directly. If it is invoked indirectly through OS deployment task sequences, endpoint management products, or Group Policy, the dependency may remain without anyone being aware the script exists. Microsoft's call for an early inventory is meant to surface these hidden calls before the complete removal.
What OSLicense changes: how activation operations and results are handled
OSLicense requires Windows PowerShell 5.1, and the published list contains 11 cmdlets in total: four Get, four Invoke, and three Set. It covers OS licensing as well as Active Directory-based activation, KMS, and subscription licensing. Instead of passing many switches to a single VBScript, you now use separate PowerShell commands by role: querying, operating, and configuring.
Microsoft showed the following three representative mappings.
| Existing call | OSLicense example | Main purpose |
|---|---|---|
slmgr.vbs /ato |
Invoke-OSLicense -ActivateOnline |
Online activation |
slmgr.vbs /ipk <key> |
Invoke-OSLicense -InstallProductKey <key> |
Product key installation |
slmgr.vbs /dlv |
Get-OSLicenseInfo |
Retrieving detailed license information |
This table reflects the mappings that Microsoft's migration blog presents for "three commonly used tasks"; it is not a one-to-one compatibility table for every switch. The blog also states that commands and arguments should be confirmed against the reference documentation at the time of publication.
The technical advantage is that results shift from strings to structured data. Get-OSLicenseInfo queries the local Software Licensing CIM classes and returns license state, grace period, KMS settings, and more as PowerShell objects. Processing can move from cutting up display-language-dependent strings to specifying properties. However, if existing monitoring uses the standard output or exit codes of slmgr.vbs for conditional branching, the side that consumes the new output must be rewritten as well.
A migration target exists, but availability conditions are not yet unified
For Windows 11, Microsoft's blog sets KB5120998 Preview or later, released on August 27, 2026, as the prerequisite for OSLicense. The targets are Windows 11 24H2 and 25H2, and that update's OS builds are 26100.9278 and 26200.9278, respectively. But because KB5120998 was delivered gradually as a preview update, you cannot assume that simply running a supported version means every device received it at the same time.
As of September 14, 2026, Microsoft's Windows IT Pro Blog explicitly states KB5120998 or later as the Windows 11 prerequisite, while the OSLicense module reference page says the applicable KB is "to be confirmed," so the official documents do not agree on availability conditions.
| Microsoft public page | Statement at time of retrieval |
|---|---|
| Windows IT Pro Blog (dated Sept. 10) | Windows 11: KB5120998 Preview or later |
| OSLicense module reference | KB number for the Windows Update that makes it available: to be confirmed |
This is the result of comparing the Windows 11 prerequisites on both pages on September 14, 2026. The KB5120998 change list also does not contain the name OSLicense, but that is not evidence that the module is excluded from the update. The documentation may simply not have caught up. Migration owners should not rely on the KB label alone and should confirm the module actually exists on target devices, for example with Get-Module -ListAvailable OSLicense.
Windows Server is at an even earlier stage. Microsoft plans general availability in the "next major release" and named Windows Server vNext Preview Build 29651 or later as the early validation target. It has not given the official name or release date of that next version, and a backport to Windows Server 2025 cannot be confirmed. This is not an announcement that existing server fleets can migrate all at once.
Beyond three command mappings: verify the whole of your existing automation
Before replacing commands, you need to identify which slmgr.vbs switches you actually use. The official documentation lists many operations, including KMS host discovery and caching, Active Directory-based activation, token activation, offline activation, and rearm. Replacing just the three representative examples will not necessarily cover an enterprise's own procedures.
Next, verify the runtime contract. Microsoft lists commands and arguments, required permissions, and how output is parsed as items to check, and also asks admins to review remote execution and logging. Each OSLicense cmdlet is documented as acting on the local computer, so there is no guarantee that a process that passed a remote computer name to slmgr.vbs can be ported as is. If you use PowerShell Remoting or distribution from an endpoint management product, you will need to test that path too.
State changes also come with their own cautions. Invoke-OSLicense is designed to select one operation at a time; if no operation is specified, it produces no output and changes nothing. Set-KmsLicenseInfo changes only the KMS settings you specify, but it requires PowerShell launched with administrator privileges. Because the licensing service, not PowerShell, validates some integer values, it is safer not to treat the absence of an exception as success and to check the return value and the post-change state.
Migration testing should run online activation, key installation, and status queries on a representative group of devices, adding KMS or offline activation if you use them. You should also confirm that success and failure logs reach existing monitoring and that re-running does not cause unexpected state changes. Only then can the old calls be removed in stages.
Around 2027 is a guide for default disablement; a full removal date is not set
Microsoft's deprecation plan has three phases. In the current Phase 1, VBScript is enabled by default as a Feature on Demand. Phase 2 moves to disabled by default around 2027, with users who need it enabling it explicitly. Phase 3 removes the feature itself from a future Windows, and no date has been set.
It is therefore not accurate to read 2027 as the complete shutdown date for slmgr.vbs. Still, once default disablement begins, overlooked dependencies are more likely to surface on new devices and updated environments. After full removal, there will be no way to turn VBScript back on and no option to keep slmgr.vbs as a backup path.
What organizations can confirm now is which automation calls VBScript, whether OSLicense has reached the target OS, and whether the same business result can be reproduced with the new output and permissions. Rather than waiting for the Phase 3 date, being able to verify these three points before the default disablement around 2027 would separate Windows activation operations from VBScript's lifespan.