The End of an Era: VBScript, WMIC, and the "Feature on Demand" Future of Windows Server 2025

For nearly two decades, the safety net of any Windows Administrator was the assumption that "it's just built-in." No matter how locked down a server was, you could always count on Notepad, Calculator, and the Windows Scripting Host (CScript/WScript) being there.

With the release of Windows Server 2025 last year, that assumption is officially dead.

Now that many organizations are moving past the "wait and see" phase and starting their upgrades, we are seeing the real-world impact of Microsoft's list of removed and deprecated features. If you are still relying on legacy scripts (and if you read this site, you probably are), here is what is breaking in production environments right now.

1. VBScript is now a "Feature on Demand" (FOD)

This is the big one. In Windows Server 2025, VBScript has been moved to a Feature on Demand status.

"VBScript is available as an FOD... before its removal from the operating system in a later release. As a replacement for VBScript, use PowerShell for automating tasks..."

What this means for you:
While it technically survives the upgrade, the "Feature on Demand" status is the waiting room for the graveyard. If you are building new server images today, your scripts simply won't run unless you explicitly add the legacy feature during your build process. If you use VBScript for login scripts or bootstrapping new servers, your automation now carries a dependency that isn't there by default.

2. WMIC is Deprecated (Use PowerShell CIM Instead)

Many of us didn't just write VBScripts; we wrapped command-line calls to WMIC.exe inside them. It was a quick and dirty way to get the serial number of a machine or kill a process.

"PowerShell for WMI replaces the WMIC tool."

If you have batch files or scripts that call wmic /node:ServerName, these are failing on clean installs of the new OS unless you manually add the capability back via DISM. It is time to replace those calls with Get-CimInstance.

3. The Silent Killer: SMTP Server is Removed

While everyone focused on VBScript, another change has been silently breaking old monitoring scripts. The SMTP Server feature has been moved from "Deprecated" to "Removed."

"Because SMTP Server features were removed from Windows Server 2025, there's no replacement within the operating system."

Why this matters:
Think back to 2008. How did we send alerts from VBScript? We used CDO.Message and often pointed it to the "Pickupt" directory or the local SMTP service to relay mail to Exchange. With the removal of the local SMTP Server role, any script relying on the local machine to act as a mail relay will fail immediately.

The "Archaeologist's" Roadmap

It is easy to get annoyed at Microsoft for moving the cheese, but maintaining 20-year-old code in a modern OS is a security nightmare. They are doing the right thing, even if it hurts.

Your action plan for this week:

  1. Audit for CDO.Message: Search your script repository for email functions. If they rely on localhost for SMTP, you need to rewrite them to authenticate against a real mail server (or use AWS SES).
  2. Inventory WMIC calls: Look for wmic.exe in your scheduled tasks. These are easy wins to convert to one-liner PowerShell scripts.
  3. Accept the "FOD" Reality: If you absolutely must keep VBScript for a legacy app, start updating your build images (or User Data scripts) to explicitly enable the VBScript capability. Don't assume it will be there.
  4. Get the Book: If you are still putting off learning the modern way, check out my book Pro PowerShell for Amazon Web Services. It helps with the transition from on-premise logic to cloud automation.

The tools we used to build our careers are being retired. It’s time we let them rest.

About the Author

Emmanuel Tsouris is a Systems Management veteran and Cloud Automation expert. If you are looking to bridge the gap between legacy scripting and modern cloud architecture, check out his book Pro PowerShell for Amazon Web Services.

Visit EmmanuelTsouris.com to see his latest projects.

As an Amazon Associate, I earn from qualifying purchases at no cost to you.

Comments

Post a Comment

Popular posts from this blog

SMS "Program failed (run time exceeded)" 10070

When a program fails due to error 10070, it does so because the Run Time was Exceeded. SMS Allows a program to run for 12 hours, afterwhich it will issue the failed status message if the program hasn't completed successfully. Note: The Maximum allowed run time within program properties is generally a guide for users running the program themselves, and is not enforced. About the Author Emmanuel Tsouris is a Systems Management veteran and Developer Advocate specializing in PowerShell and Cloud Automation. He maintains DotVBS to preserve legacy knowledge for the "archaeologist admin." Ready to move from VBScript to the Cloud? Check out his book, Pro PowerShell for Amazon Web Services . Visit EmmanuelTsouris.com for his latest projects. As an Amazon Associate, I earn from...
Read more

SMS "Waiting for User Condition" 10036

Status Message ID 10036, or "Waiting for User Condition" can occasionally grind advertisements to a halt. Make sure the environment and user condition settings for a particular program have been configured appropriately and are not excluding a large portion of your intended audience. Related Articles SMS WQL for All Clients where Last Status is Waiting for User Condition SMS Status Message ID's About the Author Emmanuel Tsouris is a Systems Management veteran and Developer Advocate specializing in PowerShell and Cloud Automation. He maintains DotVBS to preserve legacy knowledge for the "archaeologist admin." Ready to move from VBScript to the Cloud? Check out his book, Pro PowerShell for Amazon Web Services . Visit EmmanuelTsouris.com for his latest projects. ...
Read more

Reading the SCCM Client GUID

Recently I encountered an issue with the SCCM client GUID missing from the  %windir%\SMSCFG.INI file. We wanted to write a script to put the GUID back, so I was asked how to read the SCCM Client GUID from a script or command line. VBScript: Set objWMIService = GetObject("winmgmts:\\.\root\ccm") Set colItems = objWMIService.ExecQuery("Select ClientID From CCM_Client") For Each objItem in colItems Wscript.Echo "Client ID" & objItem.ClientID Next WMIC via commandline: wmic /namespace:\\root\ccm path ccm_client get clientid PowerShell: Get-WMIObject -namespace root\ccm ccm_client clientid | Select-Object clientid Suggested Reading: MSDN Article on How to Get the Unique Identifier Value for a Client (Includes Code Snippets) MSDN Article on Using the Get-WMiObject Cmdlet About the Author Emmanuel Tsouris is a Systems Management veteran and Dev...
Read more