Windows Server 2012 R2 で WSUS を構築し、GPO でクライアントを WSUS 参照にしているのに、Windows 10 だけ更新プログラムを取得しない――この現象は現場で非常に多い“つまずきポイント”です。WSUS コンソールには端末が登録されるため一見サーバー側の問題に見えますが、原因がクライアント側の設定競合（デュアルスキャン）であるケースが少なくありません。本記事では、最短で原因を切り分け、GPO で確実に解消する手順を具体例付きでまとめます。
起きている症状を整理する（WSUS に端末は見えるのに更新が来ない）
質問でよくある状況は次の通りです。
- Windows Server 2012 R2 に WSUS を新規構築した
- GPO で「イントラネットの Microsoft 更新サービスの場所を指定する（WSUS の URL）」を設定済み
- WSUS コンソールに Windows 10 クライアントが“登録”されてくる（コンピューター一覧に表示される）
- しかし Windows 10（例：1809）が WSUS から更新を読み取らない／ダウンロードしない
- WSUS 側では Windows 10 1903 関連の更新を未承認（またはそもそも配布したくない）
| 見え方（現象） | 管理者が勘違いしやすいポイント | 実際に起きがちな原因 |
|---|---|---|
| WSUS コンソールに端末が出る | 「WSUS 参照はできているはず」 | 端末登録（検出）と、更新スキャン／取得は別。登録だけできて更新だけ別経路になることがある |
| Windows 10 が更新を要求してこない | 「WSUS で承認が足りない？」 | デュアルスキャンで Windows Update 側にスキャンし、WSUS の承認状態が反映されない |
| “1903 を承認していない”のに挙動が変 | 「1903 を拒否しないとダメ？」 | Windows Update for Business（更新延期）系のポリシーが絡むと、WSUS を設定していてもクラウドへスキャンする |
結論：典型原因は「デュアルスキャン（Dual Scan）」
デュアルスキャンとは、端末に WSUS 参照設定が入っているにもかかわらず、Windows Update for Business（WUfB）の「更新延期」や「一時停止」などのポリシーが同時に適用されることで、クライアントが WSUS と Windows Update（インターネット側）へ同時にスキャンしてしまう状態を指します。
この状態になると、管理者目線では次のように見えてしまいます。
- WSUS には端末がいるのに、必要な更新が検出されない
- 端末側で更新を確認しても、WSUS 承認とは無関係な動きをする
- 更新ソースが混ざり、トラブルシュートが泥沼化する
特に「WSUS 運用をしたい」組織でも、過去の設定流用やテンプレート GPO の影響で WUfB の延期系ポリシーが残っていると、意図せずデュアルスキャンが発生します。
まずは切り分け：クライアントの“既定の更新元（Default AU Service）”を確認する
デュアルスキャンを疑うときは、闇雲に WSUS を疑う前に、クライアントが実際にどこを既定の更新元として扱っているかを確認します。管理者権限の PowerShell で次を実行してください。
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.Services | Select-Object Name, IsDefaultAUService出力例（イメージ）は次のようになります。
| Name | IsDefaultAUService | 意味 |
|---|---|---|
| Windows Update | True | 既定の更新元がクラウド（インターネット）。WSUS を設定していても、WSUS から取らない挙動と一致 |
| Windows Server Update Service | True | 既定の更新元が WSUS。通常は WSUS 承認に沿って検出／取得する |
ここで WSUS が既定になっていない（Windows Update が既定になっている）場合、WSUS 側の承認や同期以前に「端末が WSUS を主戦場としていない」ことが確定します。原因の第一候補がデュアルスキャンになります。
デュアルスキャンが発生する典型パターン（GPO の競合）
WSUS 構成でデュアルスキャンを誘発しやすいのは、次のような “更新延期／一時停止” 系のポリシーです（名称は Windows 10 のバージョンや ADMX により多少異なります）。
| ポリシーの例 | 本来の用途 | WSUS 運用で起きること |
|---|---|---|
| 機能更新プログラムを受け取るタイミングを選択する（延期） | WUfB（クラウド）で Feature Update を段階配布する | WSUS 参照でも Windows Update へスキャンが走り、WSUS から更新が来ないように見える |
| 品質更新プログラムを受け取るタイミングを選択する（延期） | WUfB で Quality Update を延期する | 同上。延期設定を維持したいほどデュアルスキャンが顕在化しやすい |
| 更新を一時停止する（Pause Updates） | クラウド更新を一時停止する | 端末が「WSUS ではなくクラウドの更新制御」を優先するトリガーになり得る |
このように、WSUS と WUfB は“更新の供給元”が別物です。両方の思想のポリシーを同時に当てると、Windows Update Agent が「クラウドに聞きに行く」動きになり、結果として WSUS の承認が効かない状態になります。
本命対策：デュアルスキャンを防ぐ GPO を有効化する
解決策はシンプルで、Windows 10 クライアントに次のポリシーを 有効 にします。
| 設定名 | 英語 UI | 場所（GPO） | 効果 |
|---|---|---|---|
| 更新の延期ポリシーによって Windows Update に対してスキャンが行われないようにする | Do not allow update deferral policies to cause scans against Windows Update | コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → Windows Update | WSUS 構成時に、延期系ポリシーが原因でクラウドへスキャンしないよう抑止する |
この GPO を有効化すると、端末の既定の更新元（Default AU Service）が WSUS に揃う方向に働き、「WSUS から更新を取ってこない」問題が解消するケースが多いです。
手順（GUI での設定）
- グループ ポリシー管理（gpmc.msc）で、Windows 10 に適用している GPO を編集します。
- 「コンピューターの構成」→「管理用テンプレート」→「Windows コンポーネント」→「Windows Update」を開きます。
- 「更新の延期ポリシーによって Windows Update に対してスキャンが行われないようにする」を 有効 にします。
- クライアントで
gpupdate /forceを実行し、必要に応じて再起動します。
設定項目が見つからないとき（2012 R2 管理端末での落とし穴）
Windows Server 2012 R2 の管理端末や古い ADMX のままだと、目的のポリシーが一覧に出てこないことがあります。その場合は ポリシー定義（ADMX/ADML）の更新が必要です。
- ドメインで「セントラルストア」を使っている場合：
\\ドメイン名\\SYSVOL\\ドメイン名\\Policies\\PolicyDefinitionsに最新の ADMX/ADML（ja-JP）を配置します。 - セントラルストア未使用の場合：GPO 編集を行う端末の
C:\\Windows\\PolicyDefinitionsを更新します。
ADMX を更新したら、GPO エディターを開き直してポリシーが表示されるか確認してください。
適用後の確認：WSUS に戻ったかを「見える化」する
対策を入れたら、必ず「効いたかどうか」を確認します。おすすめの確認ポイントを表にまとめます。
| 確認項目 | 確認方法 | 期待値（解消時） |
|---|---|---|
| 既定の更新元 | PowerShell（ServiceManager の IsDefaultAUService） | WSUS（Windows Server Update Service）が True |
| GPO の適用状況 | gpresult /h C:\\temp\\gp.html でレポート確認 | 目的のポリシーが「有効」として反映 |
| 端末側の更新スキャン | イベントログ（WindowsUpdateClient/Operational） | 更新サービスとして WSUS の URL が出る／エラーが減る |
| WSUS 側のステータス | WSUS コンソールで「必要な更新」「最終状態報告」 | 必要な更新が計上され、承認した更新が配布対象になる |
スキャンを手動で走らせる（Windows 10 向け）
GPO 適用直後は、端末が次の検出サイクルまで待つと時間がかかります。検証時は手動スキャンで状況を早めに確認できます。
| 目的 | コマンド例 | 補足 |
|---|---|---|
| ポリシー更新 | gpupdate /force | まずはこれ。必要なら再起動 |
| 更新スキャン開始 | UsoClient StartScan | Windows 10 の標準コマンド。管理者で実行 |
| ダウンロード開始 | UsoClient StartDownload | スキャン後に実行すると状況が進む場合がある |
| インストール開始 | UsoClient StartInstall | 運用ルールに従い慎重に |
それでも直らない場合の追加チェック（“WSUS 側が原因”のケースも潰す）
デュアルスキャン対策で大半は解決しますが、同時に次の基本も押さえておくと再発防止に役立ちます。
WSUS 側の最低限チェック
- 製品と分類：Windows 10（必要なら “Windows 10, version 1903 and later” など）と、セキュリティ更新・重要な更新・更新プログラム（運用方針により）を同期対象にしているか
- 同期が正常：WSUS の同期エラーが出ていないか（プロキシ、TLS、証明書、ストレージ）
- 承認先グループ：端末が所属するコンピューターグループに更新を承認しているか
- 期限切れ・拒否：誤って更新を拒否（Decline）していないか
クライアント側の WSUS 設定（レジストリでの確認ポイント）
GPO が正しく入っているかを、レジストリで目視するのも有効です（変更は GPO で行うのが基本）。
| 場所 | 値 | 期待例 |
|---|---|---|
HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate | WUServer | http://wsus.example.local:8530 など |
HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate | WUStatusServer | http://wsus.example.local:8530 など |
HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU | UseWUServer | 1（WSUS を使う） |
※レジストリが正しくても、延期系ポリシーが効いてデュアルスキャンが発生していると、見かけ上 WSUS を使っていないような挙動になります。だからこそ「Default AU Service の確認」が効きます。
ログで原因を追う（“どこにスキャンしているか”を証拠で見る）
「本当に WSUS に問い合わせているのか」「クラウドに行っていないか」を詰めるなら、ログが最短です。
- イベントビューアー：アプリケーションとサービス ログ → Microsoft → Windows → WindowsUpdateClient → Operational
- WindowsUpdate.log：Windows 10 は統合ログ形式のため、管理者 PowerShell で
Get-WindowsUpdateLogを実行して生成します
現場でやりがちな失敗と、再発させないための設計ヒント
失敗：WSUS 用 GPO に、WUfB の延期設定を“同居”させてしまう
テンプレート GPO を流用している組織ほど、WSUS の設定と WUfB の設定が同じ GPO（または同じ OU にリンクされた複数 GPO）に混在しがちです。運用上は次のどちらかに寄せるとトラブルが激減します。
| 方針 | おすすめの使い方 | 向いている環境 |
|---|---|---|
| WSUS 中心 | 更新は WSUS 承認で制御。WUfB の延期系ポリシーは極力使わない（使うならデュアルスキャン抑止を必ず有効化） | 社内 LAN/VPN 前提で一元管理したい |
| WUfB 中心 | Intune などで段階配布。WSUS は使わない／限定用途にする | モバイル端末が多く、クラウド更新が現実的 |
失敗：GPO は直したのに、ADMX が古くて実は設定できていない
Server 2012 R2 世代では、ポリシー定義が古いままだと “目的の設定項目が存在しない” だけでなく、似た名前の古い設定を触ってしまい、意図と違う状態になることがあります。GPO 設計の前に、まずは セントラルストアの ADMX を最新化しておくと安心です。
失敗：クライアントの Windows Update UI を見て「WSUS が効いていない」と判断する
Windows 10 の UI 表示は状況によって変わります。「一部の設定は組織によって管理されています」と出ていても、実際のスキャン先は別ということがあり得ます。判断材料としては UI よりも、次の順で “事実” を取りに行くのが確実です。
- Default AU Service（PowerShell）
- イベントログ（WindowsUpdateClient/Operational）
- WSUS の報告時刻／必要更新の計上
Q&A（問い合わせが多いポイント）
Q：WSUS 側で Windows 10 1903 の更新を承認していないのに、なぜ問題になるの？
A：デュアルスキャンが起きると、端末は WSUS 以外（Windows Update）にも問い合わせます。端末がクラウド側のメタデータを基準に動くと、WSUS の承認状況とズレた挙動になり、「1903 を承認していないのに Windows 10 が思った通りに更新しない」という現象につながります。WSUS で制御したいなら、まずスキャン先を WSUS に一本化するのが近道です。
Q：デュアルスキャン対策の GPO を入れると、ほかに影響はある？
A：基本的には「延期系ポリシーが原因でクラウドへスキャンすること」を抑止するため、WSUS 中心で運用したい組織ではメリットが大きい設定です。ただし、意図的にクラウド更新を併用している（例：一部端末だけ WUfB で更新する）場合は設計を見直した方がよいです。運用方針が混ざっていること自体がトラブルの温床になります。
Q：端末が社外にいる（VPN なし）ときも WSUS に固定される？
A：このポリシーは「延期系ポリシーによるクラウドスキャン」を止める目的のため、社外にいる端末が WSUS に到達できない場合、更新が進まなくなる可能性があります。テレワーク主体の環境では、WSUS 一択にするのか、WUfB を併用するのか、VPN を前提にするのかを含めて設計を先に固めるのがおすすめです。
まとめ：最短で直すなら「既定の更新元の確認」→「デュアルスキャン抑止 GPO」
WSUS（Windows Server 2012 R2）環境で Windows 10 が更新を取得しないとき、端末が WSUS に登録されているだけでは安心できません。まず PowerShell で Default AU Service を確認し、クラウドが既定になっているならデュアルスキャンを疑いましょう。対策として「更新の延期ポリシーによって Windows Update に対してスキャンが行われないようにする」を有効化すれば、WSUS にスキャン先が揃い、承認した更新が端末に降りてくる状態へ戻せます。
コメント