Как предотвратить отключение коллекции сеансов RDS на WS2022

Чтобы предотвратить отключение списка сеансов коллекции RDS на Windows Server 2022 при установке обновлений, планируйте и контролируйте перезагрузки (WSUS/SCCM/Intune), перед патчем выводите хосты из коллекции или ставьте их в режим обслуживания, и проверяйте состояние RD Connection Broker и базы RDCms до и после перезагрузки. Если gpupdate /force больше не помогает, причиной чаще всего становятся флаги “pending reboot”, проблемы с базой RDCms или несинхронизированный брокер — проверяйте журналы, статус БД и используйте обходы (двойная перезагрузка, прямое теневое подключение через mstsc /shadow) до восстановления коллекции.

Содержание

• Краткое описание проблемы и причины отключения RDS на Windows Server 2022
• Подготовка: как выводить хосты RDS из коллекции перед обновлением
• Управление обновлениями и групповые политики для RDS на WS 2022
• Диагностика: проверка Connection Broker и базы RDCms
• Быстрая помощь: шаги при пропаже списка сеансов (если gpupdate /force не помогает)
• Обходные пути и теневое подключение (shadow) как резервный план
• Рекомендации по патчам, тестированию и долгосрочным мерам защиты коллекции сеансов
• Источники
• Заключение

Краткое описание проблемы и причины отключения RDS Windows Server 2022 при обновлениях

При установке обновлений сервер может перейти в состояние «Ожидание перезагрузки» — это не просто служебный флаг: ряд компонентов RDS (особенно RD Connection Broker и веб-интерфейсы, зависящие от базы RDCms) перестаёт корректно отвечать, и Server Manager / RDWeb перестаёт показывать список сеансов коллекции. Иногда база RDCms уходит в состояние Recovery Pending (известная проблема после некоторых накопительных обновлений), а в HA‑сценариях пассивный брокер может быть несинхронизирован с активным — тогда коллекция «исчезает» у точки доступа. Подробнее о случаях с застреванием RDCms и проблемах с брокером см. на Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/691356/rdcms-database-stuck-in-recovery-pending-mode-afte и https://learn.microsoft.com/en-us/answers/questions/1822721/rds-2022-session-host-remains-in-collection-after.

Почему gpupdate /force перестал помогать? Потому что gpupdate только перечитывает политики — он не снимает флаги “pending reboot”, не поднимает базу данных и не синхронизирует состояние брокеров. Если после обновления блокирован доступ к RDCms или сам брокер висит в неконсистентном состоянии, обновление политик бесполезно.

Подготовка: как выводить хосты RDS из коллекции перед обновлениями

Чтобы избежать потери видимости сеансов во время патчинга, выведите серверы из обслуживаемой группы по схеме «rolling update»:

• План: обновляйте по одному хосту за раз (canary → stage → prod). Для фермы RDS это стандартный подход.
• Перед установкой патчей:
• Выведите конкретный RD Session Host из коллекции (или поставьте в «режим обслуживания / drain»), чтобы на него не шли новые подключения. Делать это можно через Server Manager (Remote Desktop Services → Collections → выбрать коллекцию → удалить/вывести сервер временно) или аналогичной командой/скриптом в вашей автомасштабируемой системе управления.
• Сделайте бэкап конфигурации Connection Broker / экспорт ключевых реестровых записей и бэкап базы RDCms (SQL‑сервер). Это важно, особенно если у вас HA‑брокеры. В известных инцидентах экспорт/импорт реестра помогал синхронизировать пассивный брокер с активным — см. https://learn.microsoft.com/en-us/answers/questions/1479199/remote-desktop-session-collection-not-showing-up-i.
• Снимите снимок (snapshot) виртуальной машины или бэкап ОС перед массовой установкой.

Практическое правило: если у вас несколько RDSH, отключите один узел от коллекции → обновите → перезагрузите(ы) → убедитесь, что список сеансов и теневое подключение работают → вернуть в коллекцию и перейти к следующему хосту.

Управление обновлениями и групповые политики для Windows Server 2022 (RDS)

Контроль над тем, когда и как перезагружаются серверы — ключ к стабильности RDS. Рекомендации:

• Централизованный контроль обновлений:
• Используйте WSUS / SCCM / Intune (Update Management) для одобрения патчей и задания maintenance windows. Не полагайтесь на автоматические обновления с немедленной перезагрузкой на production RDS.
• Настройки групповой политики (примерные политики):
• Computer Configuration → Administrative Templates → Windows Components → Windows Update → “No auto-restart with logged on users for scheduled automatic updates installations” — включите, чтобы авто‑перезагрузка не происходила, когда пользователи залогинены.
• Computer Configuration → Administrative Templates → Windows Components → Windows Update → “Configure Automatic Updates” — задавайте поведение в зависимости от вашей организации (для серверов — чаще ручная установка/утверждение).
• Используйте SCCM/Intune maintenance windows вместо «active hours» на серверах.
• План перезагрузок:
• Планируйте и уведомляйте пользователей. Рекомендуемый сценарий: установить обновления → перезагрузить сервер как минимум один раз; при подозрении на проблемы с RDCms — выполнить вторую перезагрузку (двойной перезапуск часто решает состояния, которые остаются после первого рестарта).
• Не отключайте обновления навсегда — вместо этого управляйте их внедрением и временем перезагрузок.

Документируйте процедуру: кто выводит хост из коллекции, кто ставит обратно и кто проверяет работоспособность списка сеансов.

Диагностика: проверка Connection Broker и базы RDCms

Если список сеансов пропал, выполняйте диагностику по шагам:

1. Журналы:

• Откройте Event Viewer → Windows Logs → System и Application, а также лог Remote Desktop (Applications and Services Logs → Microsoft → Windows → RemoteDesktop*). Ищите ошибки и тайминги вокруг установки обновлений. Примеры и рекомендации по проверке — https://learn.microsoft.com/en-us/answers/questions/1822721/rds-2022-session-host-remains-in-collection-after.

2. Проверка состояния базы RDCms (SQL):

• Подключитесь к экземпляру SQL (SSMS) и выполните:

SELECT name, state_desc FROM sys.databases WHERE name LIKE '%RDCms%';

Если состояние = RECOVERY_PENDING или SUSPECT — это объясняет недоступность списка. Варианты действий: проверить доступность дисков/журналов транзакций, выполнить DBCC CHECKDB, вернуть из бэкапа или попытаться поставить БД ONLINE (только после бэкапа!).

• Примеры SQL‑шагов (делайте только с бэкапом и/или с DBA):

-- Проверка статуса
SELECT name, state_desc FROM sys.databases WHERE name = 'RDCms';
-- При осторожном подходе (после анализа)
ALTER DATABASE [RDCms] SET ONLINE;
DBCC CHECKDB([RDCms]) WITH NO_INFOMSGS, ALL_ERRORMSGS;

Детали типовой проблемы и обходы описаны в Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/691356/rdcms-database-stuck-in-recovery-pending-mode-afte.
3. Pending reboot и реестр:

• Проверьте наличие флагов ожидания перезагрузки:

Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name 'PendingFileRenameOperations' -ErrorAction SilentlyContinue

• Если найдено — это указывает, что служба или компонент ждёт перезагрузки; gpupdate не снимет эти флаги. Иногда помогает корректная перезагрузка или, при очевидной ошибке, очистка ключа PendingFileRenameOperations (только с пониманием рисков). На практике полезно свериться с рекомендацией по очистке подобных флагов (см. обсуждение на Server Fault): https://serverfault.com/questions/518483/windows-server-2012-selected-server-has-pending-reboots-and-does-not-clear-whe.

4. HA брокер:

• В сценариях с несколькими брокерами проверьте синхронизацию реестра и конфигурации. Если пассивный брокер не синхронизирован, коллекции могут быть недоступны через RDWeb/Server Manager — см. https://learn.microsoft.com/en-us/answers/questions/1479199/remote-desktop-session-collection-not-showing-up-i.

Быстрая помощь: шаги при пропаже списка сеансов (если gpupdate /force не помогает)

Если после обновления список сеансов пропал — быстрый чек‑лист (в порядке от безопасных к более вмешательным):

1. Проверка и уведомление:

• Сразу проверьте Event Viewer на broker/rdcms ошибки и предупредите пользователей.

2. Проверить pending reboot (PowerShell кусок выше). Если ключи есть — перезагрузите сервер в запланированное окно. Не пытайтесь вручную редактировать реестр без бэкапа.
3. Проверить доступность RDCms в SSMS (см. раздел Диагностика). Если база OFFLINE/RECOVERY_PENDING — свяжитесь с DBA или восстановите из бэкапа.
4. Перезапуск RDS‑ролевых служб:

• Попробуйте перезапустить сервисы RD Connection Broker и RD Web Access (не просто TermService), лучше через Server Manager или Services.msc. Перезапуск TermService (Remote Desktop Services) приведёт к разрыву всех сессий — используйте крайне осторожно.

5. Двойная перезагрузка:

• На практике иногда помогает полная перезагрузка хоста дважды подряд: install → reboot → дождаться полной загрузки и служб → второй reboot → проверка коллекции. Это часто завершает отложенные операции установки и позволяет базе вернуться в норму.

6. Временный выход из коллекции и прямое подключение:

• Если брокер недоступен, выйдите временно из коллекции и подключитесь напрямую к нужному RDSH для теневого доступа (см. раздел ниже про mstsc /shadow). Это восстановит администрирование, пока вы лечите брокер/БД.

7. Если причиной явно является последний KB/патч:

• Откатите проблемный обновление (wusa /uninstall /kb:XXXX) в контролируемом окне и сообщите Microsoft (ticket) — часто это путь к официальному исправлению.

Обходные пути и теневое подключение (shadow) как резервный план

Когда список сеансов недоступен, теневое подключение всё ещё можно делать напрямую к Session Host:

• Получить список сессий на хосте:
• Через командную строку:

qwinsta /server:rdsh1.contoso.local
query user /server:rdsh1.contoso.local

• Это вернёт ID сеанса и имя пользователя.
• Подключиться к сеансу (shadow) с управляющего ПК:
• Пример команды:

mstsc /v:rdsh1.contoso.local /shadow:3 /control /noConsentPrompt

где 3 — ID сеанса. Если нужно сначала запросить согласие пользователя — уберите /noConsentPrompt.

• Чтобы избежать запроса согласия в будущем, настройте групповую политику:
• Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections → “Set rules for remote control of Remote Desktop Services user sessions” — настройте “Full control without user’s permission” (или по потребности).
• В качестве дополнительного метода — используйте RDP файл / RDPMan или PowerShell скрипты для автоматизации поиска сессии и запуска mstsc. Это полезно на аварийных станциях администраторов.

Рекомендации по патчам, тестированию и долгосрочным мерам защиты коллекции сеансов

• Тестируйте обновления на канаре / стейдж среде с конфигурацией RDS, как в продакшене. Это выявит баги, связанные с RDCms или брокером.
• Ведите журнал версии пакетов и KB‑номеров для RDS‑ролей; при проблемах используйте откат проблемного KB и обращайтесь в поддержку Microsoft с логами. Примеры проблем фиксируются в Microsoft Q&A (см. ссылки в разделе Источники).
• Автоматизация и мониторинг:
• Настройте мониторинг здоровья RD Connection Broker и состояния базы RDCms (alert при смене статуса БД). Автоматический скрипт может оповещать и инициировать безопасное восстановление (перезапуск роли, алерт DBA).
• Патчи RDS:
• Регулярно проверяйте релизы и известные проблемы для Windows Server 2022 и RDS‑ролей; применяйте cumulative updates согласно вашей политике staged rollout.
• Документируйте процедуру обслуживания и восстановление: кто выводит/возвращает хост в коллекцию, шаблон команд, ответственные лица.

Источники

1. Microsoft Q&A — RDS 2022 session host remains in collection after reboot: https://learn.microsoft.com/en-us/answers/questions/1822721/rds-2022-session-host-remains-in-collection-after
2. Microsoft Q&A — Remote Desktop Session Collection not showing up in RdWeb (Connection Broker HA): https://learn.microsoft.com/en-us/answers/questions/1479199/remote-desktop-session-collection-not-showing-up-i
3. Microsoft Q&A — RDCms Database Stuck in Recovery Pending Mode After Reboot: https://learn.microsoft.com/en-us/answers/questions/691356/rdcms-database-stuck-in-recovery-pending-mode-afte
4. Server Fault — Pending reboots and registry fixes: https://serverfault.com/questions/518483/windows-server-2012-selected-server-has-pending-reboots-and-does-not-clear-whe
5. Microsoft Troubleshooting — RDS client can’t connect to RD Session Host server: https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/rds-client-not-connect-to-rd-session-host-server
6. Microsoft Troubleshooting (RU) — “Your session will be disconnected in 60 minutes” (общие рекомендации по стабильности RDS): https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/remote/your-session-will-be-disconnected-in-60-minutes
7. Winitpro — реальный опыт с обновлениями и зависанием RDS (пример кейса): https://winitpro.ru/index.php/2022/02/17/ustanovka-nastrojka-remote-desktop-services-rds-windows-server/
8. Winitpro — зависание RDP при работе по UDP после обновлений: https://winitpro.ru/index.php/2023/04/18/zavisaet-rdp-sessiya-udp-transport/
9. Reddit (sysadmin) — обсуждения проблем при добавлении ролей RDS (кейс‑советы): https://www.reddit.com/r/sysadmin/comments/1dzbwyl/windows_server_22_rdp_session_services_add_role/
10. Reddit (sysadmin) — Issue with adding RD Session Host Server to Collection: https://www.reddit.com/r/sysadmin/comments/18helc4/issue_with_adding_rd_session_host_server_to/
11. Experts‑Exchange — Pending restart loop при установке RDS: https://www.experts-exchange.com/questions/29155282/Pending-restart-loop-trying-to-install-RDS.html
12. StackOverflow (AWS RDS — нерелевантно к Windows RDS, включено для полноты анализа): https://stackoverflow.com/questions/67007890/is-rds-instance-in-pending-reboot-status-after-parameter-group-change-automati
13. StackOverflow (AWS RDS — нерелевантно): https://stackoverflow.com/questions/41570431/aws-rds-parameter-group-showing-pending-reboot-after-mysql-upgrade

Заключение

Коротко: предотвращение пропажи списка сеансов на RDS Windows Server 2022 — это процесс: управляйте перезагрузками централизованно (WSUS/SCCM/Intune), перед патчем выводите хосты из коллекции или ставьте в режим обслуживания, проверяйте и поддерживайте здоровье RD Connection Broker и базы RDCms, а в аварийной ситуации используйте прямое теневое подключение к RDSH и стандартные диагностические шаги (журналы, проверка статуса базы, очистка pending reboot с осторожностью). Эти меры вместе минимизируют риск потери коллекции сеансов и обеспечат продолжение работы теневого подключения и администрирования.