2026 Windows Server 2019: что делать, если после KB5122876 зависает RDP?

Исправление: сначала проверьте, установлена ли KB5129238 или более позднее применимое накопительное обновление, а затем заново проверьте RDP; удалять KB5122876 по умолчанию не следует. Этот порядок подходит, если сервер работает под Windows Server 2019 и сбой начался после установки сентябрьского обновления безопасности 2026 года: Microsoft подтвердила проблему RDS в части сред и указала, что её исправляют KB5129238 и последующие обновления.

Статья для администраторов, которым нужно установить, связан ли сбой с известной проблемой обновления, а не просто с похожим симптомом. Также пригодится тем, кто обслуживает узел сеансов RDS или поддерживает бизнес-приложение, доступное через RDP.

Последнее обновление: 30 октября 2026 года. Статус проблемы и сведения об исправлении сверены с Microsoft: перечень решённых проблем Windows Server 2019 и описанием KB5129238. Перед изменением сервера проверьте эти страницы ещё раз: статус и применимость обновлений могут измениться.

Граница известной проблемы KB5122876

Microsoft сообщает, что после установки KB5122876 у части организаций могут возникнуть проблемы со службой удалённых рабочих столов. Для затронутой ситуации указано исправление KB5129238 и последующие обновления, содержащие это исправление. Это не означает, что каждый сервер под Windows Server 2019 после обновления обязательно перестанет принимать подключения: область проблемы ограничена, и совпадение по времени само по себе не устанавливает причину.

Сопоставьте наблюдения с несколькими независимыми признаками:

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

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

Microsoft публикует сведения о подтверждённом влиянии на странице решённых проблем Windows Server 2019 и отдельную инструкцию по проблемам RDS после обновлений сентября 2026 года. Обсуждение администраторов в сообществе sysadmin показывает, что симптом обсуждался на практике, но не подтверждает ни причинную связь, ни применимость исправления к конкретному серверу.

Проверка обновлений Windows Server 2019

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

Сначала зафиксируйте систему. В графическом интерфейсе запустите winver и сохраните сведения о версии Windows Server. Затем откройте Параметры → Обновление и безопасность → Центр обновления Windows → Просмотр журнала обновлений. Названия пунктов могут незначительно отличаться в зависимости от языка и конфигурации системы. В журнале ищите KB5122876, KB5129238 и последующие накопительные обновления. Дополнительно проверьте список установленных обновлений в панели управления.

В PowerShell с правами администратора можно выполнить:

Get-ComputerInfo |
  Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Get-HotFix |
  Where-Object { $_.HotFixID -in 'KB5122876', 'KB5129238' } |
  Select-Object HotFixID, InstalledOn, Description

Get-HotFix полезен как дополнительная проверка, но пустой результат не следует трактовать как доказательство отсутствия исправления: способ отображения зависит от типа обслуживающего пакета. Сопоставьте вывод с журналом Windows Update и актуальными сведениями Microsoft. Если требуется подтвердить пакет через DISM, используйте вывод списка пакетов как ещё один источник, а не как замену проверке применимости:

Get-WindowsPackage -Online |
  Where-Object { $_.PackageName -match 'KB5122876|KB5129238' } |
  Select-Object PackageName, PackageState, ReleaseType

При необходимости откройте командную строку с повышенными правами и выполните dism /online /get-packages; сохраните вывод для журнала изменения. Название пакета может не содержать номер KB в ожидаемом виде, поэтому отрицательный поиск по строке не является окончательным заключением.

Для поиска подходящего обновления сверяйтесь с официальными сведениями о KB5129238 и с перечнем актуальных выпусков и обслуживающих ветвей в информации о выпусках Windows Server. Установка должна соответствовать версии, ветви обслуживания и текущему состоянию конкретного сервера.

Решение по состоянию обновления

Ключевой выбор — не «оставить обновления включёнными или удалить проблемный пакет», а проверить, применимо ли исправление, и провести контролируемую установку. Microsoft указывает связь проблемы с KB5122876 и наличие исправления в KB5129238 и более поздних обновлениях; это делает установку подходящего исправления предпочтительнее удаления обновления безопасности без подтверждённого плана восстановления.

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

Порядок установки и проверки результата

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

1. Зафиксируйте исходное состояние. Сохраните версию и сборку Windows Server, список последних обновлений, время появления сбоя и точный этап, на котором зависает RDP. В графическом интерфейсе используйте winver и журнал Центра обновления Windows; в PowerShell сохраните результаты Get-ComputerInfo и Get-HotFix.

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

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

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

5. Установите применимое обновление. Используйте Центр обновления Windows или утверждённый в организации канал управления обновлениями. После установки проверьте результат в истории обновлений и, при необходимости, PowerShell. Зафиксируйте код KB, сборку и состояние пакета.

6. Проверьте доступ разными путями. Сначала выполните тестовый вход с административной рабочей станции, затем проверьте вход реального пользователя или тестовой учётной записи с обычными правами. Убедитесь, что сеанс не просто создаётся, но и доходит до рабочего стола и нужного бизнес-приложения. Если требуется проверить способ подключения клиента к серверу, используйте руководство CloudUDP по доступу к услуге, не подменяя этим проверку RDS на самом сервере.

7. Сопоставьте результат с журналами. Проверьте системные события, журналы служб удалённых рабочих столов и записи, относящиеся к моменту неудачного подключения. Сохраните время тестов и сообщения об ошибках. Это позволяет сравнить поведение до и после обновления и передать специалистам факты, а не только формулировку «RDP зависает».

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

Что проверять, если RDP зависает после исправления

Если применимое исправление установлено, но соединение по-прежнему не проходит, разделите диагностику на независимые ветви.

• Сеть и путь подключения. Проверьте, одинаково ли воспроизводится проблема из разных разрешённых сетей и для разных клиентов. Уточните, не изменились ли правила межсетевого экрана, маршрутизация или промежуточные средства доступа. Сетевой отказ и проблема службы RDS могут выглядеть одинаково на стороне пользователя.
• Учётная запись и аутентификация. Проверьте срок действия и состояние учётной записи, членство в разрешённых группах и результаты входа в журнале безопасности. Если сбой возникает до создания сеанса, изучите этап проверки подлинности отдельно от загрузки пользовательского профиля.
• Узел сеансов и службы. Проверьте связанные службы и события за точное время неудачного подключения. Состояние «выполняется» не доказывает, что служба корректно обрабатывает новый сеанс. Для ситуации с сообщением о занятости Microsoft предлагает отдельные инструкции по диагностике службы удалённых рабочих столов и сбору данных.
• Сеанс и приложение. Если пользователь доходит до рабочего стола, но зависает конкретная программа, проверьте её журналы, профиль пользователя и доступность зависимостей. Это уже не равнозначно отказу RDP-транспорта.
• Сравнение с контрольным входом. Зафиксируйте разницу между административным тестом и входом обычного пользователя. Администраторский сеанс может иметь иной профиль, права и набор запускаемых приложений; успешный тест администратора не гарантирует восстановление рабочего процесса пользователей.

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

Проверка обновлений как контрольная точка

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

После изменения проверяйте не один признак, а цепочку: обновление применилось; система находится в ожидаемом состоянии; новый сеанс RDP создаётся; пользователь проходит аутентификацию; рабочий стол и нужное приложение доступны. Запись результата должна включать номер KB, сведения о перезагрузке, точное время проверки и фрагменты журналов, необходимые для повторного анализа.

Для команд, которые поддерживают старую установку Windows Server 2019, но планируют отдельное развёртывание, версии и язык системы лучше сверять до переноса приложения. Варианты Windows Server, доступные у CloudUDP, и поддерживаемые языковые варианты можно проверить на странице тарифов CloudUDP. Это проверка конкретной конфигурации для нового сервера, а не обещание совместимости установленного приложения: её следует подтвердить собственным тестом.

Переход на отдельный сервер не исправляет ошибку обновления автоматически. Однако при длительной эксплуатации общий виртуальный сервер может ограничивать контроль над выделенными ресурсами и конфигурацией среды, а нагрузка соседних арендаторов способна затруднить анализ нестабильности. Если приложению требуется постоянно доступная Windows-среда с выделенным физическим сервером AMD, имеет смысл сопоставить такую схему с текущей и заранее проверить совместимость, обновления и лицензирование. CloudUDP предлагает варианты Windows Server 2019, 2022 и 2025 с доступными языками системы; подключение к Windows выполняется через RDP. RDS CAL и услуги миграции или администрирования в это предложение не включаются — их необходимо учитывать отдельно.