Keep Windows activation automation working with PowerShell

If your organization uses slmgr.vbs to automate Windows activation, now is the time to identify dependencies and prepare for a move to PowerShell. VBScript has been deprecated and will eventually be removed from future Windows releases, which means any automation that depends on slmgr.vbs will need to change.

While you can continue with existing activation processes during the transition phase, automation that depends on slmgr.vbs should be identified, tested, and migrated before VBScript is removed. The OSLicense PowerShell module is now the recommended way to perform common Windows activation tasks. The steps outlined in this article can help you get started.

Note: Availability of the OSLicense PowerShell module varies by Windows release. Please confirm support for each segment of your device population before changing your production automation approach.

VBScript deprecation gives you time to prepare

VBScript deprecation is occurring in phases. The sequence matters more than a single date:

• Current phase: VBScript is available as part of Features on Demand (FOD) and is enabled by default on applicable Windows releases.
• Later phase: VBScript will no longer be enabled by default. Workflows that still depend on it may require the feature to be enabled while migration is completed.
• Final phase: VBScript will be removed from future Windows releases. At that point, slmgr.vbs will no longer be available as a fallback.

For the published VBScript lifecycle and timeline, see VBScript deprecation: Timelines and next steps.

Check availability of the PowerShell module before you migrate

The availability of the OSLicense PowerShell module differs between Windows client and Windows Server. Before updating your production scripts, confirm that the target device is running a supported release and has the required servicing update installed.

Replace common slmgr.vbs tasks with PowerShell

The following examples show the intended mapping for three common tasks. Validate the final command names and parameters against the published OSLicense PowerShell reference before using them in production.

For the complete command reference—and to learn more about migration scenarios, parameters, and output details—see our OSLicense Module documentation.

Start preparing your activation automation now

1. Inventory dependencies: Search scripts, runbooks, task sequences, management policies, deployment tooling, and support procedures for slmgr, cscript, wscript, and .vbs references.
2. Confirm prerequisites: Identify the Windows client and Windows Server versions in scope, then verify OSLicense PowerShell availability and servicing requirements for each.
3. Pilot the replacement: Update representative scripts in a test environment. Validate command behavior, exit handling, output parsing, permissions, remoting, and logging before broad deployment.
4. Deploy and monitor: Roll out the transition through your standard change management process. Keep rollback guidance until the new automation is validated across the intended device population.

Move critical workflows first

You do not need to replace every slmgr.vbs call at once. Start by inventorying dependencies and identifying the activation workflows most important to your organization. Then confirm OSLicense availability, test representative scripts, and deploy validated changes through your normal change-management process. Inventory your slmgr.vbs, cscript, wscript, and .vbs dependencies, then select one representative workflow for a migration pilot.

The earlier you begin planning and validation, the easier it will be to modernize your activation workflows before VBScript reaches its final phase of removal.

Continue the conversation. Find best practices. Join the Windows Tech Community.

For updates on new releases, tools, and resources, bookmark the Windows IT Pro Blog and follow @WindowsUpdate on X. For the latest on how Windows is evolving for organizations and the people who support them, follow Windows at Work on LinkedIn.