為 VBScript 停用做準備:VBA・企業內部工具盤點指南
· 小村 豪 · VBScript, VBA, Excel, PowerShell, Office, Windows, 既有資產活用
摘要
截至 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,整理為具代表性的影響點。
以這張表的形式來思考實務上的優先順序,會比較容易判斷。
| 依賴模式 | 會發生什麼 | 優先度 |
|---|---|---|
從 VBA/Excel 直接執行 .vbs |
Phase 2 之後依裝置組態而定會失敗,Phase 3 原則上會停止 | 高 |
參照 VBScript.RegExp |
在仍保留 Office 2508 之前版本的混合環境中容易出現缺陷 | 高 |
透過 WScript.Shell / Shell 啟動外部處理程序 |
替換之後仍可能被 ASR 或 AppLocker 擋下 | 高 |
| GPO 登入 / 啟動 / 關機腳本、Scheduled Task、Intune 部署腳本 | OS 更新或原則切換時容易一次性大規模故障 | 高 |
| MSI 的 VBScript Custom Action | 在安裝、修復、解除安裝時突然失敗 | 高 |
這個優先順序,是根據 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 呼叫外部處理,且涉及 OS、共用資料夾、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 偏向流程協調。下表是以官方公開的各方案特性為基礎所做的實務估算,工時僅為作者的粗略參考。
| 替代方案 | 適合的處理 | 主要優點 | 主要限制 | 工時估計 | 優先度 |
|---|---|---|---|---|---|
| 原生 VBA | 儲存格操作、報表、簡易檔案輸出、現有巨集的小幅修正 | 容易活用現有資產,使用者訓練成本低 | 對 OS 操作、簽章、部署的管控較弱,容易殘留外部處理程序依賴 | 低 | 高 |
| PowerShell | 檔案操作、共用資料夾、AD、工作排程、安裝程式、運作自動化 | Microsoft 建議的替換對象,可運用簽章與執行原則 | 需調整執行原則、簽章、ASR、AppLocker | 中 | 高 |
| .NET / VSTO | 複雜業務邏輯、長期使用的內部增益集、厚重的 UI 整合 | Office 整合深,可依應用程式單位提供功能 | 以 Windows 為前提,需要 VSTO 執行環境與部署設計 | 高 | 中 |
| Office Scripts | Excel 活頁簿內的定型整理、雲端執行、Power Automate 整合 | 跨平台、易於共用,若以 Excel 為中心較容易整理 | 僅限 Excel,不適合外部 OS 處理,巨量資料有限制 | 中 | 中 |
| Power Automate | 排程執行、核准、檔案到達為起點、與其他服務整合 | 容易將整個流程視覺化,也能嵌入 PowerShell/.NET | 桌面/雲端的運作設計會分開,需要權限設計 | 中~高 | 中 |
把選型的判斷基準畫得更直覺一點,就會像下面這樣。
flowchart TD
A[發現的 VBScript 依賴] --> B{是否在 Excel 活頁簿內完成}
B -->|是| C[原生 VBA]
B -->|是,且重視共用/雲端| D[Office Scripts]
B -->|否| E{是否涉及 OS・檔案・工作排程・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、共用資料夾、工作排程、AD、報表輸出 | 整個批次順利完成,沒有錯誤 |
| 安全性測試 | 簽章、執行原則、AppLocker、App Control、ASR、MOTW | 套用原則後仍能依預期執行/被稽核 |
| 驗收測試 | 操作步驟、所需時間、錯誤時的訊息 | 現場流程被簡化或維持原樣 |
| 相容性・效能測試 | Office 版本差異、大量資料、日誌蒐集負載 | 在混合裝置上仍能維持在可接受的效能範圍內 |
特別容易被忽略的地方如下:
- 從 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 之前,留下「未使用」的證據
風險與對策
| 風險 | 典型症狀 | 對策 |
|---|---|---|
| 殘留隱藏依賴 | 只有部分部門在月初處理時失敗 | 除了靜態搜尋,也並用 Sysmon/AppLocker/App Control 稽核 |
| 安全原則導致替換後仍停止運作 | 已改為 PowerShell,但從 Excel 起動時卻無法運作 | 先在測試環境中把 ASR、AppLocker、App Control 設為稽核模式 |
| 簽章不完整導致只在正式環境失敗 | 在開發者電腦上可以動,但在使用者電腦上被拒絕 | 用 Set-AuthenticodeSignature 與 Get-AuthenticodeSignature 固定簽章運作方式 |
| 在混合 Office 環境中 RegExp 損壞 | 部分裝置出現編譯錯誤 | 將低於 2508 的殘留建立台帳,先以包裝或更新處理 |
| Office Scripts / Flow 變得緩慢 | 大型 CSV 出現逾時 | 進行檔案分割、批次化、同步點設計 |
這張表中的對策,是把 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 端分階段切換時出問題的領域,則應優先切離。
相關文章
共用相同標籤的最新文章。能以相近的主題延伸理解。
用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工,以及錯誤處理設計
本文整理 Power Automate 雲端流程與桌面流程的差異、與 PowerShell / VBA 的分工、授權、錯誤處理、UI 自動化的穩定化,以及認證資訊的安全處理,提供將業務自動化導入正式運作的實務設計指引。
在 C#(CSharp)中執行 PowerShell 並以物件形式接收結果
本文從實務角度整理如何從 C# 啟動 PowerShell,並以 PSObject 而非字串來接收結果,涵蓋 PowerShell SDK、AddCommand、AddParameter、BaseObject、Properties 到錯誤處理。
用 Pester 整備 PowerShell 測試 ── 讓維運腳本不易損壞的實務做法
本文整理用 Pester v5 測試 PowerShell 腳本的實務步驟,涵蓋日期處理、檔案操作、刪除處理、Mock,一路到 CI 執行,協助安全地建立測試基礎。
PowerShell 實用指令集錦 ── 累積日常工作常用的小工具
本文整理 PowerShell 日常工作中常用的實用指令,說明 Measure-Object、Group-Object、Select-String、Compare-Object、Tee-Object、Start-Transcript 等指令的使用場景與時機。
PowerShell 腳本應用 ── 安全地自動化日誌調查、封存與報表化
本文整理用 PowerShell 腳本安全地推進日誌調查、CSV 報表、舊日誌封存、留存紀錄,一直到工作排程器定期執行的實務步驟。
相關主題
與本文相近的主題頁面。以本文為起點,可進一步連到相關服務與其他文章。
Windows 技術主題
彙整 KomuraSoft LLC 關於 Windows 開發、故障調查與既有資產活用文章的主題中心。
與本主題相關的服務
本文連結到以下服務頁面,歡迎從最接近的入口查看。
Windows 應用程式開發
支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。
既有資產活用 & 遷移支援
在持續活用 COM / ActiveX / OCX 資產、原生程式碼與 32 位元相依的同時,協助規劃階段性的遷移。
常見問題
整理諮詢這個主題時常見的問題。
- 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 的替代方案該用什麼?
- 替代方案不是看「能用什麼語言寫」,而是要看打算讓它承擔到哪種程度的責任來選擇。涉及 OS、檔案、共用資料夾、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 軟體開發、技術諮詢與故障調查為中心,在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。