Windows Server 2012／2012 R2でWindows Updateエラー「80072EFE」を最短で直す実践ガイド

Windows Server 2012（R2）でWindows Updateを実行したときに「80072EFE」が出る場合、原因の多くは“更新サーバーと安定して暗号通信できない”ことにあります。ネットワークが普通に使えていても、TLS設定・プロキシ・時刻ずれ・更新コンポーネント破損など、更新だけが失敗する条件が揃うと発生します。この記事では、現場で再現性の高い対処を「上から順に試すだけ」で整理しました。

• Windows Server 2012／2012 R2でWindows Updateエラー「80072EFE」を最短で直す実践ガイド
  • 80072EFEとは何か：症状とよくある発生パターン
  • いきなり修復する前に：最低限の安全策（バックアップ）
  • 対処はこの順で：80072EFEを潰す5ステップ
    • ステップ1：ネットワーク・DNS・プロキシを“Update目線”で点検する
    • ステップ2：TLS 1.2を有効化する（最重要）
    • ステップ3：時刻ずれ（NTP）を修正する
    • ステップ4：Windows Updateコンポーネントをリセットする
    • ステップ5：セキュリティ製品・FW・プロキシの“HTTPS干渉”を疑う
  • それでも直らない場合の現実的な選択肢
    • 1）WSUS（社内配布）に切り替える
    • 2）Microsoft Update Catalog等による手動適用
    • 3）サポート終了による制約を前提に、更新運用を再設計する
  • まとめ：最短ルートは「TLS 1.2 → Updateリセット → 干渉要因の切り分け」

80072EFEとは何か：症状とよくある発生パターン

80072EFEは、Windows Updateが更新配信側との通信を途中で切断されたり、SSL/TLSの検証に失敗したりしたときに出やすいエラーです。典型例は次のような状況です。

• 「更新プログラムを確認しています…」で止まる／ダウンロードが始まらない

• 途中まで進んで失敗し、再試行しても同じ

• Web閲覧やドメイン機能は問題ないのに、Updateだけ不調

• 社内NW（プロキシ・UTM・FW）配下で発生しやすい

いきなり修復する前に：最低限の安全策（バックアップ）

更新周りの修復は、サービス停止やレジストリ変更を伴うことがあります。ドメインコントローラーや業務サーバーならなおさら、作業前に「復元できる状態」を作ってから進めるのが鉄則です。
推奨は、少なくとも以下のどれかを確保することです。

• システム状態（System State）バックアップ

• ベアメタル復旧可能なイメージバックアップ

• 仮想環境ならスナップショット（ただしDCは運用ルールに注意）

対処はこの順で：80072EFEを潰す5ステップ

ここからは、効果が出やすい順に並べています。1つずつ実施し、Windows Updateを再試行してください。

ステップ1：ネットワーク・DNS・プロキシを“Update目線”で点検する

「ネットは生きている」のにUpdateが失敗する場合、DNS解決・プロキシ設定・TLS中継機器が引っかかっていることが多いです。

確認ポイント

• DNSが社内向けに偏りすぎていないか（外部解決不可など）

• サーバーにプロキシが入っていないか、または誤設定がないか

• 透過プロキシ／UTMがHTTPSを検査していないか（証明書差し替え）

すぐできる確認（コマンド例）

• WinHTTPプロキシ確認

  • netsh winhttp show proxy

• 不要なプロキシが入っている場合は一旦直結で検証

  • netsh winhttp reset proxy

社内ルールでプロキシ必須の場合、WinHTTP側（サービスが参照）とユーザー側（IE設定）がズレているとUpdateだけ失敗します。サーバー運用方針に合わせて、どちらに揃えるかを決めてから調整してください。

ステップ2：TLS 1.2を有効化する（最重要）

Windows Server 2012／2012 R2は、環境によってTLS 1.2が既定で十分に有効になっていないことがあります。更新配信側が強い暗号設定を要求するようになると、ここで詰まって80072EFEが出ます。

やること（方針）

• OSに必要な更新（暗号化関連・WinHTTP関連）が未適用なら適用する

• TLS 1.2を有効化し、古いプロトコル依存を避ける

• 可能なら .NET の強い暗号利用（Strong Crypto）を有効にする

レジストリ変更や適用すべき更新の組み合わせは環境差が出やすいので、運用手順としては「まずTLS 1.2を有効化 → 再起動 → Update再試行」の流れが堅いです。以後のステップを試しても改善しないときも、最終的にここに戻って見直す価値があります。

ステップ3：時刻ずれ（NTP）を修正する

SSL/TLSは証明書の有効期限チェックを行うため、サーバー時刻がズレていると“通信自体はできるのに失敗”が起きます。ドメイン参加機でも、PDCエミュレーターや上位NTPが不安定だと影響します。

確認

• OSの時刻・タイムゾーンが正しいか

• DCの場合、時刻同期の階層（PDC→外部NTP）が崩れていないか

時刻を正した後は、Windows Updateサービスの再試行だけでなく、必要なら再起動も挟むと変化が出やすいです。

ステップ4：Windows Updateコンポーネントをリセットする

更新関連のキャッシュやサービス状態が壊れていると、通信が通っても失敗します。ここは再現性が高い定番対処です。

狙い

• SoftwareDistribution や catroot2 の破損を疑って初期化

• BITS／Windows Update関連サービスの再起動

• 破損したダウンロード途中ファイルを捨ててやり直す

作業としては「関連サービス停止 → キャッシュ退避（名前変更）→ サービス開始 → 再試行」が基本です。これで改善するケースは多いです。

ステップ5：セキュリティ製品・FW・プロキシの“HTTPS干渉”を疑う

ウイルス対策ソフトやUTMがHTTPS通信を検査（復号して再暗号化）していると、更新の署名検証や証明書チェーンで失敗しやすくなります。特に「それ以外のWeb通信は問題ない」場合に盲点になります。

対処の考え方

• 一時的にHTTPSスキャンを無効化して切り分け（可能な範囲で）

• 更新関連の通信先に対して例外設定（許可ルール）を検討

• 変更できない場合は、WSUSやオフライン更新の活用を検討

切り分けの結果、機器側が原因なら“OS側をいくら弄っても直らない”ので、ネットワーク運用担当と原因箇所を共有できる形（いつ・どこで遮断されるか）で詰めるのが近道です。

それでも直らない場合の現実的な選択肢

1）WSUS（社内配布）に切り替える

外部通信要件を社内側で吸収でき、プロキシやFWの影響を受けにくくなります。複数台ある環境ほど効果的です。

2）Microsoft Update Catalog等による手動適用

必要な更新を個別に取得して適用する運用です。恒久対策というより「今この更新だけ入れたい」局面に向きます。

3）サポート終了による制約を前提に、更新運用を再設計する

Windows Server 2012／2012 R2は、更新配信基盤や暗号要件の変化に追随しにくい局面が増えます。移行計画（後継OSへの更改）や、延命するなら更新経路（WSUS/閉域設計）を含めて整理すると、同種トラブルの再発が減ります。

まとめ：最短ルートは「TLS 1.2 → Updateリセット → 干渉要因の切り分け」

80072EFEは、単純な回線不調よりも「暗号通信の条件不足」や「更新コンポーネント破損」「HTTPS干渉」で起きがちです。手戻りを減らすなら、

1. ネットワーク／DNS／プロキシの整合

2. TLS 1.2の有効化（最優先）

3. 時刻同期の是正

4. Windows Updateコンポーネントのリセット

5. セキュリティ製品・UTM・FWの干渉切り分け

この順で当てていくのが最も効率的です。サーバーがDCなど重要ロールの場合は、必ず復元手段（バックアップ）を確保した上で進めてください。