Microsoft починила баг с обновлением до Windows 11 24H2 через WSUS

Microsoft починила баг с обновлением до Windows 11 24H2 через WSUS

Microsoft починила баг с обновлением до Windows 11 24H2 через WSUS

Если ты админ в компании и используешь WSUS для раздачи обновлений — хорошие новости: Microsoft наконец-то починила проблему, из-за которой Windows 11 24H2 не загружалась через локальный сервер обновлений.

Баг появился после апрельского патча безопасности (KB5055528, выпущен 8 апреля 2025 года) и вызывал у многих пользователей ошибки 0x80240069 при попытке обновиться с версий 22H2 или 23H2.

Служба обновлений Windows (wuauserv) просто «падала» и ничего не происходило. Проблема затрагивала только корпоративные среды — дома её никто не замечал, потому что WSUS (Windows Server Update Services) используется исключительно в бизнес-сетапах.

Это та самая система, которая позволяет централизованно управлять апдейтами, а не полагаться на то, что каждый ПК сам тянет их с серверов Microsoft.

Сейчас Microsoft начала раскатывать автоматический откат Known Issue Rollback (KIR), чтобы исправить ситуацию. Правда, пока ещё не на всех устройствах. Чтобы ускорить процесс, админам нужно вручную установить групповую политику KIR на затронутые машины с Windows 11 22H2 и 23H2.

Как это делается: через Group Policy Editor — на локальном ПК или на контроллере домена. После применения политики потребуется перезагрузка, чтобы всё заработало.

Подробная инструкция — как всегда — на сайте Microsoft в разделе документации.

И это ещё не всё. Microsoft призналась, что работает над устранением другой проблемы: некоторые ПК неожиданно обновляются до Windows 11, несмотря на запрет в политике Intune.

Такая «самодеятельность» уже случалась раньше — в ноябре компания сообщала о похожих случаях с серверами Windows Server 2019 и 2022, которые внезапно обновились до Server 2025 без спроса.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

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

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

Через 120 секунд задача автоматически перешла в фон. Агент запросил остановку и получил сообщение об успехе, однако, судя по описанным изменениям файловой системы, удаление продолжалось. Вероятное объяснение — дочерний процесс пережил остановку задачи.

Проверка тоже оказалась поверхностной: агент посмотрел на названия папок верхнего уровня, которые могли сохраняться, пока их содержимое исчезало.

Пользователь сообщил о потере проектов за несколько месяцев, инструментов разработки, SSH-ключей и учетных данных. В корзине удаленные файлы не оказались. Обращение помечено как ошибка высокого приоритета с потерей данных.

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

RSS: Новости на портале Anti-Malware.ru