VBScript deprecation: Timelines and next steps

microsoft, you do realize that you will literally break thousands of applications using Windows Installer for deployment that use VBScript in their actions?  And, you have not replaced that technology for Custom Actions with .NET!

Hi Naveen_Shankar Srirama_Mogali how can we remove this or other "Optional Features" at scale?
I was not able to find VBScript with the typical *-WindowsOptionalFeature -Online.

What can replace this in Outlook client?  I have script to run all manual Outlook rules with 1 click to move emails my inbox.  It would be unmanageable if this function is removed.   I've searched, Graph, Powershell, Python, Rest API and none can do this.  Very odd.

In my field experience, some wiredo organization (which even give every logon user as Administrator) blocked Powershell on security concerns. It leave guys no choice if VBScript is depreciated. 

Bruce Neiman  : There are indeed obviously no plan "B". Javascript scripting technologies in Windows and runtimes are EcmaScript 3, and Naveen_Shankar  recommendation to use this is just pure bull...thing.
He surely never programmed a complete business app in JScript or VBScript. We, developers, do it. Every day. Because these technologies are incredibly simple and powerful.

Young cost-killers not even born when Classic ASP was invented were happy to find a job at Microsoft.
Then, one day, they decided to deprecate VBScript, simply because "it could look cool" and reassure investors in regards to "Microsoft high commitment into end-users privacy and security".
Deprecations are a way to communicate publicly.

Erasing the past is the way they have chosen to do so (a sort of technical "cancel-culture").

Completely counter-intuitive, that decision will explode in their face as surely than other major catastrophic events in this company's memory :

1. Internet Explorer antitrust prosecute
2. Steve Ballmer as CEO
3. The Windows Phone
4. Add VBScript and Classic ASP deprecation to this list? NO! A BIG NO!

Security arguments are weak motivations: every antivirus knows how to block "harmful" Office macros and dangerous VBScripts for almost 15 years.

Why not remove and deprecate Microsoft SysInternals Suite tools?
After all, they are old, ugly. But they are useful. Exactly like Classic ASP.

Talking about the SysInternals tools makes me think: time has come for Mark Russinovich to jump in the game.

Every 7 days, 10 people (Classic ASP Developers and VBScript SysAdmins) sign the petition addressed to the Microsoft Windows Server team.
Far for disminishing, this number is constant from this petition's launch: Why? Well, we already all know why. This has been explained by everyone on this post.

Seriously, should we have the specialized tech IT magazines to jump in the game and make a bad press to Microsoft on this one, too?
That scenario is just so simple to avoid if MS simply just reconsiders this absurd position.

There are rational people at Microsoft, and Mark is one of them.

• Noone better than Mark knows how widely spread is VBScript usage in the Windows Server Administrators ecosystem.
• Noone better than him knows what disaster it will be if VBScript and Classic ASP engines would be wiped out.

Mark is a living memory, still alive and kicking.
He knew the "world before", and is deeply involved in the "world after".

VBScript must stay! System Administration is much easier with VBScript, we used it many times for system administration.

Look how strange Powershell looks for sysadmins:

Instead of:

a = 23 > 12 and 12 > 40

You have to write in Powershell:

$a = 23 -gt 12 -and 12 -gt 40

And to convert the number 13 to a currency:

a = CCUR(13)

You have to do in Powershell a crazy stunt like this:

$a = "{0:C}" -f 13

This is crazy to learn, nobody wants that and Microsoft should start to understand that users want a SIMPLE, EASY Language for System administration!

It's definitively NOT Powershell, you can push that as long as you want, SysAdmins will NEVER ever love it!

I ask Microsoft to keep VBScript, maybe add some security layers.

If you must remove it from WSH, then please update the JavaScript module in WSH so that it supports modern JavaScript!

Another way for Microsoft would be to include Python into WSH.

WSH is a great way to let users extend Applications with scripts. And that MUST stay.

And, noneless to say, many business applications rely on WSH+VBScript, we have now to rewrite much much code to JavaScript which is a big big present from you Microsoft!

Do you, Microsoft, think, we developers have too much freetime?

I guess you know the answer...

just keep VBScript and the beloved WSH which extends so many critical business applications, that have now to be rewritten.

I ask you, Microsoft, to go back to your roots, and to keep focus on DEVELOPERS, DEVELOPERS, DEVELOPERS!

Because we make you big!

We have already read some great arguments about why VBScript should not simply be thrown into the trash. Let me add another one. VBScript developers never embraced ASP.NET. But that does not mean VBScript is worthless. It was Microsoft’s first popular web scripting technology. Not so much in the browser—it quickly became clear that JavaScript would dominate there—but on the server side. VBScript was a highly popular web technology between 1996 and 2005.  

As soon as ASP.NET was pushed as the "new thing" by the Microsoft .NET developer team, many developers turned their backs on Microsoft and embraced PHP instead. ASP.NET was Microsoft's biggest failure to date. Between 2005 and 2010, they lost the web developer war to PHP and other technologies.  

Now, if Microsoft decides to remove VBScript, they are eliminating the only successful web technology they have ever developed. And that is unfortunate. It even seems like a self-destructive, auto-mutilating act. "If we can't be the biggest, we don’t want to be anything at all." Well, good luck with that!  

At this moment, Python is ready to fill the gap. Many (if not most) plugins for Visual Studio Code are specifically made for and by Python developers. There are also several web development frameworks for Python (Flask, Django, etc.).  

But once again, this is truly unfortunate. It should not have turned out this way. The stubbornness of the .NET development team between 2002 and 2010 has led to Microsoft’s complete downfall as a leading software developer. Microsoft even lost it's browser to Google Chromium. Microsoft plays absolutely no role anymore in the wonderful world of web development. That is the only conclusion you can draw today. Nothing more, nothing less.  

Microsoft, with its failing strategies, has managed to dismantle a community of 10 million developers who once used Basic, pushing them to switch to other programming languages like PHP and Python.

Regarding the deprecation timeline of VBScript/ASP Classic, I understand that:

2024 – VBScript has been included in the FOD, enabled by default.
2027 – VBScript will no longer be enabled by default in the FOD, but it will still be possible to enable it.
At an unspecified future date (hopefully never or in 2099), it will be removed.

I believe that in 2028, 2029, 2030... it will still work...

Did you understand it the same way?

I agree that VBScript is a universal way to integrate and automate routine tasks and extend functions. Its simplicity and flexibility make it unique, and there is truly nothing quite like it in the current Microsoft ecosystem.  What is plan 'b'?

Naveen_Shankar VBScript Classic ASP holds a special place in the hearts of those who enjoy rapid prototyping and “script-like” development. This language, which does not differentiate between uppercase and lowercase letters and does not overly burden you with variable types, can deliver highly satisfactory results in terms of both efficiency and performance—provided it is structured well. Many developers who once automated tasks with batch files discovered the convenience of Classic ASP and felt as if they were “developing web applications with batch scripts.”

Although Microsoft made attempts to revisit the past with ASP Web Pages, it’s hard to say they truly captured the free and flexible development environment provided by Classic ASP. Modern technologies such as ASP.NET, Python, and Node.js do not fully align with Classic ASP’s straightforward “scripting” nature. In fact, the fact that 76% of websites use PHP today may partly be due to Microsoft’s decision on February 17, 2000, to stop evolving Classic ASP and fail to provide sufficient community support.

One of Classic ASP’s major advantages is its seamless integration with COM/DCOM components. Configurable through DCOMCNFG (dcomcnfg.exe), these components give developers the ability to easily invoke business logic prepared in different languages (such as C++ or Python) within Classic ASP. As a result, Classic ASP goes beyond just being a “language,” serving instead as a bridge capable of communicating with various system-level services or enterprise applications. Even today, many older but mission-critical applications in the business world still run on COM/DCOM, so Classic ASP’s integration capabilities enable it to remain part of large projects.

Despite there being a dedicated group that has insisted on using Classic ASP for 25 years, keeping their applications running on this technology, Microsoft has not only stopped developing Classic ASP but has also refrained from gifting it to the open-source world. 

If they had, Classic ASP might have sustained its momentum—similar to PHP—through an engaged community. Ultimately, with years of accumulated expertise and practical experience, significant innovations, security patches, or performance-enhancing improvements could have been added to Classic ASP.

When it comes to a simple scripting language and ease of use, there is still no direct equivalent to Classic ASP within the Microsoft ecosystem. For that reason, those seeking something “like Classic ASP” in the Microsoft world actually tend to turn to PHP rather than ASP.NET. ASP.NET and other modern solutions are undoubtedly powerful frameworks, but they can’t match the lightness, flexibility, and freedom from excessive rules that Classic ASP provides.

Microsoft is also known for launching numerous products and then shelving them later. Classic ASP is one of the most notable examples of this. Consequently, developers have hesitated to invest in building long-term projects on a Microsoft technology out of concern it might be discontinued. Its lack of transition into open source casts a shadow over both its nostalgic value and the community members who still rely on it.

Classic ASP continues to maintain its simplicity, rapid prototyping capability, and ability to integrate with other technologies via COM/DCOM. If Microsoft had brought this old yet powerful scripting language into the open-source domain, perhaps it would have shed its “forgotten technology” or “insecure Microsoft technology” labels and found renewed excitement as an alternative solution.

Nevertheless, with official support winding down and the open-source path overlooked, Classic ASP is gradually being consigned to history. Even so, a community of dedicated users who recognize its merits and continue to use it ensures that the spirit of Classic ASP lives on.