Microsoft опубликовала ручной сценарий восстановления для серверов WSUS, где из-за накопившихся метаданных обновления Windows либо синхронизировались слишком долго, либо упирались в тайм-аут. Для российских IT-команд, которые до сих пор держат у себя Windows Server Update Services и завязанные на него процессы, это не абстрактная история из чужого дата-центра: сбои синхронизации WSUS напрямую бьют по срокам патч-менеджмента, а значит и по рискам для инфраструктуры.
Проблема затрагивает клиентские системы Windows 10 версии 1607 и новее, а также серверные платформы Windows Server 2012 и новее, сообщает BleepingComputer. На затронутых инсталляциях администраторы не могли штатно раскатывать свежие обновления через WSUS или Configuration Manager: синхронизация занимала ненормально много времени, а иногда просто завершалась по тайм-ауту. Причина, по версии Microsoft, в разросшемся массиве publishing metadata — служебных метаданных публикации, которые накопились в существующих WSUS-базах и начали тормозить весь процесс.
Microsoft уточняет хронологию довольно конкретно. Усиление влияния проблемы компания заметила 13 июля 2026 года. В субботу, 18 июля, она выкатила server-side mitigation, который должен был помочь новым или заново собранным WSUS-серверам. Иными словами, если сервер установили с нуля или восстановили заново, синхронизация после этого должна была вернуться в норму. Но для уже работающих инсталляций одного «починили на стороне сервиса» не хватило. Поэтому 21 июля Microsoft выпустила отдельные ручные меры для тех, у кого сбои синхронизации WSUS никуда не делись.
Суть исправления не сводится к нажатию одной кнопки в консоли. Администраторам предлагают сначала сделать резервную копию каждой базы SUSDB, затем через SQL Server Management Studio выполнить cleanup-запрос для всех этих баз, включая WSUS replica-серверы. После этого нужно вернуть параметр MaxXMLPerRequest к значению по умолчанию. Дальше начинается уже знакомая серверная рутина: переиндексация SUSDB, запуск WSUS Server Cleanup Wizard и очистка кэшированного состояния каталога через IISReset или recycle пула приложений WsusPool. Отдельно Microsoft предупреждает, что первый Windows Update scan после очистки может занять больше времени обычного, зато следующие проверки должны проходить уже в штатные сроки. Ещё один нюанс: клиентский файл DataStore.edb после удаления detectoids сам по себе не уменьшается. Компания прямо пишет, что это ожидаемое поведение и на производительность последующих сканов оно не влияет.
Для корпоративной инфраструктуры здесь важен не только сам баг, но и его повторяемость. Это уже не первый случай за последние месяцы, когда WSUS начинает вредить ровно в тот момент, когда от него ждут скучной предсказуемости. Microsoft уже закрывала схожие проблемы в мае, июле и августе 2025 года — тогда они тоже мешали администраторам получать и разворачивать актуальные обновления Windows. Патч-канал, который должен сокращать окно уязвимости, периодически сам становится источником задержки. Для старых Windows-ландшафтов это неприятное напоминание: чем больше в инфраструктуре исторических слоёв, реплик, прокси и аккуратно переживших миграции WSUS-серверов, тем выше шанс, что сбой окажется не в самой доставке обновления, а в накопившемся техническом осадке вокруг неё.
Практический вывод для администраторов и IT-руководителей довольно приземлённый. Если в компании всё ещё используется WSUS как основная точка управления обновлениями, стоит проверить, не выросли ли в последние дни время синхронизации и число неудачных сканов. Если да, то проблема, вероятно, не в сети, не в очередном «глючном агенте» на клиентах и не в загадочной фазе луны, а в той самой базе метаданных, которую годами никто не трогал, пока она не решила напомнить о себе. Это ещё и повод пересмотреть операционную дисциплину вокруг WSUS: регулярное обслуживание SUSDB, контроль индексов, очистка мусора и проверка параметров IIS выглядят скучно ровно до первого массового сбоя в окне обновлений. А если инфраструктура опирается на Configuration Manager, зависимость никуда не исчезает: когда базовый механизм синхронизации буксует, надстройка сверху не спасает.
Для разработчиков и продактов история тоже не совсем чужая. В средах, где тестовые стенды, VDI, офисные ПК и серверы обновляются по корпоративным регламентам, задержка обновлений легко превращается в фоновый операционный шум: отложенные проверки совместимости, нестабильные окна релизов, лишние согласования с безопасниками. Чем дольше тянется такой сбой, тем выше соблазн обойти централизованный процесс и «поставить руками», а это уже прямой путь к разношёрстной инфраструктуре. Ирония здесь простая: система, созданная ради управляемости, в плохой день сама подталкивает к ручному хаосу.
Вся эта история поднимает неприятный, но полезный вопрос: сколько ещё корпоративных Windows-контуров держатся на WSUS как на незаметной опоре, которую вспоминают только в момент поломки. Пока Microsoft продолжает выпускать точечные исправления и ручные рецепты очистки, рынок получает всё более прозрачный сигнал: старый патч-стек ещё жив, но требует к себе почти архивного внимания. И чем чаще сбои синхронизации WSUS лечатся через резервные копии, SQL-запросы и ручную уборку метаданных, тем громче звучит вопрос не только о ремонте очередного сервера, но и о пределе жизнеспособности всей этой схемы.