VBScript deprecation: Detection strategies for Windows

Start detecting Visual Basic Scripting Edition (VBScript) across your organization in preparation for the next deprecation phase.

At the current deprecation phase of VBScript, it’s available as a feature on demand (FOD) and is enabled by default in Windows 11, version 24H2. Before VBScript is disabled by default on these and future OS versions, it’s critical that you to identify where and how vbscript.dll is still being used within your enterprise environment. Take a look at four scalable, enterprise-ready mechanisms to detect usage and plan mitigation steps across all Windows platforms. 

Strategy 1: Use Sysmon to monitor VBScript usage

Use System Monitor (Sysmon) and load the tracking capability for its dynamic link libraries (.dll) to monitor enterprise-wide usage of VBScript. You can detect vbscript.dll loads by collecting and analyzing Sysmon logs across all Windows platforms.

Important: Sysmon monitoring can cause performance and operational overhead, especially when deployed at scale. Before broad deployment, test on a small group of devices to evaluate performance impact.

Configure .dll load tracking and deploy Sysmon

Before deploying Sysmon, configure it with a minimal and focused rule set that targets .dll loads. Since Sysmon doesn’t have a graphical user interface (GUI), you’ll manage configurations via XML files and the command-line interface.

Add a configuration to your Sysmon setup as illustrated in the following sample:

<Sysmon schemaversion=”4.50″>
<EventFiltering>
   <ImageLoad onmatch=”include”>
     <ImageLoaded condition=”contains”>vbscript.dll</ImageLoaded>
   </ImageLoad>
</EventFiltering>
</Sysmon>

To apply this configuration:

1. Edit your Sysmon configuration file (typically, sysmon-config.xml).
2. Reload it using the Sysinternals Sysmon utility.
3. Open an elevated command prompt and run: Sysmon64.exe -c sysmon-config.xml
4. Verify the current configuration by running: Sysmon64.exe -c

This configuration instructs Sysmon to generate Event ID 7 (image loaded) entries whenever any process loads vbscript.dll. The rule set sample above is sufficient to track VBScript. However, for more mature or modular configurations, consider adapting broader rule sets from these GitHub resources:

• SwiftOnSecurity’s baseline Sysmon config
• Olaf Hartong’s Sysmon Modular framework

Now, you can deploy Sysmon using Microsoft Intune, Group Policy, Microsoft Configuration Manager, or scripts, depending on your organization’s setup.

Collect Sysmon logs of .dll loads

After you configure and deploy Sysmon, collect the logs for Event ID 7. At this stage, you’ll identify how many and which processes load vbscript.dll.

1. In the Event Viewer, go to Applications and Services Logs.
2. Locate Microsoft > Windows > Sysmon on the left navigation bar.
3. Select Operational.
4. In the Actions pane on the right, filter the log by Event ID 7, Sysmon.

Screenshot of Event Viewer showing search results for Event ID 7 in Sysmon.

Forward these events to a central log store for analysis. Do this through Windows event forwarding, security information and event management (SIEM) agents, or manual exports.

You can then use standard tools like Power BI, Microsoft Excel, or custom scripts to analyze these Sysmon logs.

Analysis tip 1: Trace process ancestry in desktop and script usage

Sysmon’s Event ID 7 (image loaded) and Event ID 1 (process creation) can help identify which process loaded vbscript.dll and its immediate parent. This gives insights into process ancestry. Learn more about the types of events that Sysmon generates.

To trace deeper process lineage (e.g., grandparent processes), use endpoint detection and response (EDR) or SIEM tools with visual process graphs.

For more thorough analysis, consider using PowerShell scripts to:

• Parse Event ID 7 to extract Process IDs (PIDs) of processes that loaded vbscript.dll.
• Use Event ID 1 to find the parent process. This allows you to gain insight into what launched the script-capable process, such as wscript.exe, regsvr32.exe, or application binaries.

If you’re new to PowerShell, learn how to query and filter event logs.

Analysis tip 2: Solve for noise in web-hosted environments

Web-hosted environments are different. These include Internet Information Services (IIS) running VBScript for server-side scripting (e.g., classic Active Server Pages known as ASP). In such environments, vbscript.dll may be loaded passively during the initial page load, even before user interaction. This can generate noise in Sysmon logs, because Event ID 7 entries are logged regardless of whether VBScript is actively invoked. Furthermore, Sysmon events do not include web-layer context such as the URL or page name.

To reduce noise and improve traceability, combine Sysmon logs with IIS logs. By correlating Sysmon timestamps with IIS request entries, you can identify which specific HTTP request triggered the vbscript.dll load, providing clearer context for web-based script execution. See Advanced logging for IIS – Log filtering if this is new to you.

Strategy 2: Review VBScript dependencies

In many enterprise environments, VBScript dependencies may be embedded in any of the following centrally managed locations:

• Group Policy logon scripts
• Group Policy logoff scripts
• Group Policy startup scripts
• Group Policy shutdown scripts
• Scheduled tasks configured to launch legacy scripts
• PowerShell scripts deployed via Intune that invoke .vbs scripts indirectly

With this strategy, you’ll identify these scripts in preparation for their remediation and VBScript removal. 

Note: You can often perform these analyses from a single admin workstation or a domain controller (DC). That is because Group Policy objects (GPOs), scheduled tasks, and Intune scripts are centrally configured either via GPO or device-management platforms.

Group Policy object scripts

1. Check \\<domain>\SYSVOL for .vbs files. 
2. Extract referenced scripts (e.g., using PowerShell). 
3. Look for any invocation of wscript.exe, cscript.exe, or .vbs files. 

Brush up on using these scripts in Group Policy if needed.

Scheduled tasks

List scheduled tasks and inspect command lines (e.g., using PowerShell). Pay special attention to tasks under \Microsoft\Windows or custom organization-defined folders. 

Microsoft Intune–deployed scripts (PowerShell)

Although Intune doesn’t natively run .vbs files, PowerShell scripts deployed via Intune can still invoke VBScript indirectly (e.g., via cscript.exe). Please review any PowerShell scripts deployed through Intune for embedded VBScript execution patterns.

Strategy 3: Scan for .vbs files across the system 

To complement other detection strategies for your enterprise, proactively search for .vbs script files on endpoints. This helps surface any legacy script usage not tied to scheduled tasks or GPOs. 

Recursively look for .vbs files in common paths like: 

• C:\Users\ 
• C:\ProgramData\ 
• C:\Program Files\ 
• C:\Program Files (x86)\
• C:\Scripts\ 
• C:\Windows\ (optional: might include noise) 

Caution: Avoid scanning the entire C:\ blindly in production. It can cause performance issues or access errors. Focus on user- and script-relevant paths. 

To scan relevant paths, adapt the following sample PowerShell script: 

$pathsToScan = @(“C:\Users”, “C:\ProgramData”, “C:\Scripts”)
$logPath = “C:\VBSScriptScan\VbsFiles_$(hostname).csv”
$results = foreach ($path in $pathsToScan) {
   if (Test-Path $path) {
       Get-ChildItem -Path $path -Filter *.vbs -Recurse -ErrorAction SilentlyContinue |
           Select-Object FullName, LastWriteTime, Length
   }
}
$pathsToScan = @(“C:\Users”, “C:\ProgramData”, “C:\Scripts”)
$logPath = “C:\VBSScriptScan\VbsFiles_$(hostname).csv”
$results = foreach ($path in $pathsToScan) {
   if (Test-Path $path) {
       Get-ChildItem -Path $path -Filter *.vbs -Recurse -ErrorAction SilentlyContinue |
           Select-Object FullName, LastWriteTime, Length
   }
}

For large enterprise deployments, you can run this command via:

• Microsoft Intune
• Group Policy startup script 
• Remote PowerShell (Invoke-Command) 
• Microsoft Configuration Manager script deployments 

Store results centrally (e.g., \\AdminPC\Scans\) or log them locally and collect them later. 

Strategy 4: Scan custom MSI packages for embedded VBScript

Custom Microsoft Installer (MSI) packages may contain embedded VBScript through custom actions. This was a common packaging practice in older enterprise applications. These scripts are often silently executed during installation, repair, or uninstallation processes. Don’t overlook them during your modernization efforts!

With this strategy, you’ll identify VBScript use in MSI files so you can flag legacy packages for remediation.

Detect custom action

1. Use PowerShell to recursively scan .msi files across your software repositories.
2. Inspect the MSI CustomAction table for action types 6, 38, and 50. These correspond to VBScript entries.
3. Look for VBScript stored in binary streams, embedded inline, or referenced by path.

Adapt the following PowerShell sample detection script:

Get-ChildItem -Path “C:\MSIRepo” -Recurse -Filter *.msi | ForEach-Object {
    $msiPath = $_.FullName
    $sql = “SELECT * FROM CustomAction”
    $installer = New-Object -ComObject WindowsInstaller.Installer
    $database = $installer.GetType().InvokeMember(“OpenDatabase”, “InvokeMethod”, $null, $installer, @($msiPath, 0))
    $view = $database.OpenView($sql)
    $view.Execute()
    $record = $view.Fetch()
    while ($record -ne $null) {
        $actionName = $record.StringData(1)
        $actionType = [int]$record.StringData(2)
        if ($actionType -eq 6 -or $actionType -eq 38 -or $actionType -eq 50) {
            Write-Output “⚠ VBScript Custom Action: $actionName in $msiPath”
        }
        $record = $view.Fetch()
    }
}

Replace C:\MSIRepo with a local or network share that stores your MSI files (e.g., software deployment folders, Microsoft Configuration Manager package sources, or app archives).

Scaling recommendations

For better scaling experience, follow these recommendations:

• Collect MSI files from known deployment shares (e.g., Intune or Configuration Manager package sources, network software shares).
• Automate scanning using scheduled tasks or deployment tools (like Intune or Configuration Manager).
• Export findings to a central log or reporting system for visibility and tracking.

Avoid using Win32_Product for MSI enumeration. It can trigger a repair of all MSI-installed applications. Instead, rely on registry-based software inventory or trusted package management tools. To audit installed software, adapt the following PowerShell script. It lists installed applications from the Windows registry, showing each app’s name, installation data, and publisher.

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
   Where-Object { $_.DisplayName } |
   Select-Object DisplayName, InstallDate, Publisher

For reference on action types, see Microsoft official MSI documentation at CustomAction Table and Custom Action Types.

Remediation options for MSI packages using VBScript

You need to remediate MSI packages with VBScript custom actions. Your options depend on the source of the package:

• Internally packaged MSIs: You may be able to repackage the installer using tools like Orca or Advanced Installer to remove or replace the VBScript custom actions.
• Third-party/independent software vendor (ISV) software: Contact the vendor to request a supported version without VBScript usage. If unavailable, consider isolating or monitoring the app until migration is possible.

VBScript is detected. What next?

With these four detection methods, you gain a comprehensive view of VBScript dependencies across your current Windows platforms. This insight is key to planning effective remediation and aligning with future-proof technologies.

Proactively migrate away from VBScript

Once you identify scripts and processes that depend on VBScript, you’re ready to migrate these dependencies away from VBScript. Please refer to the section “Next steps if my app or website has dependency on VBScript” in VBScript deprecation: Timelines and next steps.

Remember: During the deprecation phase, you can continue using VBScript until it’s completely retired in upcoming OS versions. The deprecation phase is designed to signal the upcoming change and give you time to research and migrate to alternatives.

Proactively disable VBScript on Windows 11

Now that VBScript is enabled by default on Windows 11, version 24H2 and later, you can take additional steps to prepare. Once you confirm that VBScript is unused across these devices with the detection methods above, you should proactively disable it. Use the following Deployment Image Servicing and Management (DISM) command to do so: Dism /Online /Remove-Capability /CapabilityName:VBSCRIPT~~~~ 

Use Microsoft Intune, GPO Startup Scripts, or Microsoft Configuration Manager to deploy this command across your fleet. 

Expect the following consequences of disabling VBScript:

• All processes attempting to use VBScript (e.g., cscript.exe, wscript.exe, embedded Internet Explorer) are blocked. 

• Scripts relying on VBScript fail silently or with errors. 

Important: Please validate capability state and commands in a controlled test environment before wide-scale automation or rollout of this DISM command. The availability and behavior of the VBScript capability vary based on system configurations and different builds. This includes enabling or disabling VBScript via DISM or PowerShell.

In summary, now is the time to start proactively migrating away from VBScript. We hope this guidance helps you detect and remediate usage before VBScript becomes disabled by default in the next deprecation phase. Read VBScript deprecation: Timelines and next steps for additional context and recommendations for more advanced scripting alternatives.

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