WSUSでWindows 10の機能更新プログラム（Feature Update）を配布しているのに、Version 2004だけが「Not applicable（適用対象外）／Not needed」となり、承認しても必要判定が出ないことがあります。原因の切り分けと、Upgrades分類の再有効化で復旧した手順をまとめます。
発生した現象（WSUSでは2004だけが適用対象外になる）
WSUSでWindows 10の機能更新プログラム（Feature Update）を管理している環境で、次のような挙動に遭遇しました。ここでいうVersion 2004は、いわゆる20H1に相当します。
- Windows 10 Version 1909（x64）の機能更新は、クライアント側で「必要（Needed）」または「インストール済み（Installed）」として正しく判定される
- しかしWindows 10 Version 2004（x64）の機能更新は、WSUSで承認し、ダウンロード済みでも、全クライアントが「Not applicable（適用対象外）」や「Not needed」と表示される
- 1909が動作している端末であっても、2004が「必要」にならず、配布が始まらない
- 一方、端末でWindows 10 Update Assistant（更新アシスタント）を実行すると2004への更新が推奨され、互換性要因よりもWSUS側の判定・レポートに違和感がある
| 観点 | Version 1909（x64） | Version 2004（x64） |
|---|---|---|
| WSUSでの承認 | 承認済み | 承認済み（ダウンロード済み） |
| クライアントの状態 | Needed / Installed として正常 | Not applicable / Not needed になり配布されない |
| 端末側の更新手段 | WSUSで配布可能 | Update Assistantでは推奨されることがあり、WSUSの判定が疑わしい |
作業前に確認しておきたい前提（ここがズレると切り分けが迷子になる）
今回のようなトラブルは、WSUSの問題と端末側の問題が見え方として混ざりやすいです。復旧作業に入る前に、最低限の前提だけは揃えておくと、後戻りが減ります。
- WSUSで当該Feature Update（例：Feature update to Windows 10, version 2004, x64-based systems）が「承認済み」である
- WSUSがその更新を「ダウンロード済み」と認識している（コンテンツ領域の容量も不足していない）
- 対象端末がWSUSを参照している（社内WSUSのURLがポリシーで正しく配布されている）
- 端末がWSUSへ状態報告できている（最後の状態報告日時が更新される）
まず押さえたい：WSUSの「Not applicable」と「Not needed」の意味
WSUSコンソールで表示される状態は、端末の状況だけでなく、WSUSが保持するメタデータ（分類・製品・適用規則・改訂情報）や、端末からの状態報告のタイミングにも影響されます。誤解が起きやすい代表例が「Not applicable」と「Not needed」です。
| 表示 | 一般的な意味合い | よくある要因 |
|---|---|---|
| Needed | 端末に未適用で、適用対象として判定された | 要件を満たし、対象製品・エディション・アーキテクチャが一致している |
| Installed | 端末にインストール済みとして報告された | 正常に適用済み、または後続の更新で置き換えられた |
| Not applicable | そもそも適用対象外として判定された | 製品/分類の不一致、エディション違い、言語違い、前提条件未達、メタデータ不整合 |
| Not needed | 「必要なし」として扱われた（既に同等以上、または抑止されている可能性） | ターゲットバージョン固定、ポリシーでの延期/ブロック、後続版が優先、レポートの不整合 |
今回のポイントは、「1909の端末ですら2004が必要にならない」ことです。一般論として「段階的に上げる必要がある」「互換性でブロックされる」ケースもありますが、1909で正常に機能更新が評価できているなら、端末側の仕組みは一定動いています。よって、WSUS側の分類（Classification）やメタデータの整合性を疑うのが近道でした。
結論：Classificationの「Upgrades」を一度OFF→再ONし、WSUSサービスを再起動する
最終的に復旧した方法はシンプルで、WSUSの「分類（Classifications）」で “Upgrades（アップグレード）” を一度無効化し、WSUSサービスを再起動した後に、再度有効化して再起動する、という手順でした。これにより、Feature Update to Windows 10 Version 2004 が「Needed」として正しく評価されるようになりました。
復旧手順（コンソール操作の例）
- WSUS管理コンソールで [Options] → [Products and Classifications] → [Classifications] を開く
- 「Upgrades」 のチェックを外し、設定を保存する
- WSUSサービスを再起動する（IISを含めて再起動する場合もある）
- 必要に応じて、端末の状態報告が揃うまで数時間〜1日程度待つ（後述の「再検出」で促進も可能）
- 同じ画面に戻り、再度「Upgrades」を有効化して保存する
- もう一度WSUSサービスを再起動する
- WSUSの対象更新（Feature Update to v2004）を確認し、端末側で「Needed」として出るか観測する
サービス再起動をPowerShellで行う例
運用上はメンテナンス時間を確保し、影響範囲を理解したうえで実施してください。以下は一例です。
Restart-Service -Name WsusService -Force
# IISも含めて再起動したい場合（影響が大きいので慎重に）
iisreset /restart復旧後に確認したい「変化」
本当に直ったかどうかは、WSUSコンソールの表示だけでなく、端末からの報告更新も合わせて確認すると確実です。
- WSUSの更新一覧で、v2004のFeature Updateが「Not applicable」一色から、対象端末で「Needed」が混ざる
- 端末の「最後の状態報告」が更新される（報告が止まっていると表示が古いままになる）
- 端末側のWindows Update画面やイベントログで、WSUSへのスキャンが走っている痕跡がある
この手順で何が起きているか（現場感のある説明）
「Upgrades」は、Windows 10の機能更新（Feature Update）が属する分類です。分類を一度外して戻すことで、WSUSが保持している“アップグレード系メタデータ”の取り扱いがリセットされ、同期・承認・レポートの整合が取り直されることがあります。症状としては、承認済みのはずなのに全端末が適用対象外扱いになっていたものが、再評価され「必要」として現れる、という形で表面化します。
特に、WSUS運用では同期の改訂（Revision）やメタデータの蓄積、分類の追加・削除の履歴などが重なると、“更新自体は存在するのに、判定だけがおかしい”という状態になりやすい印象があります。今回の手順は、そのねじれを最小の操作で戻す「再整列」のような位置づけです。
補足：同じ症状でも別の原因が隠れていることがある
今回の解決策は「UpgradesのOFF→ON」でしたが、同じように2004が出ないケースでも、原因が複数存在します。復旧後の再発防止にもつながるため、切り分け観点を整理しておきます。
承認しているFeature Updateが端末エディションと合っているか
WSUSでは、機能更新が「Business editions」向けと「Consumer editions」向けに分かれていたり、言語（ja-jp / en-us など）が異なるものが並ぶことがあります。端末のエディションと異なる更新を承認していると、端末は適用対象外として扱いがちです。
| 確認ポイント | 見る場所 | チェックのコツ |
|---|---|---|
| エディション（Business/Consumer） | WSUSの更新タイトル・説明 | 端末がPro/Enterprise中心ならBusiness editions側が合うことが多い |
| 言語 | 更新タイトル（ja-jp等） | 日本語端末でも多言語イメージや英語UIの場合は要注意 |
| アーキテクチャ | x64 / x86 / ARM64 | x64端末にx86を承認しても対象外になって当然 |
Products（製品）の選択が不足していないか
WSUSでは「製品（Products）」と「分類（Classifications）」の組み合わせで同期対象が決まります。機能更新は、いわゆる“通常の更新”とは別枠として扱われることがあり、Windows 10関連の製品チェックが不足していると、メタデータが揃わず判定が崩れることがあります。
- Windows 10関連の製品が適切に選ばれているか
- 機能更新を扱うために「Upgrades」が有効になっているか
- 同期後、更新が正しくダウンロード・展開されているか
GPO/レジストリでFeature Updateが抑止されていないか
環境によっては、端末側で「特定のバージョンに固定する」「機能更新を延期する」設定が入っていることがあります。この場合、WSUSで承認していても端末が“必要ない”と扱うことがあるため、Not neededが大量発生するときは疑ってください。
代表例として、ターゲットバージョン固定（TargetReleaseVersion）系の設定が入っていると、端末は指定バージョン以上に上がりません。設定が必要な環境もありますが、2004へ上げたいのに1909固定が残っていると、まさに今回の症状に似た見え方になります。
Windows Update for Business（WUfB）やDual Scanの混在
WSUS運用とWUfBの設定が混ざると、端末は「スキャン元」「適用判断」が揺れやすくなります。結果として、WSUS側では対象外に見えたり、端末側で別経路から更新候補が出たりします。Update Assistantで推奨されるのにWSUSでは出ない、という“ねじれ”があるときは、端末がどこに問い合わせているかを確認するのが有効です。
最短で原因に近づく：切り分けチェックリスト
「とにかく早く配布を回復したい」状況では、闇雲に作業を増やすより、観点を固定して潰していくほうが安全です。以下は、現場で使いやすい順序のチェックリストです。
| チェック項目 | どこを見る | 正常の目安 | NG時のアクション例 |
|---|---|---|---|
| Upgrades分類が有効 | WSUS: Options → Products and Classifications | Upgradesにチェックが入っている | 一度OFF→再ON（今回の解決策） |
| 対象製品が有効 | WSUS: Products | Windows 10系の製品が選択されている | 製品を見直し、同期を実行 |
| 承認している更新が正しい | WSUS: Updates（タイトル/説明） | Business/Consumer、言語、x64が一致 | 誤承認を解除し、正しい更新を承認 |
| 同期が成功している | WSUS: Synchronizations / Event Log | エラーなしで最新まで同期 | 同期設定、プロキシ、証明書を確認 |
| 端末のポリシーで抑止されていない | 端末: gpresult / レジストリ / WindowsUpdateポリシー | ターゲット固定や極端な延期がない | 必要に応じてポリシーを調整 |
| 端末が状態報告できている | WSUS: Reports / 端末イベントログ | 最近の報告日時が更新される | 検出・報告を促進（次項） |
WSUSでFeature Update（v2004）を見つけやすくするフィルター例
「承認したはずなのに一覧で見つからない」「別の版を承認していた」といった人的ミスは意外と起きます。更新一覧のフィルターを固定すると、確認が楽になります。
| フィルター項目 | 設定例 | 狙い |
|---|---|---|
| Classification | Upgrades | 機能更新だけに絞り込む |
| Status | Any / Approved | 承認済みのアップグレード更新を拾う |
| Text search | version 2004 / 20H1 | v2004に関連する更新タイトルを抽出 |
| Architecture | x64 | x64端末向けに限定して誤承認を減らす |
端末側でできること：再検出・状態報告を促進して「待ち」を短縮する
WSUS側を直しても、端末が次回の検出・報告を行うまで、コンソールの表示が追随しないことがあります。急ぎたい場合は、端末側でスキャンや報告を促すことで、待ち時間を圧縮できます（ただし組織の運用ルールに従ってください）。
| 目的 | コマンド例 | 補足 |
|---|---|---|
| 更新のスキャン | UsoClient StartScan | Windows 10の世代によって挙動が異なる場合あり |
| ダウンロード開始 | UsoClient StartDownload | 帯域や配布設計（BranchCache等）に注意 |
| インストール開始 | UsoClient StartInstall | ユーザー影響があるため運用と調整 |
| 状態報告 | wuauclt /reportnow | 環境によっては効果が限定的。イベントログで確認 |
併せて、端末のWindows Update関連ログ（イベントビューアーのWindowsUpdateClient系）や、更新履歴が動いているかも確認すると、「WSUSは直ったのに表示だけ古い」状態を早期に見分けられます。
復旧しない場合の追加アプローチ（やる順番を間違えない）
Upgradesのトグルで復旧しない場合は、原因が別にあるか、WSUS側の状態がさらに崩れている可能性があります。影響が小さいものから順に試すのが安全です。
| 優先度 | アプローチ | 狙い | 注意点 |
|---|---|---|---|
| 高 | 製品・分類の見直し → 同期の再実行 | そもそもの同期対象が不足していないか確認 | 同期対象を増やすほどDBが肥大化しやすい |
| 高 | 誤ったFeature Update承認の解除 | Business/Consumer・言語違いの誤承認を排除 | グループ単位で承認している場合は影響確認 |
| 中 | WSUSのサーバークリーンアップ | 不要更新の整理でメタデータ負荷を軽減 | 時間がかかる。業務時間帯は避ける |
| 中 | コンテンツ不整合の修復（例：wsusutil reset） | ダウンロード済み表示と実体のズレを解消 | ネットワーク負荷が増える場合がある |
| 低 | DBメンテナンス（インデックス再構築等） | コンソール遅延や判定遅れを改善 | 実施手順は環境（WID/SQL）で変わる |
運用のコツ：Feature Update配布でハマりやすいポイント
機能更新は累積更新（LCU）と比べてサイズが大きく、判定ロジックも複雑です。WSUSでの配布を安定させるには、トラブル対応だけでなく、日常運用の品質が効いてきます。
- ディスク容量：WSUSのコンテンツ領域は余裕を持たせる（機能更新は特に肥大化しやすい）
- 同期対象の絞り込み：不要な製品・言語・分類を増やし過ぎない（DBとメタデータが重くなる）
- 承認の粒度：いきなり全台ではなく、テスト用コンピューターグループで段階配布する
- レポートの見方：コンソール表示が追随するまでタイムラグがある前提で、報告日時も合わせて判断する
| 定期的にやること | 目安 | 期待できる効果 |
|---|---|---|
| サーバークリーンアップ（不要更新・未使用コンテンツの整理） | 月1回〜四半期 | メタデータ肥大化の抑制、コンソールの安定化 |
| 同期結果の監視 | 日次/週次 | プロキシ・証明書・通信エラーの早期発見 |
| 機能更新の承認設計の見直し | バージョン切替時 | 誤承認（エディション/言語違い）を減らす |
よくある質問
UpgradesをOFFにすると、承認情報や更新が消えますか？
画面上でアップグレード分類の更新が一時的に見えにくくなることはありますが、一般的には「承認を取り消した」のとは別扱いです。ただし、環境や運用設計によって影響範囲が異なるため、メンテナンス時間帯に実施し、事前に対象グループや承認ポリシーを把握しておくのが安全です。
「待つ」のが難しい場合はどうすればいいですか？
端末側でスキャンと報告を促進すると、WSUSコンソールの追随が早まることがあります。本記事の「端末側でできること」を参考に、運用ルールの範囲で実施してください。
2004以外の機能更新でも同じ対処は有効ですか？
本質は「Upgrades分類に属する更新のメタデータとレポートのねじれ」を解消することなので、類似の症状（特定のFeature UpdateだけがNot applicableになる）では同様に効果が出る可能性があります。まずは小さな検証グループで試し、変化が出るかを見てから展開するのがおすすめです。
まとめ（今回のケースで効いたポイント）
- WSUSで1909は正常なのに2004だけが「Not applicable／Not needed」になる場合、端末互換性よりもWSUS側の分類・メタデータ不整合が原因のことがある
- まずはUpgrades分類を一度OFF→再ONし、WSUSサービスを再起動する手順が有効だった
- 併せて、Business/Consumerの違い、製品選択、端末ポリシー（ターゲット固定/延期）、Dual Scan混在などもチェックすると再発防止になる
機能更新は「承認したのに出ない」ときほど焦りがちですが、WSUS側の分類とメタデータを疑うと、短い手数で復旧できることがあります。まずは本記事の手順で状態が変わるかを確認し、変化が出たらチェックリストで原因を絞り込むのが安全です。
コメント