Як віддалено виявити Windows завершив конфігурацію патча після перезавантаження

Ми плануємо автоматизувати створення віртуальних машин для нашої інфраструктури побудови, щоб ми могли:

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

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

Створює новий VHDX з ISO за допомогою сценарію Convert-WindowsImage . Наразі ми використовуємо Windows 2012R2, але будемо з нетерпінням розпочати роботу з 2016 року, як тільки вона стане доступною.
Додає сценарій без нагляду до нового VHDX з усією необхідною базовою конфігурацією
Оновлення VHDX за допомогою останніх патчів Windows за допомогою сценарію Apply-WindowsUpdate
Створює новий VM Hyper-V на основі VHDX і запускає його
Чекає завантаження VM і чекає, коли служба WinRM буде готова прийняти віддалені з'єднання
Чекає, коли Windows завершить початкову конфігурацію та конфігурацію нових патчів
Застосовує будь-які подальші виправлення
Перезавантажте для завершення конфігурації останніх виправлень
Чекає, поки Windows завершить налаштування патчів
Натискає на машину сценарій sysprep і викликає цей сценарій. Це запускає sysprep, а потім вимикає машину
Видаляє VM, але зберігає VHDX
Вилучає файли з системою синхронізації та скасування запиту з VHDX, а потім ущільнює VHDX
Переміщує VHDX до місця розташування шаблону та позначає лише для читання

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

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

Отже, питання полягає в тому, що є найбільш дурним способом виявити через віддалене з'єднання, що Windows закінчила налаштування оновлень тощо, щоб ми могли перезавантажувати / вимикати машину, не викликаючи проблем пізніше.

------ EDIT -----

Зрештою, ми використовуємо модифіковану версію відповіді Кетрін у тому, що наш сценарій також чекає windeployта ngenзавершує. З огляду на те, що ngenце не завершується до завершення ініціалізації ОС, що працює, і як бонус остаточний VHDX матиме всі рамки .NET ngen-ed, що означає, що нам не доведеться мати справу з цим, коли ми створюємо нові Віртуальних машин шаблонного диска. І сценарій, який ми використовуємо для створення шаблону VHDX, і сценарії для створення локального тестового середовища знаходяться на github у випадку, якщо хтось зацікавлений.

windows unattended winrm

— Петрик
джерело

Відповіді:

Це може здатися дивним відповіді, але ...

Існує сценарій PowerShell для перевірки наявності наявних оновлень для Nagios . Можливо, ви могли б використовувати цей сценарій або варіант для своїх цілей, без Nagios.

Що стосується того, чи вони тривають, перевірте, чи працюють Wuauclt та TrustedInstaller чи ні. Тут можуть допомогти поради Microsoft щодо оновлень на сервері Core Core :

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

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

— Кетрін Вільярд
джерело

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

— Петрик

Ви коментували, поки я редагував. Я додав інформацію про виявлення цього стану в сердечному ядрі, що близьке до віддаленого виконання.

— Кетрін Вільярд

Я був надто коментар задоволений. Я буду дивитись на пошук Wuauclt або TrustedInstaller.

— Петрик

Я був маленький "хіт-пост" задоволений сам. :)

— Кетрін Вільярд

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

— Петрик

Кожен патч оновлення Windows запише декілька подій у журнал подій установки.

Ідентифікатор події 1 - Ініціювання змін для пакету KB ####
Ідентифікатор події 4 - Перезавантаження необхідне, перш ніж пакет KB #### може бути змінений на встановлений стан
Ідентифікатор події 2 - пакет KB #### був успішно змінений на встановлений стан

Один із способів визначити всі застосовані виправлення - це фіксувати перевірку на ID події 4. Порівняйте час цієї події з поточним часом. Якщо жоден ідентифікатор події 4 не був записаний протягом 5 або 10 хвилин, то, мабуть, всі патачі зроблені, і готові до перезавантаження.

Мені не ясно, якщо ви хочете виконати першу перезавантаження при встановленні патчів (event4) або другу перезавантаження після їх налаштування (подія 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
    }
}

— Клейтон
джерело

Чи не вдасться записати ідентифікатори KB усіх пакетів, які починають інсталювати, та припускати їх завершення лише тоді, коли більше оновлень не буде в польоті?

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

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

— Клейтон

Я мав на увазі як розширення вашої відповіді: коли оновлення починає встановлюватися (подія 1), воно додається до списку та видаляється, коли воно звітується (подія 4). З деякими налаштуваннями (невдалі оновлення, скидання списку під час перезавантаження?) Слід встановити, чи все ще триває установка.

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

Тож для нової інсталяції, на жаль, немає записів у eventlog. Я не намагався встановити після ініціалізації машини, але припускаю, що в цьому випадку цей підхід буде добре працювати.

— Петрик

Свіжий встановити? Плутати. Тут у вас є 13 кроковий процес. Ви звернулися за допомогою до кроків 6 та 9. Ваше питання полягав у тому, що "спосіб виявити, що Windows закінчив етап конфігурації", а не спосіб розпочати розгортання патчів.

— Клейтон

Я мав добрий успіх із наступним підходом: Зачекайте, поки Windows змінить тип запуску служби інсталятора модуля Windows (він же TrustedInstaller) на «Ручний (запуск запиту») - після перезавантаження. Після цього встановлення оновлення завершено.

Процес Trusted Installer іноді продовжує працювати після встановлення патчів? Однак тип запуску послуги все одно скидається до ручного.

Ви можете переконатися в тому, якщо вищезазначене спостереження є послідовним / правильним, переглянувши попередні повідомлення журналу подій та співставляючи події між журналами системи та налаштування.

Після зміни перезавантаження після зміни перезавантаження реєструється зміна при запуску в інсталятор модуля Windows як системна подія 7040, і воно співвідноситься з останньою подією 2 в журналі установки.

Я думаю, що при першому встановленні оновлень ця служба встановлюється на "Автозапуск" у разі необхідності перезавантаження. Він встановлюється назад у "Вручну", коли встановлено останній виправлення (незалежно від того, чи потрібно було перезавантаження).

На деяких серверах я помітив, що запуск довіреної програми встановлення швидко перемикається з ручного на автоматичний і назад, і це може відбуватися щогодини або близько того. Я підозрюю, що це якась програма, яка регулярно перевіряє наявність оновлень. Але я вважаю, що це, як правило, здається безпечним припустити, якщо запуск - це "Ручний", то ніякого виправлення не відбувається.

— йдрол
джерело