MENU

WSUS同期が10〜40%で止まる原因と対策：Windows Server 2012 R2のWebExceptionをIIS/TLS1.2で解消

Windows Server

Windows Server 2012 R2 上の WSUS で同期が10〜40%付近で止まり、「WebException: The underlying connection was closed」「connection was closed unexpectedly（接続が予期せず切断）」などが出る場合は、IIS（WSUSPool）の再起動・推奨設定未適用、または TLS/暗号設定が原因で通信が途中で切られているケースが多いです。現場で再現しやすい順に、切り分けと具体的な直し方をまとめます。

目次

WSUS同期が10〜40%で止まるときに起きていること

WSUS の同期（Synchronization）は、更新プログラム本体だけでなく、製品/分類情報、更新メタデータ、関連付け情報などを段階的に取得します。進捗が10〜40%で止まるのは「取得途中で接続が落ちる（または落とされる）」タイミングがその辺りで発生している、というサインです。

エラーメッセージが似ていても原因は複数ありますが、特に多いのは次の２系統です。

  • IIS 側（WSUSPool）が途中でリサイクル/停止して接続が切れる：メモリ制限、定期リサイクル、Ping/Idle タイムアウトなどで w3wp.exe が再起動し、同期中のセッションが途切れます。
  • 外部（Microsoft Update など）との TLS 交渉に失敗して切断される：TLS 1.0/1.1 で接続しようとしたり、暗号スイートが絞られすぎたりして、相手側が接続をリセットします。
よくある原因現れやすいサイン優先度が高い対処
IIS（WSUSPool）のリサイクル/メモリ制限同期が一定%で止まる、負荷や時間帯で再現、WSUSPool が停止していることがあるWSUSPool を推奨設定へ調整＋AppPool再起動
TLS 1.2 未対応/ .NET の既定TLS設定が古いSoftwareDistribution.log に WebException（send/receive）、SChannel 関連ログ、TLS1.0 で接続しようとして失敗月例ロールアップ適用＋.NET 強力暗号/既定TLS有効化
プロキシ/ファイアウォール/SSL検査（HTTPSの中身を検査）特定ネットワークだけ失敗、別回線では成功、プロキシ経由でのみ再現通信経路を単純化（直通テスト）→ 例外/許可を見直す
上流WSUSの不調（下流WSUS構成）下流側は常に同じ%で失敗、上流側のIIS/WSUSが不安定上流WSUSにも同じ対策を実施（IIS/ TLS）

切り分けを最短にするログの確認ポイント

闇雲に設定を触る前に、どこで切れているかを短時間で掴むと復旧が早いです。WSUS の同期・TLS・IIS の３点を、次の順で確認します。

確認先場所/ファイル見るポイント分かること
WSUSログ%ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.logWebException、SChannel Protocol、接続先URL（sws.update.microsoft.com 等）TLS/暗号/通信断の方向性
IISログIIS ログ（既定: C:\inetpub\logs\LogFiles）503/500、要求の途中終了、時間帯WSUSPool の再起動や過負荷の兆候
イベントビューアWindows ログ（アプリケーション/システム）IIS/ASP.NET/SChannel/WSUS関連再起動・暗号設定・証明書などの根拠

IIS設定を“WSUS推奨値”に合わせる（上流・下流とも必須）

同期が途中で切れるパターンで、最も費用対効果が高いのが IIS の WSUSPool 調整です。WSUS は更新メタデータを内部キャッシュとして扱うためメモリ負荷が大きく、既定設定のままだとアプリケーションプールがリサイクルし、同期中の接続が切れやすくなります。

とくに下流WSUS（社内の上流WSUSから同期する構成）では、下流だけを直しても再発します。上流側の WSUSPool が途中で落ちれば、下流は「接続が予期せず切断」としか見えないためです。上流・下流の両方で同じ方針の設定に揃えるのがコツです。

WSUSPool（Application Pool）の推奨設定

IIS マネージャーで「Application Pools」→「WsusPool」→「Advanced Settings」から設定します。下表は Microsoft が案内している代表的な推奨値です。

設定名推奨値狙い補足
Queue Length2000同時要求が増えたときに 503 を起こしにくくする既定1000から引き上げ
Idle Time-out (minutes)0アイドル判定で停止→再起動、を防ぐ常時稼働させる
Ping EnabledFalsePing判定による不要な再起動を避ける高負荷時に落ちやすい環境で有効
Private Memory Limit (KB)0メモリ上限超過によるリサイクルを防ぐ“無制限”扱い
Regular Time Interval (minutes)0定期的な自動リサイクルを無効化既定1740(29時間)を無効化

上記を入れると WSUSPool がメモリを多く使うようになります。環境によってはキャッシュ構築時に大きなメモリが必要になり得るため、サーバーのメモリ余力や他役割との同居状況もあわせて確認してください。

WSUSPool を再起動する（影響を小さく）

設定変更後は、反映のために WSUSPool を再起動します。IIS 全体を再起動する iisreset は影響範囲が広いので、まずは AppPool 再起動から始めると安全です。

Import-Module WebAdministration
Restart-WebAppPool -Name "WsusPool"

「WSUSPool が停止している」「起動してもすぐ止まる」場合は、上表の Private Memory Limit と Regular Time Interval が 0 になっているかを優先的に見直します。ここが残っていると、同期途中で w3wp.exe が再起動しやすくなります。

“軽い復旧”を挟んでから同期を再試行する

設定反映後、次の流れで同期をやり直すと、切り分けが早くなります。

  • WSUS コンソールを閉じる（接続を切る）
  • WSUSPool を再起動する
  • WSUS サービス（Windows Server Update Services）を再起動する
  • WSUS コンソールを開き直し、同期を手動実行する

ここで改善する場合、原因は「WSUSPool の状態不良（メモリ逼迫・断続的な再起動）」または「IIS 既定設定がWSUSに厳しかった」可能性が高いです。

IIS推奨設定でも直らないなら TLS 1.2 を疑う（2012 R2で多い）

2012 R2 の WSUS で WebException が出るとき、IIS 調整で直らなければ TLS 1.2 と暗号設定を優先的に疑います。WSUS が TLS 1.0 などで接続しようとすると、TLS 1.2 のみを受け付けるエンドポイントでは接続がリセットされ、「An existing connection was forcibly closed by the remote host（相手に切断された）」として失敗します。

まずは Windows Update のロールアップ適用状況を確認する

Windows Server 2012 / 2012 R2 では、セキュリティのみ更新（Security-only）だけを当て、月例ロールアップを適用していないと、TLS 1.2 対応に必要な更新が不足して同期できなくなることがあります。まずは最新の月例ロールアップを適用してベースを揃えるのが安全です。

加えて、WSUS を 2012 R2 上で動かしている場合、TLS 1.2 対応のために特定の更新プログラム（またはそれ以降のロールアップ）を要求する案内もあります。OS と WSUS の更新適用状況を“最新寄り”に保つことが、同種トラブルの予防策になります。

SoftwareDistribution.log で TLS の状態を確認する

WSUS は起動時に有効な SSL/TLS をログへ出力します。次TLS が疑わしい場合は、次の手順でログを更新し、SCHANNEL Protocol で始まる行を探します。

  • WSUS サービスを再起動する
  • 管理者コマンドプロンプトで iisreset を実行する（WSUS の起動シーケンスを通す）
  • %ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log を開く
ログの見え方解釈次の手
TLS 1.0 / TLS 1.1 が無効、TLS 1.2 が有効OS側のSChannelは概ねOK.NET の既定TLS（強力暗号）を確認
TLS 1.2 に関する記述が出ないTLS1.2対応更新が不足の可能性月例ロールアップ適用を優先
WebException（send/receive）だけが並ぶTLS/暗号/経路のどれかで握手が破綻次節の .NET 設定と暗号スイート制限を確認

.NET を “強力な暗号/OS既定TLS” で動かす（重要）

WSUS は IIS（w3wp.exe）上で動くため、.NET の既定TLS設定が古いと TLS 1.2 が使われずに失敗します。次のレジストリ値を設定し、再起動します（サーバー再起動が必要です）。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

再起動後は、WSUSPool を再起動して同期を再実行します。運用上すぐ再起動できない場合でも、再起動なしで「たまたま直ったり、直らなかったり」を繰り返すより、計画停止で確実に反映させた方が結果的に早いです。

w3wp.exe.config で既定TLSを有効化する（補助策）

環境によっては、.NET のレジストリ設定に加えて w3wp.exe.config を用意して「OSの既定TLSを使う」挙動を明示すると安定します。次の内容を %SystemRoot%\System32\inetsrv\w3wp.exe.config に作成（または追記）します。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
  </runtime>
</configuration>

暗号スイート制限（GPO）も要注意

TLS 1.2 が有効でも、サーバーのポリシーで暗号スイートが絞られすぎていると、相手と共通暗号がなく同期に失敗します。適用ポリシーを可視化するため、次のコマンドでレポートを作成します。

gpresult /scope computer /h GPReport.html

レポートで SSL Cipher Suite Order を検索し、明示設定がある場合は、共通暗号が含まれるかを確認します。Windows Server 2012 / 2012 R2 向けに、代表的に必要になり得る暗号の例が Microsoft から示されています。

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384

社内基準で暗号を厳格化している場合は、セキュリティ担当と相談のうえ「TLS 1.2 は維持しつつ、WSUS が外部と握手できる最小限」を確保します。

プロキシ/ファイアウォールの基本も同時に確認する

IIS と TLS を整えても改善しない場合、次はネットワーク要因を疑います。特にプロキシや SSL 検査（HTTPS の中身を代理で復号する仕組み）があると、TLS の交渉が途中で失敗しやすくなります。下流WSUS構成では「下流→上流は通るが、上流→Microsoft Update が出られない」という形で見落とされがちです。

確認項目具体的な確認ポイント
外向き通信（上流WSUS）HTTPS(443)/HTTP(80) が Microsoft Update 系エンドポイントへ到達できるかプロキシ経由なら WSUS のプロキシ設定・例外（バイパス）も確認
社内通信（クライアント→WSUS）GPO「社内更新サービスの場所」のURL/ポートが正しいか一般的に 8530(HTTP)/8531(HTTPS)。環境の実値に合わせる
名前解決DNS/hosts で上流・下流の名前が正しく解決できるかFQDN と短縮名の混在は、証明書/TLS で詰まりやすい
サーバーの強化設定セキュリティ強化（IE ESC等）や通信制限の影響「管理者操作は通る/サービスは通らない」の差に注意

WSUSのメンテナンス不足が“切断”を誘発することもある

同期の途中停止は通信エラーに見えますが、根はパフォーマンスのこともあります。更新分類を大量に選びすぎたり、置き換え済み（Superseded）更新が放置されてメタデータが肥大化すると、WSUS の処理負荷が跳ね上がり、結果的に WSUSPool が不安定になります。Microsoft も、不要な更新の整理やメンテナンスを重要視しています。

  • 製品/分類は必要最小限にする（後から追加は可能）
  • 置き換え済み（Superseded）更新を適切に整理する
  • 定期的にサーバークリーンアップ（Server Cleanup Wizard）を回す
  • WSUS向けのDBメンテナンス（再インデックス等）を計画的に行う

「IIS 推奨設定で一旦直るが、数日〜数週間で再発する」場合は、メンテナンス不足で内部処理が重くなっているサインになりがちです。再発防止として、同期対象の絞り込みと更新整理をセットで行います。

それでも直らない場合：2012 R2 固有の制約を前提に移行を検討する

WSUS の同期は外部サービス・暗号要件・更新形式の変化の影響を受けます。2012 R2 はすでに古い世代で、更新適用状況や暗号設定の組み合わせ次第で「正しい設定でも詰まる」ことがあります。IIS 推奨設定、TLS 1.2、暗号スイートまで潰しても改善しない場合は、WSUS をより新しい Windows Server（例：2016/2019/2022）へ移行して解消するケースが現実的にあります。

移行を判断する材料として、次の観点を整理するとスムーズです。

観点確認ポイント判断の目安
サポート/更新Windows Server 2012 R2 は延長サポート終了後の運用形態となり、製品や役割によってはサポート対象外になり得る長期運用なら移行が堅い
安定運用同期失敗が業務影響（更新遅延/ゼロデイ対応）に直結するか影響が大きいほど早期移行
構成の複雑さ上流・下流・プロキシ・SSL検査などの依存関係複雑なほど新環境で再設計が有効

なお、移行前に「上流だけ新OSへ」「下流は現状維持」といった段階移行をすると、原因切り分けにもなりやすいです。上流が安定すれば下流の WebException が止まることがあります。

再現しやすい順に潰す（チェックリスト）

  • IIS の WSUSPool を推奨値に合わせ、上流・下流の両方で WSUSPool を再起動する
  • SoftwareDistribution.log で TLS/SChannel の状態を確認し、月例ロールアップと .NET の既定TLS（強力暗号）を整える
  • 暗号スイート制限（GPO）やプロキシ/SSL検査を含むネットワーク要因を切り分ける
  • 再発する場合は、同期対象の絞り込みとWSUSメンテナンスで負荷を落とす
  • どうしても詰まる場合は、WSUS（OS）バージョンアップを現実解として検討する
Windows Server
wsus IIS Windows Server 2012 R2 TLS1.2 WebException

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次