Microsoft 4 июня закрыла сбой, из-за которого обновления драйверов Windows на части корпоративных устройств устанавливались без предупреждения и вопреки настроенным ограничениям. Для компаний, которые держат парк ПК под жёстким контролем через Intune и Windows Update, история неприятная: если политика запрещает автодеплой драйверов, администраторы ожидают именно запрет, а не сюрприз в виде BIOS-апдейта на рабочей машине.
О проблеме, как пишет BleepingComputer, Microsoft сначала сообщила 2 июня, а уже 4 июня объявила инцидент закрытым. В отчёте в центре администрирования под номером MO1332784 компания связала сбой с некорректной конфигурацией кэширующего сервиса Windows Update. Из-за этого сервис временно терял сведения о регистрации части устройств, и такие машины начинали обрабатываться как незарегистрированные. В результате механизмы одобрения драйверов, на которые рассчитывают ИТ-отделы, применялись некорректно или не применялись вовсе.
Формулировка у Microsoft довольно аккуратная: драйверы, которые успели разъехаться по устройствам, были подписаны и одобрены самой компанией, поэтому угрозы безопасности в прямом смысле она не увидела. Но для инфраструктурной команды это слабое утешение. Подписанный драйвер не равен безболезненному драйверу, особенно когда обновление прилетает вне окна изменений и без теста на конкретной модели железа. По сообщениям администраторов, с которыми столкнулась отраслевая пресса и обсуждения в сообществах, речь в отдельных случаях шла о десятках тысяч устройств, получивших неожиданные обновления BIOS и драйверов. После этого на части машин переставали нормально работать аудио- и видеоустройства.
Технически сбой выглядит особенно неприятно именно потому, что ударил не по домашним ПК, а по корпоративной логике управления. В больших Windows-парках драйверы давно перестали быть мелочью из разряда «поставим и посмотрим». Их выкатывают по кольцам, ограничивают по моделям, согласуют с вендорами и часто тормозят до ручного подтверждения. Причина простая: одно неверное обновление может не устроить громкий инцидент уровня ransomware, но легко положит переговорные комнаты, колл-центры, графические станции или ноутбуки топ-менеджеров перед важной встречей. Для бизнеса это не баг в вакууме, а вполне измеримый простой.
Microsoft сообщила, что для смягчения последствий обновила кэш затронутого сервиса и восстановила статус регистрации для пострадавших устройств. После этого компания получила подтверждение от части ранее затронутых пользователей и признала проблему устранённой. Параллельно Intune Support Team подтверждала инцидент в X и Reddit, то есть история не ограничилась сухой записью в админ-центре. Это важная деталь: когда поддержка публично комментирует проблему в нескольких каналах, обычно речь идёт уже не об единичной аномалии, а о сбое, который успели заметить в реальной эксплуатации.
Контекст для Microsoft здесь тоже не самый удобный. В апреле компания уже закрывала известную проблему, из-за которой системы на Windows Server 2019 и 2022 могли неожиданно обновиться до Windows Server 2025. В мае она исправляла другой баг: на части устройств с Windows 11 под управлением Autopatch в странах Евросоюза всё равно устанавливались драйверы, хотя административные политики ограничивали их развёртывание. Теперь добавился ещё один эпизод, снова связанный с обходом управленческих ограничений. По отдельности такие случаи можно списывать на разные технические причины, но в сумме они выглядят как тревожный сигнал для платформы, которая продаёт enterprise-контроль как базовую ценность.
Для разработчиков и продуктовых команд внутри компаний из этой истории следует довольно приземлённый вывод: политика в MDM или Windows Update for Business не должна считаться единственным рубежом контроля. Если инфраструктура критична к состоянию драйверов, нужны дополнительные проверки на уровне инвентаризации, мониторинга и постфактум-алертов. ИТ-отделам имеет смысл пересмотреть, как быстро они узнают о незапланированном изменении BIOS или драйверного стека, какие группы устройств попадают под повышенный контроль и есть ли понятная процедура отката. Сбой в кэше Microsoft не отменяет того факта, что последствия разгребать приходится локальной команде.
Остаётся и более неудобный вопрос к самой модели «облачного» управления конечными устройствами. Чем больше логика принятия решений уходит в сервисы вендора, тем выше цена ошибки в его служебных состояниях: потеря сведений о регистрации на стороне платформы внезапно превращается в массовую установку того, что локальная политика запрещала. Microsoft уже пообещала разобраться, как именно кэширующий сервис временно сбрасывал данные о регистрации, чтобы лучше выявлять и предотвращать похожие сбои в будущем. Для корпоративных заказчиков этого, вероятно, будет мало: после серии историй с неожиданными апдейтами главный запрос теперь не к скорости исправления, а к предсказуемости самого контура управления Windows.