Обслуживание стека обслуживания Windows: добро пожаловать в кошмар
Завязать шнурки на ботинках достаточно сложно. И никто не хочет ходить с развязанными шнурками, так как вы можете споткнуться и расколоть себе череп. Однако обновление стека обслуживания в ваших системах Windows и Windows Server — это нечто иное. Это жизненно важно для безопасности вашей инфраструктуры на базе Windows. К сожалению, это также становится все более и более сложной задачей, а некоторые даже назвали бы ее кошмаром.
Попробуем разобраться в этом вопросе. Microsoft использует термин «обслуживание» для обозначения задачи по установке роли, функции, исправления или обновления программного обеспечения в установке операционной системы Windows или Windows Server. Онлайн-обслуживание происходит во время работы операционной системы; хорошим примером этого является загрузка и установка обновления безопасности или исправления. Обслуживание также может выполняться в автономном режиме, когда Windows не запущена, например, при монтировании образа Windows с помощью DISM и применении обновления к вашему образу. В этой статье мы сосредоточимся только на онлайн-обслуживании, когда речь идет о применении обновлений Windows.
Стек обслуживания: что это такое?
Термин «стек обслуживания» относится к группе компонентов Windows, которые делают возможным обслуживание в системах Windows. Эти компоненты включают хранилище компонентов (каталог %WinDir%winsxs), хранилище пакетов (каталог %WinDir%servicingpackages), различные исполняемые файлы и другой системный код, а также реестр (в частности, HKLMSOFTWAREMicrosoft Ключ реестра WindowsCurrentVersionComponent Based Servicing). Так было со времен Windows Vista и Windows Server 2008, и в основном так обстоят дела сегодня с Windows 10 и Windows Server 2019, за исключением некоторых улучшенных функций, которые были добавлены в команду DISM в более поздних версиях Windows. В любом случае, если вам интересно, вы можете узнать больше о том, как работает стек обслуживания Windows, в этих двух сообщениях в блоге Джозефа Конвея, который раньше был известен как Специалист по обслуживанию Windows. С тех пор он перешел в другие области в Microsoft, но его блог не закрыли (слава богу).
Однако проблема с точки зрения администратора заключается в том, что Microsoft иногда выпускает обновления стека обслуживания для разных версий Windows. Обновление стека обслуживания (SSU) — это, по сути, исправление, которое вы применяете к своей системе Windows или Windows Server, чтобы улучшить или исправить некоторые аспекты стека обслуживания в этой установке. Я не могу точно вспомнить, когда Microsoft начала выпускать внеплановые обновления для своих сервисных стеков — я думаю, что была выпущена одна или две публикации SP1 SSU для Windows 7 SP1 — но я помню, в частности, одну, которую Microsoft выпустила в начале 2014 года. которая перенесла новую функцию уменьшения размера хранилища компонентов, представленную в Windows 8.1, в более раннюю операционную систему Windows 8. Резервное копирование новых функций в предыдущие версии Windows звучит как хорошая идея, и в целом так оно и есть.
Но что происходит, когда SSU начинают летать влево и вправо для каждой выпущенной версии Windows, включая каждую поддерживаемую версию Windows 10? Что ж, ответ должен заключаться в том, что все в порядке, если есть простой способ определить, какой SSU подходит к какой версии Windows, и надежный способ убедиться, что соответствующие SSU установлены в ваших системах Windows.
Почему всегда должна быть проблема?
К сожалению, именно здесь часто начинаются неприятности. Что Microsoft в последнее время, похоже, не учитывала, так это то, как обновление стека обслуживания может помешать обновлению ваших клиентских и серверных систем Windows до последних обновлений. Проблема заключается в том, что если новый SSU выпускается одновременно с последним накопительным обновлением (CU) для Windows, перед установкой CU необходимо сначала применить SSU. К сожалению, до недавнего времени Microsoft часто упаковывала SSU вместе с CU, и если SSU по какой-то причине не устанавливается первым, установка CU завершается ошибкой. И, к сожалению, CU устанавливает сбой без уведомления о том, почему он сбой; вы не получаете уведомление Центра обновления Windows о том, что «Не удалось установить одно или несколько обновлений из-за устаревшего стека обслуживания» или что-то подобное. Вместо этого администраторам приходилось искать статьи базы знаний (KB), связанные с неисправным CU, чтобы прочитать «Важно! При установке обновления стека обслуживания (SSU) и последнего накопительного обновления (LCU) сначала установите SSU, чтобы устранить потенциальные проблемы. при установке LCU». Что ж, большое спасибо, что не сказали мне об этом раньше времени!
Однако эта неприятность обычно не влияет на обычных пользователей, потому что они обычно устанавливают обновления программного обеспечения напрямую, загружая их из Центра обновления Windows (WU), и в таких случаях SSU обычно устанавливается первым за кулисами, прежде чем будут установлены другие обновления. Однако обратите внимание, что если вы используете Центр обновления Windows напрямую для автоматического обновления клиентских систем, установленные SSU не отображаются в истории обновлений в Центре обновления Windows. Вместо этого вам нужно использовать DISM, чтобы убедиться, что последняя версия SSU была применена к вашей установке.
Если вместо этого вы являетесь предприятием или организацией, использующей службы Windows Server Update Services (WSUS) или System Center Configuration Manager (SCCM) для обновления Windows, обычно все работает одинаково — большую часть времени. К сожалению, WSUS/SCCM, по-видимому, время от времени дает сбой в связи с этим, а трудности с устранением неполадок возникают из-за того, что упаковка SSU в CU, как это происходило в прошлом, затрудняет определение того, было ли обновление для стек обслуживания требуется или был выпущен для CU этого месяца. Большая часть проблемы, по-видимому, заключалась в том, что Microsoft помечала SSU как «критические» обновления, а не как обновления «безопасности», хотя они, очевидно, важны с точки зрения безопасности, поскольку они гарантируют, что вы сможете установить последние CU в ваших системах.
Это одна из причин многих неудач, произошедших прошлой осенью с обновлениями, выпущенными Microsoft для своих платформ Windows. Чтобы решить эту проблему, Джон Уилкокс, евангелист Windows как услуга в Microsoft, в октябре прошлого года опубликовал комментарий в Microsoft Tech Community, в котором говорилось: «Чтобы гарантировать, что наши клиенты не столкнутся с этой конкретной ситуацией в будущем, если мы выпустим новое обновление стека обслуживания, оно будет помечено как «безопасное», а не просто «критическое», так что оно будет включено теми клиентами, которые устанавливают только помеченные исправления безопасности». Надеемся, что это устранило большинство проблем, связанных с поддержанием стека обслуживания Windows в актуальном состоянии, чтобы ваши клиентские и серверные системы Windows могли быть безопасными.
Администраторы также должны знать, что при ручной загрузке и установке SSU и CU из каталога Центра обновления Майкрософт, как это делают некоторые из вас, вам необходимо знать, какой SSU установить в какой версии Windows, и убедиться, что вы установили SSU перед установкой LCU. для этой версии. Кроме того, вам следует проявлять особую осторожность, если вы используете решение для управления исправлениями Windows, произведенное не Microsoft, например PDQ Deploy, BatchPatch, SolarWinds и т. д. Убедитесь, проверив, что используемая вами платформа управления исправлениями применяет необходимый и подходящий SSU к вашей версии Windows, прежде чем она попытается установить LCU для этой версии.
Так что теперь все должно пройти гладко. Но так ли это?
9 октября прошлого года Microsoft выпустила SSU (KB3177467) для Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 с пакетом обновления 1 (SP1), которая вызвала некоторые проблемы у некоторых пользователей. Когда они установили обновление вместе с другими обновлениями и потребовалась перезагрузка, они обнаружили, что их машины застряли на «Этапе 2 из 2» или «Этапе 3 из 3». Чтобы завершить установку SSU и связанных обновлений, в статье базы знаний им было сказано нажать Ctrl+Alt+Del, чтобы продолжить вход в систему, а в управляемых средах, таких как WSUS/SCCM, им было рекомендовано избежать подобных проблем, развернув SSU как отдельное обновление. Поэтому для администраторов была задействована некоторая ручная работа. К счастью, установка SSU обычно не требует перезагрузки, а это означает, что обновление стека обслуживания обычно не приводит к каким-либо особым сбоям ни для ваших пользователей, ни для серверов Windows, от которых зависит ваш бизнес. Но если SU связан с CU и CU требует обновления после установки, то необходимо какое-то прерывание. В любом случае, эта ситуация говорит нам о том, что мы еще не полностью вышли из леса.
Мало того, пользователи WU по-прежнему часто обременены ненужными перезагрузками, которые прерывают и замедляют их рабочий процесс. Компьютер пользователя загружает последнюю версию CU вместе с новым SSU, а затем пытается сначала установить CU. Конечно, это не удается — сначала необходимо установить SSU. Таким образом, цикл WU запускается снова, и на этот раз SSU устанавливается, но машина еще не защищена, поскольку CCU не установлен. Таким образом, машина перезагружается, WU снова запускается, и на этот раз устанавливается CU. Как больно. Я не говорю, что это происходит каждый месяц с каждым пользователем для каждой версии Windows, но это все же происходит достаточно часто, что пользователи и те, кто администрирует пользователей, жалуются на это на различных форумах. Это случилось со мной перед Рождеством, когда я пытался установить KB4471332 (CU) и KB4470788 (SSU) на свой ноутбук под управлением Windows 10 v.1809.
Майкрософт помогает?!
Вероятно, было бы также полезно, если бы Microsoft постоянно информировала нас как администраторов о выпуске новых SSU для каждой поддерживаемой версии Windows. Что ж, сюрприз, Microsoft начала делать это с сентября прошлого года — см. рекомендации по безопасности Microsoft Security Response Center ADV990001 для получения обновленного списка последних обновлений стека обслуживания для каждой операционной системы. Администраторам следует добавить эту страницу в закладки и использовать ее каждый месяц вместе с DISM.exe, чтобы убедиться, что в их системах установлены последние версии SSU, чтобы убедиться, что последние CU также установлены, чтобы они могли быть уверены, что их системы все полностью пропатчено.
Помните, что если вы не установите последнюю версию SSU, вы, вероятно, не сможете установить последнюю версию CU, а это означает, что ваша система может быть уязвима, поскольку она не полностью исправлена. Также возможны другие контрольные признаки (плохие вещи), которые могут произойти, если вы не установите требуемый SSU перед попыткой установить последнюю версию CU. Например, еще в январе прошлого года это вызвало BSOD у некоторых пользователей Windows, а аналогичная ситуация в следующем месяце привела к тому, что некоторые пользователи потеряли функциональность USB в своих системах.
В будущем, чтобы полностью избежать таких проблем, Microsoft, возможно, могла бы попробовать сделать что-то инновационное, например, пометить SSU уникальным новым тегом, таким как «Обновление стека обслуживания», вместо текущего тега «Обновление безопасности». Это значительно облегчило бы жизнь тем из нас, кто использует WSUS/SCCM для обновления клиентских и серверных систем Windows. Другими словами, всем администраторам Windows было бы полезно, если бы Microsoft предприняла попытку исправить весь процесс, с помощью которого идентифицируются и выпускаются SSU, вместо того, чтобы просто пойти на некоторые уступки администраторам WSUS/SSCM. Поскольку Windows и Windows Server (а также WSUS и SCSM) являются продуктами Microsoft, ясно, что Microsoft должна нести ответственность за упрощение управления исправлениями для этих платформ. Мы, как администраторы, не должны нести ответственность за поиск способов обхода пробелов, которые Microsoft имеет в своих процессах исправления, например, общий обходной путь использования отдельных групп обновлений программного обеспечения в ConfigMgr для SSU и CU и развертывание SSU за день до ТС.
И, кстати, если вы хотите подтолкнуть Microsoft к тому, чтобы сделать что-то конкретное по этому вопросу, проголосуйте за это предложение на UserVoice. Спасибо!