PowerShellでWindows Updateの履歴を確認する方法は一つではありません。Get-HotFixとWin32_QuickFixEngineeringは主にCBSで提供されたQFE更新の情報を返し、設定アプリの更新履歴やWindows Update Agentの履歴と完全には一致しません。機能更新、ドライバー、Microsoft Storeアプリ、Defender定義、失敗履歴を同じ一覧で扱えない場合があります。本記事では取得元ごとの範囲を理解し、読み取り専用で安全に確認する方法を解説します。
最初に確認したい「履歴」の種類を決める
調査目的が、特定KBの適用確認、直近の品質更新、失敗した更新、ドライバー、機能更新、再起動原因、脆弱性対応のどれかを決めます。更新元により記録場所と保持期間が異なります。端末名、Windowsの製品名とビルド、実行時刻、管理方式を一緒に記録し、単独のKB一覧だけで最新状態と判断しません。
WSUS、Microsoft Intune、Windows Update for Business、Configuration Managerなどで管理される端末は、ローカル履歴だけでなく管理基盤の展開状態を確認します。ローカルでは成功しても組織の準拠判定が遅れる、逆に管理画面では配布済みでも端末が再起動待ちの場合があります。誰のどの判定を答えるのかを明確にします。
Get-HotFixでQFE一覧を確認する
Get-HotFix | Sort-Object InstalledOn -Descendingで、利用可能な修正プログラムを日付順に表示できます。HotFixID、Description、InstalledBy、InstalledOnなどを選んで記録します。特定KBならGet-HotFix -Id KB5030000のように確認しますが、存在しないとエラーになるため、運用スクリプトではtry/catchで未検出と取得失敗を分けます。
MicrosoftのGet-HotFix資料では、このコマンドがWin32_QuickFixEngineeringクラスを使用し、CBSで提供された更新を返すことが説明されています。MSIやWindows Updateサイト由来のすべてを列挙するものではありません。Get-HotFixに出ないことだけで未適用と断定せず、ビルド、設定画面、更新履歴、管理基盤を照合します。
Win32_QuickFixEngineeringをCIMで取得する
Get-CimInstance -ClassName Win32_QuickFixEngineering | Select-Object HotFixID,Description,InstalledBy,InstalledOnで同系統の情報をオブジェクトとして取得できます。リモート端末ではCIMセッションを指定できますが、認証、ファイアウォール、CIM構成の失敗を「更新なし」と混同しません。
InstalledOnは環境によって空、文字列形式、日時の扱いが異なることがあります。単純な文字列ソートでは順序を誤る可能性があるため、値の型とカルチャを確認します。更新の適用日は、パッケージ導入、再起動、ビルド反映の時刻と一致しない場合があります。正確な障害時系列ではイベントログと再起動履歴も確認します。
Windows Update Agentの履歴をQueryHistoryで読む
Windows Update Agent APIを使う例では、$session = New-Object -ComObject Microsoft.Update.Session、$searcher = $session.CreateUpdateSearcher()、$count = $searcher.GetTotalHistoryCount()、$searcher.QueryHistory(0,$count)の順に履歴を取得できます。これは更新の検索履歴を読む操作ですが、COMが利用できるWindows環境で実行します。
履歴オブジェクトにはDate、Title、Description、ResultCode、HResult、Operationなどがあります。ResultCodeは数値または列挙値で、Succeeded、SucceededWithErrors、Failed、Abortedなどを区別します。HResultを単独で検索して即断せず、タイトル、時刻、操作種別、イベントログ、公式エラー情報を照合します。履歴件数が非常に多い場合は直近件数へ絞ります。
設定アプリの更新履歴と照合する
利用者が確認する場合は「設定」「Windows Update」「更新の履歴」を開き、品質更新、ドライバー更新、定義更新、その他の更新などの区分を確認します。PowerShell結果と設定画面が違うときは、取得元の範囲差、保持期間、適用済みパッケージの置き換え、再起動待ちを確認します。
画面上のKBリンクや更新名を記録し、OSビルドとの対応をMicrosoftのWindowsリリース情報で確認します。更新履歴のスクリーンショットには端末名や組織情報が含まれる場合があるため、共有前に確認します。「更新プログラムをアンインストールする」画面は確認だけに使い、原因特定なしに削除しません。
イベントログで成功・失敗の時刻を追う
Event ViewerのApplications and Services Logs配下にあるMicrosoft-Windows-WindowsUpdateClient/Operationalログは、更新検出、ダウンロード、インストールなどの手掛かりになります。PowerShellではGet-WinEventで対象ログと時刻を絞れますが、イベントIDはWindowsの版や場面で意味を確認します。
大量のログをすべて出力せず、障害時刻の前後、更新タイトル、KB、エラーコードを抽出します。同じエラーが以前から繰り返されている場合、今回の障害と時刻が一致するかを見ます。ログを消去すると調査証拠が失われるため、必要に応じてエクスポートしてから保守を行います。
履歴をCSVへ出力し差分管理する
Get-HotFixの結果ならGet-HotFix | Select-Object HotFixID,Description,InstalledBy,InstalledOn | Export-Csv -LiteralPath "C:\Reports\hotfixes.csv" -NoTypeInformation -Encoding utf8で保存できます。Update Agent履歴はDate、Title、ResultCode、HResult、Operationを選び、列名と意味を文書化します。
InstalledByやTitleには組織情報が含まれる場合があります。CSVを公開共有へ置かず、アクセス権と保管期限を決めます。前回との差分では、置き換えられた更新や履歴保持の変化を「アンインストール」と誤認しないよう、OSビルドと管理基盤の状態を合わせて保存します。
未適用・失敗を判断した後の対応
特定KBが見つからない場合、対象OSとエディションに適用される更新か、より新しい累積更新に置き換えられているか、機能更新後かを確認します。累積更新では最新パッケージが過去修正を含むため、古いKBが一覧にないことがあります。Microsoft Update Catalogやリリースノートを公式情報として参照します。
失敗履歴を見つけても、SoftwareDistributionの削除、更新サービスの停止、更新アンインストールを初手にしません。空き容量、ネットワーク、再起動待ち、日時、プロキシ、証明書、Windows Updateトラブルシューティング、管理基盤を確認し、組織の手順で復旧します。変更前にログと現在状態を保存します。
実務での確認チェックリスト
- 確認したい更新種別と管理基盤を明確にする
- Get-HotFixの範囲がCBS/QFE中心であることを理解する
- Win32_QuickFixEngineeringとUpdate Agent履歴を必要に応じて照合する
- 設定アプリとイベントログで失敗時刻・区分を確認する
- KB一覧だけで最新・準拠・未適用を断定しない
- 更新アンインストールやサービス変更を確認手順と分離する
コメント