VB-Script is leaving Windows

… and what worXpace admins should do now

VBScript has been part of Windows for a very long time.
Long enough that some scripts are now older than some IT-managers, which might already be causing problems.

Microsoft is deprecating VBScript and plans to remove it from Windows in phases. This does not mean every VBScript will stop working tomorrow. It does mean that relying on VBScript as a strategic automation platform is no longer a safe plan.

For worXpace admins, the right response is not panic. It is inventory, replacement and testing. Preferably in that order.

 

What Microsoft’s VBScript deprecation means

The facts and myths so far:

Date / period	Planned change	Certainty
October 2023	Microsoft formally deprecated VBScript. It stopped being actively developed and was marked for eventual removal from Windows. (Microsoft Learn)	Confirmed
Windows 11 version 24H2 released in 2024	Phase 1: VBScript became a Windows Feature on Demand. It remains preinstalled and enabled by default, so existing scripts should normally continue working. (Microsoft Learn)	Confirmed/current
Approximately 2026 or 2027	Phase 2: the VBScript Feature on Demand is planned to be disabled by default. Administrators should still be able to enable it manually, but new/default installations should no longer assume it is present. (Microsoft for Developers)	Approximate, not a committed release date
Later Windows release; date TBD	Phase 3: VBScript will be completely removed from Windows. Applications, .vbs scripts, installer custom actions and components relying on the VBScript runtime will no longer work. (Windows IT-Pro Blog)	No date announced yet

 

So, Microsoft’s published plan follows three phases:

1. VBScript becomes an optional Windows feature, while remaining enabled by default.
2. VBScript remains available, but is disabled by default.
3. VBScript is removed from Windows.

The first stage gives organizations time to find dependencies and prepare replacements. The second stage is where unnoticed scripts are likely to start failing on newly installed or updated devices. The final stage removes the option to enable VBScript again.

Microsoft has not tied every stage to one universal date for all supported Windows releases. Timing may differ by Windows version, servicing channel and update state.

That makes “we will deal with it when it breaks” a poor migration strategy. Despite being a poor strategy It is also a surprisingly popular one.

 

How VBScript is currently supported in worXpace

worXpace currently supports VBScript through the Script Action. It can also be used in a scripted Variable Action when a script must calculate and return a value.

A Script Action runs code and writes its return value to the logs.

A scripted Variable Action uses the return value as the value of a worXpace variable. That variable can then be checked with a Variable Criterion to control later Actions.

This distinction is important during migration. A script that makes a decision should normally remain a scripted Variable Action after conversion, rather than becoming a PowerShell Script Action with extra logic wrapped around it.

If you’re currently using VB-Script in your worXpace, you might see messages like this in the eventlog of your computers:

 

VBScript is scheduled for deprecation. Our telemetry indicates that your system is currently utilizing VBScript.

We strongly recommend identifying and migrating away from any VBScript dependencies at the earliest.

 

The following process has been detected as using VBScript. The associated process tree and call stack are provided below to assist in identifying the scenario in which VBScript was invoked.

ProcessName = “axf.user.exe”

 

Will Microsoft’s change immediately break VBScript in worXpace?

Not necessarily.

worXpace provides the place where the script is configured and executed, but VBScript still depends on Windows components. When Microsoft disables or removes those components, worXpace cannot make the missing Windows scripting engine magically reappear.

During the early deprecation stage, existing VBScript may continue to work because the Windows optional feature is still installed and enabled.

Later, problems may appear in several ways:

• New devices may have VBScript disabled.
• Reinstalled devices may behave differently from existing devices.
• Feature updates may change the default state.
• Security baselines may disable the optional feature early.
• A script may work on one device group and fail on another.
• The final removal stage will make re-enabling VBScript impossible.

The dangerous period is therefore not only the final removal date. It starts when different devices can have different VBScript states.
Inconsistent failure are hardly entertaining for a helpdesk or administrator.

 

Do not replace every VBScript with another script

The best replacement for a VBScript is often not PowerShell.

First check what the script actually does. worXpace already provides native Actions for many common tasks:

• Use a File Action to copy, move or rename files.
• Use a Registry Action to create or change registry values.
• Use a Process Action to start a program.
• Use a Network Action to manage network drives.
• Use a Printer Action to manage printers.
• Use a Shortcut Action to create managed shortcuts.
• Use a Variable Action when a calculated result must control later processing.

Native Actions are easier to understand, test and support. They also provide clearer logging and reduce the amount of custom code that future admins must study like an archaeological site.

Use scripts only where the required logic cannot be expressed cleanly with standard Actions.

 

The preferred migration order

Use the following order for each VBScript dependency.

1. Remove scripts that are no longer needed

Some scripts exist only because an old application, operating system or deployment method once needed them.

Before rewriting anything, confirm that the task is still required.

Deleting obsolete automation is usually the fastest and most reliable migration method.

2. Replace simple operations with native worXpace Actions

If the script only changes a registry value, copies a file or launches a process, replace it with the matching Action.

This reduces scripting dependencies completely.

Remember that users normally do not have local admin rights. Where an operation needs elevation, configure the relevant Action to run as System and test the resulting file and registry locations carefully.

3. Convert calculated conditions to a scripted Variable Action

When a script calculates a result that determines what happens next, use a scripted Variable Action.

The Variable Action should return a clear value, such as:

• True or False
• an application version
• a device state
• a detected configuration value

Use a Variable Criterion in the Scope of the following Action or Context to evaluate that result.
This keeps decision-making visible in the worXpace configuration instead of hiding the whole workflow inside one large script.

4. Convert remaining code to PowerShell

For logic that genuinely requires scripting, PowerShell is normally the preferred replacement.

Within a worXpace Script Action or Variable Action, PowerShell runs inside the AXF Runtime host. It can use the worXpace language extensions, including variable resolution and logging.

Do not assume that an in-process worXpace PowerShell script behaves exactly like a normal .ps1 file. The embedded environment has its own boundaries.

Where full system PowerShell capabilities are required, a FileDeploy Action can write and invoke a .ps1 file through the operating system’s PowerShell host. That process does not have the worXpace language extensions, so required values must be resolved or supplied before execution.

C# is also available, but it is rarely the sensible migration target. It adds compilation time and complexity without making most administration tasks any happier.

 

What should be included in the inventory?

Searching only for files ending in .vbs is not enough.
Your inventory should cover at least these areas.

worXpace configuration

Find:

• Script Actions configured for VBScript
• Variable Actions using VBScript
• Tasks that contain those Actions
• Application install, start or uninstall Contexts containing VBScript
• Actions called indirectly through Call Actions
• Scope logic that depends on a value returned by VBScript

Application packages and source folders

Check packages for:

• .vbs and .vbe files
• command files that call cscript.exe or wscript.exe
• installers with custom actions that launch VBScript
• vendor setup wrappers
• logon helpers
• repair and uninstall scripts
• scheduled tasks created by application installers

A worXpace object may contain no VBScript while the application package it deploys contains several.

The wider IT environment

VBScript may also exist outside worXpace in:

• Group Policy logon and startup scripts
• Microsoft Endpoint Configuration Manager packages
• Microsoft Intune remediation or deployment content
• scheduled tasks
• golden images
• device build processes
• shared administration folders
• monitoring tools
• vendor management agents
• legacy web applications
• Office automation and macros that call external scripts

A complete migration needs one inventory across all deployment and management platforms. Otherwise, VBScript may leave worXpace and quietly move into someone else’s problem queue.

 

Questions to ask when reviewing a script

For every VBScript, ask:

1. Who needs this?
2. When does it run?
3. What does it actually do?
4. Does that task still need to exist?
5. Can a native worXpace Action do it?
6. Does it need administrative rights?
7. Does it depend on 32-bit registry or file-system behaviour?
8. Does it return a value used elsewhere?
9. How will we prove the replacement works?
10. What happens when it fails?

These questions turn a folder full of mysterious scripts into a manageable set of tasks.
They may also reveal that nobody knows why a script exists. This is useful information, though not always comforting.

 

Recommended policy for new work

You should probably stop creating new VBScript dependencies now if you haven’t already.

A simple policy can be:

• Do not introduce new VBScript code.
• Prefer native worXpace Actions.
• Use a scripted Variable Action for calculated conditions.
• Use PowerShell only when native Actions are not suitable.
• Require an owner, purpose and test case for each new script.
• Test all automation with standard-user rights unless System execution is explicitly required.
• Review scripting dependencies during application updates and migrations.

This prevents the migration list from growing while the current backlog is being reduced.

 

The practical takeaway

VBScript deprecation is not an immediate outage announcement. It is an advance notice that an old dependency is moving from “still works” to “works only under certain conditions” and eventually to “no longer exists.”

Our stance on this matter:
The VB-Script language provider will only be removed from worXpace when our records confirm that it is no longer in use by any customers.

worXpace admins have a good starting point. Many VBScript tasks can be replaced by native Actions, while more complex logic can move to PowerShell. The main work is not choosing a new language. It is finding every dependency, understanding its purpose and testing the replacement properly.

Start with the inventory. Remove what is obsolete. Replace simple scripts with standard Actions. Convert only the logic that genuinely needs code. Then test with VBScript disabled before Microsoft makes that test on your behalf.

That is a much calmer migration plan.

And, unlike VBScript, calm migration plans are not being deprecated.

 

PS. Yes, that stepladder was designed by M.C. Escher