Microsoft исправила сбой WUSA, из-за которого обновления Windows, выпущенные с 28 мая 2025 года, могли не устанавливаться из сетевых папок. Для домашних ПК история почти незаметная, а вот для корпоративных Windows 11 24H2, 25H2 и Windows Server 2025 это неприятный удар по привычным сценариям развёртывания патчей: вроде всё штатно, а обновление не доезжает.
О проблеме сообщает BleepingComputer. Речь идёт о Windows Update Standalone Installer, или WUSA, встроенном инструменте командной строки для установки и удаления автономных пакетов обновлений в формате .msu через Windows Update Agent API. Именно им администраторы часто пользуются там, где обновления нужно раскатывать не через обычный Windows Update, а через внутренние процессы, скрипты и сетевые шары с набором пакетов.
Сбой выглядел довольно коварно, потому что проявлялся не всегда. По данным Microsoft, ошибка возникала, когда администратор запускал установку через WUSA или просто открывал .msu-файл двойным кликом из сетевой папки, где лежало сразу несколько .msu-файлов. В таком случае система могла вернуть ERROR_BAD_PATHNAME. Если же файл был один или его заранее копировали локально на устройство, проблема не воспроизводилась. Для тех, кто сопровождал инфраструктуру, это неприятный тип дефекта: он бьёт не по самому обновлению, а по способу доставки, поэтому диагностика легко уходит не туда.
Технически важная деталь в том, что проблема затронула не все обновления подряд, а пакеты начиная с релиза от 28 мая 2025 года, известного как KB5058499, и более поздние. Это сужает круг поиска для администраторов, которые разбирали неудачные установки задним числом. Если после конца мая 2025-го пайплайн установки из сетевой папки внезапно начал вести себя нестабильно, виноват мог быть не сетевой доступ, не права и не повреждённый .msu, а именно сбой WUSA на затронутых версиях Windows.
Что именно исправили
Полное исправление Microsoft включила в июньский Patch Tuesday 2026 года. Для Windows 11 это накопительное обновление KB5079391, для Windows Server 2025 — KB5094125. После их установки сценарий с запуском .msu из сетевого ресурса должен снова работать корректно на всех затронутых системах. Это уже не временная заплатка для части устройств, а нормальный фикс в регулярной линии кумулятивных обновлений.
До этого Microsoft лечила проблему поэтапно. Ещё в сентябре 2025 года компания начала автоматически смягчать эффект бага на домашних и неуправляемых бизнес-устройствах через механизм Known Issue Rollback и групповую политику. Но для корпоративной среды, где как раз чаще встречаются нестандартные схемы развёртывания и строгий контроль обновлений, этого было недостаточно: предприятиям нужен был не обходной манёвр, а предсказуемое поведение платформы. И вот только в июне 2026 года сбой WUSA официально закрыли для всей затронутой линейки.
Пока июньские кумулятивные обновления не были установлены, Microsoft советовала простой, но показательный обходной путь: сохранять .msu-файлы локально на устройство и запускать установку уже оттуда. Формально это решение работает, но в крупных сетях такой совет звучит как возвращение к ручному режиму там, где всё давно должно быть автоматизировано. Если у компании раздача патчей строится через сетевые каталоги, дополнительные копирования на локальный диск означают лишние шаги, больше точек отказа и больше шансов, что реальный процесс начнёт расходиться с документацией.
Есть и ещё одна деталь, на которую Microsoft отдельно указала: после установки .msu через WUSA и перезагрузки не стоит сразу бежать в журнал обновлений в настройках. Компания рекомендует подождать не меньше 15 минут, прежде чем проверять историю обновлений, иначе интерфейс Settings может некорректно показать статус. Для администраторов это важное замечание, потому что в инцидентах с обновлениями ложная отрицательная индикация почти так же вредна, как реальная ошибка. Когда панель говорит, что патч не встал, команды обычно начинают повторный прогон, искать проблему в логах и трогать систему лишний раз.
Почему это важно не только для админов Windows
На первый взгляд история узкая: WUSA, .msu, сетевые шары, корпоративные устройства. Но именно такие «узкие» баги чаще всего и обходятся бизнесу дороже всего. Домашний пользователь просто нажмёт «Обновить позже», а у компании есть окно обслуживания, зависимые сервисы, контроль соответствия политике безопасности и отчётность по установке патчей. Когда ломается один из тихих служебных механизмов, проблема быстро выходит за рамки Windows-команды и касается уже ИБ, эксплуатации и владельцев внутренних сервисов.
Контекст тоже показательный. Microsoft за последний год уже разбиралась с несколькими сбоями вокруг корпоративного обновления Windows. В апреле 2025 года компания устранила проблему, которая мешала ставить апрельские security-обновления через WSUS. Позже всплыл похожий дефект, из-за которого августовские обновления Windows 11 2025 года могли падать с ошибкой 0x80240069. А уже на этой неделе Microsoft отдельно предупредила, что на некоторых системах, обновлённых до Windows 11 24H2 или 25H2, могут возникать сложности с установкой свежих ежемесячных пакетов. Картина складывается не катастрофическая, но довольно утомительная: механика обновлений в корпоративном контуре становится зоной, где без тестового кольца и нормальной валидации лучше ничего не разворачивать.
Для русскоязычной IT-аудитории вывод приземлённый. Если в инфраструктуре ещё используется установка .msu из сетевых папок, стоит проверить, не попадают ли устройства под сочетание Windows 11 24H2, 25H2 или Windows Server 2025 с обновлениями после KB5058499. Если попадают, логика простая: либо уже перейти на июньские накопительные пакеты 2026 года, либо как минимум исключить сетевой сценарий до обновления базовой системы. И заодно пересмотреть сам процесс контроля установки: один источник истины в виде GUI давно не спасает, нужны журналы, скриптовая проверка и тестовая группа перед широким развёртыванием.
Главный вопрос здесь даже не в том, что конкретный баг закрыт, а в том, насколько надёжными остаются старые корпоративные сценарии обслуживания Windows на фоне постоянной перестройки клиентских и серверных веток. Чем больше в компании завязано на полуавтономную доставку патчей, локальные репозитории и собственные скрипты, тем дороже становится каждый такой сбой WUSA, даже если формально он чинится очередным кумулятивным обновлением.