Windows Server 2019 の Windows Update が「Downloading 100%」で止まり、Azure Update Automation でも全台失敗する──端末側をいくら直しても改善しない場合、原因はネットワーク機器の IPS 偽陽性かもしれません。本記事では Sophos XG Firewall で実際に解消した手順と、他社 FW/IPS でも使える切り分け観点をまとめます。
現象：Azure Update Automation でも GUI でも更新が失敗し、Downloading 100% から動かない
今回のトラブルは、オンプレミスにある Windows Server 2019 を Azure Update Automation（Update Management）で更新していた環境で発生しました。2020年7月の更新以降、突然「更新が全台で失敗」するようになり、しかも同じサーバーをローカルで操作しても状況は変わりません。
代表的な症状は次のとおりです。
- Azure Update Automation からの適用が毎回失敗する
- サーバーの Windows Update（GUI）で手動実行しても、進捗が Downloading 100% のまま止まる
- しばらく待っても Installing へ進まず、最終的に失敗として扱われる（再試行しても同じ）
| 観測されたポイント | 意味合い（切り分けのヒント） |
|---|---|
| WindowsUpdateLog でダウンロード済みバイト数が想定総量を超える | 通信の途中断・リトライが多発している可能性。BITS/配信最適化が「再開」するたびに累積カウントが増えることがある。 |
| 0x80D02002 が出る（CDN を試したがダウンロードできない系） | 端末のストレージや更新コンポーネントよりも、ネットワーク経路（FW/IPS/プロキシ）を疑う価値が高い。 |
| ログに出ている CDN の URL（例：dl.delivery.mp.microsoft.com 系）をブラウザで開くとダウンロード自体はできる | 「完全にインターネットへ出られない」わけではない。Windows Update 特有の通信（Range/再開/ユーザーエージェント/TLS 処理）が阻害されている可能性。 |
| .cab を SoftwareDistribution 配下へ手動で置くと更新が完了する | 更新パッケージ自体は正しい。端末側での展開・適用はできており、問題は「自動ダウンロード経路」に寄っている。 |
| SoftwareDistribution / catroot2 のリセット、sfc / dism、AV 無効化が効かない | 端末側の典型手順で改善しない場合、共通経路の機器（FW/IPS/SSL インスペクション）や上流の制御を疑う。 |
結論：Windows 側ではなく Sophos XG Firewall の IPS 偽陽性が原因だった
このケースの根本原因は、Microsoft/Windows Update 側の不具合ではありませんでした。実際には Sophos XG Firewall の IPS（侵入防止）が Windows Update の配信 CDN への通信を誤検知（偽陽性）してブロックしていたことが原因でした。
ポイントは次のとおりです。
- 2020年7月の更新タイミングで Windows Update の通信（配信されるコンテンツや取り方）が変化し、Sophos 側の IPS シグネチャが攻撃と誤判定
- その結果、CDN へのダウンロードが途中で遮断され、Windows Update 側では「利用可能な CDN を試したが失敗」といった挙動（0x80D02002）になる
- ブラウザでの直接ダウンロードができても、Windows Update は BITS/配信最適化等の仕組みで「分割取得・再開」を行うため、IPS の誤検知条件に当たりやすいことがある
対処はシンプルで、Sophos XG の IPS ログを確認し、該当するシグネチャを許可／例外化（あるいは Windows Update 通信に限り IPS を回避）することで、更新の自動ダウンロードが正常化しました。
なぜ「ブラウザで落ちるのに Windows Update だけ落ちない」ではなく「Windows Update だけが失敗する」ことが起きるのか
「同じ URL がブラウザで落とせるのに、なぜ Windows Update だけが失敗するのか？」は、この手の障害で最も混乱しやすいポイントです。結論から言うと、ブラウザと Windows Update では“同じ HTTPS ダウンロード”に見えても、実際の振る舞いがかなり異なります。
| 観点 | ブラウザでのダウンロード | Windows Update（WUA / BITS / 配信最適化） |
|---|---|---|
| 取得方法 | 1本のファイルを連続的に取得することが多い | 分割取得（Range リクエスト）や途中再開、複数 CDN の切り替えが起きやすい |
| 再試行 | 失敗するとユーザーが再実行することが多い | バックグラウンドで自動再試行し、断片的な通信が大量に発生する |
| 識別情報 | User-Agent が一般的 | WindowsUpdate/DeliveryOptimization 特有のヘッダーや UA を使うことがある |
| セキュリティ機器の見え方 | 一般的な HTTPS ダウンロードとして扱われやすい | 分割・再開・断続的な通信が「異常な挙動」に見え、IPS/SSL インスペクションの偽陽性条件に当たることがある |
今回 WindowsUpdateLog で「ダウンロード済みバイト数が想定総量を超える」という現象が出たのも、途中断→再試行が繰り返されていたことを示唆します。IPS が通信を遮断すると、クライアント側は “失敗” と判断して取り直します。これが積み重なると、ログ上は「取得した量が増え続ける」のに、実ファイルとしては完成しない、という状態になり得ます。
切り分けのコツ：端末側より先に「共通点」を疑う
Azure Update Automation でも GUI でも同じ失敗をする、しかも全台で同時期から発生する、という条件が揃ったら「各サーバー固有の破損」よりも 共通経路（ネットワーク／セキュリティ機器）の変化をまず疑うのが近道です。
特に次の条件が揃うと、FW/IPS 側が原因である可能性が一気に高まります。
- 複数台（場合によっては全台）で同じタイミングから失敗する
- 手動で .msu/.cab を適用すると成功する（= 適用自体は壊れていない）
- SoftwareDistribution リセットや DISM/SFC など“端末修復”をしても変化がない
- WindowsUpdateLog に CDN／ダウンロード失敗系のエラーが出る（0x80D02002 など）
端末側で最低限やること：証拠を集めて「ネットワーク問題」と確信する
原因が IPS 偽陽性だったとしても、まずは端末側で「何が起きているか」をログとして押さえておくと、ネットワーク担当やセキュリティ担当に説明しやすくなります。ここでは、遠回りになりにくい“最低限”の確認だけを整理します。
WindowsUpdateLog を作ってエラーの軸を決める
Windows Server 2019 では Windows Update の詳細ログが ETL 形式で保持されているため、PowerShell でテキスト化します。
PowerShell（管理者）:
Get-WindowsUpdateLog生成された WindowsUpdate.log を開き、次のようなキーワードを探します。
0x80D02002（CDN ダウンロード失敗系）Delivery Optimization/DO/BITSdl.delivery.mp.microsoft.comなどの配信 CDN のホスト名- ダウンロード量の不自然な増加（想定総量より大きい、延々と増える）
イベントログで WindowsUpdateClient の失敗を確認する
イベントビューアーの以下は、原因が「インストール」なのか「ダウンロード」なのかを見分けるのに役立ちます。
- アプリケーションとサービス ログ → Microsoft → Windows → WindowsUpdateClient → Operational
WinHTTP プロキシ設定を確認する（プロキシ利用環境のみ）
環境によっては WinHTTP のプロキシ設定が Windows Update に影響します。意図しないプロキシが入っていないかだけは確認しておくと安全です。
netsh winhttp show proxy「手動インストールは成功」を事実として残す
同じ KB を Microsoft Update Catalog 等から取得して手動インストールし、成功することを確認します（すでに実施済みなら、その結果をメモしておきます）。
- 手動で落とした .msu/.cab が正常に適用できる → パッケージ破損や CBS 破損の可能性が下がる
- 自動ダウンロードだけが失敗する → ネットワーク経路／セキュリティ機器／配信最適化の影響を疑う
ネットワーク側の確認：Sophos XG（IPS）の偽陽性を特定する手順
ここからが今回の本題です。Sophos XG では、IPS が遮断した通信がログに残ります。重要なのは「Windows Update を実行した時刻」と「IPS がブロックした時刻」を突き合わせることです。
実施のポイント
- Windows Update を開始した時刻（サーバー側）をメモする
- 同じ時間帯の Sophos XG の IPS アラート／ブロックログを確認する
- 送信元がサーバー（または NAT 後のグローバル IP）、宛先が Microsoft の CDN／更新関連ドメインになっていないかを見る
管理画面のメニュー名はバージョンで多少異なりますが、一般的には「ログビューアー」や「レポート」から IPS のイベントを絞り込めます。絞り込みのコツは次のとおりです。
- ログ種別：IPS（Intrusion Prevention）
- アクション：Drop / Block / Reset など遮断を示すもの
- 対象ホスト：Windows Server 2019 の IP
- 時間帯：Windows Update の開始〜失敗まで
ここで、Windows Update を走らせるたびに同じシグネチャ（あるいは同系統のシグネチャ）が連発していれば、ほぼ原因確定です。
「短時間だけ IPS を無効化」して差分を見る（切り分け専用）
切り分けを速くする一手として、メンテナンス可能な短時間に限り、Windows Update 通信のポリシーで IPS を無効化して挙動を比較します。
- IPS を無効化した瞬間に、Downloading 100% 停止が解消し、通常のダウンロード・インストールが進む
- IPS を戻すと再発する
この差分が取れれば、端末側での再インストールや WSUS 構築よりも先に、IPS 例外化が最短ルートになります。なお、IPS を恒久的に無効化するのは推奨しません。あくまで「原因特定のための比較テスト」として実施し、恒久対応は例外化・シグネチャ更新で行います。
対処：Sophos XG の IPS 例外化（または Windows Update 用ポリシーで IPS 回避）
原因が IPS 偽陽性だと分かったら、次のいずれかで対処します。運用ポリシーやネットワーク構成に合わせて選んでください。
| 対処方法 | 概要 | メリット | 注意点 |
|---|---|---|---|
| 該当 IPS シグネチャを例外化（Allow/Exclude） | ログに出たシグネチャ（偽陽性）だけを除外し、他の IPS は維持する | 影響範囲が最小。セキュリティレベルを落としにくい | シグネチャ番号や名称が変わる可能性があるため、更新後も再発監視が必要 |
| Windows Update 通信専用の FW ルールを作り、IPS を緩和/無効化 | 送信元（サーバー）と宛先（Microsoft 更新系）を限定したうえで、その通信だけ IPS を弱める | 設定が分かりやすい。対象を明確にできる | 宛先の定義（FQDN/URL カテゴリ）が不十分だと、例外が広がりすぎることがある |
| IPS パターン/ファームウェアの更新 | ベンダーが偽陽性を修正している場合、アップデートで解決することがある | 例外の維持コストが下がる | 更新直後は挙動が変わる可能性があるため、事前検証とロールバック手段が必要 |
例外化の考え方：対象を「Windows Update の通信」に絞る
恒久対応では、例外を広げすぎない設計が重要です。おすすめは次の順番です。
- まずはログに出た“特定のシグネチャ”を除外し、他は維持する
- それでも再発する場合、Windows Update の通信に限定した FW ルールで IPS を緩和する
- さらに必要なら、SSL/TLS インスペクションや Web フィルタの例外（Microsoft 更新系ドメイン）も追加する
環境によっては「URL カテゴリ（Software/Updates など）」でまとめて許可する方が運用しやすいこともあります。ただしカテゴリ許可は範囲が広くなりがちなので、サーバーの送信元 IP を限定したり、更新用の時間帯だけ適用するなど、制御の粒度を落とさない工夫をすると安全です。
他社 FW/IPS でも起きる：同様のケースで見るべきチェックリスト
今回の原因は Sophos XG の IPS 偽陽性でしたが、同じ構図は他社の FW/IPS、UTM、プロキシ、SSL インスペクションでも起こり得ます。「Windows Update だけが失敗する」障害は、端末の修復よりもネットワーク経路の差分が効くことが多いからです。
| 疑う機能 | 起きやすい症状 | 確認ポイント | よくある対処 |
|---|---|---|---|
| IPS/IDS | Downloading 100% 停止、0x80D02002、断続的な失敗 | IPS ログに該当サーバーからの通信が Block/Drop されていないか | シグネチャ例外、更新系通信の IPS 緩和、パターン更新 |
| SSL/TLS インスペクション（HTTPS 検査） | 特定ドメインだけ TLS ハンドシェイクで失敗、証明書系のエラー | FW が中間証明書として介在していないか。例外設定があるか | Microsoft 更新系ドメインの SSL インスペクション除外 |
| Web フィルタ/URL フィルタ | CDN の一部だけブロックされる、時間帯で失敗 | カテゴリ判定の誤り、ブロックログの有無 | 更新系カテゴリ許可、ドメイン許可（最小権限で） |
| プロキシ（明示/透過） | WinHTTP 経由だけ失敗、ユーザー操作のブラウザは成功 | WinHTTP と WinINET のプロキシ差分（netsh winhttp） | プロキシ例外、PAC 見直し、認証方式の調整 |
| 帯域制御/セッション制御 | 大容量更新だけ失敗、途中で切れる | セッションタイムアウト、上限、優先度、同時接続数 | 更新時間帯の緩和、タイムアウト延長、QoS 調整 |
「Windows Update 通信だけ違う」差分に注目する
ブラウザで落とせるのに Windows Update だけが落ちる場合、次の差分がトリガーになりがちです。
- Range リクエスト（分割ダウンロード）を多用する
- 短時間に大量の接続を張る（CDN 切り替え、再試行）
- 配信最適化（Delivery Optimization）が働き、CDN 以外（ピアや別経路）も使おうとする
- サービス（SYSTEM）コンテキストで通信するため、プロキシ認証やフィルタの扱いが変わる
つまり「URL をブラウザで開けた」だけでは、Windows Update 経路の健全性確認として不十分です。ネットワーク機器側のログと突き合わせるのが最短です。
復旧後にやっておくと安心なこと：再発防止と運用のコツ
一度 IPS 例外で復旧しても、次の月例パッチや機器アップデートで再発する可能性はゼロではありません。運用としては、次のような形にしておくと“また同じ沼”にハマりにくくなります。
Windows Update の実行時間帯と FW/IPS のログ保管を合わせる
- 更新実行の時間帯（メンテウィンドウ）を固定し、ログ調査の範囲を狭める
- IPS/プロキシのログ保持期間を、少なくともパッチ適用サイクルをカバーするように確保する
例外は「理由・対象・期限」をセットで管理する
例外化は便利ですが、放置すると穴になります。おすすめは、例外に次の3点を必ず紐付けることです。
- 理由：どの現象を解決するためか（例：Windows Server 2019 の Windows Update Downloading 100% 停止）
- 対象：送信元（サーバー群）と宛先（更新系）を最小化
- 期限：ベンダーのシグネチャ更新で解消したら戻す、など見直し時期を決める
SSU→LCU の順序、手動適用を“非常手段”として準備しておく
今回の本質はネットワークブロックでしたが、月例更新ではサービススタック更新（SSU）と累積更新（LCU）の依存関係でつまずくこともあります。自動更新が詰まったときに備え、次の手順を手元に置いておくと復旧が速いです。
- 対象 OS の最新 SSU と LCU を把握し、必要なら SSU→LCU の順に適用できるようにしておく
- 更新サイクルが厳しいサーバーは、WSUS や管理ツールで段階展開（検証→本番）を徹底する
それでも解消しない場合に見る追加ポイント（端末側の“次の一手”）
IPS 例外化で直るケースが多い一方、似た症状でも原因が別にあることはあります。最後に、よくある追加チェックを“優先度が高い順”に並べます。
| チェック項目 | 確認方法の例 | ハマりどころ |
|---|---|---|
| WSUS 指定の有無（社内 WSUS を使っているか） | レジストリ（UseWUServer）や GPO を確認 | 社内 WSUS が古い/不調だと、Microsoft CDN とは別の問題になる |
| プロキシ設定の二重管理 | netsh winhttp show proxy とブラウザ設定の差分 | ブラウザは成功するが SYSTEM は失敗、が典型 |
| 時刻ずれ・証明書ストア | NTP 同期、証明書更新、ルート証明書 | TLS 失敗が「ダウンロード失敗」に見えることがある |
| 更新コンポーネントの破損 | SoftwareDistribution / catroot2 リセット、DISM/SFC | 今回のケースでは決定打ではないが、他要因では効く |
| セキュリティソフトの HTTPS スキャン | 一時停止で差分を見る（短時間・隔離ネットワークで） | FW 側だけでなく端末側で TLS を触っているケースもある |
まとめ：Downloading 100% 停止は「端末修復」より「IPS 偽陽性」を疑うと早い
Windows Server 2019 の Windows Update が Downloading 100% で止まり、Azure Update Automation でも失敗する場合、まずは WindowsUpdateLog を確認して「CDN ダウンロード失敗（0x80D02002 など）」の匂いがないかを見ます。手動インストールは成功するのに自動ダウンロードだけが失敗するなら、端末よりもネットワーク機器の IPS/SSL インスペクション/Web フィルタを疑うのが近道です。
Sophos XG Firewall を使っている環境では、IPS ログに偽陽性が出ていないかを確認し、該当シグネチャの例外化や Windows Update 通信に限定したポリシーで IPS を回避することで、更新が正常化することがあります。全台で止まる更新ほど「共通経路のどこかが止めている」可能性が高いので、端末側のリセットに時間を使いすぎる前に、ぜひログの突き合わせから始めてみてください。
コメント