WSUSがMicrosoft Updateと同期できない（HTTP 401／0x80072EFE）原因とKB4022720の対処法

Windows Server 2012 R2 の WSUS が突然 Microsoft Update と同期できなくなり、HTTP 401 Unauthorized や 0x80072EFE、invalid header、HTTPERR の 404 が大量に出る――この手のトラブルは「プロキシが怪しい」と思われがちですが、実は WSUS サーバー側の重要更新不足が原因になることがあります。ここでは KB4022720（または置き換え先ロールアップ）の確認から、適用後の再同期までを実務目線で整理します。

よくある症状：WSUS が Microsoft Update と同期できない

発生パターンとして多いのは「これまで問題なく運用できていたのに、ある時期から急に同期だけが失敗し始めた」というケースです。プロキシ環境であっても、プロキシ側に明確な変更がないと言われることがあり、原因切り分けが難航しがちです。

WSUS 管理コンソールで手動同期を実行すると、次のようなエラーが混在して表示されることがあります。

• HTTP 401: Unauthorized
• 0x80072EFE（接続が異常終了した、などの通信系エラー）
• “invalid header” などヘッダー関連の例外
• HTTPERR ログに 404 NotFound が大量に出る

表に出やすいエラー	意味（ざっくり）	まず見るべき場所
HTTP 401: Unauthorized	要求が拒否されている（認証・仕様不一致・要求形式の問題など）	WSUS 同期ログ／イベントログ（WSUS）／プロキシログ
0x80072EFE	接続が途中で切断された、通信が維持できない	ネットワーク経路、TLS/暗号設定、プロキシ、WinHTTP 設定
invalid header	ヘッダーが想定外（クライアントが古くて解釈できない、など）	OS 更新状況、.NET／WinHTTP／Windows Update 関連の更新
HTTPERR 404 が大量	存在しない URL へのアクセスが発生している	IIS の HTTPERR ログ、WSUS/IIS 構成、要求先 URL の変化

ログの場所（切り分けで頻繁に参照するもの）

「どこを見ればいいか分からない」状態だと切り分けが止まるため、WSUS 障害の定番ログを先に押さえておきます。

種類	代表的な場所	見るポイント
HTTPERR ログ	%windir%\system32\LogFiles\HTTPERR\	同期実行の時間帯に 404 / 401 が雪崩れていないか
WSUS ログ	C:\Program Files\Update Services\LogFiles\	同期処理の例外、要求先、失敗のタイミング
イベントログ（WSUS）	イベント ビューアー（WSUS 関連）	同期失敗イベント、例外の種類、連続性

結論：WSUS サーバー側（Windows Server 2012 R2）の重要更新不足を最優先で疑う

今回のケースで最初に当たりたい結論は、WSUS サーバー（Windows Server 2012 R2）側に重要な更新が入っておらず、Microsoft Update 側の仕様変化に追随できていない可能性が高い、という点です。

WSUS の同期処理は、単体の「WSUS アプリ」だけで完結しているわけではありません。HTTP 通信（WinHTTP）、暗号スイートや証明書（SChannel）、.NET など、OS 側の基盤コンポーネントの影響を受けます。結果として OS の更新が不足していると、同期で 401 やヘッダー例外、接続断といった形で表面化しやすくなります。

まず確認する更新：KB4022720（未適用なら先に導入して再同期）

対処としてはシンプルで、KB4022720 の適用有無を確認し、未適用であれば先にインストールしてから WSUS の再同期を行います。

ただし、KB4022720 は後続の更新（いわゆる月例ロールアップ等）に置き換え（含まれている）ため、環境によっては「KB4022720 が見つからない」こともあります。その場合は、次の置き換え先（またはそれ以降の月例ロールアップ）が入っているかを確認してください。

確認したい更新	位置づけ	ポイント
KB4022720	優先して確認したい更新	未適用なら導入 → 再起動 → WSUS 再同期
KB4025336	KB4022720 を含む置き換え先の例	KB4022720 が見つからない場合に確認
KB4039871	KB4022720 を含む置き換え先の例	月例ロールアップ運用なら導入済みのことが多い
KB4025335	KB4022720 を含む置き換え先（プレビュー）の例	環境によってはプレビューを入れていない場合もある

KB の適用状況を確認する方法（GUI とコマンド）

現場では「見つからない＝未適用」と早合点してしまうことがあります。まずは、WSUS サーバー自身に対象 KB（または置き換え先）が入っているかを確実に確認しましょう。

GUI（コントロールパネル）で確認

• 「プログラムと機能」→「インストールされた更新プログラムを表示」
• 検索欄で KB 番号（例：4022720）を検索

PowerShell / コマンドで確認

リモート作業や、GUI が重い環境ではコマンド確認が確実です。

# まず KB4022720 を直接確認
Get-HotFix -Id KB4022720

# KB4022720 が見つからない場合は置き換え先も確認
$kbs = "KB4022720","KB4025336","KB4039871","KB4025335"
$kbs | ForEach-Object {
  $_ + " : " + (Get-HotFix -Id $_ -ErrorAction SilentlyContinue | Select-Object -ExpandProperty InstalledOn -ErrorAction SilentlyContinue)
}

Get-HotFix でヒットしない場合でも、更新プログラムが「累積更新」や「ロールアップ」として別の形で表示されるケースもあります。運用ルール上、月例ロールアップを入れている環境なら、該当時期以降のロールアップ導入有無を棚卸しするのが近道です。

適用手順：ロールアップ導入 → 再起動 → WSUS 再同期

未適用と判断できたら、次の流れで進めます。ポイントは「更新の導入」と「再起動」を省略しないこと、そして「適用後に同期をやり直して結果を確認する」ことです。

手順	作業内容	実務メモ
事前確認	WSUS の役割・IIS が稼働しているか、空き容量、バックアップ方針を確認	DB が肥大化している環境は作業前に空き容量を必ず確保
更新の適用	KB4022720 または置き換え先（あるいは後続ロールアップ）を導入	「Security Only」中心の環境はロールアップ不足が起こりやすい
再起動	OS 再起動	保留中の再起動が残ると WSUS/IIS の挙動が不安定になりやすい
サービス確認	WSUS サービスと IIS の起動、イベントログを確認	WSUSService、W3SVC など
同期再実行	WSUS 管理コンソールから同期を実行	成功/失敗だけでなく、エラーの種類が変わったかも見る

同期を PowerShell で叩いて状況を揃える（任意）

GUI での操作が難しい場合や、作業手順を標準化したい場合は PowerShell から同期を開始できます（環境によりモジュール名が異なることがあります）。

# 例：UpdateServices モジュールが利用できる場合
Import-Module UpdateServices -ErrorAction SilentlyContinue
$wsus = Get-WsusServer
$sub = $wsus.GetSubscription()
$sub.StartSynchronization()

実行後は、WSUS 管理コンソールの同期結果や WSUS のイベントログでエラーが解消しているかを確認します。

適用後の確認ポイント：「直った」と判断する基準

同期が 1 回成功しても、すぐに「完全復旧」とは言い切れません。少なくとも次のポイントを押さえておくと、再発や取りこぼしを減らせます。

確認項目	OK の目安	NG の例
同期結果	「成功」になり、更新のメタデータ取得が進む	401/0x80072EFE が継続、または別の通信エラーに変化
HTTPERR ログ	404 が沈静化し、短時間に大量発生しない	同期実行のたびに 404 が雪崩のように増える
イベントログ	WSUS 関連のエラーが減り、警告が解消する	同期失敗イベントが連続し、同じ例外が繰り返される
管理コンソール	「同期した更新プログラム」の日付が進む	最終同期日時が更新されない／途中で停止する

補足：Security Only 運用だと「直すための修正」が入りにくい

「セキュリティのみ更新（Security Only）」中心で運用している環境では、セキュリティ修正は入っていても、Windows Update クライアントや通信周りの不具合修正が入らないことがあります。その結果、プロキシやネットワークが正常でも WSUS の同期だけが失敗し続ける、という状況が起こり得ます。

運用方針	メリット	落とし穴
Security Only	変更量を抑えやすい	非セキュリティ修正（WSUS/通信/互換性）が取りこぼされやすい
月例ロールアップ	修正がまとまって入り、結果的に復旧が早いことが多い	変更量が増えるため検証が必要

今回のように「同期が止まる」タイプの障害は、ロールアップ（置き換え先を含む）を入れることが解決に直結しやすい傾向があります。運用ルール上ロールアップが難しい場合でも、少なくとも WSUS を担うサーバーについては、影響とメリットを比較して方針を決めるのが現実的です。

それでも改善しない場合の追加チェック（現場で詰まりやすい順）

KB 適用で多くは解消しますが、環境によっては複合要因になっていることもあります。再同期しても改善しない場合は、次の項目を上から順に確認すると遠回りになりにくいです。

WinHTTP のプロキシ設定を確認する

WSUS や Windows Update 関連の通信は、IE の設定ではなく WinHTTP のプロキシ設定を参照する場面があります。プロキシ環境で「設定は変えていない」のに同期が止まる場合でも、サーバー側の WinHTTP 設定が空だったり、古い設定が残っていたりすることがあります。

netsh winhttp show proxy

必要に応じて、IE 設定を WinHTTP に取り込む例です。

netsh winhttp import proxy source=ie

明示的に指定する場合は、環境のポリシーに合わせて設定します（例）。

netsh winhttp set proxy proxy-server="http=proxy.example.local:8080;https=proxy.example.local:8080" bypass-list="<local>"

証明書・TLS の問題が混ざっていないかを見る

0x80072EFE は「接続断」として表に出ますが、根っこが TLS/証明書関連であることもあります。Windows Server 2012 R2 は比較的古い世代のため、暗号設定や中間証明書の状態によっては、外部サービス側の更新で影響を受けることがあります。

• サーバーの時刻ずれ（数分〜数十分のずれでも影響するケースあり）
• ルート証明書・中間証明書の更新状況
• セキュリティ製品による SSL インスペクションの有無（プロキシ側で実施している場合）

この領域は環境依存が大きいため、WSUS だけでなく「同じサーバーから https で外部に出られるか」という観点で切り分けると判断しやすくなります。

WSUS 側の整合性チェック（reset / checkhealth）

更新を入れた後でも、WSUS コンテンツや DB の状態次第で動作が重くなり、同期がタイムアウトすることがあります。影響範囲を見極めつつ、次のコマンドで整合性を確認します。

cd "C:\Program Files\Update Services\Tools"
wsusutil.exe checkhealth
wsusutil.exe reset

reset はコンテンツの照合・再ダウンロードを伴うことがあるため、回線やディスクに余裕がある時間帯で実施するのが安全です。

復旧を早めるためのチェックリスト

最後に、同様の障害が起きたときに「最短で復旧するための順番」をチェックリストとしてまとめます。運用手順書に貼り付けて使える形を意識しています。

チェック項目	確認方法	次のアクション
KB4022720 または置き換え先が入っているか	Get-HotFix / 更新履歴	未適用なら導入して再起動
WSUS サービス/IIS が正常か	サービス状態、イベントログ	停止・エラーなら原因を先に解消
WinHTTP プロキシ設定が適切か	netsh winhttp show proxy	必要なら import / set proxy
同期後のエラー内容が変化したか	同期結果、HTTPERR、WSUS ログ	エラーが変化したら次の層（TLS/証明書等）を疑う
WSUS の整合性	wsusutil checkhealth / reset	コンテンツ/DB の問題が疑われる場合に実施

まとめ

Windows Server 2012 R2 上の WSUS が「HTTP 401 Unauthorized」「0x80072EFE」「invalid header」などで Microsoft Update と同期できない場合、プロキシやネットワークの前に、WSUS サーバー自身の重要更新（KB4022720 または置き換え先）不足を疑うのが近道です。対象更新を適用して再起動し、WSUS の再同期を行うことで改善するケースが多く、Security Only 運用の環境ほど効果が出やすい傾向があります。適用後もログと同期結果を確認し、必要に応じて WinHTTP プロキシや WSUS の整合性チェックまで進めると、復旧を最短化できます。