Полезные статьи

Microsoft закрыла RDP-баг в Windows Server 2022 и 2019: вышли KB5129237 и KB5129238

Через неделю после сентябрьского фиаско с зависающим RDP (см. статью ниже) Microsoft выпустила внеплановые (out-of-band) кумулятивные обновления, которые закрывают проблему на уровне патча, а не обходного пути.

Что чинят

Оба пакета кумулятивные — включают в себя всё из сентябрьского CU (KB5122882 для 2022, KB5122876 для 2019), переустанавливать который отдельно не нужно. Основная правка — тот самый дедлок в Remote Desktop Services после установки сентябрьского обновления безопасности: зависания при подключении по RDP, невозможность входа, а иногда и полная неотзывчивость сервера в процессе настройки удалённого рабочего стола. Заодно тянутся зависшие MMC, RDS Licensing Diagnoser, File Explorer и страница Центра обновления. Попутно в 2022-й сборке закрыт баг с USB Audio Class 1.0 на многоканальном звуке.

Скачать

• KB5129237 для Windows Server 2022 — Microsoft Update Catalog →
• KB5129238 для Windows Server 2019 — Microsoft Update Catalog →
• Официальная страница KB5129237 →

Как ставить

Скачать .msu-пакет со своей архитектурой (x64) → установить → перезагрузка обязательна, это полноценный servicing-рестарт, не hotfix без ребута. После загрузки — проверить сборку:

$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.CurrentBuild).$($cv.UBR)"

Для 2022 ожидаем 20348.5631, для 2019 — 17763.9247. После установки стоит проверить именно новые RDP-логоны, а не только уже открытые сессии — баг проявлялся в первую очередь на них.

Что думаем по этому поводу

Если коротко — сначала выкатили обновление, которое кладёт RDP на ровном месте на серверах без единой RDS-роли, потом неделю чинили через полукустарный KIR, который часть админов вообще не увидела, потому что рассылку получили не все. Для патча безопасности, который должен закрывать критичную RCE, это, мягко говоря, не образец инженерной культуры.

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

Если у вас есть серверы на 2022 или 2019, которые всё ещё живут на сентябрьском CU без KIR — сейчас самое время закрыть вопрос сразу нормальным патчем, а не полумерой. Если разбираться с этим самостоятельно нет времени или желания — обращайтесь, накатим, проверим и оставим мониторинг на пару дней, чтобы вы были уверены, что всё встало на место.

Фатальное обновление Windows Server 2022: что сломалось и как это починить

Сентябрьский Patch Tuesday 2026 года привёз обновление KB5122882 (сборка 20348.5622), которое ломает Remote Desktop. Ломает не сразу: сервер работает нормально несколько часов после перезагрузки, а потом новые RDP-подключения намертво зависают на «Connecting…», пользователи не могут разлогиниться, Task Manager и query user встают вместе с ними. Штатная перезагрузка тоже не проходит — помогает только hard reset, до следующего раза.

Проверено на живом сервере. Ниже — что именно происходит, как это опознать и как починить, не снимая сентябрьские патчи безопасности.

Кого затронуло

Важный момент: роль RDS для проявления бага не нужна. Обычный административный RDP — те самые две сессии — ложится точно так же на голом Server 2022 без RDSH. То есть под удар попадают в том числе контроллеры домена и одиночные standalone-серверы.

Причина

Дедлок в пути завершения сессии. Функция RDPSERVERBASE!WDLIB_Close при активном внутреннем feature-флаге 3802373433 вызывает RtlWaitOnAddress без таймаута. Поток висит бесконечно, а поскольку Local Session Manager сериализует все изменения состояния сессий через одну критическую секцию — за этим потоком встаёт очередь из всего остального: новых подключений, логоффов, запросов брокера.

Реверс сделал независимый исследователь на живом Server 2022. Microsoft причину публично не подтверждал, но 13 сентября сменил статус проблемы на Mitigated и выпустил Known Issue Rollback.

Как опознать

Сначала проверяем сборку:

$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.CurrentBuild).$($cv.UBR)"

Для Server 2022 проблемная — 20348.5622. Затем ищем в журналах три характерные подписи:

• Event 20498, TerminalServices-RemoteConnectionManager/Admin — RDS слишком долго устанавливает клиентское подключение.
• Event 6005, Microsoft-Windows-Winlogon (журнал System) — подписчик SessionEnv долго обрабатывает Disconnect.
• TermService в состоянии StopPending вместо Running — дедлок уже активен.

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
    Id      = 20498
} -MaxEvents 5 -ErrorAction SilentlyContinue

Если журнал чист и служба в Running — хост либо ещё не дошёл до нужного условия, либо не затронут.

Почему не стоит просто снести обновление

Тот же пакет закрывает CVE-2026-69525 — критический RCE в Remote Desktop Services с CVSS 9.8. Плюс два зеродея, уже эксплуатируемых и внесённых в каталог CISA KEV: CVE-2026-81963 (стек Windows Update) и CVE-2026-85880 (ALPC). Если сервер смотрит в интернет, полный откат — крайняя мера, а не первый шаг.

Отдельно: wusa /uninstall /kb:5122882 не сработает в принципе. Сентябрьские обновления пришли комбинированным пакетом SSU + LCU, SSU удалению не подлежит, и standalone-инсталлятор отклоняет всю сборку целиком.

Правильный фикс: официальный KIR

Microsoft выпустил Known Issue Rollback — механизм, который откатывает конкретное проблемное изменение, оставляя все патчи безопасности на месте. Для Server 2022 это пакет KB5122882 260911_18471. Рассылку получили только подписчики с корпоративным лицензированием Microsoft 365 или Windows, поэтому многие о нём просто не узнали — но сами MSI лежат в публичном доступе.

1. Скачать MSI для своей версии и установить его.
2. Установщик кладёт ADMX/ADML в %SystemRoot%\PolicyDefinitions. В домене — скопировать их в central store \\domain\SYSVOL\domain\Policies\PolicyDefinitions\. На standalone-сервере этот шаг не нужен: локального хранилища достаточно.
3. Открыть gpedit.msc (или GPMC в домене) → Computer Configuration → Administrative Templates → раздел, привязанный к KB5122882.
4. Перевести политику в Enabled.
5. Выполнить gpupdate /force.

gpedit.msc есть в Server 2022 Standard, не только в Datacenter — отдельная доменная инфраструктура для развёртывания KIR не требуется. Перезагрузка по документации не нужна, но события 20498 и 6005 стоит мониторить 24–48 часов, особенно в часы массовых логоффов.

Грабли: DISM может отказать

Классический путь для уже мёртвого хоста — hard reset, потом удаление пакета через DISM:

dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"
dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2 /NoRestart

Но DISM вполне может ответить, что пакет стал неотъемлемой частью системы и удалению не подлежит. Это значит, что на хосте уже отработала очистка компонентов — /StartComponentCleanup /ResetBase вручную либо соответствующая запланированная задача. После ResetBase компонентное хранилище больше не держит предыдущие версии файлов, и откат конкретно этого обновления становится невозможен в принципе.

Если откат всё же прошёл — сразу заблокируйте обновление от повторной установки: decline в WSUS либо GPO-отсрочка обновлений. Иначе оно вернётся в следующее окно обслуживания.

Что делать, если сервер уже висит

Применить KIR на зависшем хосте не получится — он недоступен ни по RDP, ни по remote management. Порядок такой: hard reset, затем сразу, не дожидаясь повторного дедлока, применяем KIR (или, если он недоступен, снимаем обновление через DISM). Окно — несколько часов после загрузки.

Свой сервер, colocation, dedicated или VDS: что выбрать

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

Собственный сервер в ЛВС — классика для небольших офисов: полный контроль над данными, но и полная ответственность за питание, охлаждение и ремонт при поломках.

Colocation снимает вопрос инфраструктуры — сервер ваш, но стоит в дата-центре провайдера с надёжным питанием, каналом и охраной. Аренда dedicated-сервера убирает и вопрос владения железом: провайдер сам обслуживает и меняет комплектующие, но конфигурация ограничена тем, что есть в наличии. VDS/VPS — самый гибкий и доступный вариант с быстрым масштабированием ресурсов, но без полного контроля над физическим сервером.

Коротко о плюсах и минусах

Где держать 1С: локально, в облаке, на арендованном сервере или через веб-клиент

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

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

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

Коротко о плюсах и минусах

Безопасный обмен короткими сообщениями

Не доверяете даже Threema и Signal, не говоря уже о Viber и Telegram? При этом защищённый обмен сообщениями, документами и фото по-прежнему важен?

Решение — собственный Jabber-сервер с компонентом шифрования OMEMO. Это не панацея от атак «человек посередине» и социальной инженерии, но в связке с VPN и разграничением доступа по IP заметно повышает безопасность, уверенность и спокойствие.

Обращайтесь — разверну и настрою под ваши задачи.

Почтовый сервер для совместной работы

Календари, удобная почта, совместная работа с файлами. В «энтерпрайзе» первым делом вспоминают Microsoft Exchange — но это далеко не единственный вариант.

Zimbra Collaboration Suite (ZCS) — зрелая альтернатива Exchange с элементами Google Docs и Google Workspace. Продукт родился в калифорнийской компании Zimbra: в 2007 году её купил Yahoo!, в 2010-м бизнес перешёл к VMware, а в 2013-м — к Telligent Systems. ZCS доступна в нескольких редакциях, включая бесплатную Open Source Edition.

Что входит в поставку

• Zimbra Web Client — веб-интерфейс на AJAX с общим доступом к почте и календарям, продвинутым поиском и модулями Zimlet.
• Zimbra Desktop — почтовый клиент для Linux, Windows и macOS с поддержкой POP/IMAP и синхронизацией с Zimbra, Yahoo! Mail и Gmail.
• Zimbra Server — сервер на Linux или macOS с полноценным SOAP API, IMAP- и POP3-доступом.

ZCS совместим с Outlook и Apple Mail через собственные модули, а также с открытым Novell Evolution — почта, контакты и календарь переносятся без потерь. Поддерживается синхронизация и с мобильными устройствами.

Более 20 внедрений Zimbra — обращайтесь.

Облачный офис

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

Это моя основная услуга: более 40 внедрений по России и несколько — в Европе.

Коротко о плюсах и минусах

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

Защита протокола RDP

RDP (Remote Desktop Protocol) — популярный способ удалённого доступа к рабочим станциям и серверам и один из самых частых векторов атак, если оставить его «как есть». Минимальный набор мер, которые стоит включить:

• Сложный уникальный пароль — не переиспользуемый для других сервисов.
• Двухфакторная аутентификация — вход по паролю плюс код с отдельного устройства.
• Шифрование трафика — TLS/SSL для канала между клиентом и сервером.
• VPN — для удалённой работы подключение к RDP лучше заворачивать через VPN-туннель.
• Ограничение доступа — только нужным пользователям и компьютерам, по белым спискам IP.
• Регулярные обновления — ОС, антивирус, сам RDP-сервер.
• Мониторинг активности — отслеживание подозрительных попыток входа.
• Ограничение прав клиента — доступ только к своим файлам, не к чужим.
• Отключение лишних функций — проброс принтеров, дисков, звука, если они не нужны.
• Проверка логов — регулярный аудит событий сервера.

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