Windows Server 2012 上の WSUS から Windows 10 1909 を承認したのにクライアントが「Not applicable（適用対象外）」になって進まない――この症状は“コンソールの表示”よりも、WSUS サーバーの更新状態・後処理不足、製品/分類設定、クライアントの検出・報告の破綻で起きやすい。この記事では原因の切り分けから復旧手順までを順番に解説します。
現象をもう一度整理する
相談の内容を、トラブルシューティングしやすい形に整理すると次の通りです。
- WSUS サーバー：Windows Server 2012（Build 9200）で運用
- やりたいこと：WSUS から Windows 10 の機能更新プログラム（Feature Update）「1909」を承認して配信したい
- 起きていること：クライアント側で対象の更新が Not applicable（適用対象外） と判定され、インストールされない
- 比較条件：Microsoft Update（インターネット側）で実行すると 1909 が提示され、アップグレードできる
- 気になっている点：WSUS コンソールの不具合なのか／より新しいコンソールにすべきなのか
結論：WSUS コンソールより「サーバー側の更新状態」と「クライアント側の検出」が本丸
WSUS での「Not applicable（適用対象外）」は、コンソールの表示やボタン操作が原因というより、次のどれか（または複合）で発生します。
- WSUS サーバーの更新や後処理が不足しており、機能更新（Upgrades）を正しく扱えない／メタデータや配信形態に追従できていない
- WSUS の製品・分類・言語の設定が合っていない（Upgrades が未選択、Windows 10 製品が不足、言語制限で一致しない、など）
- 承認した「1909」がクライアントの条件に合っていない（Business/Consumer、x64/x86、言語、エディションなどの取り違え）
- クライアントの検出・報告が壊れている／WSUS を見ていない（ポリシー競合、Dual Scan、WU コンポーネント破損、レポート未送信）
つまり「より新しいコンソールに入れ替えれば直る」というより、WSUS サーバーの更新状態と後処理を整え、承認と検出の整合性を取るのが最短ルートです。
最短で復旧させるための手順（全体像）
遠回りしないために、まずは “当たりやすい順” に潰していきます。作業の意図が分かるように、成功のサインも併記します。
| 優先度 | 作業 | 狙い | 成功のサイン |
|---|---|---|---|
| 高 | WSUS サーバーに最新の SSU / 月例ロールアップを適用し、wsusutil の後処理を実行 | 機能更新メタデータ・配信形態への追従 | 同期・承認が安定し、クライアントのスキャンで 1909 が「必要」に変わる |
| 高 | WSUS の「製品」と「分類（Upgrades）」を見直す | そもそも配信対象を WSUS に載せる | 1909 の更新が WSUS に出現し、承認できる |
| 高 | 承認した 1909 が Business/Consumer・x64/x86・言語などで合っているか確認 | Not applicable の典型原因を排除 | 対象端末で「インストール必要」に変わる |
| 中 | クライアントの WSUS 参照・報告を点検（Dual Scan、GPO 競合、再スキャン） | 検出・報告の破綻を修正 | WSUS コンソールの「最終報告時刻」が更新され、適用判定が変わる |
| 中 | WSUS のメンテナンス（不要更新の整理、クリーンアップ、DB 最適化） | 性能劣化によるタイムアウト・異常を予防 | 同期やコンソール操作が軽くなり、配信が安定 |
WSUS の「世代」と “3.0 表示” の勘違いを先に解消する
「WSUS 3.0 だから Windows 10 の機能更新が扱えないのでは？」という不安はよくありますが、Windows Server 2012（Build 9200）で動く WSUS は、実態としては OS 組み込みの WSUS（6.x 系）であることが多いです。一方で、WSUS 管理コンソール（MMC スナップイン）の表記や画面上の情報が紛らわしく、“表示だけ” で古いと誤認するケースがあります。
| 確認したいこと | 見る場所 | 目的 |
|---|---|---|
| WSUS サーバー本体のバージョン | WSUS サーバーのレジストリ／更新サービスのファイルバージョン | WSUS 3.0 相当の誤解を排除し、以降の対処が有効な前提を固める |
| 管理コンソールのバージョン | WSUS コンソールの「ヘルプ」→「バージョン情報」 | “コンソール表記” と “サーバー本体” を切り分ける |
WSUS サーバー本体のバージョン確認は、次のような方法が現実的です。
- レジストリ：
HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup付近のVersionStringなどを確認 - ファイル：
C:\Program Files\Update Services\Services\WsusService.exeなどのファイルバージョンを確認
ここで重要なのは「3.0 表示＝サーバーが古い」と決めつけないことです。以降の改善は WSUS サーバー側の更新・後処理が中心になります。
WSUS サーバーを最新の状態にする（SSU／月例ロールアップ）
WSUS で機能更新（Upgrades）を扱う上で、WSUS サーバー自身の更新が古いと、メタデータ処理や配信形態の差分に追従できずトラブルが起きます。まずは Windows Server 2012 に対して以下の考え方で更新を揃えます。
適用の基本方針
- Servicing Stack Update（SSU）を最新にする（SSU が古いと累積更新の適用が不安定になりやすい）
- その後に月例ロールアップ（累積更新）を適用する
- .NET Framework 更新が絡む場合は、関連する更新も合わせて適用し、必要に応じて再起動する
適用後に必ず実行したい WSUS の後処理
WSUS の更新で取り込まれる修正は、OS 更新を入れただけでは反映しきらず、WSUS 側の “後処理” が必要になることがあります。代表例が wsusutil の postinstall です。
cd "C:\Program Files\Update Services\Tools"
wsusutil.exe postinstall /servicing環境によっては postinstall のみでよい場合もありますが、機能更新が絡むトラブルでは /servicing を付けて実行することで WSUS の内部調整が走り、挙動が改善するケースが多いです。実行しても派手な出力が出ないことがあり、「何も起きていないように見える」のが普通です。
過去の個別 KB が「適用対象外」になるのは異常とは限らない
WSUS 関連でよく参照される KB（例：KB3159706 / KB3095513 など）は、後続の月例ロールアップに包含されている場合があります。この状態では、個別 KB を手動で適用しようとしても 「この更新プログラムは適用対象外」になり得ます。
ここで重要なのは、「KB が入らない＝失敗」と判断しないことです。最新の SSU と累積更新が入っているかを軸に確認し、前段の wsusutil.exe postinstall を含めて “WSUS サーバーの更新・後処理が完了している状態” に持っていくのが現実的です。
WSUS と IIS の設定で詰まりやすいポイント（ESD / ファイル配信）
機能更新プログラムは配信ファイルのサイズも形式も大きく、WSUS サーバー側の IIS 設定で詰まることがあります。特に過去の修正では ESD 形式の配信を扱うために IIS に設定追加が必要だったケースがあり、環境によっては今でも影響します。
| 症状 | チェックポイント | 対処の方向性 |
|---|---|---|
| 同期はできるが、機能更新の配信が不安定 | IIS の MIME タイプに .esd が登録されているか | 未登録なら .esd を application/octet-stream で追加 |
| 承認したのにクライアントが取りに来ない／途中で失敗する | WSUSContent のディスク容量／IIS のログ／BITS の状態 | 容量確保、プロキシ・FW 設定、アンチウイルスの例外、BITS の再起動 |
IIS の設定は、次のように GUI で確認・追加できます。
- IIS マネージャーを開く
- 対象サーバー →「MIME タイプ」
- 一覧に
.esdが無ければ追加（MIME：application/octet-stream）
なお、環境が十分に更新されていれば既に適切な設定が入っている場合もあります。“不足しているときだけ” 追加するのが安全です。
WSUS の設定：製品（Products）と分類（Classifications）を見直す
機能更新プログラムが「Not applicable」になる前に、そもそも WSUS が必要なメタデータを持っていない／正しく同期していない、というケースは非常に多いです。特に重要なのは 分類（Upgrades） と、Windows 10 系の 製品チェックです。
最低限の推奨（Windows 10 の機能更新を扱う場合）
| 項目 | 推奨 | 理由 |
|---|---|---|
| 製品（Products） | Windows 10（加えて、環境によっては「Windows 10, version 1903 and later」等の派生があれば併せて選択） | 機能更新のメタデータが製品に紐づくため |
| 分類（Classifications） | Upgrades（必須）、Security Updates / Critical Updates などは環境方針で | Feature Update は Upgrades に分類される |
| 言語（Languages） | 端末の OS 言語に合わせる（日本語 OS なら日本語を含める） | 言語を絞りすぎると、更新が一致せず Not applicable になりやすい |
設定変更後は、次の流れで “反映の遅延” を潰します。
- WSUS の同期を実行（必要ならフル同期）
- 対象の 1909 機能更新が WSUS に出現しているか確認
- 承認を見直し（誤承認があれば取り消し、正しい更新を承認）
- クライアント側で再スキャンを実施
意外と多い「承認する更新を間違えていた」問題（Business / Consumer、x64/x86、言語）
WSUS の一覧には、同じ “1909” に見えても複数の更新が並びます。ここで 対象条件が合っていないものを承認すると、クライアントは必ず Not applicable になります。Microsoft Update 側でうまくいくのに WSUS だけ失敗する場合、この取り違えが原因になっていることが少なくありません。
| WSUS に並ぶ表記の例 | 想定される対象 | 取り違えた時の典型症状 |
|---|---|---|
| Feature update to Windows 10, version 1909, business editions | Pro / Enterprise / Education など | Home 向け端末では Not applicable になりやすい |
| Feature update to Windows 10, version 1909, consumer editions | Home など | 企業端末（Pro/Enterprise）で Not applicable になりやすい |
| … x64-based Systems / x86-based Systems | CPU アーキテクチャ別 | x64 端末に x86 を承認しても適用されない |
| … Japanese / English | OS 言語別 | 言語を絞っていると一致せず適用されない |
まずは対象端末の条件（エディション／アーキテクチャ／言語）を “事実ベース” で揃えます。
- エディション：
winverまたは設定 → システム → バージョン情報 - アーキテクチャ：
設定 → システム → バージョン情報の「システムの種類」 - 表示言語：
設定 → 時刻と言語 → 言語
その上で、WSUS 側で承認した 1909 が “同じ条件” のものかを見直してください。ここがズレていると、サーバーやクライアントをどれだけ触っても判定は変わりません。
クライアントが WSUS を正しく見ているか（報告・検出の健全性チェック）
WSUS で承認しても、クライアントが WSUS に正しく問い合わせできていなければ、更新は「必要」と判定されません。まずは “WSUS に届いているか” を確認します。
WSUS コンソール側で見るべき項目
- 対象端末が WSUS に登録されているか（台数が増減しているか）
- 対象端末の「最終状態報告時刻」が更新されているか
- 端末が所属するコンピューターグループと、更新の承認先が一致しているか
クライアント側で見るべき項目（最低限）
| 確認内容 | 確認方法 | ポイント |
|---|---|---|
| WSUS の参照先（WUServer / WUStatusServer） | レジストリ：HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate | 想定の WSUS URL（例：http://server:8530）になっているか |
| ポリシー適用状況 | gpresult /h で HTML 出力し確認 | WSUS 関連 GPO と WUfB/Intune 系の競合がないか |
| スキャンの実行 | UsoClient StartScan（または環境により GUI で「更新プログラムのチェック」） | スキャン後に WSUS 側の「最終報告時刻」が進むか |
| イベントログ | イベント ビューアー：Microsoft-Windows-WindowsUpdateClient/Operational | スキャンエラーや接続エラーが出ていないか |
クライアントの Windows Update コンポーネントをリセット（手段として知っておく）
検出・報告が壊れている場合、SoftwareDistribution の破損や BITS の詰まりで “適用判定が更新されない” ことがあります。恒久対策ではありませんが、切り分けとして有効です。
net stop wuauserv
net stop bits
net stop cryptsvc
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauserv実行後、クライアントで再スキャン（例：UsoClient StartScan）を行い、WSUS への報告が進むかを確認します。
Dual Scan や管理方式の競合を疑う（Microsoft Update が成功するのに WSUS が失敗する典型）
「WSUS を使っているつもりなのに、端末が Microsoft Update も見に行ってしまう」状態（いわゆる Dual Scan）や、Intune／Windows Update for Business（WUfB）系のポリシー競合があると、挙動が一気に分かりにくくなります。
この場合、管理者の視点では次のように見えます。
- WSUS では承認しているのに入らない／Not applicable のまま
- 端末で「更新のチェック」をすると Microsoft 側の更新が降りてくる
- 結果として “WSUS が壊れているように見える”
WSUS 運用で揃えたい代表的なポリシー（例）
| ポリシー | 推奨例 | 狙い |
|---|---|---|
| イントラネットの Microsoft 更新サービスの場所を指定する | 有効（WSUS URL を指定） | 端末の参照先を WSUS に固定 |
| インターネット上の Windows Update の場所に接続しない | 有効 | Microsoft Update 側への逸脱を防ぐ |
| 自動更新を構成する | 組織の運用に合わせて（自動/通知/手動など） | 更新適用のタイミングを統制 |
| WUfB（機能更新の延期・ターゲット指定等） | WSUS で機能更新を配るなら、原則 “無効/未構成” で揃える | 競合で適用判定が変わるのを防ぐ |
ポイントは、「どの方式で機能更新を配るか」を 1 つに寄せることです。WSUS で配るなら、WSUS 以外の “機能更新の制御” が混ざらないように整理すると、Not applicable の切り分けが一気に楽になります。
それでも直らない場合に見るべき追加ポイント
ここまでの「更新・後処理」「製品/分類」「承認の取り違え」「クライアント検出」を潰しても改善しない場合、次の “運用劣化” を疑います。
WSUS の肥大化・性能劣化（クリーンアップ不足）
WSUS は運用が長いとメタデータが膨らみ、同期やクライアント応答が遅くなります。結果として、クライアントが正しくスキャンできず、判定が更新されないことがあります。
- WSUS の「サーバー クリーンアップ ウィザード」を定期実行
- 不要な製品・分類を増やしすぎない（特に過去バージョンを選びっぱなしにしない）
- SUSDB のメンテナンス（再インデックス等）を検討
WSUSContent の容量・ダウンロード状態
機能更新はサイズが大きく、WSUSContent の容量不足やダウンロード失敗があると配信が崩れます。次の観点で確認します。
- WSUSContent の保存先に十分な空き容量があるか
- プロキシ環境なら、WSUS のプロキシ設定が正しいか
- セキュリティ製品が WSUSContent や IIS 配信をブロックしていないか（例外設定）
- WSUS サーバーのログ（
C:\Program Files\Update Services\LogFilesなど）にエラーが出ていないか
「より新しいコンソールはあるのか？」への答え
WSUS の管理コンソール（MMC）は “表示と操作” の役割が中心で、更新の適用判定や配信可否を決めるのは、主に次の要素です。
- WSUS サーバーが保持する更新メタデータと配信ファイル
- WSUS サーバーの処理（IIS/WSUS サービス/DB）
- クライアント（Windows Update Agent）の検出と適用判定
そのため、コンソール単体を新しくしても「Not applicable」が劇的に直る可能性は低いのが実情です。改善したい場合は、次の優先順位になります。
- Windows Server 2012 の SSU／累積更新を最新化し、
wsusutil postinstallなどの後処理を完了させる - 製品・分類（特に Upgrades）と言語の設定を適正化する
- 承認する 1909 の種類（Business/Consumer、x64/x86、言語）を正しく選ぶ
- クライアントの WSUS 参照・報告と、ポリシー競合（Dual Scan 等）を解消する
まとめ：1909 が Not applicable になるときに “まずやること”
最後に、現場で再現性が高い “まずやること” を短くまとめます。
- WSUS サーバーを最新の SSU／累積更新で揃え、
wsusutil.exe postinstall /servicingを実行する - WSUS の「製品：Windows 10」「分類：Upgrades」を見直し、同期→承認をやり直す
- 1909 の承認が Business/Consumer・x64/x86・言語で端末条件と一致しているか確認する
- クライアントが WSUS に報告できているか（最終報告時刻、イベントログ、再スキャン）を確認する
この順で進めると、「コンソールの表示」ではなく “どこで判定がズレているか” が見えるようになり、最短で復旧しやすくなります。
コメント