Windows Server 2019 Core に WSUS（Windows Server Update Services）をインストールしたあと、「ログファイル（WindowsUpdate.log）が見つからない」「WSUS／Windows Update 関連のログはどこ？」で詰まることがあります。結論は、Windows Update クライアント側と WSUS サービス側のログを分けて追うこと。本記事では Server Core でも完結できる具体的な確認先と PowerShell 手順をまとめます。
最初に整理：WSUS と Windows Update は「ログの出どころ」が違う
「WSUS サーバー上の WindowsUpdate.log」を探しているつもりでも、実際に見たいものがどちらのログかで確認先がまったく変わります。WSUS 環境では、最低でも次の3つを分けて考えると切り分けが一気に早くなります。
| 分類 | 対象 | 主な確認先 | 分かること | この分類でよく起きる誤解 |
|---|---|---|---|---|
| Windows Update クライアント側 | WSUS サーバー（OS）が更新を実行した時 | WindowsUpdate.log / WindowsUpdateClient のイベントログ | 「このサーバー自身が更新に失敗している理由」 | WSUS の不具合＝WindowsUpdate.log だと思い込む |
| WSUS サービス側 | WSUS の同期・承認・配信・メタデータ処理 | WSUS のログファイル、Application ログ、IIS ログ | 「更新を取得して配れる状態か（同期/配信/DB/コンテンツ）」 | WindowsUpdate.log だけ見ても同期失敗の原因は出ないことが多い |
| クライアント端末側 | Windows 10/11 や別サーバー（WSUS に接続する側） | 端末の WindowsUpdate.log / イベントログ / GPO | 「端末が WSUS に到達できているか、検出できているか」 | WSUS サーバーだけ調べて端末設定（ポリシー）を見落とす |
今回の「Windows Server 2019 Core の WSUS で WindowsUpdate.log が見つからない」は、まず WSUS サーバー OS（Windows Update クライアント）のログとして WindowsUpdate.log を探しているケースが多い一方、実際には WSUS サービス側の調査が必要なケースもあります。以降は両方の確認先を、Server Core 前提で具体的に紹介します。
結論：まず確認する Windows Update 関連ログは C:\Windows\WindowsUpdate.log
想定しているログファイルが存在するか、まずは次のパスを確認します。
- Windows Update 関連ログ：
C:\Windows\WindowsUpdate.log
ただし Windows Server 2019（Windows 10 世代）では、環境によって WindowsUpdate.log が自動生成されないことがあります。昔のようにテキストログが常時書き込まれるのではなく、内部のイベントトレース（ETW/ETL）を後から読みやすい形式に「変換」する運用になる場面がある、という点が重要です。
WindowsUpdate.log が見つからない主な理由
Server Core で特にハマりやすいのが、「パスは合っているのにファイルが無い」パターンです。よくある原因を先に整理しておきます。
| 状況 | 起こりがちな原因 | 対処の方向性 |
|---|---|---|
| C:\Windows\WindowsUpdate.log が存在しない | ログが ETL で保持され、テキスト log が未生成 | PowerShell で WindowsUpdate.log を生成（変換）する |
| ファイルはあるが内容が薄い/追えない | 対象が WSUS サービス側で、OS の更新ログでは情報が不足 | WSUS のログ・IIS ログ・イベントログを併用する |
| 更新は進んでいるのにログが増えない | イベントログ側に詳細が記録され、WindowsUpdate.log だけでは追い切れない | WindowsUpdateClient の Operational ログを確認する |
PowerShell で WindowsUpdate.log を生成（変換）して確認する
Windows Server 2019 では、PowerShell の Get-WindowsUpdateLog を使って内部のトレースから読みやすい WindowsUpdate.log を生成できます。Server Core でも実行可能で、GUI は不要です。
まずは出力先フォルダを用意し、生成先を明示すると迷いません。
New-Item -Path C:\Temp -ItemType Directory -Force
Get-WindowsUpdateLog -LogPath C:\Temp\WindowsUpdate.log「そもそも ETL はどこにあるの？」という視点では、次のような場所に Windows Update 関連のトレースが残ることがあります（環境により増減します）。
| 種類 | 代表パス | 用途 |
|---|---|---|
| Windows Update のトレース | C:\Windows\Logs\WindowsUpdate\（配下の .etl など） | Get-WindowsUpdateLog が参照する元データの一部になりやすい |
| CBS（コンポーネント）ログ | C:\Windows\Logs\CBS\CBS.log | 更新適用・コンポーネント修復に絡む失敗を追う |
| DISM ログ | C:\Windows\Logs\DISM\dism.log | イメージ修復や機能追加時の失敗を追う |
運用上のポイントは次のとおりです。
- 問題が再現した直後に生成する（時間が経つと追いづらくなります）。
- 外部通信制限がある環境では、生成に時間がかかったり期待どおり出力できないことがあります。その場合でも、イベントログ側の調査は継続できます。
- 生成した WindowsUpdate.log は「WSUS サーバー OS が更新クライアントとして動いたログ」です。WSUS サービス側（同期・配信・IIS）の問題は別ログで追う必要があります。
イベントログ（Application など）を PowerShell で追う方法
WSUS／Windows Update の切り分けでは、イベントログが非常に強力です。Server Core ではイベントビューアが使えないため、PowerShell で「直近のイベント→詳細表示」の流れを作ると効率が上がります。
まずは質問で挙がっている手順です。直近のイベントを抽出して、該当する Index を控えます。
Get-EventLog Application -After (Get-Date).AddHours(-1)次に、控えた Index の詳細を表示します。
Get-EventLog Application | Where-Object Index -eq <控えたIndex> | Format-List *この方法は「古典的なログ（Application / System など）」には非常に分かりやすい一方、Windows Update では Application and Services Logs 側（Operational など）も見たくなることが多いです。そこで、次のように Get-WinEvent も併用できると調査の幅が広がります。
# Windows Update クライアント（Operational）の直近200件
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 200 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-Listもし Operational ログが無効化されている場合は、有効化してから再現させるとログが取りやすくなります。
wevtutil sl "Microsoft-Windows-WindowsUpdateClient/Operational" /e:trueWindows Update / WSUS の調査でよく使う「ログの場所」一覧
「結局どこを見るのが正解？」を迷いやすいので、代表的な確認先を一覧にします。実務では、障害の種類に応じて見るログを切り替えるのがコツです。
| 目的 | 確認先の種類 | 代表パス / ログ名 | 主な用途 |
|---|---|---|---|
| WSUS サーバー（OS）の更新失敗を追う | テキストログ | C:\Windows\WindowsUpdate.log（生成済みの場合） | 更新の検出・ダウンロード・適用の流れ、エラーコードの発生箇所 |
| Windows Update の詳細イベントを追う | イベントログ | Microsoft-Windows-WindowsUpdateClient/Operational | いつ何がトリガーになったか、失敗時のメッセージ、関連 ID |
| WSUS の同期・メタデータ処理を追う | ログファイル | C:\Program Files\Update Services\LogFiles\（配下） | 同期・ダウンロードの状況、警告・エラーの手掛かり |
| WSUS の HTTP 配信エラーを追う | IIS ログ | C:\inetpub\logs\LogFiles\（配下） | クライアントからのアクセス結果（200/403/404/500）やパス |
| HTTP.sys レベルのエラーを追う | HTTPERR ログ | C:\Windows\System32\LogFiles\HTTPERR\ | IIS より下層（受け口）でのエラー、接続拒否など |
| 更新適用（CBS）を追う | OS コンポーネントログ | C:\Windows\Logs\CBS\CBS.log | コンポーネントストア、更新適用時の整合性エラー |
WSUS サービス側のログ：LogFiles フォルダで見るべきもの
WSUS サービス側の調査では、次のフォルダが「まず見る場所」になりやすいです。
C:\Program Files\Update Services\LogFiles\
フォルダ配下には、たとえば次のようなログが出力されます（インストール形態や構成によりファイル名は増減します）。
| ログ例 | ざっくり何が分かるか | 見るべき観点 |
|---|---|---|
SoftwareDistribution.log | 同期や更新メタデータ処理、配信に関する動きの手掛かり | 同期実行時刻と一致するエラー行、例外、タイムアウト |
Change.log | 更新の変更・差分に関する情報の手掛かり | 更新が増えない/消える/メタデータが不安定なときの補助 |
WSUS のログファイルは「エラーが出た瞬間」だけが記録されるとは限りません。同期の開始から終了までの流れの中で、時間帯で前後の行も一緒に読むのがポイントです。
IIS/HTTP のログ：WSUS への到達性はステータスコードで見える
WSUS は IIS の上で動くため、クライアントが WSUS にアクセスできているかは IIS ログが非常に分かりやすい一次情報になります。特に次の観点で見ます。
- 200 が返っているか（最低限の到達性）
- 403/404 が多くないか（権限/パス/設定ミス）
- 500 が出ていないか（アプリ側例外、アプリプール、DB など）
- 対象パス（SelfUpdate、ClientWebService、SimpleAuthWebService など）
併せて、HTTP.sys のエラーログ（HTTPERR）を見ておくと「IIS より下の層で弾かれている」ケースを拾えます。IIS ログはアプリケーション寄り、HTTPERR は受け口寄りの視点です。
イベントログを「エラーだけ」効率よく抽出するテクニック
ログは量が多いので、まずは「直近」「エラー/警告」「関連プロバイダ」で絞り込んで当たりを付けるのがコツです。
| やりたいこと | コマンド例 | 補足 |
|---|---|---|
| 直近1時間の Application ログを見る | Get-EventLog Application -After (Get-Date).AddHours(-1) | Index を控えて詳細を見る流れに繋げやすい |
| 直近24時間の警告以上だけを見る | Get-EventLog Application -EntryType Error,Warning -After (Get-Date).AddHours(-24) | まずはノイズを減らして、エラーの傾向をつかむ |
| Windows Update の Operational を直近で見る | Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 200 | WindowsUpdate.log が薄いときの主戦場 |
| 特定 ID のイベントを抽出する | Get-WinEvent -FilterHashtable @{LogName="Application"; Id=12072} | WSUS 関連で参照されることがある ID。環境によって出ないこともある |
Get-EventLog はシンプルで分かりやすい反面、Operational のような新しいログでは Get-WinEvent が必要になります。調査が長引くほど Get-WinEvent を使う場面が増えるため、最初から「両方使う前提」で手順を作っておくのがおすすめです。
WindowsUpdate.log の補足：WSUS サービス調査ではイベントログも必須
WindowsUpdate.log は「WSUS サーバー（OS）が Windows Update クライアントとして動いたときのログ」に寄ることがあり、WSUS サービス側の調査では情報が不足するケースがあります。ここで重要なのは、WindowsUpdate.log が無い/薄いこと自体が、即座に異常とは限らないという点です。
WSUS の切り分けでは次の組み合わせが定番です。
- WindowsUpdate.log（あるいは Get-WindowsUpdateLog で生成したログ）：OS 更新の流れ
- WindowsUpdateClient/Operational：より詳細なイベントの裏取り
- WSUS LogFiles：同期・配信・メタデータ処理
- IIS ログ + HTTPERR：クライアント到達性と HTTP エラー
Server Core で使える「ログ採取セット」：困った時にそのまま使う
障害調査では「何を・どの範囲で・いつ採取したか」が後から効きます。Server Core で最低限のログをまとめて保存する例を載せます。運用に合わせてパスは調整してください。
# 1) 作業用フォルダ
$Out = "C:\Temp\WSUS_LogPack"
New-Item -Path $Out -ItemType Directory -Force | Out-Null
# 2) WindowsUpdate.log を生成（可能な範囲で）
try {
Get-WindowsUpdateLog -LogPath (Join-Path $Out "WindowsUpdate.log") -ErrorAction Stop
} catch {
"Get-WindowsUpdateLog failed: $($_.Exception.Message)" | Out-File (Join-Path $Out "Get-WindowsUpdateLog_error.txt")
}
# 3) イベントログを書き出し（Application / System）
wevtutil epl Application (Join-Path $Out "Application.evtx")
wevtutil epl System (Join-Path $Out "System.evtx")
# 4) Windows Update Client の Operational を書き出し
wevtutil epl "Microsoft-Windows-WindowsUpdateClient/Operational" (Join-Path $Out "WindowsUpdateClient_Operational.evtx")
# 5) IIS / HTTPERR / WSUS LogFiles をコピー（存在する範囲で）
$paths = @(
"C:\inetpub\logs\LogFiles",
"C:\Windows\System32\LogFiles\HTTPERR",
"C:\Program Files\Update Services\LogFiles"
)
foreach ($p in $paths) {
if (Test-Path $p) {
Copy-Item $p -Destination (Join-Path $Out (Split-Path $p -Leaf)) -Recurse -Force
}
}この「ログパック」を作っておくと、後から別端末でイベントビューアを開いて精査できます。特に WSUS の調査は、WSUS サーバー単体のログだけでなく、クライアント側で失敗した時刻と照合するのが重要なので、時刻（タイムゾーン含む）を揃えて採取する運用を意識してください。
切り分けの手順：最短で原因に近づくチェックリスト
最後に、現場で迷いにくいように、ログ確認を前提にしたチェック手順をまとめます。上から順に潰すだけで、問題の層（OS / WSUS / IIS / ネットワーク / クライアント設定）を切り分けやすくなります。
| 手順 | やること | 見るべきログ/コマンド | 判断の目安 |
|---|---|---|---|
| 1 | WindowsUpdate.log の有無を確認 | Test-Path C:\Windows\WindowsUpdate.log | 無ければ Get-WindowsUpdateLog の出番 |
| 2 | WindowsUpdate.log を生成して時系列で読む | Get-WindowsUpdateLog -LogPath C:\Temp\WindowsUpdate.log | 失敗ステップ（検出/DL/インストール）を特定 |
| 3 | WindowsUpdateClient の Operational で裏取り | Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 200 | WindowsUpdate.log より粒度が細かいことが多い |
| 4 | WSUS サービスと IIS の稼働を確認 | Get-Service WsusService, W3SVC, BITS | 停止しているならログ以前に復旧が必要 |
| 5 | WSUS LogFiles と IIS ログで配信状況を確認 | WSUS LogFiles / IIS のステータスコード | 200 が多ければ到達、403/404/500 は設定・権限・IIS 側を疑う |
| 6 | クライアント側の WSUS URL 設定を確認 | クライアントの WindowsUpdate.log / GPO | URL 違い・プロキシ・証明書などで失敗する |
補足：Server Core でも「別端末から」イベントログを見られる
Server Core 上で完結させるなら本記事の PowerShell が便利ですが、状況によっては管理端末からイベントビューアでリモート接続して確認する方が速いこともあります。ログ採取（evtx 出力）と併用し、現場の動きやすい方法で進めてください。
WindowsUpdate.log が見つからない場合でも、C:\Windows\WindowsUpdate.log の確認 → Get-WindowsUpdateLog による生成 → イベントログ（Application/Operational） → WSUS LogFiles/IIS ログの順に追えば、原因の層がはっきりしてきます。まずは「どのログが、何を表しているか」を整理し、同じ時間帯のログを突き合わせるところから始めましょう。
コメント