Microsoft Windows Hotpatch потребует перезагрузки в сентябре 2026 года

Hotpatch долгое время решал одну из самых неприятных задач администрирования Windows: устанавливать значительную часть исправлений безопасности без остановки рабочих систем. Для серверов это особенно удобно, поскольку обновление можно провести без привычного окна простоя. Однако сентябрьский цикл 2026 года нарушит эту схему. Устройства с включённым Hotpatch получат обновление, для завершения которого потребуется перезагрузка.

Причина не в том, что Hotpatch внезапно отключается. Microsoft продолжает считать устройства участниками соответствующего цикла. Проблема в самом составе сентябрьского пакета: это стандартное обновление с изменениями системных компонентов, которые невозможно полностью применить к работающей системе. После установки потребуется перезапуск, чтобы новые компоненты загрузились и заменила работающие версии.

Для администратора это означает довольно необычную ситуацию. Политика Hotpatch может оставаться включённой, устройство продолжает находиться в соответствующей группе, но привычное ожидание "обновление установится без перезапуска" в сентябре больше не работает. Поэтому окно обслуживания теперь нужно планировать заранее, особенно если речь идёт о рабочих станциях пользователей, терминальных серверах или системах, где простой даже на несколько минут заметен.

Сентябрьский пакет меняет привычный цикл Hotpatch без отключения устройств

Обычная модель Hotpatch строится вокруг двух типов обновлений. Baseline-обновление содержит изменения, которые требуют перезагрузки. Hotpatch выпускается между такими обновлениями и предназначен прежде всего для исправлений безопасности, которые можно применить без перезапуска. В документации Microsoft прямо указано, что baseline требует перезагрузки, а hotpatch обычно устанавливается без неё.

Именно поэтому внезапное появление обязательной перезагрузки в сентябре может выглядеть как сбой. На самом деле это другой сценарий обслуживания. Microsoft заранее сообщила, что сентябрьское обновление 2026 года будет стандартным, а не обычным hotpatch-пакетом. Изменения затрагивают компоненты, которые нельзя обновить во время работы операционной системы.

Для IT-отдела здесь есть несколько важных следствий. Самое очевидное связано с пользователями. Если рабочая станция получит обновление автоматически, система может показать уведомление о необходимости перезапуска. Если политика организации допускает автоматическую перезагрузку, пользователь может столкнуться с ней в рабочее время.

На сервере последствия ещё заметнее. Перезапуск означает временную недоступность роли, приложения или виртуальных машин, если они не перенесены заранее. Поэтому сентябрьский выпуск нужно рассматривать как обычное обновление с обязательным reboot, даже если конкретный сервер месяцами обновлялся через Hotpatch без остановки.

При этом переоформлять устройство или исключать его из Hotpatch не нужно. Microsoft указывает, что после установки стандартного сентябрьского обновления устройство остаётся зарегистрированным для Hotpatch. Дополнительное изменение конфигурации или повторное включение функции не требуется.

Это важное различие. Перезагрузка в сентябре является особенностью конкретного цикла обновлений, а не сигналом о том, что Hotpatch перестал работать.

Почему Hotpatch иногда не может заменить перезагрузку системы

Hotpatch работает с ограничением, которое легко забыть при длительном использовании технологии. Не любой компонент Windows можно заменить непосредственно во время работы системы. Часть файлов, драйверов и системных механизмов находится в таком состоянии, что полноценное обновление возможно только после остановки соответствующих процессов или загрузки новой версии операционной системы.

Именно поэтому у Hotpatch существует понятие baseline. Такой выпуск обновляет фундаментальную часть системы, после чего требуется reboot. Следующие hotpatch-обновления уже могут накладываться поверх этого состояния без нового перезапуска. Microsoft описывает такую модель как регулярный цикл baseline и hotpatch.

Сентябрьский случай отличается тем, что стандартное обновление появляется вне привычного ожидания администратора. Документация Microsoft отдельно допускает дополнительные baseline-месяцы, если этого требуют обстоятельства безопасности. При этом плановый календарь Hotpatch сам по себе не перестраивается.

Поэтому администратору не стоит делать вывод "раз появился reboot, значит Hotpatch отключился". Такой вывод приведёт к неправильным действиям. Устройство может оставаться в Hotpatch-политике, а сентябрьский пакет просто требует однократной перезагрузки.

Есть и практический момент. Если система ещё не находится на необходимом baseline, в период, который считается hotpatch-месяцем, она может получить и baseline, и hotpatch. Microsoft отдельно предупреждает об этом поведении. В результате наличие Hotpatch не гарантирует отсутствие reboot при любых обстоятельствах.

Для администрирования полезно разделять три понятия: устройство зарегистрировано для Hotpatch, устройство соответствует требованиям Hotpatch и конкретное установленное обновление не требует перезапуска. Это не одно и то же.

Проверить участие устройства в Hotpatch лучше до установки сентябрьского пакета

Первый этап подготовки заключается не в ручном запуске обновления, а в инвентаризации. Нужно понять, какие компьютеры и серверы относятся к Hotpatch-парку, какие политики на них распространяются и какие системы потенциально могут потребовать reboot.

В управляемой инфраструктуре членство определяется не локальной настройкой Windows Update, а назначением соответствующей политики. Microsoft указывает, что при использовании групп автоматического исправления устройства получают Hotpatch через назначенную политику обновлений. Для Windows 11 управление выполняется через Windows Autopatch, а поддерживаемые серверные конфигурации используют соответствующие механизмы управления обновлениями.

Поэтому проверка "состоит ли компьютер в Hotpatch-группе" и проверка "готов ли компьютер технически получать Hotpatch" должны выполняться отдельно.

Для локальной проверки полезно посмотреть состояние виртуализации на основе безопасности. Для ряда поддерживаемых сценариев Hotpatch требуется VBS. Microsoft предоставляет PowerShell-команду, которая показывает текущее состояние VBS:

Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' `
    -ClassName 'Win32_DeviceGuard' |
    Select-Object VirtualizationBasedSecurityStatus

Значение 2 означает, что VBS настроена и работает. Если система показывает другое состояние, одного факта включения соответствующей политики недостаточно.

Проверить установленные исправления можно через стандартный Get-HotFix. Например:

Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 10 HotFixID, InstalledOn, Description

Такая команда не показывает членство в облачной группе управления. Она отвечает на другой вопрос: какие исправления уже находятся на конкретном компьютере.

Для самого членства в группе администратору следует использовать ту систему управления, через которую назначается политика Hotpatch. Это может быть Windows Autopatch или Intune в зависимости от сценария. Локальный PowerShell при этом полезен как второй уровень контроля: он позволяет массово собрать технические параметры компьютеров и найти машины, которые требуют отдельного внимания.

PowerShell помогает собрать парк перед сентябрьским перезапуском

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

Один из безопасных вариантов состоит в том, чтобы передавать список имён компьютеров и удалённо собирать состояние VBS, последнего исправления и наличие признаков ожидающей перезагрузки. Сам скрипт не меняет конфигурацию и не перезапускает машины:

$Computers = Get-Content .\computers.txt

$Report = foreach ($Computer in $Computers) {
    try {
        $os = Get-CimInstance -ComputerName $Computer `
            -ClassName Win32_OperatingSystem -ErrorAction Stop

        $deviceGuard = Get-CimInstance -ComputerName $Computer `
            -Namespace 'root/Microsoft/Windows/DeviceGuard' `
            -ClassName Win32_DeviceGuard -ErrorAction Stop

        $hotfix = Get-HotFix -ComputerName $Computer -ErrorAction SilentlyContinue |
            Sort-Object InstalledOn -Descending |
            Select-Object -First 1

        [pscustomobject]@{
            ComputerName = $Computer
            LastBoot     = $os.LastBootUpTime
            VBSStatus    = $deviceGuard.VirtualizationBasedSecurityStatus
            LastHotFix   = $hotfix.HotFixID
            InstalledOn  = $hotfix.InstalledOn
            Reachable    = $true
        }
    }
    catch {
        [pscustomobject]@{
            ComputerName = $Computer
            LastBoot     = $null
            VBSStatus    = $null
            LastHotFix   = $null
            InstalledOn  = $null
            Reachable    = $false
        }
    }
}

$Report | Export-Csv .\hotpatch-readiness.csv `
    -NoTypeInformation -Encoding UTF8

Получившийся CSV удобно использовать как предварительный список. Компьютеры с Reachable = False требуют отдельной проверки соединения. Машины с неожиданным состоянием VBS стоит проверить до окна обновления. Дата последнего запуска помогает понять, какие устройства давно не перезагружались.

Этот отчёт не следует воспринимать как официальный детектор членства в Hotpatch. Он собирает локальные признаки состояния системы. Само назначение политики остаётся задачей системы управления устройствами.

Практический смысл такого разделения очень простой. Если компьютер оказался вне нужной группы, исправлять это нужно в управлении устройствами. Если политика назначена, но техническое состояние машины не соответствует требованиям, искать причину следует уже на самом устройстве.

Перед reboot нужно проверить политики автоматического перезапуска

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

Microsoft рекомендует учитывать активные часы, параметры автоматической установки и политики перезапуска. Для управляемых устройств можно задавать время установки и соответствующие параметры поведения после неё. На уровне групповой политики существуют отдельные настройки, определяющие, будет ли система автоматически перезапускаться при вошедшем пользователе и когда запускается таймер перезагрузки.

На сервере особенно важно не переносить пользовательскую модель настройки один в один. Microsoft рекомендует для серверных устройств сценарий, при котором администратор получает уведомление об установке и перезагрузке, а само окно обслуживания контролируется отдельно.

На рабочих станциях ситуация другая. Пользователь может быть активен в момент установки, а автоматический reboot способен прервать незаписанную работу. Поэтому перед массовым развёртыванием сентябрьского обновления стоит проверить, какие политики уже применяются.

PowerShell позволяет быстро посмотреть соответствующие параметры реестра Windows Update:

$Path = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU'

Get-ItemProperty -Path $Path -ErrorAction SilentlyContinue |
    Select-Object AUOptions,
                  NoAutoRebootWithLoggedOnUsers,
                  AlwaysAutoRebootAtScheduledTime,
                  AlwaysAutoRebootAtScheduledTimeMinutes,
                  ScheduledInstallTime

Здесь особенно интересны NoAutoRebootWithLoggedOnUsers, параметры запланированного перезапуска и выбранный режим автоматических обновлений. Нельзя просто взять один параметр и считать его полной картиной. Поведение Windows зависит от комбинации настроек, а некоторые политики имеют ограничения по версиям системы.

Если в организации используются MDM-политики, проверять нужно уже применяемую конфигурацию управления устройствами, а не только локальный реестр. Локальное значение может не отражать весь набор политик, который получает компьютер.

Массовое планирование reboot лучше делать отдельным этапом

Для десятков машин ручной запуск перезапуска допустим. Для сотен систем лучше сначала создать окно, предупредить пользователей, проверить критичные сервисы и только после этого отправлять команды.

Удобная схема выглядит так:

Собрать список устройств, которые относятся к Hotpatch-парку, и отдельно отметить серверы и рабочие станции;
Проверить достижимость машин, состояние VBS и дату последней загрузки;
Проверить политики Windows Update и убедиться, что автоматическая перезагрузка не пересекается с выбранным окном обслуживания;
Разослать уведомление пользователям и владельцам сервисов о необходимости сентябрьского reboot;
Выполнить перезапуск волнами, сначала на тестовой группе, затем на остальных устройствах;
После загрузки проверить установку обновления и убедиться, что устройства сохранили участие в Hotpatch.

Для планирования можно использовать встроенный планировщик Windows. Например, на конкретной машине администратор может создать задачу, которая выполнит reboot в заданное время:

$Action = New-ScheduledTaskAction `
    -Execute 'shutdown.exe' `
    -Argument '/r /t 60 /d p:2:4 /c "Planned September 2026 maintenance"'

$Trigger = New-ScheduledTaskTrigger `
    -Once `
    -At (Get-Date '2026-09-15 23:00')

Register-ScheduledTask `
    -TaskName 'September2026-Hotpatch-Reboot' `
    -Action $Action `
    -Trigger $Trigger `
    -RunLevel Highest `
    -Force

Перед применением такого варианта дату и время нужно заменить на реальное окно обслуживания организации. Задача даёт компьютеру минуту после запуска команды shutdown.exe, чтобы пользователь мог сохранить работу. Само создание задания не означает, что обновление будет установлено именно в этот момент: оно лишь планирует reboot.

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

Для серверов лучше добавить предварительную проверку. Нельзя бездумно отправлять reboot на контроллер домена, сервер базы данных или узел виртуализации только потому, что он оказался в общем списке. Перед каждым окном нужно понимать, какие роли находятся на машине и есть ли резервный экземпляр.

После перезагрузки нужно проверить не только Windows Update

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

Нужно убедиться, что обновление действительно установилось, система загрузилась с новым состоянием компонентов и устройство продолжает получать Hotpatch в дальнейшем. Важно не перепутать обязательный reboot с выходом из программы.

Microsoft прямо указывает, что устройства, затронутые сентябрьским стандартным обновлением, сохраняют регистрацию Hotpatch. Поэтому после перезапуска не требуется заново включать Hotpatch или переназначать устройство в соответствующую конфигурацию.

На локальной машине можно повторно собрать состояние:

Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' `
    -ClassName 'Win32_DeviceGuard' |
    Select-Object VirtualizationBasedSecurityStatus

Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 5 HotFixID, InstalledOn

Первый результат позволяет проверить VBS, второй показывает последние установленные исправления.

Если устройство управляется через Intune или Windows Autopatch, финальную проверку лучше выполнять и в соответствующей консоли. Именно там видно назначение политики и состояние устройства в управляемом парке. Локальная команда не заменяет серверную сторону управления.

После успешной перезагрузки полезно проверить ещё один показатель: когда компьютер действительно снова стал доступен. На сервере это помогает оценить фактическую длительность окна обслуживания. Если система обычно возвращается за две минуты, а после сентябрьского обновления начинает загружаться пять минут, это уже повод посмотреть журналы и состояние компонентов.

Что делать администраторам Windows Server и Windows 11

Для Windows Server последствия сентябрьского выпуска могут быть чувствительнее, поскольку перезапуск непосредственно связан с доступностью сервисов. В Windows 11 основная проблема чаще касается пользовательской работы и риска незапланированного reboot в рабочее время.

При этом базовая стратегия для обеих категорий похожа. Сначала определить устройства с Hotpatch, затем проверить применяемые политики, после этого выбрать окно перезапуска и только потом разрешить массовую установку.

Для серверов имеет смысл проводить обслуживание волнами. Сначала обновляются машины, которые не находятся на критическом пути. Если используется кластер или несколько экземпляров одного сервиса, узлы можно перезапускать последовательно, оставляя часть инфраструктуры доступной.

Для рабочих станций полезнее использовать несколько групп по времени. Например, первая группа получает обновление вечером, вторая позже, а устройства сотрудников с нестандартным графиком обслуживаются отдельно. Так администратор не сталкивается с ситуацией, когда весь парк одновременно требует reboot.

Особое внимание нужно уделить политикам. Microsoft указывает, что настройки активных часов, сроков установки и поведения перезапуска продолжают определять пользовательский опыт. Само включение Hotpatch не отменяет существующие параметры управления обновлениями.

Именно здесь возникает практическая ловушка сентября. Администратор мог привыкнуть к тому, что Hotpatch почти всегда означает отсутствие перезагрузки. Но политика, которая месяцами не создавала проблем, теперь должна рассматриваться вместе с конкретным типом сентябрьского обновления.

Сентябрьский reboot не отменяет ценность Hotpatch

Однократная перезагрузка может создать впечатление, что вся идея Hotpatch теряет смысл. Это неправильная оценка. Функция решает другую задачу: она сокращает количество перезапусков в тех циклах, где обновления действительно можно применить без остановки системы.

Microsoft продолжает разделять baseline и hotpatch. Baseline нужен для изменений, которые требуют загрузки обновлённых системных компонентов, а hotpatch позволяет устанавливать подходящие исправления без reboot. В обычном цикле такая модель заметно уменьшает количество окон обслуживания.

Сентябрь 2026 года показывает обратную сторону этой архитектуры. Даже если технология рассчитана на работу без перезапуска, она не может отменить фундаментальное ограничение обновления работающей операционной системы. Когда затронуты компоненты, требующие загрузки новой версии, reboot становится необходимым.

Для IT-отдела это скорее напоминание о правильной модели управления. Hotpatch нужно воспринимать как способ сократить количество перезагрузок, а не как абсолютную гарантию отсутствия reboot.

Поэтому в расписании обслуживания всё равно должно существовать резервное окно. Если обновление неожиданно оказывается baseline-типом или Microsoft выпускает дополнительное обновление, инфраструктура уже готова к остановке. Сентябрьский выпуск как раз показывает, зачем нужен такой запас.

Важнее всего заранее отделить Hotpatch от конкретного обновления

Главный практический вывод сентября заключается в том, что статус Hotpatch и требование перезагрузки не противоречат друг другу. Устройство может оставаться в Hotpatch-группе, получать соответствующие обновления в следующих циклах и одновременно требовать reboot для конкретного сентябрьского пакета.

Поэтому перед распространением обновления администратору не стоит проверять только один признак. Нужна связка из состояния управляемой политики, технической готовности устройства, применённых обновлений и фактического требования к перезапуску.

Microsoft уже описывает Hotpatch как циклическую модель, в которой baseline-обновления требуют reboot, а hotpatch-выпуски рассчитаны на работу без него. При необходимости могут появляться дополнительные baseline-выпуски, не меняющие основной цикл.

В сентябре это особенно важно для тех организаций, где Hotpatch воспринимался как полностью автоматический процесс. Если ничего не проверить, обновление может попасть на компьютер в неудобный момент, а сервер может получить перезагрузку вне запланированного окна.

Намного надёжнее заранее собрать список машин, определить их состояние и назначение, проверить политики и только после этого запустить обновление. PowerShell здесь удобен как инструмент инвентаризации и локальной диагностики. Для самого членства в управляемой Hotpatch-группе нужно смотреть систему управления устройствами, потому что локальная команда не является заменой Intune или Autopatch.

Сентябрьский выпуск 2026 года в итоге не отменяет Hotpatch, а показывает его реальное ограничение. Технология позволяет убрать значительную часть reboot из процесса обновления, но не превращает Windows в систему, которую можно полностью обновлять без перезапуска. Поэтому грамотная инфраструктура должна быть готова к обоим вариантам: обычному hotpatch без остановки и baseline-обновлению с заранее согласованным окном.

Для администратора лучший сценарий на сентябрь выглядит достаточно прозаично: проверить парк заранее, предупредить пользователей, убедиться в корректности политик, назначить reboot-окно, выполнить обновление поэтапно и после перезапуска подтвердить состояние машин. После этого устройства продолжают находиться в Hotpatch-цикле, а следующий подходящий выпуск снова сможет установить исправления без обязательной перезагрузки.