Windows Server 2016 上の WSUS を運用しているのに、Windows 10 端末だけが WSUS コンソールに表示されなくなった――この症状は「端末が WSUS を参照できていない／参照していない」か「別の更新ポリシーに上書きされている」ケースが大半です。現場で迷わないための確認順と具体的な切り分け手順をまとめます。
WSUS コンソールに端末が表示される仕組みを最初に押さえる
WSUS の「コンピューター」一覧は、Active Directory の OU にいる端末を自動で拾って表示する仕組みではありません。WSUS に表示されるのは、Windows Update クライアント（端末側）が WSUS に対して“スキャン・状態報告”を実行し、WSUS がその報告を受け取った端末です。
つまり、Windows 10 端末が WSUS コンソールに出てこない場合は、基本的に次のどれかです。
- WSUS を指す GPO（更新ポリシー）が端末に適用されていない（OUリンクミス、セキュリティフィルタ、WMIフィルタ、優先順位、継承ブロック など）
- 端末はポリシー適用されているように見えるが、WSUS の URL/ポートが正しくない（URL誤り、HTTP/HTTPS混在、ポート違い、名前解決）
- Windows Update for Business（WUfB）/ MDM（Intune等）/ ローカルポリシーが上書きして WSUS を見ていない
- 通信できない（FW/プロキシ/TLS/証明書/IIS/到達性）
- WSUS 側に届いてはいるが、重複IDや表示条件の問題で見えにくい（クライアントID重複、フィルタ、グループ割当、クリーンアップの影響）
| よくある勘違い | 実際に起きていること | 初動で見るべき場所 |
|---|---|---|
| 「組織によって一部の設定が管理されています」が出ているから WSUS 設定はOK | WSUS以外の更新ポリシー（WUfB/MDM/別GPO）でも同じ表示になる | gpresult / rsop / レジストリ（WUServer/UseWUServer） |
| OUに入っている端末は WSUS に自動登録される | 端末が WSUS に「報告」して初めて表示される | 端末の到達性（ポート）、WindowsUpdateClientログ、IISログ |
| サーバーOSは出るのに Windows 10 だけ出ないのは WSUS の不具合 | Windows 10 側の更新管理方式（WUfB/MDM）やポリシー競合が多い | Windows 10 の適用GPO一覧、MDM適用有無、レジストリ |
最優先：Windows 10 に適用されている GPO が WSUS を正しく指しているか確認する
結論から言うと、ここが最優先です。WSUS コンソールに端末が出ないときは、まず「Windows 10 が本当に WSUS を参照する設定になっているか」を証拠ベースで確認します。
OU リンク／適用状況を “端末で” 確認する（管理者が見落としやすい）
GPMC（グループポリシー管理）で「リンクしているはず」と思っても、以下で外れていることがよくあります。
- Windows 10 が想定外の OU に移動していた（または別OUに再作成された）
- セキュリティフィルタ（適用対象グループ）に Windows 10 だけ入っていない
- WMI フィルタで OS バージョン条件が合っていない（古い条件式が残っている）
- OU の継承ブロックや、上位GPOで上書きされている
端末側で、適用GPOの結果を確認します。
gpresult /r
gpresult /h C:\temp\gpresult.htmlまたは、結果セット（RSoP）で GUI で追います。
rsop.msc確認するときのポイントは次の2つです。
- 「Windows Update」関連のポリシーが、どのGPOから来ているか（意図したGPO名になっているか）
- 同種の設定が複数GPOに存在していないか（競合して最後に勝っている設定が想定外、という事故が多い）
WSUS 参照に必須の代表設定（GPO）
Windows 10 が WSUS を参照して報告するための中核は、一般に次のポリシーです（ドメインGPOの場合、コンピューターの構成側で設定します）。
| ポリシー（代表例） | 目的 | チェック観点 | NG例（よくある） |
|---|---|---|---|
| イントラネットの Microsoft 更新サービスの場所を指定する | WSUS の参照先（WUServer/WUStatusServer）を指定 | URL（http/https）とポート（8530/8531 等）が正しい | ポート違い、http/https混在、ホスト名誤り、末尾に余計なパス |
| 自動更新を構成する | スキャン・ダウンロード・インストールの方針 | 無効化されていないか、運用方針と一致するか | 意図せず「無効」になりスキャンが進まない |
| クライアント側ターゲット設定を有効にする（必要な場合） | WSUS グループを端末から自動振り分け | グループ名が WSUS 側と一致、TargetGroupEnabled が有効 | グループ名のタイプミス、OUごとに別名が混在 |
| Windows Update インターネット ロケーションに接続しない | Microsoft 側への参照（デュアルスキャン等）を抑止 | WSUS運用で「WSUSのみ」を徹底したい場合に重要 | 有効化されず、結果として Microsoft 側に流れる |
「サーバーOSは表示されるのに Windows 10 だけ表示されない」場合、OU設計やフィルタ設計が OS ごとに分かれており、Windows 10 の OU に WSUS 用 GPO がリンクされていない、あるいはWindows 10 用の別GPOが WSUS 設定を上書きしている、というパターンが非常に多いです。
端末のレジストリで “WSUS を見ている証拠” を取る
UIの表示や「管理されています」という文言よりも、レジストリのほうが確実です。Windows 10 端末で以下を確認します。
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /s特に注目する値は次のとおりです。
| キー | 値 | 意味 | 目安 |
|---|---|---|---|
| …WindowsUpdate | WUServer | 更新取得先（WSUS URL） | http(s)://WSUSサーバー:ポート |
| …WindowsUpdate | WUStatusServer | 状態報告先（通常 WUServer と同じ） | WUServer と一致するのが一般的 |
| …WindowsUpdate\AU | UseWUServer | WSUS を使うかどうか | 1 になっていること |
| …WindowsUpdate | TargetGroupEnabled / TargetGroup | クライアント側ターゲット設定 | 使う運用なら Enabled=1 かつグループ名一致 |
ここで WUServer / WUStatusServer が空、または UseWUServer が 0 の場合、WSUS コンソールに出てこないのは自然な結果です。まずは GPO の適用・競合を解消して、これらが正しく入る状態に戻すのが最短です。
Windows 10 特有の落とし穴：Windows Update for Business（WUfB）や MDM の混在
Windows 10 が「組織によって管理されています」と表示していても、その管理主体が WSUS（GPO）とは限りません。特に次の混在があると、Windows 10 が WSUS を見に行かず Microsoft 側へ流れる（または設定が揺れて不安定になる）ことがあります。
- Windows Update for Business（更新延期、更新リング、プレビュー/機能更新の制御）
- MDM（Intune など）で配布された Update ring / Update policy
- ローカルポリシーやスクリプトで Windows Update 設定が書き換えられている
競合の典型パターンと症状
| 競合パターン | 起きやすい症状 | 見分け方 | 対処の方向性 |
|---|---|---|---|
| WSUS と WUfB（更新延期ポリシー）を同時に適用 | Microsoft 側を見に行く/挙動が揺れる/WSUSに出ない | gpresult で Windows Update for Business のポリシーが有効 | WUfB を外すか、WSUS用OUでは適用しない設計に分離 |
| Intune の Update Ring が有効（MDM 管理） | GPO を入れても期待どおりにならない | 端末が Azure AD Join/登録済み、MDM管理あり | 更新管理の責任主体を統一（WSUS運用なら MDM の更新ポリシーを無効化） |
| 別GPOで「WSUS URL」が上書き | 一部端末だけ別の WSUS/URL を参照、または空になる | rsop.msc で勝っているGPOが想定外 | WSUS設定を1つのGPOに集約、競合を排除 |
MDM 管理の有無をざっくり把握する方法
Windows 10 端末が MDM（Intune 等）で管理されていると、GPO と並走して更新設定が入ってくることがあります。次の観点で確認できます。
- 設定 → アカウント → 「職場または学校にアクセス」
- コマンドで状態確認（Join/登録状況の把握）
dsregcmd /statusここで「Device State」や「Workplace Join」関連の情報が出ている場合、更新ポリシーの主体が分散していないか（GPOとMDMが両方触っていないか）を疑います。
通信の切り分け：Windows 10 から WSUS へ到達できるか（ポート・名前解決・プロキシ）
GPO とレジストリが正しくても、端末が WSUS へ到達できなければ登録（表示）されません。Windows 10 だけ出ない場合、ネットワークセグメントや FW ルール、プロキシ設定が Windows 10 のみ異なるケースもあります。
まずはポート疎通を確認する
WSUS の既定は 8530（HTTP）/ 8531（HTTPS）であることが多いですが、環境により 80/443 の場合もあります。端末側で以下を実行して、疎通を確認します。
PowerShell
Test-NetConnection WSUSサーバー名 -Port 8530HTTPS 運用の場合：
PowerShell
Test-NetConnection WSUSサーバー名 -Port 8531加えて、WSUS の SelfUpdate パスにアクセスできるかを見ると、IIS 側の応答有無を掴みやすいです。
PowerShell
Invoke-WebRequest -UseBasicParsing "http://WSUSサーバー名:8530/selfupdate/wuident.cab"成功すればダウンロード（または 200 応答）になります。名前解決や FW に問題があると、タイムアウトや接続エラーになります。
プロキシが絡む場合は WinHTTP プロキシも確認する
ブラウザのプロキシ設定と、Windows Update が参照するプロキシ（WinHTTP）が一致していないと、Windows Update 通信だけ失敗することがあります。
netsh winhttp show proxy「直接アクセス（Direct access）」なのか、明示プロキシが入っているのかを確認し、組織の標準設定と揃えます。
HTTPS（8531/443）運用なら証明書・TLSも疑う
WSUS を HTTPS で公開している場合、Windows 10 は証明書の信頼や TLS 設定の影響を受けます。よくある原因は次のとおりです。
- 端末が WSUS のサーバー証明書を信頼していない（中間CA未配布など）
- WSUS 側で古い暗号スイートや TLS を無効化し、端末との共通がなくなった
- FQDN で証明書を発行したのに端末は短い名前でアクセスしている（CN/SAN 不一致）
この場合、ブラウザで WSUS URL にアクセスしたときの証明書エラーや、イベントログ（後述）のエラーが手がかりになります。
端末側の「スキャン・報告」を促進して WSUS へ再登録させる
設定を直しても、端末が次の検出・報告タイミングまで待つと「直ったのかどうか」が判断しづらくなります。安全に確認するために、まずは GUI の操作から始め、必要に応じてコマンドで促進します。
もっとも確実：Windows Update 画面で手動チェック
Windows 10 の「設定 → 更新とセキュリティ → Windows Update → 更新プログラムのチェック」を実行します。これだけでも WSUS 参照が正しくなっていれば、端末はスキャン動作に入ります。
コマンドで促進する（環境差があるため複数手段を用意）
Windows 10 のビルドや運用形態によって有効なコマンドが異なることがあります。次を上から順に試し、「イベントログで WSUS へのアクセスを試みた形跡が出るか」を確認します。
rem ポリシー更新
gpupdate /force
rem スキャン促進（Windows 10 で使われることが多い）
UsoClient StartScan
rem 旧来のWindows Update Agent操作（環境により効かない場合も）
wuauclt /detectnow
wuauclt /reportnow「WSUS コンソールに出ない」症状の切り分けでは、コマンドが効いたかどうかを“画面の変化”だけで判断しないのがポイントです。次のログで、WSUS へ向かう通信が発生しているかを追います。
Windows Update 関連ログで確認する
| 見る場所 | 目的 | 探すキーワード例 |
|---|---|---|
| イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → WindowsUpdateClient → Operational | スキャン開始、サーバー参照、失敗理由の確認 | scan / update service / error / 0x |
| WindowsUpdate.log（必要に応じて生成） | より詳細なトレース確認 | WSUS のURL、SOAP通信、失敗コード |
Windows 10 では WindowsUpdate.log が ETW から生成される形式になっていることがあるため、必要に応じて次で作成します。
PowerShell
Get-WindowsUpdateLogそれでも出ないときの追加切り分け（現場で効く順）
WSUS 側にリクエストが届いているか IIS ログで確認する
端末が WSUS に報告する際、WSUS（IIS）には特定の Web サービス（例：ClientWebService など）へのアクセスが残ります。WSUS サーバー側で IIS ログを確認して、Windows 10 のアクセスが来ているかを見ます。
- IIS ログの一般的な場所：
C:\inetpub\logs\LogFiles\ - 確認観点：Windows 10 の IP からのアクセスがあるか、ステータスコードが 200/401/403/404/503 などになっていないか
サーバーOSの端末は来ているのに Windows 10 のアクセスがまったく来ないなら、問題はほぼ端末側（ポリシー/通信/プロキシ/証明書）に絞れます。
WSUS コンソールの表示条件・フィルタを疑う
意外とあるのが「存在しているが見えていない」ケースです。
- 「すべてのコンピューター」や「未割り当てのコンピューター」を見ているか
- 検索ボックスで端末名（完全一致/部分一致）を試したか
- クリーンアップ（不要コンピューターの削除）後に、端末が再報告していないだけではないか
ただし、質問のように「以前は出ていたが途中から Windows 10 だけ出なくなった」場合、フィルタよりもポリシーの上書きや通信条件の変化のほうが頻出です。
クライアントID（SUSClientId）重複を疑う（イメージ展開環境で多い）
Windows 10 をクローニング（同一イメージから大量展開）している場合、端末の WSUS クライアントIDが重複し、WSUS 上で「別端末として増えない」「片方が上書きされる」ように見えることがあります。特に Windows 10 だけが同一イメージ由来なら疑いどころです。
この場合は、まず WSUS コンソールで端末が “1台分だけ存在していないか” を確認し、怪しい場合に限り、端末側の WSUS クライアントID再生成を検討します。影響が出る操作のため、実施前に運用ルール（再起動可否、メンテ時間）に沿ってください。
参考として、確認の観点は次です（手順自体は環境方針により差が出るため、実施可否は社内標準に合わせます）。
- 同一端末名が出たり消えたりする／台数が増えない
- WSUS で「最後の状態報告」が別端末の時間で更新される
- 端末側のレジストリ（WindowsUpdate のクライアント識別）に同一値が多発
Windows Update コンポーネントのリセット（最後の手段として）
通信もポリシーも正しいのに、Windows Update クライアントが内部的に壊れていて報告できないケースもゼロではありません。イベントログにエラーが継続する、SoftwareDistribution が破損している疑いがある、といった場合は、Windows Update コンポーネントのリセットが有効なことがあります。
一般的な実施例（影響：更新キャッシュの再取得が発生することがあります）。
net stop wuauserv
net stop bits
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
net start bits
net start wuauservリセット後に Windows Update の手動チェックを実施し、WindowsUpdateClient ログで WSUS 参照が復活したかを確認します。
「更新プログラムによる競合が原因か？」への考え方
「以前は出ていたのに、途中から出なくなった」という時点で、環境のどこかが変わっています。更新プログラムそのものが直接の原因というより、更新をきっかけに次の変化が起きていることがよくあります。
- Windows 10 の機能更新（Feature Update）後に、更新管理ポリシーの設計が追いつかず混在（WUfBの適用、MDM管理の開始、GPOの分岐など）
- WSUS サーバー側の更新やセキュリティ強化で TLS/暗号周りが変わり、Windows 10 だけ影響（HTTPS運用時に顕在化しやすい）
- ネットワーク変更（FW/プロキシ/ルーティング）で、Windows 10 のいるセグメントだけ到達不可
原因を一点に決め打ちするより、次の順番で機械的に切り分けると、短時間で当たりに到達しやすいです。
| 切り分け順 | 確認内容 | 判断のしかた | 次アクション |
|---|---|---|---|
| 1 | Windows 10 に WSUS を指す GPO が適用されているか | gpresult / rsop で GPO 名と設定を特定 | OUリンク/フィルタ/競合を修正 |
| 2 | レジストリに WUServer/WUStatusServer/UseWUServer が入っているか | reg query で “WSUS参照の証拠” を確認 | 入っていなければポリシー側を再調整 |
| 3 | WSUS へ到達できるか（ポート、名前解決、プロキシ） | Test-NetConnection / Invoke-WebRequest | FW/プロキシ/証明書/TLS を修正 |
| 4 | Windows Update for Business / MDM の混在がないか | gpresult で WUfB 設定、dsregcmd で登録状態 | 更新管理の主体を統一（WSUS運用なら競合を排除） |
| 5 | WSUS/IISログに Windows 10 のアクセスが来ているか | IISログで該当IP/200応答を確認 | 来ていなければ端末側、来ていればWSUS側の処理/表示を深掘り |
まとめ：最短で直すための「初動」は GPO と参照先の証拠取り
Windows 10 端末が WSUS コンソールに表示されない問題は、WSUS サーバー側の設定よりも、Windows 10 側が WSUS を参照して報告できているかで決まります。特に「組織によって管理されています」という表示だけで安心せず、
- Windows 10 に適用されている GPO（gpresult / rsop）
- WSUS 参照のレジストリ（WUServer / WUStatusServer / UseWUServer）
- WSUS への疎通（ポート/プロキシ/TLS）
- WUfB/MDM の混在（更新管理の主体の統一）
この順で確認すると、遠回りせず原因に到達できます。サーバーOSは出ているのに Windows 10 だけ出ない、という状況ほど「Windows 10 にだけ別のポリシーが勝っている」ことが多いので、まずは “端末側の適用結果” を確実に押さえるのが最優先です。
コメント