Гид по подготовке VBA и внутренних инструментов к отказу от VBScript

Краткое резюме

В этой статье «внутренние инструменты» — это не только макросы Excel и файлы .vbs. Сюда входят сценарии входа через GPO, задачи, зарегистрированные в Планировщике заданий, скрипты, которые разворачивает Intune, и пользовательские действия VBScript в MSI. Даже если вы сами VBScript не писали, объект тот же: достаточно, чтобы .vbs был зарыт в любом из этих мест.

По состоянию на апрель 2026 года Microsoft опубликовала план поэтапного отказа от VBScript: в Windows 11 версии 24H2 VBScript сначала становится компонентом по требованию (Feature on Demand), включённым по умолчанию, на следующем этапе — отключённым по умолчанию, а на финальном этапе планируется удалить его из будущего выпуска Windows. Иными словами, прежде чем браться за «полное переписывание», действительно нужно сначала «сделать видимым, где именно есть зависимость от VBScript».

По срокам фиксированная дата не опубликована. В материалах Microsoft для VBA Phase 2 (FOD отключён по умолчанию) указана как «примерно 2026–2027 годы», а Phase 3 (удаление) — как «TBD (не определено)». То есть по этой теме нельзя отсчитать дедлайн от конкретной даты. Чем больше устройств на Windows 11 24H2 и новее, тем ближе срок — из этого и стоит исходить, а инвентаризацию лучше закончить заранее.

У VBA и макросов Excel есть, по сути, два реалистичных проблемных момента. Первый — случаи, когда .vbs запускается извне. Второй — обращение к библиотекам VBScript-типа, таким как VBScript.RegExp. Что касается второго, начиная с Office версии 2508 (сборка 19127.20154) класс RegExp включён в VBE по умолчанию, и хотя бы часть зависимости от RegExp мигрировать стало легче. С другой стороны, в смешанных средах, где остаются старые клиенты Office, один и тот же VBA-код легко работает на одних машинах и не работает на других.

Миграцию усложняет не столько сам VBScript, сколько «сопутствующая эксплуатация». Например, даже если заменить код так, чтобы Excel запускал powershell.exe, решение не заработает в продакшне, если оно упирается в правила сокращения поверхности атаки — «блокировка создания дочерних процессов приложениями Office» или «блокировка вызовов Win32 API из макросов Office» — а также в AppLocker, App Control for Business, политику выполнения PowerShell, порядок подписи или контроль макросов у файлов с меткой MOTW. План миграции стоит проектировать не только как конвертацию кода, но и с учётом политик, подписи и аудита логов.

Кратчайший путь — инвентаризация → статическое обнаружение → сбор логов выполнения → выбор замены → тестирование → поэтапное внедрение. В этой статье мы разберём материал именно в таком порядке, с прицелом на практику.

Отметим, что весь код, встречающийся в этой статье, опубликован на GitHub как готовый к запуску и тестированию набор примеров (аудиторские скрипты PowerShell, примеры замены, справочный код VBA и Office Scripts, тесты Pester).

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

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 25, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

Мини-словарь терминов

В следующих главах подряд идут аббревиатуры функций безопасности Windows. Если зафиксировать их здесь, дальше читать проще.

Что именно меняется

Первое, что нужно усвоить: речь не о том, что «VBA будет отменён». Microsoft публикует план только о поэтапном отказе от VBScript, а влияние на проекты VBA концентрируется в основном на выполнении внешних .vbs и обращении к библиотекам семейства VBScript. В Microsoft 365 Developer Blog тоже указывается, что выполнение .vbs из VBA и использование VBScript.RegExp — типичные точки влияния.

Практический порядок приоритетов легче оценить в виде таблицы.

Этот порядок приоритетов — практическое решение, учитывающее план отказа от VBScript на стороне Windows, официальную стратегию обнаружения и спецификации ASR/AppLocker/App Control.

Только с RegExp ситуация немного иная. Начиная с Office версии 2508, класс RegExp по умолчанию входит в VBE, поэтому, если ограничиться сценариями RegExp, «часть зависимости от VBScript теперь можно снять обновлением Office». Однако это не решается автоматически в организациях со старым Office, медленными каналами обновления, смешанными средами или устаревшими образами устройств. Важно включить в реестр и «обновление Office», и «поэтапное переключение Windows» одновременно.

Как проводить инвентаризацию

Одного поиска по имени файла для инвентаризации недостаточно. Рекомендуем как минимум держать следующие десять аспектов в виде колонок по проектам, по инструментам и по бизнес-процессам.

• ① Способ обнаружения мест, зависящих от VBScript Отдельно фиксировать поиск по файлам, анализ кода и анализ логов.
• ② Использование CreateObject / GetObject / Execute / ExecuteGlobal и подобного внутри VBA Зависимость прячется в строках, поэтому статический поиск легко её пропускает.
• ③ Вызовы внешних скриптов из макросов Excel Отдельно отслеживать WScript.Shell, функцию Shell, wscript.exe / cscript.exe, а также .vbs / .js / .ps1.
• ④ Зависимость внутренних пакетных заданий и инструментов от скриптов Включить задачи планировщика, GPO, Intune, рабочие скрипты на общих папках и установщики.
• ⑤ Безопасность, права, подпись, политика AppLocker, App Control for Business, ASR, политика выполнения PowerShell, цифровая подпись, необходимость прав администратора.
• ⑥ Сравнение технологий замены и затрат на миграцию Сравнить нативный VBA, PowerShell, .NET/VSTO, Office Scripts и Power Automate.
• ⑦ План тестирования Разделить модульное, интеграционное, приёмочное тестирование и повторное тестирование после применения политик.
• ⑧ Порядок эксплуатации и откат Явно указать, что нужно вернуть для восстановления и насколько это можно автоматизировать.
• ⑨ Совместимость и производительность Различия версий Office, разрядность 32/64 бит, производительность устройств, нагрузка от сбора логов, тайм-ауты облачных потоков.
• ⑩ Пример практического кейса миграции Заранее подготовить один показательный пример, который можно использовать при объяснении на местах.

Из этих десяти пунктов особенно GPO, задачи планировщика, скрипты развёртывания Intune, пользовательские действия MSI и обнаружение через Sysmon/AppLocker/App Control прямо указаны в официальном руководстве Microsoft как приоритетные зоны.

Если представлять весь ход миграции в виде схемы, курс не собьётся.

flowchart TD
    A[Инвентаризация активов] --> B{Тип зависимости}
    B -->|Выполнение внешнего .vbs| C[Замена на PowerShell или нативный VBA]
    B -->|VBScript.RegExp| D[Переход на встроенный RegExp Office 2508+]
    B -->|GPO / задачи / MSI| E[Исправление централизованных настроек и артефактов развёртывания]
    B -->|Неизвестная / скрытая зависимость| F[Сбор логов выполнения через Sysmon / AppLocker / App Control]
    C --> G[Модульное тестирование]
    D --> G
    E --> H[Интеграционное тестирование]
    F --> H
    H --> I[Пилотное развёртывание в режиме аудита]
    I --> J[Поэтапное отключение VBScript FOD]

Для окружений, где схема не отображается, те же три строки.

1. Найденные при инвентаризации зависимости разложить на четыре корзины: выполнение внешнего .vbs / VBScript.RegExp / централизованные настройки (GPO, задачи, MSI) / неизвестные
2. Для каждой корзины выбрать замену, провести модульные тесты и свести их в интеграционные
3. Развернуть пилот в режиме аудита и, если проблем нет, поэтапно отключать VBScript FOD

Такой порядок заметно сокращает типичную переделку, когда «сначала переписали код, а потом всё упало из-за GPO или ASR».

Практическое обнаружение и примеры кода

Поиск по файлам и выявление конфигурации

В руководстве Microsoft по обнаружению рекомендуется вести рекурсивный поиск .vbs, отдавая приоритет путям с понятным назначением, таким как C:\Users, C:\ProgramData, C:\Scripts, а GPO, задачи планировщика, скрипты развёртывания Intune и пакеты MSI проверять отдельным треком. Мониторинг vbscript.dll через Sysmon эффективен, но мониторинг 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 оказываются зарыты внутри определений задач.

# Извлекаем вызовы 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 позволяет отслеживать загрузку vbscript.dll через Event ID 7, а события разрешения/аудита 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. Отметим, что Shell в VBA по умолчанию асинхронен, поэтому для обработки, требующей контроля порядка, нужно отдельно продумать дизайн потока или логику ожидания.

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]

Те же три строки.

1. Если обработка полностью укладывается внутри книги Excel — нативный VBA. Если важны совместный доступ и облачное выполнение — Office Scripts
2. Если затрагиваются ОС, файлы, задачи, AD — PowerShell
3. Если нужна плотная интеграция UI или долгоживущая надстройка — .NET / VSTO. Если центр — запуск по потоку или согласование — 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».
• Если оставить объявления или вызовы API в VBA, можно упереться в правило ASR «блокировка вызовов Win32 API из макросов Office».
• Тестовые .xlsm / .ps1, распространяемые через загруженные файлы или вложения писем, ведут себя по-разному в зависимости от метки MOTW и состояния подписи.
• Сочетание Office Scripts и Power Automate удобно, но на больших CSV или при большом числе ячеек нужно учитывать тайм-ауты и ограничения на передачу данных.
• Мониторинг Image Load в Sysmon удобен, но если небрежно расширить его на всю компанию, объём логов легко растёт.

Контрольный список процедуры миграции

• Проведён статический поиск .vbs, wscript.exe, cscript.exe, VBScript.RegExp, WScript.Shell, Shell(, ExecuteGlobal
• GPO, задачи планировщика, 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 запускает cleanup.vbs через WScript.Shell, после форматирования CSV проверяет коды через VBScript.RegExp и в конце выводит результат в общую папку. Такая конфигурация получает прямой удар от отказа VBScript, и даже при простой замене на PowerShell она легко снова остановится из-за ASR или порядка подписи.

Без масштаба это трудно положить в обоснование, поэтому рядом стоят условные цифры для объяснения. Реальные значения определяются инвентаризацией, но если переписать план в этой гранулярности, его можно сразу использовать как подложку таблицы работ.

Срок длиннее трудозатрат именно потому, что обработка ежемесячная. Даже если модульные тесты уложатся в один день, «совпадает ли результат с прошлым месяцем» нельзя проверить, не дождавшись конца месяца. Если в инструменте есть ещё и годовая обработка, это ожидание растягивается дальше. В плане отсчитывайте не от трудозатрат, а от моментов, когда результат можно проверить.

В этом случае правильно разбить задачу на части. Проверку, форматирование и агрегацию, полностью укладывающиеся внутри Excel, стоит перенести на нативный VBA или встроенный RegExp Office 2508+. Конвертацию файлов и ввод-вывод в общую папку — перенести на PowerShell. Если триггером служит «прибытие файла» или «ежедневно в заданное время» — перенести на Power Automate. Так можно упорядочить обязанности, которые раньше были втиснуты в один .vbs.

Пример конфигурации после миграции такой.

• Макрос Excel: проверка ввода, работа с экраном, сообщения для пользователя
• PowerShell: нормализация CSV, ввод-вывод в общую папку, вывод логов
• Порядок подписи: подпись Authenticode на скриптах PowerShell
• Безопасность: заранее проверить 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, задачи планировщика, Intune и пользовательские действия MSI.
• Prepare your VBA projects for VBScript deprecation in Windows Самый важный материал с точки зрения VBA. В нём разобраны встраивание RegExp, работа с версиями Office 2508 и новее, а также таблица совместимости.
• Различия между Office Scripts и макросами 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 и сбора событий уровня процессов.
• Шаблоны настройки Sysmon на GitHub sysmon-config от SwiftOnSecurity — качественный стартовый шаблон, а sysmon-modular от Olaf Hartong — модульная и удобная в эксплуатации отправная точка.
• oletools / olevba Хорошо подходят как вспомогательное средство для извлечения исходного кода VBA из файлов Office и обнаружения подозрительных ключевых слов и автоматически выполняющихся макросов.

В заключение: подготовки к отказу от VBScript через «найти VBScript и заменить на PowerShell» недостаточно. Кратчайший и надёжный путь — вести единый реестр, охватывающий обновления Office, анализ кода, конфигурацию эксплуатации, подпись, ASR/AppLocker/App Control и UAT. Области, которые можно спасти обновлением Office, такие как RegExp, спасайте заранее, а области, которые легко ломаются на поэтапном переключении Windows — выполнение .vbs и зависимости от GPO/задач/MSI, — отделяйте в приоритетном порядке.

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Когда VBScript будет отменён?

По состоянию на апрель 2026 года Microsoft опубликовала план поэтапного отказа от VBScript. В Windows 11 версии 24H2 VBScript сначала становится компонентом по требованию (Feature on Demand, FOD), включённым по умолчанию, на следующем этапе — отключённым по умолчанию, а на финальном этапе планируется полностью удалить его из будущего выпуска Windows. Иными словами, прежде чем браться за полное переписывание, действительно нужно сделать другое — сделать видимыми все места, зависящие от VBScript. Пока VBScript существует как FOD, есть возможность повторно включить его как опциональный компонент, но после удаления этой лазейки уже не будет.

Если VBScript отменят, перестанут ли работать VBA и макросы Excel?

Нет, речь не о том, что «VBA будет отменён». Microsoft публикует план только о поэтапном отказе от VBScript, а влияние на проекты VBA сосредоточено в основном на выполнении внешних файлов .vbs и на обращении к библиотекам семейства VBScript, таким как VBScript.RegExp. Обработка, которая напрямую запускает .vbs из VBA/Excel, имеет высокий риск остановки после переключения этапов, и её нужно выявлять в первую очередь. Сценарии входа через GPO, задачи планировщика, скрипты развёртывания Intune и пользовательские действия VBScript в MSI — тоже приоритетные зоны, где легко случается массовый сбой.

Чем заменить VBScript?

Замену выбирают не по тому, «на чём можно написать», а по тому, какую зону ответственности она будет нести. Для обработки, затрагивающей ОС, файлы, общие папки, AD, задачи и установщики, основной кандидат — рекомендуемый Microsoft PowerShell, у которого есть и официальные средства для подписи и политики выполнения. Для операций с ячейками и отчётов, полностью укладывающихся внутри книги Excel, подходит нативный VBA; если важны облачное выполнение и интеграция с Power Automate — Office Scripts; для плотной десктопной интеграции и долгоживущих внутренних надстроек — .NET / VSTO; а для запуска по расписанию или процессов, начинающихся с согласования, — Power Automate. После замены нужно протестировать, включая политики, не останавливается ли решение из-за ASR или AppLocker.

Что делать, если в VBA используется VBScript.RegExp?

Начиная с Office версии 2508 (сборка 19127.20154), класс RegExp входит в VBE по умолчанию, поэтому, если ограничиться сценариями с RegExp, часть зависимости от VBScript теперь можно снять обновлением Office. Однако в смешанных средах, где остаются старые клиенты Office, один и тот же VBA-код легко работает на одних машинах и не работает на других. Если остаётся хотя бы одна машина с версией ниже 2508, новый синтаксис упирается в барьер совместимости при компиляции, поэтому версии Office и каналы обновления нужно свести в реестр, оценить остаток старых версий и заранее решить, каким будет курс миграции — «новый синтаксис», «старый синтаксис» или «ветвящаяся обёртка».

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.