Exchange Setup зависает на проверке готовности: WMI и антивирусный драйвер klam.sys

Кратко: На фоне выпуска Microsoft обновления для Exchange Server, закрывающего уязвимость CVE-2026-62911, потребовалось срочно его установить. И вот кратко, что на одной из установок из этого вышло: если апгрейд или установка Exchange Server часами висит на этапе «Подготовка установки» или «Проверка готовности», а в логе ExchangeSetupLogs\ExchangeSetup.log встречаются System.Management.ManagementException: Вызов отменен с таймаутом ровно в 20 минут — велика вероятность, что дело не в самом Exchange, а в WMI-запросах к классу Win32_Service, которые блокирует антивирусный драйвер на сервере. Ниже — как это диагностировать и решить, на реальном кейсе с Kaspersky. Дальше подробно…

Симптомы

Апгрейд Exchange (2019 → SE или между CU) может идти ощутимо медленнее, чем обычно, с характерными признаками:

• этап «Проверка готовности» (Rule:ServicesAreDisabled) занимает не секунды, а десятки минут;
• этап включения ролевых служб перед установкой (ServiceControl.ps1) обрабатывает каждую службу с паузой в 15-20 минут, при десятках служб это выливается в 6-8 часов;
• в ExchangeSetup.log многократно встречается:

System.Management.ManagementException: Вызов отменен
   в System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
   в Microsoft.Exchange.Management.Deployment.WMIProvider.Run(String wmiQuery)
[Duration:00:20:00...]

• при попытке прервать Setup часть служб (например, сторонний агент бэкапа) не может штатно остановиться в отведённое время.

Почему это происходит

Rule:ServicesAreDisabled и ServiceControl.ps1 внутри Setup обращаются к состоянию служб не напрямую через SCM, а через WMI-класс Win32_Service. Если на этот класс в пространстве имён root\cimv2 навешана блокировка — каждый такой запрос виснет до истечения внутреннего таймаута (20 минут для проверки готовности, около 16 минут — для другого внутреннего вызова у ServiceControl.ps1), и только потом падает с ошибкой либо продолжает выполнение.

Прямая проверка симптома, без запуска Setup:

powershell

Measure-Command { Get-CimInstance Win32_Service -Filter "Name='MSDTC'" }

Если это виснет на минуты — причина не в Exchange.

Полезно при этом, что другие классы WMI могут отвечать нормально:

powershell

Measure-Command { Get-CimInstance Win32_OperatingSystem }   # обычно быстро
Measure-Command { Get-Service MSDTC }                        # SCM напрямую, тоже быстро

Если Get-Service/sc.exe queryex отвечают мгновенно, а именно Get-CimInstance Win32_Service виснет — проблема локализована в конкретном WMI-провайдере (CIMWin32), а не в целостности репозитория (winmgmt /verifyrepository при этом честно покажет «База данных WMI согласована» — репозиторий тут ни при чём).

Как найти виновника

1. Посмотрите журнал Microsoft-Windows-WMI-Activity/Operational — там будет видна операция ExecQuery ... Win32_Service с кодом ResultCode = 0x80041032 (WBEM_E_CALL_CANCELLED).
2. Найдите процесс-хост провайдера:

powershell

Get-CimInstance Win32_Process -Filter "Name='WmiPrvSE.exe'"

Через Process Explorer (запущенный от администратора) откройте свойства каждого WmiPrvSE.exe → вкладка WMI Providers — ищите тот, где числится CIMWin32/CIMWin32a.
3. Попробуйте открыть свойства (Image) этого процесса. Если видите [Error opening process] и User: <access denied> — это Protected Process (AM-PPL), а не обычное зависание. Обычный Stop-Process -Force на такой процесс отвечает «Отказано в доступе» даже под администратором — это ожидаемое поведение защищённых процессов, а не баг.

Решение

Защиту процессов навешивает не пользовательский антивирусный сервис, а драйвер ядра антивирусного продукта. Отключать нужно именно его, а не гасить AV-службы из панели управления или снимать «Самозащиту» в интерфейсе — эти настройки на уже созданный защищённый процесс не действуют, и часто не действуют даже на новые процессы без перезагрузки.

Пример для Kaspersky — антируткит-драйвер klam.sys:

powershell

sc.exe query klam
sc.exe config klam start= disabled
Restart-Computer

После перезагрузки, до запуска Setup, проверьте:

powershell

Measure-Command { Get-CimInstance Win32_Service -Filter "Name='MSDTC'" }

Если ответ пришёл за миллисекунды — путь открыт. Можно смело идти на проверку готовности:

Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /TestOnly

и затем на полноценный апгрейд.

После апгрейда — не забудьте вернуть защиту

Отключённый антивирусный драйвер — это окно без важного слоя защиты, поэтому держать его выключенным дольше, чем нужно, не стоит:

powershell

sc.exe config klam start= system
Restart-Computer

и убедитесь, что после этого WMI по-прежнему отвечает быстро (в нашем случае так и было — конфликт проявлялся только на самом старте нового процесса-провайдера сразу после каждой перезагрузки в момент, когда драйвер был активен, а не постоянно).

Что стоит запомнить

• Если Exchange Setup «висит без причины» — прежде чем грешить на сам продукт, проверьте отклик Win32_Service независимым тестом.
• Антивирусные продукты часто защищают процессы драйвером ядра, а не пользовательской службой — «выключить защиту» в интерфейсе может не сработать буквально, потому что защита реализована ниже уровнем.
• Любое изменение, связанное со снятием защиты процессов, требует перезагрузки, чтобы новые процессы создавались уже без AM-PPL — снятие настройки «на лету» на уже созданный процесс не действует.
• Не забудьте вернуть все временные отключения после успешного апгрейда — и антивирусный драйвер, и антиспам-агенты, и остановленные сторонние службы.