WSUS の動作確認では「どのログがクライアント側で、どのログがサーバー側か」を先に整理すると、一気にトラブルシュートが楽になります。本記事では WindowsUpdate.log の読み方・生成方法、WSUS 側で見るべきログ、そして新規構築で頻発する「No client computers have ever contacted the server（クライアントが一度も接続してこない）」を最短で切り分ける手順を具体的にまとめます。
WSUS と Windows Update のログは役割が違う：まずここを揃える
WSUS の調査で混乱しやすい最大のポイントは、「WindowsUpdate.log を見ても WSUS サーバーの異常は分からないことが多い」点です。ログは大きく分けて、次の役割になります。
| 分類 | 主役 | 主に分かること | よくある誤解 |
|---|---|---|---|
| クライアント側ログ | WindowsUpdate.log / Windows Update クライアントのイベント | 「端末が更新を探しに行ったか」「どの URL に接続しようとしたか」「失敗したエラーコード」 | WindowsUpdate.log を見れば WSUS サーバー側の障害が分かる |
| WSUS サーバー側ログ | イベントビューアー（WSUS）/ IIS ログ / WSUS ログ | 「WSUS が要求を受けたか」「Web サービスが応答したか」「同期・DB・コンテンツ配布の問題」 | WSUS 画面で “クライアントが来ない” ＝ WSUS サーバーが壊れている |
結論として、
- クライアントが WSUS を見に行っているか：クライアント側（WindowsUpdate.log など）
- WSUS が受け付けて処理できているか：サーバー側（イベントログ / IIS / WSUS ログ）
この切り分けで進めると、原因に最短で辿り着きやすくなります。
WSUS サーバー側の動作確認：サービス・IIS・ポート・ログを順に潰す
WSUS は「サービス + IIS + DB + コンテンツ」の4点セット
WSUS は単体サービスではなく、複数コンポーネントが揃って初めて正常動作します。新規構築や移行直後は、どれか1つが抜けているだけで「クライアントが来ない」に見えます。
| コンポーネント | 何が起きるとダメか | Server Core でもできる確認例 | 補足 |
|---|---|---|---|
| WSUS サービス（Update Services） | WSUS の中核が動かず、Web サービスも正常に応答しない | Get-Service WsusService Get-Service W3SVC | W3SVC は IIS。WSUS 単体だけ見て安心しない |
| DB（WID または SQL Server） | WSUS が起動しても内部処理が失敗する | Get-Service *WID* Get-Service *MSSQL* | WID 利用だとサービス名が環境により異なる |
| IIS（WSUS の Web サービス） | クライアントが接続できない / 8530 が開いていても応答しない | netstat -ano | findstr :8530 Get-NetTCPConnection -LocalPort 8530 | 「ポートが LISTEN」でも、URL パスが死んでいることはある |
| コンテンツ（更新ファイル格納先） | 検出できてもダウンロードで失敗する | dir D:\WSUS\WsusContent | クライアントが “来る/来ない” とは別問題として出ることも多い |
8530 ポートの「開いている」を“通信できる”に落とし込む
よくある落とし穴は「8530 を使っているから、ブラウザで http://wsus:8530 を開いて確認しよう」として、何も表示されずに不安になるケースです。
WSUS はトップページが人間向けに表示される設計ではありません（IIS の既定動作によっては 403/404 に見えることもあります）。したがって、動作確認はWSUS のエンドポイント（特定パス）で行うのが現実的です。
まず疎通（TCP）が取れるかを確認します。Server Core では WSUS サーバー自身、または別端末（クライアント）から実施します。
# クライアント端末（または管理端末）から
Test-NetConnection -ComputerName <WSUSサーバー名またはFQDN> -Port 8530
# 名前解決も含めて確認したい場合
ping <WSUSサーバー名>次に「WSUS の URL へ HTTP で到達できているか」を確認します。ブラウザがなくても、PowerShell で確認できます。
# 代表的な WSUS エンドポイント（HTTP 200/401/403 など “到達している反応” が返るかを見る）
Invoke-WebRequest -Uri "http://<wsus>:8530/selfupdate/wuident.cab" -UseBasicParsing
Invoke-WebRequest -Uri "http://<wsus>:8530/ClientWebService/client.asmx" -UseBasicParsing判断の目安は次のとおりです。
- ファイル（wuident.cab）が取得できる：到達性としてはかなり良好（SelfUpdate が生きている）
- client.asmx で XML っぽい応答/401/403 が返る：Web サービスに到達している（少なくとも “ルーティング” はできている）
- タイムアウト、接続拒否、名前解決不可：ファイアウォール / DNS / ルーティング / IIS バインド / ポート設定から疑う
WSUS サーバー側で真っ先に見るログ：イベントビューアー
WSUS が要求を受け付けられているか、内部でエラーを起こしていないかは、まずイベントログで掴みます。
- イベント ビューアー → Windows ログ → アプリケーション → ソース Windows Server Update Services
- （併せて）イベント ビューアー → Windows ログ → システム（IIS やネットワーク起因のヒントが出ることがあります）
「サーバーは動いていそうなのにクライアントが来ない」場合、イベントログに以下のようなヒントが出やすいです。
- DB 接続関連（WID/SQL が止まっている、権限、接続文字列）
- Web サービス関連（IIS のアプリプール停止、仮想ディレクトリの異常）
- 自己更新（SelfUpdate）関連の構成不整合
WSUS のログファイル：場所と見る観点を固定する
WSUS には専用のログファイル群もあります。環境で多少の差はありますが、代表的には WSUS のインストール先配下（例：Update Services\LogFiles）にまとまります。まずは「エラーの発生時刻」を軸に見ていくのがおすすめです。
| ログ | 何が分かるか | 見るべきタイミング | よくある使い方 |
|---|---|---|---|
| WSUSCtrl 系（ヘルスチェック系） | WSUS の健全性、主要コンポーネントの状態 | 新規構築・移行直後 | まずここで「致命傷がないか」を確認 |
| SoftwareDistribution / 同期系 | 同期、配布、内部処理の流れ | 同期が失敗する、更新の取り込みが進まない | WSUS が “動いているけど進まない” の切り分け |
| IIS ログ | クライアントがどの URL に来たか、HTTP ステータス | クライアントが来ない/来ているか不明 | “そもそも 8530 に要求が来ているか” を確認 |
IIS ログは「WSUS に到達しているかどうか」を判定する強力な材料です。クライアントが WSUS を見に行っているなら、ClientWebService などのパスにアクセスログが残ります。逆に、IIS ログが完全に静かな場合は「クライアントが WSUS URL を見に行っていない」可能性が高くなります。
WindowsUpdate.log の読み方：生成方法と “エラーの見つけ方” を決める
WindowsUpdate.log はクライアント側の更新処理ログ
WindowsUpdate.log は基本的にクライアントが更新を検出・ダウンロード・インストールする過程を記録します。WSUS のトラブルシュートでは特に、次のような情報が重要です。
- 端末が参照している更新サーバー（WSUS URL）
- 接続時のエラーコード（HTTP / WinHTTP / 証明書 / プロキシ等）
- 検出結果（どの更新を要求したか）
Windows 10 / Server 2016 以降は「生成して読む」が前提
比較的新しい OS では、Windows Update の詳細ログは ETL（イベントトレース）形式で保持され、従来のように常にテキストの WindowsUpdate.log が更新され続ける形ではありません。読みやすいログを得る定番手段が PowerShell の Get-WindowsUpdateLog です。
# 生成先を指定して WindowsUpdate.log を作る（Server Core でもパス指定が安全）
Get-WindowsUpdateLog -LogPath C:\Temp\WindowsUpdate.log閉域環境などで「対象端末がインターネットへ出られず、変換がうまくいかない」場合は、ETL を別マシンにコピーしてから生成する運用が有効です（実施可否は環境の制限に依存します）。その場合は ETL の保存場所（例：C:\Windows\Logs\WindowsUpdate\）を意識しておくと切り分けが早くなります。
WindowsUpdate.log を読むときの“見る順番”
WindowsUpdate.log は量が多く、漫然と眺めても疲弊しがちです。実務では次の順番で “当たり” を付けると、原因が早く絞れます。
- エラーコード（0x から始まる）を探す
- 同時刻の前後 1〜3分を読む（原因は少し前に出ていることが多い）
- 「どの URL に接続したか」「プロキシが介在しているか」を確認する
- クライアント側イベントログ（Operational）と突き合わせる
ログの“検索ワード”を固定するとさらに楽です。
- FATAL / ERROR / WARNING
- HRESULT / 0x
- WUServer（WSUS の URL が出ることがある）
- Proxy / WinHttp
- ServiceUrl / ClientWebService
PowerShell でログを絞る例です。
# エラーっぽい行をざっくり抽出
Select-String -Path C:\Temp\WindowsUpdate.log -Pattern "FATAL|ERROR|WARNING|0x" -SimpleMatchWindowsUpdate.log だけで詰まったら：イベントログで補完する
クライアント側は WindowsUpdate.log のほか、イベントログがかなり強力です。次を併用すると「何が起きたか」が追いやすくなります。
- イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → WindowsUpdateClient → Operational
WindowsUpdate.log で見えにくい場合でも、Operational 側に「検出開始」「サーバーへ接続」「失敗コード」などが端的に出ることがあります。
よく見るエラーの“型”と、疑うべき方向
エラーコードは環境により様々ですが、WSUS 接続不良の現場で頻出する“型”があります。コードを暗記するより、現象と疑うべき方向をセットで覚えると早いです。
| ログの雰囲気 | 疑うべき方向 | 最初にやる確認 | 次の一手 |
|---|---|---|---|
| タイムアウト / 名前解決不可 / 接続できない | DNS、FW、ルーティング、ポート、WSUS URL（ポート番号） | Test-NetConnection wsus -Port 8530 | GPO の WSUS URL を確認（:8530 付きか） |
| プロキシ関連っぽいログが出る | WinHTTP プロキシ、認証プロキシ | netsh winhttp show proxy | 閉域なら reset、必要なら WSUS を例外へ |
| HTTP 401/403 が絡む | IIS 側（認証/仮想ディレクトリ/アプリプール） | IIS ログで該当パスのステータスを見る | WSUS エンドポイントに直接アクセスして反応を確認 |
| HTTPS/証明書が絡む | SSL 設定、証明書の信頼、URL の https 化漏れ | URL が http/https で揃っているか | クライアントの信頼ストア、WSUS 側の証明書を再確認 |
「No client computers have ever contacted the server」：最短で直すチェック
WSUS コンソールで「No client computers have ever contacted the server」と表示される場合、WSUS そのものの故障というより、クライアントが一度も WSUS に“報告”していない状態です。新規構築・移行時は特に、次の順で潰すのが最短です。
最優先：GPO の WSUS URL が 8530 付きになっているか
旧環境が 80 ポート運用で、新環境が 8530（WSUS の既定）になった場合、最も多い原因はこれです。
グループポリシー（代表例：「イントラネットの Microsoft 更新サービスの場所を指定する」）で、ポート番号込みの URL を明示します。
# 例（HTTP の場合）
http://<wsusサーバー名またはFQDN>:8530ここで重要なのは、更新検出用と統計送信用の両方を同じように設定することです。
| 項目 | 設定値の例 | ミスが起きやすい点 |
|---|---|---|
| 更新検出用サーバー | http://wsus:8530 | ポート番号を付け忘れて http://wsus のまま |
| 統計送信用サーバー | http://wsus:8530 | 片方だけ 8530 を付けて片方が未設定 |
WSUS 側の表示が「一度も来ない」のままなら、まずこの URL を疑うのが王道です。
クライアントで「GPO が効いている」を最短で確かめる
GPO を設定したつもりでも、OU のリンク先違い・フィルタ・セキュリティの問題でクライアントに降りていないことがあります。最短確認は次の2つです。
1) gpresult で確認
gpupdate /force
gpresult /h C:\Temp\gpresult.html2) レジストリで WSUS URL を確認
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer期待値は次のとおりです。
WUServerとWUStatusServerにhttp://wsus:8530形式が入っているUseWUServerが0x1（WSUS を使う）になっている
ここで 80 ポートの URL が残っていたり、ポートが抜けていたりするなら、WSUS 側に来ないのは自然な挙動です。
「Web ページが開けない」でも焦らない：WSUS は“トップページ確認”が本質ではない
Server Core ではブラウザ確認がしづらく、さらに WSUS はルート（http://wsus:8530/）が人間向けに表示されないこともあるため、見た目で判断すると遠回りになります。
代わりに、次のようなエンドポイントで機械的に確認します。
http://<wsus>:8530/selfupdate/wuident.cab（取得できるか）http://<wsus>:8530/ClientWebService/client.asmx（到達して応答が返るか）
これらがクライアント端末から取得できるのに WSUS に登録されない場合は、次の “クライアントが報告しない理由” の切り分けへ進みます。
クライアントに “今すぐ” 連絡させて WSUS に出す
WSUS はクライアントが自発的に検出・報告して初めてコンソールに出てきます。設定反映後、自然に待っても出ますが、現場では「確認を急ぎたい」ことが多いので、手動トリガーで前倒しします。
代表的な流れは次のとおりです（OS バージョン差があるため、まずは安全な手順から）。
- GPO 反映：
gpupdate /force - Windows Update 関連サービス再起動（状況により）：
wuauserv,bitsなど - 検出の実行（環境の標準手順に合わせる）
サービス再起動の例です。
net stop wuauserv
net stop bits
net start bits
net start wuauserv検出の実行は、組織の標準運用（Windows 10/11 の場合は OS の仕組み）に合わせて行ってください。実行後は、クライアント側で WindowsUpdate.log（または Operational ログ）を見て、WSUS の URL に向かっているかを確認します。
それでも来ないときに多い追加原因
ポート番号以外にも、次の要因で「一度も接続してこない」状態に見えることがあります。該当しそうなものから優先的に潰してください。
| 原因カテゴリ | ありがちな状態 | 確認ポイント | 対処の方向 |
|---|---|---|---|
| ファイアウォール | サーバー/ネットワーク機器で 8530 が遮断 | Test-NetConnection が失敗 | サーバー側の受信規則、NW 側の許可 |
| 名前解決 | クライアントが wsus 名を引けない / 別 IP に向く | ping / nslookup | DNS レコード修正、FQDN で統一 |
| プロキシ | WinHTTP にプロキシが残り WSUS へ行けない | netsh winhttp show proxy | リセットまたは例外設定 |
| HTTPS/SSL | WSUS を SSL 化したがクライアントが信頼していない | URL の http/https、証明書の信頼 | 証明書配布、URL 統一、8531 の開放 |
| ポリシー競合 | WSUS と Windows Update for Business 系が混在 | 適用 GPO を棚卸し | 方針を一本化（WSUS 優先なら関連設定を整合） |
特に「移行前に別の更新方針（別の WSUS、WUfB、手動設定など）が存在していた」環境では、レジストリや GPO の整合が崩れていることがあるため、いったん “WSUS に寄せる設定だけが効く” 状態に整理するのが近道です。
Unassigned Computers に入るのは正常：グループ分けの考え方
クライアントが WSUS に見え始めた後、「どこにいるか分からない」「グループに入らない」と感じたら、まずは Unassigned Computers（未割り当て） を確認します。これは「クライアントは来たが、グループの自動割り当てがまだ」な状態としてよくあります。
グループ分けの方法は大きく2つです。
- WSUS コンソールで手動割り当て：台数が少ない、暫定対応向き
- クライアント側ターゲティング（GPO）：台数が多い、運用を標準化したい場合に向く
クライアント側ターゲティングを使う場合は、対象グループ名（WSUS 上で作成したグループ名と一致）をポリシーで指定し、端末側が自分の所属を名乗る形になります。ここが未設定だと、まず Unassigned に入るのが自然です。
現場で迷わない切り分け手順：サービス → IIS → GPO → クライアントログ → サーバーログ
最後に、実務でそのまま使える “確認順” をチェックリスト形式にします。WSUS のトラブルは、順番を固定すると再現性が上がります。
| ステップ | 目的 | 確認方法の例 | OK の目安 | NG のときの着眼点 |
|---|---|---|---|---|
| サービス | WSUS/IIS が動いているか | Get-Service WsusService Get-Service W3SVC | Running | 役割/機能、依存サービス、イベントログ |
| IIS/ポート | 8530 が待ち受けているか | netstat -ano | findstr :8530 | LISTEN がある | IIS バインド、FW、アプリプール |
| エンドポイント | WSUS の Web サービスに到達できるか | Invoke-WebRequest http://wsus:8530/selfupdate/wuident.cab | 取得できる / 応答が返る | SelfUpdate の構成、IIS の仮想ディレクトリ |
| GPO/レジストリ | クライアントが WSUS を向く設定か | reg query ... WUServer reg query ... WUStatusServer | :8530 付きで一致 | 旧 URL 残り、OU/フィルタ/優先順位 |
| クライアントログ | 実際に WSUS に行こうとしているか | WindowsUpdate.log / Operational | WSUS URL と通信の痕跡 | Proxy/DNS/HTTPS/競合ポリシー |
| サーバーログ | WSUS が受けているか | IIS ログ / WSUS イベント | 該当パスへのアクセスが残る | 来ていないなら GPO/到達性、来ているなら WSUS 側処理 |
まとめ：WindowsUpdate.log と WSUS ログを“役割分担”させると解決が早い
WSUS の動作確認は、WindowsUpdate.log だけを追うと迷いやすく、逆に WSUS サーバー側だけを見ても「クライアントが設定通り動いているか」が掴みにくい分野です。クライアント側は WindowsUpdate.log（必要なら Get-WindowsUpdateLog で生成）と Operational、サーバー側は WSUS のイベントログと IIS ログ、そして 8530 のエンドポイント疎通確認を組み合わせることで、原因が「設定（GPO/URL/ポート）」「通信（DNS/FW/Proxy）」「サーバー処理（IIS/DB/WSUS 内部）」のどこにあるかを短時間で切り分けられます。
特に「No client computers have ever contacted the server」は、移行時にポートが変わった環境で発生しやすい症状です。まずは GPO の WSUS URL に :8530 が付いているか、クライアントのレジストリに反映されているか、そしてエンドポイントへ到達できるか——この3点を最優先で確認してください。
コメント