为 VBScript 弃用做准备：VBA·企业内部工具排查指南

摘要

截至 2026 年 4 月，Microsoft 已公开将分阶段弃用 VBScript 的方针：在 Windows 11 版本 24H2 中，首先会以 Feature on Demand 的形式默认启用，下一阶段默认禁用，最终阶段则计划在未来的 Windows 版本中移除。也就是说，现在真正该做的事，并不是「全面重写」，而是先「把哪些地方依赖 VBScript 弄清楚、可视化」。

VBA、Excel 宏在实务中要面对的重点大致有两个。一个是外部执行 .vbs 的情况，另一个是像 VBScript.RegExp 这类 VBScript 系列库的引用。就后者而言，自 Office 版本 2508（Build 19127.20154）起，RegExp 类已标准内置于 VBE 中，至少让一部分 RegExp 依赖变得更容易迁移。但另一方面，在仍保留旧版 Office 客户端的混合环境中，同一份 VBA 在有些设备上能运行、有些设备上不能运行的情况也会变得容易发生。

让迁移变得困难的，与其说是 VBScript 本身，不如说是「周边的运作方式」。举例来说，即使把 Excel 改成调用 powershell.exe，只要碰上攻击面减少规则中的「阻止所有 Office 应用程序创建子进程」或「阻止 Office 宏调用 Win32 API」、AppLocker、App Control for Business、PowerShell 执行策略、签名运作，以及带有 MOTW 标记文件的宏控制，在生产环境中就无法运行。迁移方案不能只考虑代码转换，还必须把策略、签名与日志审计一并纳入设计。

最快的路径是 资产排查 → 静态检测 → 执行日志采集 → 选定替代方案 → 测试 → 分阶段推广。本文将按照这个顺序，从实务角度进行梳理。

另外，本文出现的代码已整理成一套可运行、可测试的示例（PowerShell 审计脚本、替换示例、VBA 与 Office Scripts 的参考代码、Pester 测试），发布在 GitHub 上。

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

整理有哪些变化

首先要明确的是，这次的重点并不是「VBA 将被弃用」。Microsoft 公开的仅限于 VBScript 的分阶段弃用，对 VBA 项目的影响主要集中在 外部 .vbs 的执行 与 VBScript 系列库的引用 上。Microsoft 365 Developer Blog 也把 VBA 执行 .vbs、以及使用 VBScript.RegExp，整理为具有代表性的影响点。

用下面这张表来考虑实务上的优先级，会更容易判断。

这个优先级，是根据 Windows 端的 VBScript 弃用计划、官方的检测策略，以及 ASR/AppLocker/App Control 规范所做出的实务判断。

只有 RegExp 的情况稍有不同。自 Office 版本 2508 起，VBE 端已标准内置 RegExp 类，因此 仅就 RegExp 用途而言，「部分 VBScript 依赖已可通过 Office 更新解决」。不过，这并不意味着在旧版 Office、更新渠道较慢、混合环境，或残留旧设备镜像的组织中会自动解决。必须把「Office 更新」与「Windows 的分阶段切换」两者都纳入台账，这一点很重要。

盘点的推进方式

仅靠文件名搜索并不足以完成排查。建议至少以下列 10 个维度，按项目、按工具、按业务建立为列来管理。

• ① VBScript 依赖位置的检测方法 分别记录文件搜索、代码分析、日志分析。
• ② VBA 内使用 CreateObject / GetObject / Execute / ExecuteGlobal 等 依赖对象会藏在字符串里，容易造成静态搜索的遗漏。
• ③ Excel 宏中的外部脚本调用 分别跟踪 WScript.Shell、Shell 函数、wscript.exe / cscript.exe、.vbs / .js / .ps1。
• ④ 企业内部批处理与工具的脚本依赖 纳入 Scheduled Task、GPO、Intune、共享文件夹上的运维脚本、安装程序。
• ⑤ 安全、权限、签名、策略 AppLocker、App Control for Business、ASR、PowerShell 执行策略、数字签名、是否需要管理员权限。
• ⑥ 替代技术与迁移成本比较 以原生 VBA、PowerShell、.NET/VSTO、Office Scripts、Power Automate 进行比较。
• ⑦ 测试计划 分别区分单元、集成、用户验收，以及应用策略后的重新测试。
• ⑧ 运维流程与回滚 明确写出要回滚什么才能恢复，以及自动化的程度。
• ⑨ 兼容性与性能 Office 版本差异、32/64bit、设备性能、日志采集负载、云端流程超时。
• ⑩ 示例迁移案例研究 先做出一个可用于向现场说明的代表性案例。

在这 10 个项目中，GPO、Scheduled Task、Intune 部署脚本、MSI Custom Action，以及通过 Sysmon/AppLocker/App Control 进行检测，都在 Microsoft 的官方指南中被明确列为重点领域。

用下面这张图来思考整体迁移流程，方向就不容易跑偏。

flowchart TD
    A[资产排查] --> B{依赖类型}
    B -->|外部执行 .vbs| C[替换为 PowerShell 或原生 VBA]
    B -->|VBScript.RegExp| D[整理为 Office 2508+ 的内置 RegExp]
    B -->|GPO / 任务 / MSI| E[修正集中管理设置与部署产物]
    B -->|不明·隐藏依赖| F[通过 Sysmon / AppLocker / App Control 采集执行日志]
    C --> G[单元测试]
    D --> G
    E --> H[集成测试]
    F --> H
    H --> I[以审计模式进行试点推广]
    I --> J[分阶段禁用 VBScript FOD]

按照这个顺序处理，可以大幅减少「先重写完，结果后来又被 GPO 或 ASR 拦下」这种典型的返工情况。

实务检测与代码示例

文件搜索与配置信息排查

Microsoft 的检测指南建议，优先针对用途明确的路径（如 C:\Users、C:\ProgramData、C:\Scripts）递归搜索 .vbs，并将 GPO、Scheduled Task、Intune 部署脚本、MSI 安装包另外分开确认。Sysmon 对 vbscript.dll 的监控很有效，但 Image Load 监控的日志量与运维负担较大，应先在小规模试点中验证。

# 大致扫描设备与共享文件夹上的脚本依赖
$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

接下来要扫描任务计划程序。相比文件，企业内部工具更常见的是 wscript.exe / cscript.exe / .vbs 藏在任务定义里。

# 从 Scheduled Task 中提取 VBScript 调用
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 代码分析

VBA 这一侧，光看引用设置是不够的。CreateObject 与 GetObject 可以用字符串来实例化 COM，因此即使引用设置中没有出现任何东西，代码仍可能存在依赖。Microsoft 的 VBA/Office 文档中，也把 CreateObject 说明为创建 COM 对象的基本方式，FileSystemObject 与 Scripting.Dictionary 也是以这种方式使用。此外，要通过程序读取 VBA 项目，需要启用「信任对 VBA 项目对象模型的访问」。

' 前提:
'  - 在[信任中心]启用「信任对 VBA 项目对象模型的访问」
'  - 受保护的项目需另外导出源代码或与负责人确认
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

这个扫描至少会抓出 CreateObject("VBScript.RegExp")、WScript.Shell、Shell(、.vbs、ExecuteGlobal。尤其是像 Execute / ExecuteGlobal 这类字符串执行，因为依赖对象与要执行的代码都是动态拼装出来的，特别容易造成排查遗漏。

日志分析

到了查看执行日志的阶段，Sysmon + AppLocker/App Control 的组合相当强大。Sysmon 可以通过 Event ID 7 跟踪 vbscript.dll 的加载，AppLocker 针对脚本/MSI 的允许与审计事件，可以在事件查看器中确认。以审计模式运行 App Control for Business，脚本与 MSI 会记录在 AppLocker\MSI and Script 日志中。

# Sysmon：确认加载了 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：确认脚本、MSI 相关的审计日志
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/MSI and Script" -MaxEvents 2000 |
  Where-Object { $_.Id -in 8005, 8006 } |
  Select-Object TimeCreated, Id, Message

这里重要的是，不仅要采集「正在运行」的日志，也要采集「若处于审计模式原本会被拦截」的日志。AppLocker 的审计事件与 App Control 的审计模式，非常适合用于在正式环境中拦截之前先做安全确认。

最小替换示例

如果只是调用外部 .vbs 来输出 CSV 这种程度的处理，最快的做法是先用原生 VBA 替换。

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

如果需要从 Excel 调用外部处理，且涉及操作系统、共享文件夹、AD、安装程序、日志采集，改用 PowerShell 会更现实。Microsoft 建议把 PowerShell 作为 VBScript 的替代方案，PowerShell 端也有执行策略、签名、Authenticode 验证等官方的运作方式。另外要注意的是，VBA 的 Shell 默认是异步的，因此需要顺序控制的处理，需要另外设计流程或等待机制。

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

# 添加并验证签名
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Normalize.ps1 -Certificate $cert
Get-AuthenticodeSignature -FilePath .\Normalize.ps1

如果 Excel 的处理 完全在工作簿内部就能完成整理、汇总、转换，Office Scripts 也是有力的选择。Office Scripts 是面向 Excel 设计的，适合云端、跨平台，以及与 Power Automate 集成的场景。

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);
  }
}

替代技术的选型

替代方案不应该看「能用什么语言写」，而是要依 打算让它承担到什么程度的职责 来选择。PowerShell 偏向 Windows、文件、任务、安装程序；原生 VBA 偏向 Office 内部；Office Scripts 偏向 Excel 工作簿处理；VSTO/.NET 偏向厚重的桌面集成；Power Automate 偏向编排协调。下表是以官方公开的各方案特性为基础所做的实务估算，工时仅为作者的粗略参考。

把选型的判断依据画得更直观一点，就会像下面这样。

flowchart TD
    A[发现的 VBScript 依赖] --> B{是否在 Excel 工作簿内完成}
    B -->|是| C[原生 VBA]
    B -->|是，且重视共享/云端| D[Office Scripts]
    B -->|否| E{是否涉及操作系统·文件·任务·AD}
    E -->|是| F[PowerShell]
    E -->|否| G{是否是厚重 UI 集成或长期使用的加载项}
    G -->|是| H[.NET / VSTO]
    G -->|以流程触发或审批为主| I[Power Automate]

只针对 RegExp 补充一点：如果环境中 只存在 Office 版本 2508 及以后，整理成 Dim re As RegExp / Set re = New RegExp 相当有效。但只要还有一台设备是旧版 Office，这段代码就会碰到编译兼容性的问题。在混合环境中，应先决定 迁移方针要采用「新语法」「旧语法」还是「分支包装器」。

测试与运维

测试计划

VBScript 迁移光靠单元测试是不够的。除非在 安全策略生效、等同生产环境的条件 下重新测试，替换后的 PowerShell 或 .NET 脚本很可能会因为别的原因而停止运行。Microsoft 的资料中，也把 PowerShell 执行策略、AppLocker、App Control 审计模式、ASR、带有 MOTW 标记的宏控制，分别当作独立的规则来处理。

特别容易被忽略的地方如下：

• 从 Excel 启动 PowerShell 的替换做法，可能碰到 ASR 的「阻止所有 Office 应用程序创建子进程」。
• 若保留 VBA 的声明或 API 调用，可能碰到 ASR 的「阻止 Office 宏调用 Win32 API」。
• 通过下载文件或邮件附件分发的测试用 .xlsm / .ps1，其行为会因 MOTW 与签名状态而有所不同。
• Office Scripts 与 Power Automate 的组合虽然方便，但面对大型 CSV 或大量单元格时，需注意超时与数据传输限制。
• Sysmon 的 Image Load 监控虽然好用，但若在整个公司范围内随意扩大，日志量容易大幅增加。

迁移步骤检查清单

• 已针对 .vbs、wscript.exe、cscript.exe、VBScript.RegExp、WScript.Shell、Shell(、ExecuteGlobal 进行静态搜索
• 已将 GPO、Scheduled Task、Intune、共享文件夹运维、MSI 分开系统排查
• 已将 Office 版本与更新渠道建立台账，掌握低于 2508 的残留状况
• 已在「原生 VBA / PowerShell / .NET / Office Scripts / Power Automate」中确定替换方案
• 已确定签名方针与证书分发方针
• 已测试 AppLocker / App Control / ASR / 执行策略的影响
• 已在试点部门采集审计日志
• 已将回滚流程文档化
• 已在禁用 VBScript FOD 之前，留下「未使用」的依据

风险与对策

这张表中的对策，是把 Microsoft 官方资料中设计上的限制，落实到企业内部运维中的结果。

回滚不能只靠「把代码还原」。至少要一并考虑 还原部署产物的旧版本、回滚策略、保留重新启用可选功能的空间、持续采集日志。只要 VBScript 还以 FOD 的形式存在，就有机会按照 Phase 2 的说明以可选功能重新启用；但一旦在 Phase 3 被移除，这条退路就不存在了。

迁移案例研究

以典型案例来说，假设是 财务部门的月度汇总宏。目前的状况是：Excel 宏通过 WScript.Shell 启动 cleanup.vbs，在 CSV 整理后用 VBScript.RegExp 验证代码，最后输出到共享文件夹。这种架构会直接受到 VBScript 弃用的冲击，而且即便简单替换成 PowerShell，也很容易再次被 ASR 或签名运作卡住。

在这个案例中，正确的做法是拆开来考虑。能在 Excel 内部完成的验证、格式化、汇总，移到原生 VBA 或 Office 2508+ 的内置 RegExp。 文件转换或对共享文件夹的输入输出，移到 PowerShell。 如果触发点是「文件到达」或「每天固定时间」，就移到 Power Automate。 这样一来，就能把原本挤在一个 .vbs 里的职责梳理清楚。

迁移后的架构示例如下：

• Excel 宏：输入检查、界面操作、用户提示消息
• PowerShell：CSV 规范化、共享文件夹 I/O、日志输出
• 签名运作：为 PowerShell 脚本添加 Authenticode 签名
• 安全：先以审计模式确认 AppLocker/App Control，判断是否需要 ASR 例外
• 未来扩展：Excel 内部的定型处理，分阶段迁移到 Office Scripts

这种做法的优点是，能提早切断对 VBScript 运行时的依赖，又不必一次性重做全部。RegExp 由 Office 更新吸收，运维脚本迁移到 PowerShell，业务流程迁移到 Power Automate——按职责拆分之后，故障的影响范围也会缩小。

推荐工具与参考链接

• 本文的完整示例代码（PowerShell 审计脚本与 Pester 测试） https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide

官方资料建议按下列顺序阅读。

• VBScript deprecation: Timelines and next steps 确认整体路线图与各 Phase 含义的起点。
• VBScript deprecation: Detection strategies for Windows 涵盖 Sysmon、GPO、Scheduled Task、Intune、MSI Custom Action 的实务检测指南。
• Prepare your VBA projects for VBScript deprecation in Windows 从 VBA 角度来看最重要的一份资料，整理了 RegExp 内置化、Office 2508 以后的处理方式，以及兼容性表。
• Office 脚本与 VBA 宏的区别 用来判断以 Excel 为中心的处理是否该迁移到 Office Scripts 的资料。
• about_Execution_Policies / about_Signing / Set-AuthenticodeSignature / Get-AuthenticodeSignature PowerShell 迁移时，签名与执行策略运作的基本套件。
• Using Event Viewer with AppLocker / Use audit events to create App Control policy rules / 使用 App Control for Business 应用脚本策略 理解审计模式设计、事件采集、脚本应用行为时所需要的资料。
• 攻击面减少规则参考 用来确认 Office 子进程、Win32 API、JS/VBS 下载执行的拦截规则。
• 来自互联网的宏，在 Office 中默认会被阻止 理解测试分发或生产上线时 MOTW 问题的必读资料。

作为辅助工具，以下几项在实务中经常用到。

• Sysmon 监控 vbscript.dll 加载与采集进程相关事件的基础工具。
• GitHub 上的 Sysmon 配置模板 SwiftOnSecurity 的 sysmon-config 是质量很高的初始模板，Olaf Hartong 的 sysmon-modular 则是模块化、便于运维的起点。
• oletools / olevba 适合用来从 Office 文件中提取 VBA 源代码，辅助检测可疑关键字与自动执行的宏。

结论是，为 VBScript 弃用做准备，光靠「找出 VBScript 并换成 PowerShell」是不够的。把 Office 更新、代码分析、运维架构、签名、ASR/AppLocker/App Control、UAT 全部纳入同一份台账来管理，才是最快也最可靠的做法。像 RegExp 这种可以靠 Office 更新解决的领域，应尽早解决；而像 .vbs 执行、GPO/任务/MSI 依赖这类容易在 Windows 端分阶段切换时出问题的领域，则应优先切离。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

VBScript 什么时候会被弃用？

截至 2026 年 4 月，Microsoft 已公开将分阶段弃用 VBScript 的方针。在 Windows 11 版本 24H2 中，首先会以 Feature on Demand（FOD）的形式默认启用，下一阶段默认禁用，最终阶段则计划在未来的 Windows 版本中移除。也就是说，现在真正该做的事，并不是先全面重写，而是先把哪些地方依赖 VBScript 弄清楚、可视化。只要 VBScript 还以 FOD 形式存在，就有机会以可选功能重新启用；但一旦被移除，这条退路就不存在了。

VBScript 被弃用之后，VBA 或 Excel 宏也会无法使用吗？

不会。这次的重点并不是「VBA 将被弃用」。Microsoft 公开的仅限于 VBScript 的分阶段弃用，对 VBA 项目的影响主要集中在外部 .vbs 文件的执行，以及像 VBScript.RegExp 这类 VBScript 系列库的引用上。从 VBA / Excel 直接执行 .vbs 的处理，在阶段切换之后停止运行的风险较高，是应优先排查的对象。GPO 登录脚本、Scheduled Task、Intune 部署脚本、MSI 的 VBScript Custom Action，也都是容易发生批量性故障的重点领域。

VBScript 的替代方案该用什么？

替代方案不是看「能用什么语言写」，而是要看打算让它承担到什么程度的职责来选择。涉及操作系统、文件、共享文件夹、AD、任务、安装程序的处理，Microsoft 推荐的首选是 PowerShell，也有官方的签名与执行策略运用方式。若只在 Excel 工作簿内部完成的单元格操作或报表输出，适合用原生 VBA；若重视云端执行或与 Power Automate 集成，适合用 Office Scripts；厚重的桌面集成或长期使用的内部加载项，适合用 .NET / VSTO；以计划任务执行或审批流程为起点的，适合用 Power Automate。替换之后是否会被 ASR 或 AppLocker 拦截，也需要连同策略一起测试。

在 VBA 中使用 VBScript.RegExp 的情况该怎么处理？

自 Office 版本 2508（Build 19127.20154）起，RegExp 类已标准内置于 VBE 中，因此仅就 RegExp 用途而言，部分 VBScript 依赖已可通过 Office 更新解决。不过，在仍保留旧版 Office 客户端的混合环境中，同一份 VBA 在有些设备上能运行、有些设备上不能运行的情况会变得容易发生。只要还有一台设备的 Office 版本低于 2508，新语法就会碰到编译兼容性的问题，因此应先将 Office 版本与更新渠道建立台账掌握残留状况，并先决定迁移方针要采用「新语法」「旧语法」还是「分支包装器」。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。