Суть проблемы
Сегодня 12 октября 2026 года AskWoody напомнил об одном из самых заметных «тихих» сроков в мире Windows: Microsoft поэтапно выводит VBScript, а следующий серьёзный удар по совместимости ожидается примерно в 2026–2027 годах. Почти три десятилетия этот язык держал на себе огромное число административных сценариев, логон-скриптов и старых утилит, и многие администраторы даже не помнят, где именно он у них используется.
Хорошая новость в том, что время на подготовку ещё есть. Плохая: чем позже вы начнёте искать зависимости, тем болезненнее будет момент, когда компонент перестанет включаться сам.
Три фазы вывода
Об отказе от VBScript Microsoft объявила в октябре 2023 года, а подробный график опубликовала в мае 2024 года в Windows IT Pro Blog.
| Фаза | Что происходит | Срок |
|---|---|---|
| 1 | VBScript становится опциональным компонентом (Feature on Demand), но остаётся включённым по умолчанию | идёт сейчас, начиная с Windows 11 24H2 и Windows Server 2025 |
| 2 | Компонент отключается по умолчанию, чтобы работать, его нужно включить вручную | ориентир Microsoft: 2026–2027 годы |
| 3 | Полное удаление из Windows, исчезают связанные библиотеки и поддержка | дата не объявлена |
По наблюдению участника сообщества Windows Server Insiders, Microsoft планирует отключить компонент по умолчанию в ближайшем крупном релизе, который ожидается осенью 2027 года. Это не официальное заявление, а оценка по инсайдерским материалам, поэтому ориентироваться стоит на общий коридор 2026–2027. Важно понимать: точная дата второй фазы привязана к релизу Windows, а не к календарной дате, поэтому возможны сдвиги.
Что может сломаться
Скрипты и логон-сценарии. Файлы .vbs, .vbe, .wsf, запускаемые через wscript.exe и cscript.exe: логон-скрипты в групповых политиках, задачи планировщика, инвентаризация, самописные утилиты.
Штатные VBS-инструменты. В перечне популярных сценариев, которые до сих пор опираются на VBScript, разбор woshub называет управление активацией Windows slmgr.vbs, активацию Office ospp.vbs, скрипты удаления Office (Offscrub) и утилиту отображения информации о системе Bginfo. При этом сама Microsoft полноценных замен для всех таких инструментов пока не предоставила.
Серверные роли и продукты. В материале участника сообщества Windows Server Insiders, написанном в сентябре 2026 года, как потенциально затронутые перечислены управление устаревшими расширениями IIS, сценарии развёртывания и настройки WSUS, а также продукты System Center, включая средства работы с образами и VAMT 3. Это оценка автора, а не официальный список Microsoft, но направление для проверки она задаёт верное.
VBA в Office. Сам VBA как язык макросов остаётся, но есть конкретные ограничения. Вызов .vbs-скриптов из VBA перестанет поддерживаться, а ссылки на библиотеку регулярных выражений VBScript RegExp перестанут работать, если Office не обновлён до поддерживаемой сборки. Начиная с версии Office 2508 (сборка 19127.20154) классы RegExp уже встроены в VBA по умолчанию. Подробности есть в блоге Microsoft 365 для разработчиков.
MSI-пакеты с VBScript Custom Actions. Отдельная категория скрытых зависимостей кастомные MSI-пакеты, в которых используются VBScript Custom Actions (типы 6, 38, 50). Они могут годами работать незаметно, пока VBScript доступен, и сломаться в самый неподходящий момент. Microsoft рекомендует проверить корпоративные MSI-пакеты на наличие таких действий заранее.
Как проверить своё окружение
1. Состояние компонента на машине.
Выполните команду: Get-WindowsCapability -Online -Name "VBSCRIPT*"
Если статус Installed, VBScript сейчас доступен. Важно: точное имя компонента всегда берите из вывода этой команды оно может отличаться в разных сборках. Именно это имя подставляйте в команды Remove-WindowsCapability и Add-WindowsCapability ниже.
2. Поиск скриптов на диске.
Выполните команду: Get-ChildItem -Path C:\ -Include .vbs,.vbe,.wsf,.wsh -Recurse -ErrorAction SilentlyContinue | Select-Object FullName, LastWriteTime
3. Задачи планировщика, которые вызывают скриптовые движки.
Выполните команду: Get-ScheduledTask | Where-Object { $_.Actions.Execute -match 'wscript|cscript' } | Select-Object TaskName, TaskPath
4. Логон-скрипты и политики. Проверьте каталог SYSVOL на контроллере домена на наличие .vbs-файлов и просмотрите групповые политики на настройки скриптов входа и выхода. Именно здесь чаще всего находятся забытые зависимости.
5. Мониторинг фактических запусков. Статический поиск файлов не покажет, что реально используется. Включите аудит создания процессов (событие 4688) или настройте встроенный Sysmon на события создания процессов с образом wscript.exe или cscript.exe. Дополнительно Microsoft рекомендует отслеживать Event ID 7 (Image Load) для загрузки библиотеки vbscript.dll — это точнее, чем просто отслеживание wscript.exe и cscript.exe, потому что VBScript может загружаться и из других процессов. Через несколько недель у вас будет реальный список того, что запускается.
6. Предупреждения в инсайдерских сборках. Участник сообщества описал в инсайдерских сборках предупреждение VBScriptDeprecationAlert с идентификатором события 4096, которое сообщает, что система использует VBScript, и указывает процесс-виновник. В стабильных сборках это поведение пока не подтверждено, но в инсайдерских стендах за ним стоит следить.
Пробное отключение на тестовой машине
Пока VBScript остаётся опциональным компонентом, его можно отключить на пилотной машине и посмотреть, что перестанет работать. Подставьте точное имя компонента, полученное из Get-WindowsCapability.
Для отключения выполните: Remove-WindowsCapability -Online -Name "VBSCRIPT~~~~"
Для возврата обратно выполните: Add-WindowsCapability -Online -Name "VBSCRIPT~~~~"
Это удобный способ проверить готовность до того, как отключение станет поведением по умолчанию. Но запас прочности временный: после третьей фазы, когда библиотеки удалят из системы, такой возможности отката уже не будет. Более того, на некоторых сборках Windows 11 25H2 (например, build 26200.9445) VBScript уже фактически отсутствует: Get-WindowsCapability показывает State: NotPresent, а Add-WindowsCapability рапортует об успехе, но ничего не меняет — payload удалён. Реальный пример такой поломки — приложение Hermes Agent, у которого задача в планировщике создаётся, но .vbs не выполняется, потому что движок отсутствует. Это значит, что для части пользователей третья фаза наступила раньше официального срока.
Куда переносить скрипты
Для большинства административных задач естественной заменой остаётся PowerShell. Это уже современный, поддерживаемый и безопасный вариант, о миграции на актуальную версию мы писали в статье про Microsoft Graph и PowerShell 7.
Для макросов Office с регулярными выражениями достаточно обновить клиент до сборки со встроенными классами RegExp. Для классического ASP и других узких сценариев решение придётся подбирать отдельно — на этом этапе главное хотя бы знать, что такие зависимости у вас есть.
Замена slmgr.vbs. Для управления активацией Windows Microsoft рекомендует модуль OSLicense для PowerShell. Он уже доступен на Windows 11 с обновлением KB5120998 (август 2026), а на Windows Server появится в следующем крупном релизе. Если вы используете slmgr.vbs для активации или проверки лицензий, стоит начать миграцию на OSLicense уже сейчас.
Что ещё нужно знать
Что произойдёт, если ничего не делать?
Пока действует первая фаза, ничего не изменится. Когда наступит вторая, скрипты начнут падать с ошибкой, если компонент не включить вручную, и на каждом устройстве придётся это делать отдельно или раскатывать включение централизованно.
VBA-макросы Excel и Word тоже перестанут работать?
Нет, VBA остаётся. Затронуты только макросы, которые вызывают .vbs-файлы или подключают библиотеку VBScript RegExp.
Можно ли будет включить VBScript обратно после второй фазы?
Да, пока компонент существует в системе как опциональный, его можно включить через Параметры или PowerShell. После третьей фазы, когда компонент удалят, такой возможности не будет. Учтите, что на некоторых сборках 25H2 это уже невозможно.
Точная дата известна?
Нет. Microsoft называет ориентир 2026–2027 годы для второй фазы и пока не объявила дату третьей. Но сроки уже не абстрактные, а измеряются месяцами.
В сухом остатке
VBScript уходит не завтра, но и не в далёком будущем. Самое полезное, что можно сделать сейчас, это составить реальный список зависимостей: найти файлы, проверить планировщик и SYSVOL, просканировать корпоративные MSI-пакеты на VBScript Custom Actions, а затем несколько недель наблюдать фактические запуски wscript.exe, cscript.exe и загрузку vbscript.dll. С таким списком перенос на PowerShell превращается в обычную плановую задачу, а не в аврал после очередного обновления.
