WSUS 管理コンソールから Microsoft Update Catalog を使って更新プログラムをインポートしようとすると、どの更新でも 80131509（some updates could not be imported）で失敗する――最近よく聞く症状です。TLS 要件の強化により .NET の暗号設定が追従できないのが原因になりやすく、レジストリ 1～2 行で復旧することがあります。
WSUS「更新プログラムのインポート」が失敗する症状
WSUS の運用で「配布対象にしたい更新が WSUS に存在しない」「特定の KB を手動で取り込みたい」といった場面は少なくありません。Microsoft Update Catalog からのインポートは、その場で更新を WSUS に取り込める便利な機能ですが、ある時期から突然、どの更新を選んでも失敗するケースが報告されています。
| 項目 | 内容 |
|---|---|
| 発生操作 | WSUS 管理コンソールの「更新プログラムのインポート」から Microsoft Update Catalog を開き、更新を選択してインポート |
| 代表的なエラー | 80131509 / some updates could not be imported |
| よくある環境 | Windows Server 2012 R2 / 2016 の WSUS、あるいは同じ管理端末から複数 WSUS を管理している構成 |
| 特徴 | 以前は正常にインポートできていたのに、最近になって一斉に失敗し始める（複数サーバーで同時に発生することもある） |
| 運用への影響 | 必要な更新を WSUS に取り込めず、承認・配布のワークフローが止まる（例：特定のドライバー更新、Preview 更新、特定 KB のみ配布したい場合など） |
エラー 80131509 は、WSUS が内部的に利用している .NET 例外（HRESULT）が表に出ているだけで、原因（通信失敗・証明書・プロキシなど）までは示してくれません。だからこそ、サーバー移行や再構築に走る前に、まずは暗号/TLS の観点で切り分けるのが近道です。
原因：Update Catalog 側の TLS 要件強化と .NET の暗号設定のギャップ
この現象で特に多いのが、Update Catalog 側で暗号化/TLS の要件が強化されたタイミングで、WSUS 管理コンソール（正確にはその実行環境の .NET Framework）が古い暗号設定のままになり、HTTPS の接続に失敗してインポート処理が進まなくなるパターンです。
ポイントは「WSUS サーバーそのもの」というより、WSUS 管理コンソールを実行しているマシンの .NET 設定です。たとえば次のような構成では、設定すべき場所を間違えがちです。
| あなたの運用 | 設定を入れるべき場所 | よくある勘違い |
|---|---|---|
| WSUS サーバーにログオンしてコンソールを開く | その WSUS サーバー | ― |
| 管理端末（別サーバー/PC）に WSUS コンソールを入れてリモート管理 | 管理端末側 | WSUS サーバー側を触れば直ると思い込む |
Update Catalog は HTTPS を使います。古い .NET 実行環境では、既定のままだと TLS 1.0/1.1 を優先したり、強度の低い暗号スイートを選択しようとして、サーバー側（Catalog 側）が拒否することがあります。その結果、GUI 上は「some updates could not be imported」という抽象的な表示になり、原因の切り分けが難しくなります。
最小構成の対処：.NET Framework 4 系で Strong Crypto を有効化する
まず試したいのが、.NET Framework 4 系で Strong Crypto（強力な暗号）を有効化する方法です。レジストリの SchUseStrongCrypto を 1 にすることで、.NET が OS の既定の安全な暗号設定（TLS 1.2 など）を使いやすくなり、Update Catalog への接続が成功してインポートが復旧することがあります。
作業前の注意
- レジストリ変更は影響範囲が広い作業です。可能なら事前にスナップショット/バックアップ、最低限でも対象キーのエクスポートを行ってください。
- 変更対象は「WSUS コンソールを起動しているマシン」です。リモート管理している場合は管理端末側を優先してください。
- 変更後は WSUS コンソールを開き直します。環境によってはサービス再起動や OS 再起動が必要になることがあります。
（推奨）キーのバックアップ
戻せる状態にしてから作業すると安全です。次は対象キーを .reg としてエクスポートする例です（パスは必要に応じて変更してください）。
reg export HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 C:\temp\dotnet_v4_backup.reg /y手順（最小構成）
- 管理者権限でコマンドプロンプトを開きます。
- 次を実行します（Strong Crypto 有効化）。
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /V SchUseStrongCrypto /T REG_DWORD /D 1 /F- WSUS 管理コンソールをいったん終了し、開き直します。
- 「更新プログラムのインポート」から再度インポートを実行します。
補足：64bit OS で 32bit 側も必要になることがある
WSUS コンソールや関連コンポーネントの動作状況によっては、64bit OS でも 32bit 側の .NET 設定が参照されることがあります。その場合は、次のキーにも同じ値を入れると安定するケースがあります。
reg add HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319 /V SchUseStrongCrypto /T REG_DWORD /D 1 /Fこの 1～2 本で改善するなら、原因は「WSUS の不具合」ではなく、暗号設定（TLS/暗号スイート）の不一致である可能性が高いと判断できます。
反映確認：設定が入ったかをチェックする
作業後、値が正しく設定されたかを確認しておくと安心です。次のコマンドで現在値を確認できます（存在しない場合はエラー表示になります）。
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto32bit 側も設定した場合は、こちらも確認します。
reg query HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCryptoインポートの成否は WSUS コンソール上の動作だけでなく、次の観点で確認すると「直ったつもり」を防げます。
| 確認ポイント | 見る場所 | 期待する状態 |
|---|---|---|
| インポート画面でのエラー | Update Catalog から戻った直後のダイアログ | 80131509 が出ず、正常に完了する |
| WSUS の更新一覧への反映 | WSUS コンソールの「更新プログラム」 | インポートした KB が表示され、承認/配布設定が可能 |
| ログでの裏取り | イベント ビューアー（アプリケーション/システム） | インポート直後に致命的な TLS/接続エラーが出ていない |
それでも直らないときの追加チェック
Strong Crypto の有効化で改善することが多い一方、環境によっては別の要因が重なっていることがあります。ここからは「追加で効くことがある」現場向けのチェックです。該当しそうなものから順に確認してください。
どのマシンで WSUS コンソールを動かしているか再確認する
最も多いハマりどころはこれです。WSUS サーバー側にレジストリを入れても、管理端末からリモートで WSUS コンソールを開いている場合、インポート処理は管理端末の .NET 設定に依存します。複数の WSUS サーバーで同時に失敗している場合、共通点が「管理端末」になっていないか確認してください。
TLS 1.2 が無効化されていないか（セキュリティ強化ポリシー）
セキュリティベースラインや独自のハードニングで、古い TLS を無効化したつもりが、必要な TLS 1.2 まで無効になっているケースがあります。特に「暗号の無効化をまとめて適用するツール」を使った環境では起こりがちです。
- OS のインターネット オプションで TLS 1.2 が有効か
- プロキシや FW の HTTPS 復号（SSL インスペクション）が Update Catalog を阻害していないか
- 証明書を差し替えるタイプの中間装置がある場合、管理端末の信頼済みルート証明書が適切か
.NET の「OS 既定 TLS を使う」設定も合わせて入れると安定することがある
環境によっては SchUseStrongCrypto だけではなく、OS の既定 TLS バージョンを .NET が採用するための設定が効くことがあります。これは「.NET が古い既定値のまま TLS 1.0 を選び続ける」状況を避けるための考え方です。
次の値は、.NET Framework 4 系で OS の既定 TLS を使わせるための代表的な設定です（適用可否は .NET/OS バージョンに依存します）。
| キー | 値 | 狙い |
|---|---|---|
| HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 SystemDefaultTlsVersions | DWORD 1 | .NET が OS 既定の TLS 設定を使うようにする |
| HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319 SystemDefaultTlsVersions | DWORD 1 | 32bit 側でも同様にする（必要な場合） |
コマンドで入れる場合は次のようになります（必要なものだけ実施してください）。
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /V SystemDefaultTlsVersions /T REG_DWORD /D 1 /F
reg add HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319 /V SystemDefaultTlsVersions /T REG_DWORD /D 1 /Fプロキシ配下の WSUS で起こることがある追加要因
企業ネットワークでは WSUS サーバーや管理端末がインターネット直通ではなく、プロキシ経由で通信する構成が一般的です。次のような条件があると、暗号設定を直してもインポートだけ失敗し続けることがあります。
| 条件 | 起こり得ること | 対処の方向性 |
|---|---|---|
| プロキシが TLS 1.2 非対応/古い | Catalog 側の要件に追従できず接続が落ちる | プロキシ機器/ソフトの更新、または該当ドメインのバイパス |
| SSL インスペクション（HTTPS 復号）を実施 | 証明書の差し替えにより .NET 側で信頼できず失敗 | 信頼済みルート証明書の配布、例外設定の追加 |
| 認証が必要なプロキシ | WSUS コンソールがプロキシ認証と噛み合わず失敗 | WinHTTP/IE のプロキシ設定の統一、認証方式の見直し |
Windows Update や WSUS 自体の更新状況を確認する
Update Catalog との通信以前に、WSUS のコンポーネントや関連する OS コンポーネントが古いことで周辺処理が失敗する場合もあります。特に長期間メンテナンスされていない WSUS では、以下を優先的に見直すと改善することがあります。
- OS の累積更新プログラムや .NET のセキュリティ更新が適用されているか
- WSUS の定期メンテナンス（不要更新の整理、DB 最適化など）を長期間実施していない場合は、まず基本メンテから行う
ロールバック（元に戻す）方法
「試した結果、別アプリに影響が出た」「変更管理上、いったん戻したい」という場合は、値を 0 に戻すか、値自体を削除します。運用ポリシーに合わせて選んでください。
| 方法 | コマンド例 | ポイント |
|---|---|---|
| 0 に戻す | reg add ... /D 0 | 値は残るが無効化できる（再有効化が簡単） |
| 値を削除する | reg delete ... /v ... | 既定動作に戻す（検証時は 0 戻しの方が扱いやすいことが多い） |
例として SchUseStrongCrypto を 0 に戻すコマンドは次のとおりです（32bit 側も戻す場合は同様に実施します）。
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /V SchUseStrongCrypto /T REG_DWORD /D 0 /F再発防止：設定を「属人化」させない運用のコツ
この種のトラブルは「急に起きる」「複数サーバーで一斉に起きる」ため、復旧後に手順を残しておかないと同じ作業を繰り返しがちです。特に複数の管理端末がある組織では、次のように運用で吸収すると強いです。
- どの端末で WSUS コンソールを実行しているかを棚卸しし、対象端末に同じ設定を適用する
- レジストリ変更を行う場合は、変更申請・手順書・ロールバック手順（値を戻す/削除する）までセットで管理する
- セキュリティ強化ツールを使う場合は、TLS 1.2 まで無効化しないよう例外/テンプレートを見直す
- WSUS サーバーの OS/.NET 更新を「止めない」。WSUS だけが古いまま残ると、外部要件変化に弱くなる
まとめ：80131509 は「WSUS 不調」ではなく暗号設定が原因のことが多い
WSUS の「更新プログラムのインポート」が 80131509 で失敗する問題は、更新そのものが壊れているというより、Update Catalog 側の TLS 要件強化と .NET の暗号設定のギャップが引き金になっているケースが目立ちます。まずは SchUseStrongCrypto を有効化し、必要に応じて 32bit 側も設定してから再試行してください。それでも改善しない場合は、コンソール実行端末の見直し、TLS 1.2 の有効化状況、プロキシ/SSL インスペクション、OS/.NET の更新状況まで確認すると原因に辿り着きやすくなります。
コメント