Как удаленно определить, что Windows завершила настройку патча после перезагрузки

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

Масштабируйте ресурсы сборки на основе спроса, например, добавляя больше агентов сборки, когда это необходимо, и удаляя их, когда это не нужно.
Воссоздать всю или часть среды сборки, если / когда машины умирают
Дублируйте среду сборки, когда нам нужна настройка теста

Одним из шагов в этом процессе является автоматизация создания базовых образов виртуальных машин (в нашем случае это Hyper-V). Для этого у нас есть скрипт, который:

Создает новый VHDX из ISO с помощью скрипта Convert-WindowsImage . В настоящее время мы используем Windows 2012R2, но начнем с 2016 года, как только она станет доступна.
Добавляет сценарий автоматической установки в новый VHDX со всей необходимой базовой конфигурацией
Обновляет VHDX с последними обновлениями Windows, используя скрипт Apply-WindowsUpdate
Создает новую виртуальную машину Hyper-V на основе VHDX и запускает ее
Ожидание загрузки виртуальной машины и ожидание готовности службы WinRM принимать удаленные подключения.
Ожидает, пока Windows завершит начальную настройку и настройку новых патчей.
Применяет любые дальнейшие патчи
Перезагружается для завершения настройки последних патчей
Ожидает, пока Windows завершит настройку патчей.
Выдвигает сценарий sysprep на компьютер и вызывает этот сценарий. Это запускает sysprep, а затем выключает машину
Удаляет виртуальную машину, но сохраняет VHDX
Удаляет файлы sysprep и unattend из VHDX, а затем сжимает VHDX
Перемещает VHDX в расположение шаблона и помечает его как доступный только для чтения.

Проблема, с которой мы сталкиваемся, заключается в шагах 6 и 9. В идеале мы ждем завершения всей конфигурации, прежде чем перезагрузить / выключить машину, но, похоже, нет способа определить, что Windows завершила стадию настройки.

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

Поэтому вопрос заключается в том, какой самый надежный способ обнаружить через удаленное соединение, что Windows завершила настройку обновлений и т. Д., Чтобы мы могли перезагрузить / выключить компьютер, не вызывая проблем в дальнейшем.

------ РЕДАКТИРОВАТЬ -----

В конце мы используем измененную версию ответа Кэтрин, в которой наш сценарий также ожидает windeployи ngenзавершает. Учитывая, что ngenэто не завершится до тех пор, пока ОС не завершит инициализацию, которая работает, и в качестве бонуса финальный VHDX будет иметь все .NET Framework ngen-ed, что означает, что нам не придется иметь дело с этим при создании нового ВМ шаблона диска. Оба сценария, которые мы используем для создания шаблона VHDX, и сценарии для создания локальной тестовой среды находятся на github на случай, если кому-то это будет интересно.

windows unattended winrm

— Петрик
источник

Ответы:

Это может звучать странно, но ...

Существует скрипт PowerShell для проверки наличия обновлений для Nagios . Возможно, вы могли бы использовать этот сценарий или вариант для ваших целей, без Nagios.

Что касается того, находятся ли они в процессе, проверьте, работают ли Wuauclt и TrustedInstaller. Совет Microsoft об обновлениях на Server Core может помочь здесь :

В зависимости от установленных обновлений может потребоваться перезагрузить компьютер, хотя система не уведомит вас об этом. Чтобы определить, завершен ли процесс установки, используйте диспетчер задач, чтобы убедиться, что процессы Wuauclt или Trusted Installer не работают. Вы также можете использовать методы в разделе «Просмотр установленных обновлений», чтобы проверить список установленных обновлений.

Вы, вероятно, можете получить эту информацию с чем-то вроде Get-Process -Computername YourImage TrustedInstaller.exe. После завершения процессов Wuauclt и TrustedInstaller перезагрузка должна быть безопасной.

— Кэтрин Вилляр
источник

Этот сценарий решает проблему получения обновлений и определения необходимости перезагрузки, что является еще одной проблемой, которую нам, возможно, придется решить, но сценарий не связан с ожиданием перезагрузки до момента, когда машина будет готова к работе. ,

— Петрик

Вы прокомментировали, пока я редактировал. Я добавил некоторую информацию об обнаружении этого состояния в Server Core, что близко к удаленному выполнению.

— Кэтрин Вилльярд

Я был слишком счастливым от комментариев. Я посмотрю на поиск Wuauclt или TrustedInstaller.

— Петрик

Я был немного "хитом" счастливым сам. :)

— Кэтрин Вилльярд

Этот подход почти сработал для меня, за исключением того, что и TrustedInstaller, и Wuauclt завершают работу до завершения инициализации. После добавления windeploy и ngen сценарий ожидает, пока машина завершит всю инициализацию (возможно, потому, что ngen не завершит работу до тех пор, пока машина не завершит инициализацию).

— Петрик

Каждый патч обновления Windows записывает несколько событий в журнал событий программы установки.

Идентификатор события 1 - Инициирование изменений для пакета KB ####
Событие с кодом 4 - требуется перезагрузка, прежде чем пакет KB #### можно перевести в состояние установки
Идентификатор события 2 - Пакет KB #### был успешно изменен на Установленное состояние

Одним из способов определения того, что все исправления были применены, было бы зацикливание проверки на Event ID 4. Сравните время этого события с текущим временем. Если ни одно событие с кодом 4 не было записано в течение 5 или 10 минут, то все патчи, вероятно, выполнены и готовы к перезагрузке.

Мне не ясно, хотите ли вы выполнить первую перезагрузку после завершения установки исправлений (событие 4) или вторую перезагрузку после завершения настройки (событие 2). Этот код делает первое. Просто измените filterHashTable на идентификатор события 2 для другой перезагрузки перед вашим шагом 10.

$target = "bart"
$found = $false
while (-not $found) {
    $lastEvent4 = (get-winevent -comp $target -maxEvents 1 -filterHashTable @{ Logname='Setup'; id = '4';}).timeCreated
    if (((get-date) - $lastEvent4).totalMinutes -gt 10) {
        "do reboot"
        restart-computer -comp -$target
        $found = $true
    } else {
        "wait"
        start-sleep 60
    }
}

— Clayton
источник

Разве это не сработает, чтобы записать идентификаторы KB всех пакетов, которые начинают установку, и предполагать завершение только тогда, когда больше нет обновлений в полете?

— Саймон Рихтер

Список патчей будет меняться каждый месяц во вторник патч. Обновление процесса каждый месяц для использования нового списка было бы постоянным пунктом обслуживания ... Я думал, что то, что я предложил, будет проще.

— Клейтон

Я имел в виду расширение вашего ответа: когда обновление начинает устанавливаться (событие 1), оно добавляется в список и удаляется, когда оно сообщает о завершении (событие 4). При некоторой настройке (сбой обновлений, сброс списка во время перезагрузки?) Должна быть возможность определить, продолжается ли установка.

— Саймон Рихтер

Так что для новой установки, к сожалению, в журнале событий нет записей. Я не пробовал устанавливать после инициализации машины, но я предполагаю, что этот подход будет работать нормально в этом случае.

— Петрик

Свежая установка? Смущенный. У вас есть 13 этапов процесса. Вы попросили помощи в шагах 6 и 9. Ваш вопрос был о том, как «определить, что windows завершил этап настройки», а не как начать развертывание исправлений.

— Клейтон,

У меня был хороший успех при следующем подходе: подождать, пока Windows не изменит тип запуска службы установщика модуля Windows (также известный как TrustedInstaller) на ручной (запуск по требованию) - после перезагрузки. На этом этапе обновления завершены.

Процесс Trusted Installer иногда продолжает работать после установки исправлений? Однако тип запуска службы по-прежнему сбрасывается на ручной.

Вы можете проверить сами, если приведенное выше наблюдение является последовательным / правильным, просмотрев предыдущие сообщения журнала событий и сопоставив события между журналами системы и установки.

Изменения при запуске для Установщика модулей Windows регистрируются как Системное событие 7040, и оно соответствует последнему событию 2 в журнале установки после перезагрузки.

Я думаю, что, когда обновления впервые устанавливаются, эта служба устанавливается на «Автозапуск» в случае необходимости перезагрузки. Он устанавливается на «Ручной», когда последний патч установлен (независимо от того, была ли необходима перезагрузка).

На некоторых серверах я заметил, что запуск доверенного установщика быстро переключается с ручного на автоматический и обратно, и это может происходить каждый час или около того. Я подозреваю, что это какое-то приложение, которое регулярно проверяет наличие обновлений. Но, по моему опыту, обычно можно предположить, что если запуск выполняется вручную, то исправление не происходит.

— ydrol
источник