Preparing for VBScript Deprecation: An Audit Guide for VBA and Internal Tools

Executive Summary

“Internal tools” in this article means more than Excel macros and .vbs files. It covers GPO logon scripts, tasks registered in Task Scheduler, scripts deployed through Intune, and VBScript Custom Actions inside MSIs. Even if you have no memory of ever writing VBScript yourself, a .vbs buried in any of those puts you in scope.

As of April 2026, Microsoft has published its policy of deprecating VBScript in phases: in Windows 11 version 24H2 it first becomes a Feature on Demand enabled by default, in the next phase it becomes disabled by default, and in the final phase it is planned for removal from a future Windows release. In other words, what really needs doing now, ahead of any full rewrite, is making visible where the VBScript dependencies are.

No firm dates have been published for the timing. Microsoft’s VBA-facing guidance puts Phase 2 (the FOD disabled by default) at around 2026-2027 and Phase 3 (removal) at TBD. That means you cannot work backwards from a date to decide when this has to be finished. Work on the assumption that the deadline moves closer as more devices land on Windows 11 24H2 and later, and get the inventory done ahead of everything else.

For VBA and Excel macros, the realistic concerns are two. One is cases that execute external .vbs files; the other is references to VBScript-type libraries such as VBScript.RegExp. For the latter, starting with Office version 2508 (Build 19127.20154) the RegExp class ships in the VBE as standard, so at least some RegExp-dependent code has become easier to migrate. On the other hand, in mixed environments where older Office clients remain, the same VBA can easily work on some machines and fail on others.

What makes migration hard is less VBScript itself than the operations around it. For example, even if you replace things so that Excel launches powershell.exe, it will not run in production if it trips over the attack surface reduction rules “Block all Office applications from creating child processes” or “Block Win32 API calls from Office macros”, or AppLocker, App Control for Business, PowerShell execution policy, signing operations, or the macro controls for MOTW-tagged files. The migration plan should be designed to include not just code conversion but policy, signing, and log auditing.

The shortest route is inventory, static detection, execution log collection, choosing the replacement, testing, and phased rollout. This article works through it in that order, for practical use.

The code that appears in this article is published on GitHub as a runnable, testable sample set (PowerShell audit scripts, replacement samples, reference VBA and Office Scripts code, and Pester tests).

vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide - komurasoft-blog-samples (GitHub)

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (25 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

A Short Glossary

The chapters that follow use a run of Windows security acronyms. Getting these straight up front makes the rest easier to read.

Sorting Out What Is Changing

The first thing to grasp is that this is not a story about VBA being deprecated. What Microsoft has published is strictly the phased deprecation of VBScript, and the impact on VBA projects concentrates mainly on execution of external .vbs files and references to VBScript-family libraries. The Microsoft 365 Developer Blog likewise identifies .vbs execution from VBA and use of VBScript.RegExp as the representative impact points.

For practical prioritization, this table makes the decisions easier.

This prioritization is a practical judgment based on the Windows-side VBScript deprecation plan, the official detection strategy, and the ASR/AppLocker/App Control specifications.

RegExp alone is a slightly different story. From Office version 2508 onward, the VBE includes the RegExp class as standard, so for RegExp use specifically, part of the VBScript dependency can be resolved by an Office update. However, this does not resolve automatically in organizations with old Office, slow update channels, mixed environments, or stale device images. The important part is to put both the Office update and the Windows phase switch into your ledger.

How to Run the Inventory

An inventory needs more than file-name searches. At minimum, we recommend keeping the following ten aspects as columns, per project, per tool, per business process.

• (1) Method of detecting VBScript-dependent locations Record file search, code analysis, and log analysis separately.
• (2) Use of CreateObject / GetObject / Execute / ExecuteGlobal etc. inside VBA The dependency hides inside strings, so static-search misses are common.
• (3) External script calls from Excel macros Track WScript.Shell, the Shell function, wscript.exe / cscript.exe, and .vbs / .js / .ps1 separately.
• (4) Script dependencies of internal batch jobs and tools Include Scheduled Tasks, GPO, Intune, operational scripts on shared folders, and installers.
• (5) Security, permissions, signing, policy AppLocker, App Control for Business, ASR, PowerShell execution policy, digital signatures, whether admin rights are required.
• (6) Replacement technologies and migration cost comparison Compare native VBA, PowerShell, .NET/VSTO, Office Scripts, and Power Automate.
• (7) Test plan Separate unit, integration, user acceptance, and re-testing after policy application.
• (8) Operating procedures and rollback State explicitly what must be reverted to recover, and how far to automate.
• (9) Compatibility and performance Office version differences, 32/64bit, device performance, log-collection load, cloud-flow timeouts.
• (10) A sample migration case study Build one representative example you can use to explain the work to the people who run it.

Of these ten items, GPO, Scheduled Tasks, Intune-deployed scripts, MSI Custom Actions, and detection via Sysmon/AppLocker/App Control are explicitly highlighted as focus areas in Microsoft’s official guidance.

The overall migration flow stays on track if you think of it like this diagram.

flowchart TD
    A[Asset inventory] --> B{Type of dependency}
    B -->|External .vbs execution| C[Replace with PowerShell or native VBA]
    B -->|VBScript.RegExp| D[Consolidate onto the built-in RegExp of Office 2508+]
    B -->|GPO / Tasks / MSI| E[Fix centrally managed settings and deployed artifacts]
    B -->|Unknown / buried dependencies| F[Collect execution logs via Sysmon / AppLocker / App Control]
    C --> G[Unit testing]
    D --> G
    E --> H[Integration testing]
    F --> H
    H --> I[Pilot rollout in audit mode]
    I --> J[Phased disabling of the VBScript FOD]

For environments where the diagram does not render, here it is in three lines.

1. Sort the dependencies the inventory turned up into four buckets: external .vbs execution, VBScript.RegExp, centrally managed settings (GPO, tasks, MSI), and unknown
2. Pick a replacement per bucket, get it through unit testing, and merge from there into integration testing
3. Run a pilot rollout in audit mode, and if nothing goes wrong, disable the VBScript FOD in stages

Keep this order and you greatly reduce the classic do-over of “we rewrote it first, and then GPO or ASR knocked it down afterwards”.

Practical Detection and Code Examples

File Search and Enumerating Configuration

Microsoft’s detection guidance recommends recursively searching for .vbs while prioritizing paths with a clear purpose - C:\Users, C:\ProgramData, C:\Scripts, and the like - and checking GPO, Scheduled Tasks, Intune-deployed scripts, and MSI packages on separate tracks. Sysmon’s vbscript.dll monitoring is effective, but Image Load monitoring carries heavy log volume and operational load, so validate it in a small pilot first.

# Roughly sweep script dependencies on devices and shared folders
$paths = @("C:\Users", "C:\ProgramData", "C:\Scripts")
$patterns = @(
  'wscript\.exe',
  'cscript\.exe',
  '\.vbs(\s|$)',
  'VBScript\.RegExp',
  'WScript\.Shell',
  'CreateObject\("VBScript\.RegExp"\)',
  'ExecuteGlobal'
)

$hits = foreach ($path in $paths) {
  if (Test-Path $path) {
    Get-ChildItem -Path $path -Recurse -File `
      -Include *.vbs,*.ps1,*.bat,*.cmd,*.wsf,*.hta,*.txt `
      -ErrorAction SilentlyContinue |
      Select-String -Pattern $patterns -AllMatches |
      Select-Object Path, LineNumber, Line
  }
}

$hits | Export-Csv .\vbscript-dependency-hits.csv -NoTypeInformation -Encoding UTF8

Next, sweep Task Scheduler. With internal tools, wscript.exe / cscript.exe / .vbs is buried inside task definitions more often than in files.

# Extract VBScript invocations from Scheduled Tasks
Get-ScheduledTask | ForEach-Object {
  foreach ($a in $_.Actions) {
    if ($a.Execute -match 'wscript|cscript|mshta' -or $a.Arguments -match '\.vbs\b') {
      [pscustomobject]@{
        TaskName  = $_.TaskName
        TaskPath  = $_.TaskPath
        Execute   = $a.Execute
        Arguments = $a.Arguments
      }
    }
  }
} | Export-Csv .\task-vbscript-dependencies.csv -NoTypeInformation -Encoding UTF8

VBA Code Analysis

On the VBA side, looking only at the references dialog is not enough. CreateObject and GetObject can instantiate COM from a string, so code can be dependent even when nothing shows up in the references. Microsoft’s VBA/Office documentation describes CreateObject as the basic means of creating COM objects, and FileSystemObject and Scripting.Dictionary are used in that form too. Also, reading a VBA project programmatically requires “Trust access to the VBA project object model”.

' Prerequisites:
'  - Enable "Trust access to the VBA project object model" in the Trust Center
'  - Protected projects require separate source export or confirmation with the owner
Sub ScanProjectForVbScriptRisks()

    Dim comp As Object
    Dim cm As Object
    Dim ws As Worksheet
    Dim nextRow As Long
    Dim patterns As Variant
    Dim p As Variant
    Dim i As Long
    Dim lineText As String

    patterns = Array( _
        "CreateObject(""VBScript.RegExp"")", _
        "VBScript.RegExp", _
        "WScript.Shell", _
        "Shell(", _
        ".vbs", _
        "wscript.exe", _
        "cscript.exe", _
        "ExecuteGlobal", _
        "Execute(" _
    )

    Set ws = ThisWorkbook.Worksheets.Add
    ws.Range("A1:D1").Value = Array("Module", "Line", "Pattern", "Code")
    nextRow = 2

    For Each comp In ThisWorkbook.VBProject.VBComponents
        Set cm = comp.CodeModule

        For i = 1 To cm.CountOfLines
            lineText = cm.Lines(i, 1)
            For Each p In patterns
                If InStr(1, lineText, CStr(p), vbTextCompare) > 0 Then
                    ws.Cells(nextRow, 1).Value = comp.Name
                    ws.Cells(nextRow, 2).Value = i
                    ws.Cells(nextRow, 3).Value = p
                    ws.Cells(nextRow, 4).Value = lineText
                    nextRow = nextRow + 1
                End If
            Next p
        Next i
    Next comp

    ws.Columns.AutoFit
    MsgBox "Scan finished: " & (nextRow - 2) & " hits"

End Sub

This scan picks up, at minimum, CreateObject("VBScript.RegExp"), WScript.Shell, Shell(, .vbs, and ExecuteGlobal. String-based execution like Execute / ExecuteGlobal in particular is a breeding ground for inventory misses, because the dependency target and the executed code are assembled dynamically.

Log Analysis

At the stage of examining execution logs, the combination of Sysmon plus AppLocker/App Control is powerful. Sysmon can track loads of vbscript.dll via Event ID 7, and AppLocker’s allow and audit events for scripts and MSIs are visible in Event Viewer. Run App Control for Business in audit mode, and scripts and MSIs are recorded in the AppLocker\MSI and Script log.

# Sysmon: find processes that loaded vbscript.dll
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 2000 |
  Where-Object { $_.Id -eq 7 -and $_.Message -match 'vbscript\.dll' } |
  Select-Object TimeCreated, MachineName, Message

# AppLocker / App Control: check audit logs for scripts and MSIs
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/MSI and Script" -MaxEvents 2000 |
  Where-Object { $_.Id -in 8005, 8006 } |
  Select-Object TimeCreated, Id, Message

The important thing here is collecting not just the logs that say it ran, but also the logs that say audit would have blocked it. AppLocker’s audit events and App Control’s audit mode are well suited to safety checks before you start blocking in production.

Minimal Replacement Samples

For processing on the level of calling an external .vbs to write out a CSV, the shortest path is to replace it with native VBA first.

Sub ExportCsvNativeVba()

    Dim f As Integer
    Dim outPath As String

    outPath = ThisWorkbook.Path & "\out.csv"
    f = FreeFile

    Open outPath For Output As #f
    Print #f, "Code,Name"
    Print #f, "1001,Tokyo"
    Print #f, "1002,Osaka"
    Close #f

    MsgBox "CSV exported: " & outPath

End Sub

If you need to call external processing from Excel and it reaches the OS, shared folders, AD, installers, or log collection, leaning on PowerShell is more realistic. Microsoft recommends PowerShell as the VBScript replacement, and the PowerShell side has official operational mechanisms for execution policy, signing, and Authenticode verification. Note that VBA’s Shell is asynchronous by default, so processing that needs a guaranteed order requires separate flow design or explicit waiting.

Sub RunModernPs()

    Dim cmd As String
    cmd = "powershell.exe -NoProfile -File """ & ThisWorkbook.Path & "\Normalize.ps1""" & _
          " -InputFile """ & ThisWorkbook.Path & "\in.csv""" & _
          " -OutputFile """ & ThisWorkbook.Path & "\out.csv"""

    Shell cmd, vbNormalFocus

End Sub

param(
  [string]$InputFile,
  [string]$OutputFile
)

Import-Csv $InputFile |
  Sort-Object Code |
  Export-Csv $OutputFile -NoTypeInformation -Encoding UTF8

# Apply and verify a signature
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Normalize.ps1 -Certificate $cert
Get-AuthenticodeSignature -FilePath .\Normalize.ps1

If the Excel processing completes entirely inside the workbook - formatting, aggregation, transformation - Office Scripts is also a strong option. Office Scripts targets Excel and is well suited to cloud-based, cross-platform use and Power Automate integration.

function main(workbook: ExcelScript.Workbook) {
  const sheet = workbook.getActiveWorksheet();
  const used = sheet.getUsedRange();
  used.getFormat().autofitColumns();

  const tables = workbook.getTables();
  if (tables.length > 0) {
    tables[0].getSort().apply([{ key: 0, ascending: true }], true);
  }
}

Choosing the Replacement Technology

The replacement should be chosen not by what you can write it in but by how much responsibility it will carry. PowerShell leans toward Windows, files, tasks, and installers; native VBA toward the inside of Office; Office Scripts toward Excel workbook processing; VSTO/.NET toward heavy desktop integration; Power Automate toward orchestration. The table below is a practical estimate built on the officially published characteristics of each approach. The effort figures are the author’s rough guide.

Read the effort scale as a guide for migrating one tool - one macro, or one script: Low means a few days, Medium a few weeks, High one to several months. If ten of them are in scope, the effort stacks up accordingly.

Sketching the selection guideline a bit more intuitively:

flowchart TD
    A[Discovered VBScript dependency] --> B{Completes inside the Excel workbook?}
    B -->|Yes| C[Native VBA]
    B -->|Yes, and sharing/cloud matters| D[Office Scripts]
    B -->|No| E{Touches the OS, files, tasks, AD?}
    E -->|Yes| F[PowerShell]
    E -->|No| G{Heavy UI integration or long-lived add-in?}
    G -->|Yes| H[.NET / VSTO]
    G -->|Flow-triggered or approval-centric| I[Power Automate]

In three lines, this one comes out as follows.

1. If it completes inside the Excel workbook, native VBA. If sharing or cloud execution is the priority, Office Scripts
2. If it touches the OS, files, tasks, or AD, PowerShell
3. If it is heavy UI integration or a long-lived add-in, .NET / VSTO. If it is flow-triggered or approval-centric, Power Automate

One addition about RegExp specifically: in environments where only Office version 2508 or later is present, consolidating onto Dim re As RegExp / Set re = New RegExp is quite effective. But if even one machine with older Office remains, that code hits the compile-compatibility wall. In mixed environments, decide first whether the migration policy is new syntax, old syntax, or a branching wrapper.

Testing and Operations

Test Plan

A VBScript migration is not covered by unit testing alone. Unless you re-test under production-equivalent conditions with the security policies active, the replacement PowerShell or .NET scripts will stop for entirely different reasons. Microsoft’s materials likewise treat PowerShell execution policy, AppLocker, App Control audit mode, ASR, and the macro controls for MOTW-tagged files as separate rules.

The points most often missed are these.

• A replacement where Excel launches PowerShell may trip over ASR’s “Block all Office applications from creating child processes”.
• Leaving VBA declarations or API calls in place may trip over ASR’s “Block Win32 API calls from Office macros”.
• Test .xlsm / .ps1 files distributed via downloads or mail attachments behave differently depending on MOTW and signature state.
• The Office Scripts plus Power Automate combination is convenient, but with large CSVs or huge cell counts you have to mind timeouts and data-transfer limits.
• Sysmon’s Image Load monitoring is useful, but rolled out carelessly across the whole company it inflates log volume fast.

Migration Procedure Checklist

• Statically searched for .vbs, wscript.exe, cscript.exe, VBScript.RegExp, WScript.Shell, Shell(, ExecuteGlobal
• Inventoried GPO, Scheduled Tasks, Intune, shared-folder operations, and MSIs on separate tracks
• Put Office versions and update channels into a ledger and identified remaining pre-2508 installs
• Decided the replacement among native VBA / PowerShell / .NET / Office Scripts / Power Automate
• Decided the signing policy and the certificate distribution policy
• Tested the impact of AppLocker / App Control / ASR / execution policy
• Collected audit logs in a pilot department
• Documented the rollback procedure
• Preserved the evidence that it is unused before disabling the VBScript FOD

Risks and Countermeasures

The countermeasures in this table translate the design constraints in Microsoft’s official materials into internal operations.

Rollback means more than reverting the code. At minimum, treat restoring previous versions of deployed artifacts, reverting policies, the headroom to re-enable the optional feature, and continued log collection as one set. While VBScript still exists as a FOD, there is room to re-enable it as an optional feature per the Phase 2 guidance, but once it is removed in Phase 3 that escape hatch is gone.

A Sample Migration Case Study

As a typical example, take the accounting department’s monthly aggregation macro. Today, the Excel macro launches cleanup.vbs via WScript.Shell, validates codes with VBScript.RegExp after CSV formatting, and finally writes the output to a shared folder. This setup takes a direct hit from VBScript deprecation, and even a naive port to PowerShell stalls again on ASR and signing operations.

A proposal is hard to put in front of management without a sense of scale, so here are some placeholder numbers included purely for illustration. The real values come out of your inventory, but rewritten at this granularity the table works directly as the base of a project plan.

The duration runs longer than the effort because this is a monthly process. Unit testing may finish in a day, but whether it produces the same result as last month cannot be confirmed without crossing a month end once. For a tool that includes annual processing, that wait stretches further still. Plan by working backwards from when you can actually confirm the result, not from the effort figures.

The right answer in this case is to split it apart. Validation, formatting, and aggregation that complete inside Excel move to native VBA or the built-in RegExp of Office 2508+. File conversion and shared-folder I/O move to PowerShell. If the trigger is a file arriving or a fixed daily time, move that to Power Automate. This untangles the responsibilities that had been stuffed into a single .vbs.

An example post-migration structure:

• Excel macro: input checks, screen interaction, user-facing messages
• PowerShell: CSV normalization, shared-folder I/O, log output
• Signing: Authenticode signatures on the PowerShell scripts
• Security: verify AppLocker/App Control in audit mode first; decide whether ASR exceptions are needed
• Future extension: phase routine in-Excel processing over to Office Scripts

The advantage of this approach is that you cut loose the VBScript runtime dependency early without having to rebuild everything at once. Absorb RegExp via the Office update, move operational scripts to PowerShell, move the business flow to Power Automate: split by responsibility, and the blast radius of any failure shrinks too.

Recommended Tools and Reference Links

• The complete sample code for this article (PowerShell audit scripts and Pester tests) https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide

We recommend reading the official materials in this order.

• VBScript deprecation: Timelines and next steps The starting point for confirming the overall roadmap and what each Phase means.
• VBScript deprecation: Detection strategies for Windows Practical detection guidance covering Sysmon, GPO, Scheduled Tasks, Intune, and MSI Custom Actions.
• Prepare your VBA projects for VBScript deprecation in Windows The most important from the VBA perspective. Covers the built-in RegExp, the handling of Office 2508 and later, and a compatibility table.
• Differences between Office Scripts and VBA macros Helps decide whether Excel-centric processing should move to Office Scripts.
• about_Execution_Policies / about_Signing / Set-AuthenticodeSignature / Get-AuthenticodeSignature The basic set for signing and execution-policy operations during a PowerShell migration.
• Using Event Viewer with AppLocker / Use audit events to create App Control policy rules / Script enforcement with App Control for Business Needed for understanding audit-mode design, event collection, and script enforcement behavior.
• Attack surface reduction rules reference The material for checking the block rules around Office child processes, Win32 APIs, and JS/VBS download execution.
• Macros from the internet are blocked by default in Office Required reading for understanding MOTW issues during test distribution and production rollout.

As supporting tools, these come up often in our practice.

• Sysmon The basis for monitoring vbscript.dll loads and collecting process-level events.
• Sysmon configuration templates on GitHub SwiftOnSecurity’s sysmon-config is a high-quality starting template, and Olaf Hartong’s sysmon-modular is a modular, operations-friendly starting point.
• oletools / olevba Suited to extracting VBA source from Office files and assisting detection of suspicious keywords and auto-executing macros.

In conclusion, preparing for VBScript deprecation takes more than finding the VBScript and replacing it with PowerShell. Managing the Office updates, code analysis, operational configuration, signing, ASR/AppLocker/App Control, and UAT in a single ledger is the fastest reliable way forward. Rescue early the areas an Office update can rescue, like RegExp, and give priority to detaching the areas that break on the Windows-side phase switches: .vbs execution and the GPO/task/MSI dependencies.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

When is VBScript going away?

As of April 2026, Microsoft has published a policy of deprecating VBScript in phases. In Windows 11 version 24H2 it is first a Feature on Demand (FOD) enabled by default, in the next phase it becomes disabled by default, and in the final phase it is planned for removal from a future Windows release. So the thing that actually needs doing now, ahead of any full rewrite, is making visible where the VBScript dependencies are. While it still exists as a FOD there is room to re-enable it as an optional feature, but once it has been removed that escape hatch is gone.

If VBScript goes away, do VBA and Excel macros stop working too?

No. This is not a story about VBA being deprecated. What Microsoft has published is strictly the phased deprecation of VBScript, and the impact on VBA projects concentrates on execution of external .vbs files and on references to VBScript-family libraries such as VBScript.RegExp. Processing that runs .vbs directly from VBA or Excel is at high risk of stopping once the phase switch lands, and it is the first thing to identify. GPO logon scripts, Scheduled Tasks, Intune-deployed scripts, and VBScript Custom Actions in MSIs are the other focus areas, because they are prone to mass outages.

What should I use to replace VBScript?

Choose the replacement by how much responsibility it carries, not by what you can write it in. Processing that touches the OS, files, shared folders, AD, tasks, or installers goes to PowerShell, Microsoft's recommended replacement, which also has official operational mechanisms for signing and execution policy. Cell manipulation and reporting that completes inside an Excel workbook goes to native VBA; Office Scripts fits when cloud execution and Power Automate integration matter; .NET / VSTO fits heavy desktop integration and long-lived internal add-ins; and Power Automate fits scheduled runs and approval-driven triggers. After the replacement you still have to test whether ASR or AppLocker stops it: the testing has to cover policy, not only code.

What should I do if my VBA uses VBScript.RegExp?

Starting with Office version 2508 (Build 19127.20154), the RegExp class ships in the VBE as standard, so for RegExp use specifically, part of the VBScript dependency can be resolved by an Office update. In mixed environments where older Office clients remain, however, the same VBA can easily work on some machines and fail on others. If even one machine below 2508 remains, the new syntax hits the compile-compatibility wall, so put Office versions and update channels into a ledger to see what is left, and decide up front whether the migration policy is new syntax, old syntax, or a branching wrapper.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.