Windowsをリモートで検出する方法は、再起動後にパッチ構成を完了しました

ビルドインフラストラクチャ用のVMの作成を自動化して、次のことができるようにする予定です。

1. 必要に応じてビルドエージェントを追加し、不要な場合は削除するなど、要求に基づいてビルドリソースをスケーリングします。
2. マシンが停止した場合に、ビルド環境のすべてまたは一部を再作成します
3. テストのセットアップが必要なときにビルド環境を複製する

このプロセスの手順の1つは、VMベースイメージの作成を自動化することです（この場合はHyper-Vを使用しています）。そのために、次のようなスクリプトがあります。

1. Convert-WindowsImageスクリプトを使用して、ISOから新しいVHDXを作成します。現在Windows 2012R2を使用していますが、利用可能になり次第、2016年の開始を目指しています。
2. 必要なすべての基本構成を使用して、無人スクリプトを新しいVHDXに追加します
3. Apply-WindowsUpdateスクリプトを使用して、VHDXを最新のWindowsパッチで更新します。
4. VHDXに基づいて新しいHyper-V VMを作成し、起動します
5. VMが起動するのを待ち、WinRMサービスがリモート接続を受け入れる準備ができるのを待ちます
6. ウィンドウが初期構成と新しいパッチの構成を完了するのを待ちます
7. 追加のパッチを適用します
8. 最新のパッチの構成を完了するために再起動します
9. ウィンドウがパッチの構成を完了するのを待つ
10. sysprepスクリプトをマシンにプッシュし、そのスクリプトを呼び出します。これはsysprepを実行してからマシンをオフにします
11. VMを削除しますが、VHDXは保持します
12. VHDXからsysprepファイルと無人ファイルを削除してから、VHDXを圧縮します
13. VHDXをテンプレートの場所に移動し、読み取り専用としてマーク

発生している問題はステップ6と9にあります。理想的には、すべての構成が完了するまで待ってからマシンを再起動/シャットダウンしますが、ウィンドウが構成ステージを完了したことを検出する方法がないようです。

ログインUIはプロセスの準備ができるまで表示されないので、UIを通過するとき、どちらのステップが完了しても非常に明確です。ただし、WinRMを使用してマシンにリモート接続する場合、WinRMは構成作業が完了する前にマシンへのアクセスを提供するため、これはあまり明確ではありません。

したがって、問題は、リモート接続を介してWindowsが更新の設定などを完了したことを検出する最も簡単な方法であり、後で問題を引き起こすことなくマシンを再起動/シャットダウンできるようにすることです。

------編集-----

最終的に我々は我々のスクリプトも待つにキャサリンの回答の修正版を使用しているwindeployし、ngen完全に。ngenOSが機能する初期化が完了するまでは完了しません。ボーナスとして、最終的なVHDXにはすべての.NET Framework ngen-edが含まれます。つまり、新しいフレームワークを作成するときにそれを処理する必要はありません。テンプレートディスクのVM。VHDXテンプレートを作成するために使用するスクリプトとローカルテスト環境を作成するためのスクリプトはどちらも、誰かが興味を持っている場合に備えてgithubにあります。

これは奇妙な答えのように聞こえるかもしれませんが...

Nagiosの利用可能な更新があるかどうかを確認するためのPowerShellスクリプトがあります。Nagiosがなくても、おそらくこのスクリプトまたはバリアントを目的に使用できます。

進行中かどうかは、WuaucltとTrustedInstallerが動作しているか確認してください。 Server Coreの更新に関するMicrosoftのアドバイスは、ここで役立ちます。

インストールされているアップデートによっては、システムから通知されない場合でも、コンピューターの再起動が必要になる場合があります。インストールプロセスが完了したかどうかを確認するには、タスクマネージャを使用して、WuaucltまたはTrusted Installerプロセスがアクティブに実行されていないことを確認します。「インストールされたアップデートの表示」セクションの方法を使用して、インストールされたアップデートのリストを確認することもできます。

あなたはおそらくそのようなものでその情報を引き出すことができGet-Process -Computername YourImage TrustedInstaller.exeます。WuaucltプロセスとTrustedInstallerプロセスの両方が完了したら、再起動しても安全です。

各Windows更新パッチは、セットアップイベントログにいくつかのイベントを書き込みます。

• イベントID 1-パッケージKB ####の変更の開始
• イベントID 4-パッケージKB ####をインストール済み状態に変更するには、再起動が必要です
• イベントID 2-パッケージKB ####は正常にインストール済み状態に変更されました

すべてのパッチが適用されたことを確認する1つの方法は、イベントID 4のチェックをループすることです。そのイベントの時刻を現在の時刻と比較します。イベントID 4が5分間または10分間書き込まれなかった場合は、すべてのパッチが完了しており、再起動する準備ができています。

パッチのインストールが完了したときに最初の再起動（イベント4）を行うか、構成が完了した後の2回目の再起動（イベント2）を行うかは明確ではありません。このコードは前者を実行します。ステップ10の前に他のリブートを行うには、filterHashTableをイベントID 2に変更するだけです。

$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
    }
}

私は次のアプローチで大成功しました：WindowsがWindowsモジュールインストーラーサービス（別名TrustedInstaller）のスタートアップの種類を手動（デマンドスタート）に変更するまで待機します-再起動後。この時点で、アップデートのインストールが完了しています。

Trusted Installerプロセスは、パッチのインストール後も実行され続けることがありますか？ただし、サービスの起動タイプはまだ手動にリセットされています。

上記の観察が一貫性/正しい場合は、以前のイベントログメッセージを調べて、システムログとセットアップログ間のイベントを関連付けることにより、自分で確認できます。

Windowsモジュールインストーラーの起動時の変更は7040システムイベントとしてログに記録され、再起動後、セットアップログの最後のイベント2に関連付けられます。

アップデートが最初にインストールされたとき、再起動が必要な場合に備えて、このサービスは「自動開始」に設定されていると思います。最後のパッチがインストールされると、[手動]に戻ります（再起動が必要かどうかは関係ありません）。

一部のサーバーでは、信頼できるインストーラーの起動が手動から自動に自動的に切り替わり、1時間ごとに発生する場合があります。更新を定期的にチェックしているのは、何らかのアプリケーションだと思います。しかし、私の経験では、スタートアップが手動の場合、パッチは適用されていないと一般に想定しても安全だと思われます。