RDS не работает после обновления: сбой в сентябре 2026

После обновлений Windows от 8 сентября 2026 года часть организаций столкнулась с зависаниями Remote Desktop Services (RDS). Подключение по RDP обрывалось через несколько минут, вход останавливался на ожидании настройки удалённого рабочего стола, а вместе с ним могли зависнуть административные оснастки. 14 сентября Microsoft выпустила исправление: KB5129235 для Windows Server 2025 и KB5129237 для Server 2022. Ниже — исходные пакеты, исправленные сборки и порядок проверки сервера.

Если терминальный сервер исправно работал до сентябрьского обновления, начните с проверки установленного пакета и симптомов. Зависший RD Licensing Diagnoser сам по себе не доказывает, что закончились лицензии. Покупка RDS CAL не устраняет ошибку обновления.

Дополнение от 15 сентября. Если после KB5124008 рабочая станция Windows 11 отклоняет правильный пароль, а проверка показывает нарушение защищённого канала, проверьте сбой входа в домен после обновления Windows 11. Этот сценарий отличается от зависания RDS: в описании экстренного KB5129195 отдельное исправление доверия к домену не заявлено.

Что известно о сентябрьском сбое

По состоянию на 14 сентября 2026 года страницы Windows Release Health для Server 2025 и Server 2022 отмечают инцидент RDS статусом Resolved. Исправление входит во внеплановые накопительные обновления (OOB) от 14 сентября и последующие обновления. На конкретном сервере результат зависит от установки подходящего пакета.

Таблица помогает сопоставить два распространённых серверных выпуска. Перечень затронутых платформ у Microsoft шире: в нём есть и другие версии Windows Server, а также клиентские Windows с включённым удалённым рабочим столом. Для другой системы проверяйте её собственную страницу состояния и номер пакета; устанавливать KB от Server 2025 на Server 2022 нельзя.

Характерная комбинация: после обновления перестают нормально открываться сеансы, появляется ожидание Remote Desktop Configuration, зависают MMC, Проводник или страница Windows Update. Не каждый отдельный обрыв RDP относится к этому инциденту. Важно, когда началась проблема, какие машины обновились и что происходит через консоль сервера.

Как отличить обновление от проблемы с лицензированием

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

При явной лицензионной ошибке пригодится разбор почему недоступны серверы лицензирования удалённых рабочих столов. Если совпал срок после развёртывания, проверьте 120-дневный льготный период RDS. Эти причины могут существовать отдельно от сентябрьского сбоя.

Порядок проверки для администратора

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

1. Зафиксируйте систему и обновление. Через доступную консоль откройте сведения о Windows и историю установленных обновлений. Запишите выпуск ОС, полную сборку, KB и время установки. Если страница Windows Update зависла, отметьте это как симптом и используйте доступные сведения системы или журнал вашей системы развёртывания обновлений.
2. Определите масштаб сбоя. Проверьте вход с другого разрешённого рабочего места и состояние одного другого узла той же коллекции. Запишите, зависает ли сервер сразу или спустя несколько минут, открываются ли MMC и Проводник через консоль. Не распространяйте экспериментальные изменения на всю ферму.
3. Сопоставьте результат с известной проблемой. Откройте Release Health для установленной версии. Если KB и сочетание симптомов совпадают, рассматривайте сентябрьский инцидент как рабочую гипотезу. Если нет, продолжите обычную диагностику сети, служб и лицензирования.
4. Установите исправление для своей версии Windows Server. Откройте ссылку KB из таблицы и раздел How to get this update. Оба OOB-пакета от 14 сентября доступны только через Microsoft Update Catalog; обычная проверка Windows Update их не предложит. Скачайте подходящий пакет и выполните установку по инструкции KB. Для Server 2025 учтите порядок MSU и необходимый checkpoint KB5043080, если он ещё не установлен. Если ранее применялась временная мера через Group Policy, Microsoft не требует дополнительных действий перед установкой OOB.
5. Проверьте сборку и работу сеансов. Завершите установку и предусмотренный ею перезапуск. Сверьте сборку с таблицей, выполните вход, откройте рабочее приложение и административную оснастку. Наблюдайте дольше прежнего интервала до зависания: успешный первый вход ещё не означает устойчивую работу. Сохраните время и результат проверки, затем продолжайте развёртывание по принятой процедуре.
6. При повторении сбоя передайте данные в поддержку. Укажите версии ОС и клиентов, исходный KB и установленное OOB, итоговую сборку, время первого сбоя, затронутые узлы и результат проверки. Если ошибка сохранилась на исправленной сборке, продолжайте диагностику вместе с поддержкой; циклические перезапуски не заменяют поиск причины.

Что изменилось с 12 сентября. В предыдущей редакции статьи stop (deallocate) и последующий запуск недоступной VM описывались как временная мера до выхода патча. Это операция платформы виртуализации, отличная от обычного перезапуска Windows. После выпуска OOB 14 сентября основной путь — установить исправление для своей ОС и проверить результат; прежняя мера не заменяет обновление.

Исходное обновление KB5122882 для Server 2022 остаётся ориентиром при проверке истории сбоя. Исправляющее OOB накопительное и включает предшествующие улучшения и защиту. Если нужна помощь с недоступным сервером или установкой пакета, обращайтесь в Microsoft Support for Business; доступность поддержки зависит от договора и региона.

Если картина не похожа на подтверждённый инцидент

Проверьте, разрешены ли удалённые подключения политикой организации, работают ли службы Remote Desktop Services и доступен ли нужный узел по сети. Через консоль можно выполнить qwinsta: запись rdp-tcp в состоянии Listen показывает, что слушатель принимает подключения. Это полезная проверка компонента, но не подтверждение успешного входа пользователя.

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

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

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

Когда действительно нужны RDS CAL

Переходите к лицензиям, если отдельная проверка выявила неверный режим, недоступный сервер лицензирования, несовместимую версию или нехватку прав. Сначала восстановите работу уже имеющейся конфигурации. В Server Manager откройте Tools → Terminal Services → RD Licensing Diagnoser, когда оснастка снова отвечает, и прочитайте конкретное сообщение.

Для выбора типа действует правило: User CAL лицензирует пользователя, Device CAL лицензирует устройство. Считают всех людей или устройства, которым предоставляется доступ, а не пиковое число одновременных сеансов. Ориентиры для сменных рабочих мест и личных устройств разобраны в примерах выбора User и Device CAL.

Если сотрудники домена подключаются с нескольких устройств и для них подтверждена отдельная потребность в правах доступа, в каталоге есть RDS User CAL 2025 на 50 пользователей. Такой пакет не заменяет лицензирование самой Windows Server и базовые Server CAL.

Хит продаж 5.02 отзыва

Microsoft Windows Server 2025 RDS User CAL

50 пользователей

• Активация у правообладателя
• Выдача на почту обычно за минуту
• Гарантия 12 месяцев или на срок подписки

5 990 ₽

Подробнее

Для посменной работы нескольких людей за одними терминалами сравните RDS Device CAL 2025 на 50 устройств. В рабочей группе без Active Directory для RDS требуется режим Per Device. Сам тип CAL не меняет поведение сентябрьского обновления.

Хит продаж 5.02 отзыва

Microsoft Windows Server 2025 RDS Device CAL

50 устройств

• Активация у правообладателя
• Выдача на почту обычно за минуту
• Гарантия 12 месяцев или на срок подписки

5 990 ₽

Подробнее

Для сохраняемого узла Server 2022 может подойти RDS User CAL 2022, если выбран пользовательский режим и выполнены остальные условия развёртывания. CAL 2022 не даёт доступ к узлу сеансов Server 2025. Для установки CAL 2025 нужен и совместимый сервер лицензирования версии 2025 или новее. Обе зависимости приведены в таблицах совместимости RDS CAL.

При работе с 1С отдельно проверьте права на сервер, доступ пользователей и прикладное ПО. Эти уровни разобраны в материале о терминальном сервере для 1С. Исправление соединения RDP само по себе не подтверждает, что весь комплект лицензий организации достаточен.

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

Полезный отчёт содержит точное время с часовым поясом, версию клиента, имя затронутого узла, путь подключения и описание того, что осталось доступно через консоль. Добавьте сборку, KB и результат сравнения с другими узлами. Формулировка «RDP не работает» без этих деталей заставит поддержку заново устанавливать обстоятельства.

Для углублённой диагностики Microsoft описывает сбор данных TSS на клиенте, узлах сеансов и сервере лицензирования в руководстве по соединениям RDS. Согласуйте такой сбор с администратором: он требует повышенных прав, а диагностические материалы следует передавать через одобренный канал поддержки. Скрипт сбора данных не является исправлением обновления.

Частые вопросы

Сбой подтверждён только для Windows Server 2025?
Нет. Microsoft указывает более широкий перечень серверных и клиентских Windows. В этой статье отдельно приведены пакеты для Server 2025 и 2022; для других версий проверяйте их страницы Release Health.

Исправление сентябрьского сбоя RDS уже выпущено?
Да. 14 сентября 2026 года Microsoft перевела инцидент в Resolved: для Server 2025 выпущено KB5129235, для Server 2022 — KB5129237. Эти OOB доступны только через Microsoft Update Catalog.

Зависший RD Licensing Diagnoser доказывает нехватку CAL?
Нет. Зависание этой оснастки входит в описанные симптомы инцидента. Проверять конкретные лицензионные сообщения нужно после восстановления её работы.

Нужно ли отменять временную Group Policy перед OOB?
Нет. Microsoft указывает, что администраторам, ранее применившим временную меру через Group Policy, не нужно выполнять дополнительные действия перед установкой OOB.

Нужно ли всем удалять сентябрьское обновление?
Нет. Для подтверждённого инцидента RDS Microsoft выпустила накопительное исправление. Сначала сопоставьте ОС, KB и симптомы, затем установите подходящее OOB по процедуре организации. Массовый откат по одному похожему симптому не нужен.

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

Новая RDS CAL исправит этот сбой?
Нет. CAL нужна при отдельной подтверждённой потребности в лицензировании. Ошибка обновления требует технического решения для затронутой системы.

Можно купить CAL 2022 для узла сеансов Server 2025?
Нет. Нужна совместимая версия CAL; для Server 2025 это CAL 2025 или более новая применимая версия. Учитывайте также версию сервера лицензирования и выбранный режим User или Device.