VBScript deprecation: Timelines and next steps

[Naveen_Shankar]

Scripting options for web development and task automation are modernizing. To provide you with the most modern and efficient options, we are replacing VBScript with more advanced alternatives such as JavaScript and PowerShell. Find out what VBScript deprecation means for you and how you can get ready.

What is VBScript?

Visual Basic Scripting Edition, commonly referred to as VBScript, is a lightweight scripting language first introduced by Microsoft in 1996. The language has been available as a system component in Windows OS and has been widely used for automating tasks and controlling applications on Windows-based systems. It's often embedded within HTML pages to add dynamic interactivity and functionality to web pages and is commonly used in conjunction with Microsoft technologies like Active Server Pages (ASP) and Windows Script Host (WSH). However, with the advancement of technology, more modern and efficient options are now available.

Why is VBScript deprecated?

Technology has advanced over the years, giving rise to more powerful and versatile scripting languages such as JavaScript and PowerShell. These languages offer broader capabilities and are better suited for modern web development and automation tasks.

Tip: Deprecation is a stage in the product lifecycle when a feature or functionality is no longer in active development and may be removed in future releases of a product or online service. It's a gradual process that can span a few months or years. The deprecated feature is usually meant to be replaced by something better, more advanced, or more functional. The feature will typically continue to work and is fully supported until it's officially removed. After removal, the feature or capability will no longer work. Removing a deprecated component helps reduce complexity while keeping you secure and productive.

VBScript deprecation plan

Considering the decline in VBScript usage in favor of more modern web technologies, we have developed a phased deprecation plan for VBScript. Let's review the timeline of these changes.

In October 2023, we announced our commitment to providing the best and most efficient experiences by gradually deprecating VBScript. Beginning with the new OS release slated for later this year, VBScript will be available as features on demand (FODs). The feature will be completely retired from future Windows OS releases, as we transition to the more efficient PowerShell experiences.

Deprecation will occur in three phases.

A visual timeline of important dates for VBScript deprecation phases.

Phase 1

In the first phase, VBScript FODs will be pre-installed in all Windows 11, version 24H2 and on by default. This helps ensure your experiences are not disrupted if you have a dependency on VBScript while you migrate your dependencies (applications, processes, and the like) away from VBScript. You can see the VBScript FODs enabled by default at Start > Settings > System > Optional features.

Screenshot of Windows System Settings shows VBScript installed under Optional features.

Phase 2

Around 2027, the VBScript FODs will no longer be enabled by default. This means that if you still rely on VBScript by that time, you'll need to enable the FODs to prevent your applications and processes from having problems.

Follow these steps if you need to continue using VBScript FODs:

1. Go to Start > Settings > System > Optional features.
2. Select View features next to “Add an Optional feature” option at the top.
3. Type "VBSCRIPT" in the search dialog and select the check box next to the result.
4. To enable the disabled feature, press Next.

Screenshot of a dialog box for adding an optional feature with a checkbox next to VBScript.

Phase 3

VBScript will be retired and eliminated from future versions of Windows. This means all the dynamic link libraries (.dll files) of VBScript will be removed. As a result, projects that rely on VBScript will stop functioning. By then, we expect that you'll have switched to suggested alternatives.

VBA projects that use VBScript

Visual Basic for Applications (VBA) allows users to automate repetitive tasks and customize functionalities within Microsoft Office suite. This includes Excel, Word, PowerPoint, Access, and some other applications. With VBA, you've been able to write scripts (macros) to manipulate data, create custom forms, automate reports, interact with other applications, and perform various other tasks to streamline workflows and enhance productivity.

Currently, VBScript can be used in VBA for two scenarios:

• Scenario 1: Call a .vbs script directly from VBA.
• Scenario 2: Use VBScript as typelib reference (such as VBScript regular expression) in VBA.

You can keep using the existing solutions if your VBA solutions have the scenarios above, as Phase 1 won't affect you. But future phases will affect you, so watch out for new developments.

If you see a runtime error or compile error while executing the VBA projects, check that the VBScript FODs aren't disabled by admin setting.

Next steps if my app or website has dependency on VBScript

Consider two modern solutions to replace VBscript, specifically PowerShell and JavaScript.

Migrate to PowerShell

We recommend migrating to PowerShell if you:

• Have websites or applications dependent on VBScript for automating tasks.
• Use VBScript custom actions as a feature in installer packages. During setup process, these custom actions can use the installation session and perform complex tasks. These custom actions may stop working after deprecation.

In these cases, we recommend you migrate to PowerShell. Learn how to do that at Converting VBScript to Windows PowerShell.

Migrate to JavaScript

As VBScript functionality is currently limited to browsers predating Internet Explorer 11, we recommend migrating your webpages to JavaScript before phase 2. JavaScript offers cross-browser compatibility, working seamlessly across modern browsers such as Microsoft Edge, Mozilla Firefox, Google Chrome, and Apple Safari. Notably, these browsers have never implemented support for VBScript.

If your webpage functions properly across these modern browsers, then VBScript isn't involved, and its deprecation won't affect you.

Start planning your migration and stay in touch!

We're here to help you with the latest updates around VBScript deprecation and to provide additional support as you migrate your dependencies during phases 1, 2, and 3.

Are there any special considerations or scenarios that you'd like to talk about? Please leave us a comment below.

In the meantime, check out additional resources related to VBScript functionality and deprecation:

• Creating Scripts Using Visual Basic
• VBScript is no longer supported in IE11 edge mode (Windows)
• PowerShell Documentation - PowerShell
• About Scripts - PowerShell
• Regular Expression (RegExp) Object

---

Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us @MSWindowsITPro on X/Twitter. Looking for support? Visit Windows on Microsoft Q&A.

[Tom_K]

This article addresses the desktop experience, but what are the support plans for Windows Server?

[AlanDoran]

Same question as Tom_K

[joseoyervides007]

Hi @Naveen_Shankar 

What will happen with the "Generic Script" type on Failover Clusters. They only support VBS, do you know if there is any plan to support PowerShell?

[WithinRafael]

The Converting VBScript to Windows PowerShell link leads to a dead end.

[AndAufVCG]

And when is Microsoft going to change their own scripts from EVERYwhere? Intune/Autopilot, MDT, GPOs, MSIs,...

[BosPete]

What implications does this have for Microsoft deployment took kit since it uses VBscript?

[RichardDeeming]

---

@Naveen_Shankar wrote:

It's often embedded within HTML pages to add dynamic interactivity and functionality to web pages...

---

IIRC, that only ever worked in Internet Explorer.

Given the limited availability, I don't think it was "often" used in web pages even back in the 90s. I'd be shocked if anyone was still using it in a web page today!

[empi_ml]

Hello everyone,
I use the LIB scrrun.dll in my VBA project.
In order to parse JSON files I need the dictionary object of scrrun.dll
Will this lib remain or will it also be removed? If so, then what would be the alternative?

[JKPieterse]

What is the story on Server-side scripted web pages using VBScript?

[iisboy]

I also want to know if there is any impact on classic ASP

[essentialexch]

What is happening to the various COM objects exposed for VBScript? These see heavy use in PowerShell. (For example, WScript.Shell, Scripting.FileSystemObect, CertificateAuthority.View.1, NameTranslate, etc.)

Is anything being done to improve the deplorable condition of interfacing PS to COM? I'm thinking of such common abominations as:

$property = [System.__ComObject].invokemember("item", $binding::GetProperty, $null, $BuiltinProperties, $DocProperty)

and

$obj.GetType().InvokeMember( 'DomainShortName', 'GetProperty',  $null, $obj, $null )

?

[Hagen_Stein]

@empi_ml: for a JSON parsing alternative implemented in VB(A), have a look at http://www.ediy.co.nz/vbjson-json-parser-library-in-vb6-xidc55680.html (and https://www.codeproject.com/Articles/720368/VB-JSON-Parser-Improved-Performance)

[HeinziAT]

How will this affect HTA (mshta.exe) applications written with VBScript? I guess they will be unaffected by phase 1 but will need the FOD in phase 2?

[nolongerset]

---

Phase 3

VBScript will be retired and eliminated from future versions of Windows. This means all the dynamic link libraries (.dll files) of VBScript will be removed. As a result, projects that rely on VBScript will stop functioning. By then, we expect that you’ll have switched to suggested alternatives.

---

Please explicitly state which .dll files will be removed.  When you say "all the dynamic link libraries of VBScript", which .dll's does Microsoft consider to be a part of VBScript?  It seems safe to assume vbscript.dll will be going away, but what about scrrun.dll?  That would be hugely disruptive in the VBA world as it would mean the loss of both the Dictionary object and the FileSystemObject.  Relatedly, um, there are currently NO "suggested alternatives" for the functionality these .dll's provide.

• vbscript.dll:
  • Microsoft VBScript Regular Expressions 1.0
  • Microsoft VBScript Regular Expressions 5.5
• scrrun.dll:
  • Microsoft Scripting Runtime

Also, when you say to VBA developers, "future phases will affect you, so watch out for new developments," when should we expect to see those "new developments"?  Depending on the path forward, we will need some lead time to change the hundreds of thousands (millions?) of code bases that currently rely on those features.

[Naveen_Shankar]

@Tom_K, @AlanDoran - VBScript will be available as FODs enabled by default in the upcoming Windows server 2025 version. Around 2027, VBScript FODs will be disabled by default across both the new desktop & server Windows OS versions

[Naveen_Shankar]

@AndAufVCG, @BosPete - Microsoft’s first-party applications are expected to migrate/remove/change their script dependencies from VBScript before deprecation phase 2 in the above timeline snapshot.

[Naveen_Shankar]

@empi_ml, @nolongerset - The scope of VBScript deprecation includes only vbscript.dll and no other libraries. This shall not impact any projects that are not dependent on vbscript.dll.

The VBA team is committed to provide more updates around the alternatives/new developments soon. Stay tuned for further information

[Naveen_Shankar]

@WithinRafael - Oops, sorry for the inconvenience. We will fix the link. However, the detailed guidance to convert VBScript to PowerShell is available & accessible in the webpage

[nolongerset]

@Naveen_ShankarThank you very much for the clarification.  Knowing that only vbscript.dll is affected is welcome news indeed.  I wish that had been clearer in the article itself, but with your clarification, I feel much more comfortable with the upcoming VBScript deprecation from the VBA perspective.

[AllHailTheHypnotoad]

ExcelScript is not powerful enough to replace VBA script for me, as it doesn't allow cell character level manipulation/text formatting. It's a shame, because I'd much rather be coding in TypeScript than in VBA.

[MB_Smith]

@AllHailTheHypnotoad https://github.com/dfinke/ImportExcel is strongly recommended as a PowerShell solution.

[empi_ml]

@Naveen_Shankar @nolongerset This is really good news! Thank you for the clarification.

[speedbrake]

It's good to see old technology go as new options are being introduced.
I also would like to suggest Python as an alternative to vbscript/powershell

[Sancarn]

ExcelScript is not powerful enough to replace VBA script for me

---

@AllHailTheHypnotoad It isn't as powerful as VBA end of, and it never plans to be according to Microsoft AMA. 

[FrancescoRombecchi]

Like @iisboy  I wonder what will happen with Classic ASP. Will it continue to function after 2027?

[abbodi1406]

When will you migrate slmg.vbs to Windows PowerShell? 🙂

vbscript_to_powershell.doc

https://web.archive.org/web/20100531052752/http://download.microsoft.com/download/1/c/6/1c677f64-b2b...

[forderud80]

MSI installers has in-built support for JScript and VBScript as documented on https://learn.microsoft.com/en-us/windows/win32/msi/summary-list-of-all-custom-action-types . Is the plan for MSI installers relying on VBScript to stop working after VBScript support is disabled and eventually removed?

If so, then you also risk breaking uninstallation of already installed apps after a Windows upgrade if the MSI installer relies on VBScript for uninstallation cleanup.

[FKWagner]

Hello,

what is happening in the special area of Failover Clustering Script Role. As far as I know right now, it only supports VBS calls. Mostly we call PowerrShell already, but as the script role relies on VBS, we still need it there. 

Hopefully, we see soon an dedicated article to all those questions regarding Windows Server.

Kind regards

[ihateregistrations]

So many issues with this.  As an earlier post here asked, what about the many millions of installations created using .msi installers that use vbscript?  They won't be able to update their software or uninstall.  We have a very large installed user base and some of them can take months to authorize even the tiniest changes (think U.S. military, nuclear plant operators just as two examples).

In more general terms, the whole "this is about security" angle is, to me, nonsense.  When was the last major malware spread using vbscript?  If any exist, even the worst antivirus product would catch-and-kill in an instant.  It's a non-threat.

And most important, whither IIS?  Our site is 100% vbscript not JavaScript and has stayed that way because of the vast number of folks that use stuff like noscript and many other ways to disable JavaScript. Server-side vbscript should not be destroyed in this whole process.

[Ronan_Fahy]

For those of us who are infrastructure types who use things like logon scripts, macros etc, but aren't necessarily core developers who know what some of the terminology above means, can you answer these simple scenario-type questions.

Affected or not?

1) .vbs logon scripts for users logging on to Win 11 machines for things like updating description fields for logon tracking and so on. Easy to move to powershell i know but will it be affected

2) Macros in word or excel that don't call external vbs files, they just do formatting stuff like inserting headers / footers and so on, referencing png files etc but no external vbs dependencies.

3) We also use VBS scripts as a wrapper for powershell scripts when we need it to run in user context but run hidden e.g. for scheduled tasks run in the user context or whatever but triggered by group policy. Powershell is i believe referred to as a console application or something like that and as such doesn't have a "hidden" option - the windowstyle hidden option still flashes up an initial launch window and THEN the launched script runs hidden.  using cscript or wscript on the other hand, lets you call the powershell script without it flashing up in the user's face at all.  This for us is the biggest risk of all of this change.

[MB_Smith]

@Ronan_Fahy - In regards to your item 3, I've been using this solution and I'm quite happy with it: https://github.com/MSEndpointMgr/PSInvoker

[ZaferBalkan]

I have been blocking script engines, wscript and csript for years as a hardening method. I am lucky that I am not using any SCCM components anymore. For the things I needed, I started writing Powershell alternatives already. For instance, slmgr.vbs is one of them:  https://github.com/zbalkan/slmgr-ps

I hope MS would provide Powershell alternatives for MS provided VBscript scripts, including slmgr.vbs, ospp.vbs, MDT and especially TSS.

[DickyPe48]

I am quite 'happy' to lose the scripting element of VBScript - if I need to run a script  I'll use JavaScript (even though it is far too easy to write unreadable code), but Like many other my real worry is what about Regular Expressions?  These are critical to virtually all serious VBA users and vague hints about alternatives give no reassurance.

[shahkeyur]

The link of downloading the Word document about conversion is Converting VBScript to Windows PowerShell | Microsoft Learn on this is not working. 

[BosPete]

@Naveen_Shankar " Microsoft’s first-party applications are expected to migrate/remove/change their script dependencies from VBScript before deprecation phase 2 in the above timeline snapshot." 

Is this official? Would love to hear more an updated to Microsoft Deployment tool kit (MDT)

[Ronan_Fahy]

@michael smith thanks for that it looks interesting and will check it out.

[AdvancedTechInt]

100% agree with @ihateregistrations  This seems like a massive overreaction to a non-problem.

I too would like to know what the implications are for Classic ASP using server-side VBScript?

Also, presumably the CScript.EXE and WScript.EXE will both continue to exist, so do we just need to rewrite all our .VBS files to be .JS? In which case, what's the point of dropping VBScript because you can do just as much damage via JScript‽

[Karl-WE]

@Naveen_Shankar 

I am seconding the requests for Microsoft's own dependencies on VBS.

The commenters named

• Slmgr on Windows Server and Client, which are crucial. No ETA or change visible in Windows Server 2025. Here's a thread with ideas how to compensate it. 
• Failover clustering scripts 
• Logon /logoff scripts
• MDT and ConfigMgr, no matter MDT is now deprecated for Windows Server 2025 and Windows 11
• Conversion to PShell, actually copilot in Edge does a great job

I would like to add the following:

• Print Management VBS scripts. Till today the PS commands from Microsoft should be improved
• Office LTSC activation
• Generally KMS and ADBA activation
• I would appreciate your consideration to deprecate and remove cscript and wscript to remove attack surface using other script languages
• ADK feature might have dependencies
• Other Windows Server Roles and Features affected?
• Windows Server 2025 and Windows 11 24H2, Azure Stack HCI and WS Azure Edition should follow the same timeline for consistent protection and results. If VBS marks a security concern, Windows Server are even more prone attack targets. 

[Tom_K]

@Karl-WE Regarding Office LTSC activation, I wonder if there will be such a thing in five (5) years.

[Karl-WE]

@Tom_K agreed, but since there is no deprecation of LTSC Office we have to calc Office LTSC 2021 + 5-10 years from release. This supported office version should require slmgr, for the use of ADBA (preferred) or KMS server (legacy).

[Tom_K]

@Karl-WE Office 2021 LTSC goes EOL in less than 30 months (10/13/2026), so that's well before the later dates MS is talking about here for optional VBS support.  Office 2021 and Office LTSC for Windows and Mac FAQ - Microsoft Support

[primalcode]

The only reason we currently use vbscript is to call a powershell script silently. Powershell has a -hidden command but it doesnt stop the window from intially appearing. This need to be fixed as having pop up windows appearing for our users is bad design.

[AndAufVCG]

@primalcode see https://techcommunity.microsoft.com/t5/windows-it-pro-blog/vbscript-deprecation-timelines-and-next-s...

[Karl-WE]

good catch @Tom_K didn't lookup the exact date. I never heard about a successor for LTSC 2021. So that's it with a supported version of legacy style Office? Do not want to derail/OT but then it is even not an issue with activation at least. 

[AlexLaforge]

You absolutely NEED to clarify the implications on Classic ASP : The are hundreds of thousands of mission-critical applications using it.
Abandoning Classic ASP is just unthinkable, so please clarify.

[RMittelman]

Thanks, @Naveen_Shankar for your clarification that deprecation is only for vbscript.dll, and not for the others.  I presume this means we can reference script host, object model, etc., right?

Also, what will we Regex users do?  The Microsoft VBScript Regular Expressions reference points directly to vbscript.dll which will be missing going forward.  How do we do our regular expressions from VBA?

Thanks...

[DX7Dev]

@Naveen_Shankar Yesterday we setup a Hypervised instance of Windows Server 2025 Preview. We confirmed that uninstalling the VBScript FOD completely breaks the ASP ISAPI module in IIS. The effect was that all ASP pages simply crash with a 500 Internal Server Error, and there is no other event logging or system logging. I assume this is because asp.dll has a hard dependency on vbscript.dll. Can you clarify if that is true and if asp.dll will be updated to remove this dependency, making JScript/Javascript a viable alternative for migrating ASP websites, or will ASP also be deprecated as a result? Right now the ASP module just breaks, so you can not use JScript with the VBScript FOD uninstalled.

[Karl-WE]

Hi all, if anyone is interested about the topic of deprecation, recently wrote a blog about it. 

https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/blog-what-deprecation-means-in-prac...

[Pieter_Cooreman]

The more I read about this whole VBScript-deprecation-thing, the more I think that the product managers at MicroSoft do not even realize what will be the impact for these millions of Classic ASP/VBScript web applications that still represent at around 2% of the entire WWW.

The questions about the implications for Classic ASP over here are - once again - being ignored completely. It really looks like the current product managers at MicroSoft were not even born yet when millions of Classic ASP/VBScript applications were developed between 1996 and 2010 (many are still under development or at least well supported).

Proposing to move to JavaScript (when using Classic ASP) makes no sense. The latest version of JavaScript that is supported by IIS is a JScript dialect that was abandoned by MicroSoft in 2006.

What would it take for MicroSoft to get our attention?

[AlexLaforge]

Hi Microsoft Team,

Time has come for you to realize that deprecating VBScript is NOT a good move.
It does not help in any way in terms of security.

It will just break millions (yes, really) of big Classic ASP websites that are still running.
Your team should just use BuiltWith to get a glimpse of the huge number of publicly available Classic ASP webpages !
And this number obviously does not include the biggest part of the iceberg : the billions of pages running on intranet/extranets worldwide.

I am working for many big famous companies worldwide still using Classic ASP very widely, and this deprecation will just run them out of business.
With the though times worldwide economy is facing, putting this trial to their life will be a very bad decision.
Keeping Classic ASP and VBScript will notoberate the profit you can make in newer tehcnolologies (.NET, Powershell, and so on).

So, your team must reconsider their position, and cancel this deprecation. Really.

And now clarify.