Windows Server 2016/2019 の WSUS で Microsoft Update Catalog から更新プログラム（KB）を「インポート」しようとすると、突然 80131509 で失敗することがあります。KB4497165 などの特定更新で起きやすいこの症状は、.NET Framework の暗号設定（Strong Crypto）を有効化し、再起動することで解消するケースが多いです。原因と対処、再発防止までまとめます。
症状：WSUS の「更新のインポート」が 80131509 で失敗する
WSUS（Windows Server Update Services）には、通常の同期（Microsoft Update からのカタログ同期）とは別に、Microsoft Update Catalog から個別の更新を手動で取り込むための「更新のインポート」機能があります。
ところが Windows Server 2016 / 2019 上の WSUS で、次のような症状に遭遇することがあります。
| 現象 | 具体例 | よくある状況 |
|---|---|---|
| Update Catalog から KB をインポートできない | KB4497165 / KB4558130 / KB4494174 など | 以前は同じ手順で成功していたのに、ある時期から失敗し始めた |
| WSUS コンソール上でエラー | エラーコード：80131509 | 「一部の更新をインポートできませんでした」等のメッセージ |
このエラーは WSUS の設定ミスというより、WSUS が Update Catalog 側の通信要件（暗号/TLS）に追従できていないときに出やすいタイプです。特に、セキュリティ強化（TLS の整理・弱い暗号の無効化）を進めている環境ほど、表面化しやすくなります。
原因の考え方：.NET Framework が「強い暗号」を使わずに通信してしまう
WSUS の「インポート」処理は内部的に .NET Framework の通信スタックを使います。ところが環境やターゲットの .NET バージョン次第では、既定で強い暗号（Strong Crypto）を使わない動作になることがあります。
その結果、Update Catalog 側が求める TLS 1.2 などの安全なプロトコル/暗号スイートで握手できず、WSUS 側がエラーとして 80131509 を返す…という流れです。
Microsoft Learn の .NET Framework のガイダンスでも、SchUseStrongCrypto を 1 にすることで、TLS 1.2 / 1.1 を含むより安全なプロトコルを使い、弱いプロトコルを避ける挙動になる旨が説明されています。
最短で直す：SchUseStrongCrypto を有効化して「再起動」する
Microsoft Q&A では、既知の問題として、.NET Framework に強い暗号を使わせる設定（SchUseStrongCrypto）を有効化する手順が案内されています。実運用でも、この方法で解決することが多いです。
作業前の注意点
- レジストリ変更を行うため、メンテナンス時間で実施してください。
- 既存の古いシステム（TLS 1.0 しか話せない相手）と通信している .NET アプリが同居している場合、影響が出る可能性があります。WSUS 専用/準専用サーバーであれば影響は出にくい傾向です。
- 最終的にOS 再起動を推奨します（後述）。
手順（Microsoft Q&A で案内されているコマンド）
- 管理者としてコマンドプロンプトを起動します。
- 次のコマンドを実行します。
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /V SchUseStrongCrypto /T REG_DWORD /D 1- WSUS コンソールで、対象 KB のインポートを再実行します。
- 反映が不安定な場合があるため、WSUS/IIS サービス再起動よりも OS 再起動を優先します。
実際に、同じ事象が出ていた環境で「追加の再起動をしたら正常に動いた」という報告もあり、まず再起動までセットで実施すると切り分けが早くなります。
環境によって追加で入れておきたい設定（32bit 側、OS 既定の TLS 選択）
上記 1 行で直るケースが多い一方、セキュリティ強化が進んだ環境や、32bit プロセスが絡む環境では追加設定が必要になることがあります。Microsoft の TLS 1.2 有効化ガイドでは、Strong Crypto とあわせて SystemDefaultTlsVersions も推奨しています。
| 目的 | キー（代表例） | 値 | 補足 |
|---|---|---|---|
| .NET 4 系で強い暗号を使う | HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 | SchUseStrongCrypto=1 | 64bit OS では Wow6432Node 側も用意すると安心 |
| OS 既定の TLS 設定に追従する | 同上 | SystemDefaultTlsVersions=1 | OS 側で TLS 1.2 が有効なら、それを優先して使う方向 |
追加設定をコマンドで入れる例（必要な場合のみ）です。
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 SchUseStrongCrypto /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※「どこまで入れるべきか分からない」場合は、まず Q&A の手順（SchUseStrongCrypto のみ）＋再起動で様子を見て、残る場合に追加設定を検討すると安全です。
反映確認（設定が入ったかをチェック）
設定が入っているかは reg query で確認できます。
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions64bit OS で 32bit 側も確認するなら以下です。
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersionsインポート成功後に確認したいポイント（「取り込めた」だけで終わらない）
80131509 の解消後、インポート自体が成功しても「クライアントに配布されない」「ダウンロードが始まらない」といった二次トラブルが起きることがあります。WSUS の動きとしては次の順番なので、どこで止まっているかを意識すると迷いません。
| 段階 | WSUS 上の状態 | 管理者が見る場所 | つまずきポイント |
|---|---|---|---|
| インポート | 更新メタデータが WSUS に登録される | WSUS コンソール > 更新プログラム | インポート直後は「未承認」のまま |
| 承認 | 配布対象グループに対して承認される | 右クリック > 承認 | 承認先グループの選択ミス（All Computers ではなく検証グループ推奨） |
| コンテンツ取得 | 更新ファイル（.cab 等）が WSUS にダウンロードされる | WSUS の「更新ファイルと更新言語」設定、ログ | 「承認時にのみダウンロード」の設定だと、承認するまで実体が落ちてこない |
| クライアント配布 | クライアントがスキャンし、必要ならダウンロード/適用する | クライアント側の WindowsUpdate.log、イベントログ | 検出頻度、WSUS グループ割り当て、GPO の適用漏れ |
特に「更新ファイルをこのサーバーに保存するが、承認された更新のみダウンロード」という設定の場合、インポートに成功しても、承認するまでダウンロードが始まりません。復旧確認では、インポートだけでなく「承認 → ダウンロード開始」までを確認すると確実です。
よくある落とし穴：カタログから直接ダウンロードした .MSU はそのまま WSUS に入らない
Update Catalog には「ダウンロード」ボタンがありますが、ここから落ちてくるファイルは多くの場合 .MSU です。WSUS は .MSU をそのままインポートできないため、次のどちらかで取り込む必要があります。
- WSUS コンソールの「更新のインポート」（従来方式）
- Microsoft Learn が案内する PowerShell スクリプト方式（推奨）
「ダウンロードはできるのに、WSUS に入らない」という場合は、この仕様に引っかかっていることが多いです。
ロールバックしたいとき（元に戻す方法）
原則として WSUS サーバーでは Strong Crypto 有効化を維持するのが望ましいですが、万一、同居アプリの互換性などで問題が出た場合は戻せます。
| 方法 | コマンド例 | ポイント |
|---|---|---|
| 値を 0 に戻す | reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /V SchUseStrongCrypto /T REG_DWORD /D 0 /f | 戻した後も再起動が必要 |
| 値を削除する | reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /V SchUseStrongCrypto /f | 削除前に現状値を控えると安全 |
※ Wow6432Node 側も設定している場合は、同様にそちらも戻します。実際の運用では、戻す前に「どの通信が失敗したのか」をログで特定し、Strong Crypto を戻さずにアプリ側の更新で対応できないかも検討してください。
再起動の優先度が高い理由：サービス再起動だけでは拾いきれないことがある
「WSUSService と IIS（W3SVC）を再起動したのに直らない」→「OS を再起動したら直った」というパターンが、現場では珍しくありません。
- .NET の暗号設定はプロセス起動時に読み込まれることが多く、プロセスが掴んでいる設定が残る場合がある
- IIS 関連のプロセスだけでなく、バックグラウンドで動く WSUS 周辺のコンポーネントが関与していることがある
- セキュリティ設定・証明書ストアの更新など、再起動で整う要素が複数ある
切り分けを速くするなら、まずは「Strong Crypto を有効化 → OS 再起動 → 再度インポート」を基本セットにするのがおすすめです。
まだ直らない場合の切り分けチェック
SchUseStrongCrypto を入れて再起動しても解消しない場合は、通信経路（TLS/プロキシ/証明書）か、インポート方式（ActiveX 依存）のどちらかに問題が残っていることが多いです。下のチェックリストで順に潰していきます。
| チェック項目 | 確認ポイント | 対処の方向性 |
|---|---|---|
| WSUS サーバーから Update Catalog に到達できるか | FW/プロキシ/名前解決。サーバーから https://catalog.update.microsoft.com が開けるか | プロキシ例外、SSL インスペクションの影響、到達性の見直し |
| TLS 1.2 が OS レベルで無効化されていないか | セキュリティベースライン/硬化ツールで TLS 設定を変更していないか | SCHANNEL の設定を確認し、必要なら TLS 1.2 を有効化 |
| ルート証明書・中間証明書が古くないか | 証明書チェーンの検証に失敗すると TLS で落ちる | Windows Update/ルート証明書更新の適用、証明書ストアの確認 |
| WSUS のログで何が起きているか | SoftwareDistribution.log にインポート関連のエラーが残る | ログのエラー文言から「TLS」「証明書」「接続」などの方向を特定 |
| ActiveX に依存する旧インポート方式の限界 | IE 廃止/互換モード周りで操作が不安定 | PowerShell スクリプト方式へ移行（後述） |
ログの場所（まずはここを見る）
Microsoft Learn の WSUS 公式ドキュメントでは、Update Catalog からのインポートに関するログ/エラーは次に出ると案内されています。
%ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log「80131509」のタイミング前後で、TLS/証明書/プロキシに関連する文言がないかを確認すると、次の一手が決めやすくなります。
長期的なおすすめ：WSUS の手動インポートは PowerShell 方式へ
ここ数年で特に重要なのが、WSUS の「更新のインポート」がActiveX 依存で作られており、ブラウザ環境の変化に追従しにくい点です。Microsoft Learn の最新ドキュメントでは、ActiveX による従来のインポート機能は非推奨になり、PowerShell スクリプトでのインポートに置き換えられたことが明記されています。
つまり、今回の 80131509 を直しても、今後また別の要因で「GUI のインポートが不安定になる」可能性があります。運用としては、次の方針が安定します。
- 緊急時の暫定対処：Strong Crypto の有効化＋再起動で GUI インポートを復旧
- 恒久対処：PowerShell スクリプト方式に移行し、ActiveX 依存から抜ける
PowerShell スクリプト方式の概要
Microsoft Learn の手順は大枠として次の流れです。
- Microsoft Learn の記事に掲載されているスクリプトを
ImportUpdateToWSUS.ps1として保存する - Update Catalog の更新詳細ページで UpdateID（GUID） をコピーする
- 管理者の PowerShell でスクリプトを実行し、WSUS に取り込む
実行例（1 件だけ取り込むイメージ）
.\ImportUpdateToWSUS.ps1 -WsusServer WSUSServer.contoso.com -PortNumber 8530 -UpdateId 12345678-90ab-cdef-1234-567890abcdef複数件を取り込む場合は、UpdateID を 1 行 1 件でテキスト化して -UpdateIdFilePath を使う方式が用意されています。GUI の操作に依存しないため、手動インポートを定期的に行う環境ほどメリットが大きいです。
よくある質問（FAQ）
SchUseStrongCrypto を有効化すると何が変わる？危険はない？
SchUseStrongCrypto は、.NET Framework のクライアント通信で「より強い暗号/TLS を優先して使う」ためのスイッチです。弱い暗号や古いプロトコルしか話せない相手と通信しているレガシーアプリが同居している場合、影響が出る可能性はあります。ただし WSUS サーバーはインターネット向けに安全な TLS が必須になるため、セキュリティ面ではむしろ推奨寄りの設定です。
設定は「WSUS サーバー」に入れるべき？それとも管理端末？
基本は WSUS サーバー側です。Microsoft Learn の WSUS ドキュメントでも、Strong Crypto に関するサンプルは「WSUS サーバーにレジストリを追加し、WSUSService と IIS を再起動する」と説明されています。PowerShell スクリプト方式をリモート端末から実行する場合でも、まずは WSUS サーバー側の設定を整えるのが確実です。
サービス再起動だけで良い？OS 再起動は必要？
理屈の上では WSUSService / W3SVC の再起動で足りる場合もありますが、反映が不安定なケースがあります。現場のトラブル対応としては、OS 再起動まで実施した方が成功率が高く、切り分けも速いです。
KB4497165 以外でも起きる？
起きます。実際に報告では KB4558130 や KB4494174 でも同様に失敗しています。特定の KB に限定されるというより、Update Catalog 側の要求（TLS/暗号）と、WSUS 側の既定動作の組み合わせで表面化するイメージです。
まとめ：まず Strong Crypto＋再起動、次に PowerShell 移行で安定運用へ
- WSUS（Server 2016/2019）で Update Catalog のインポートが 80131509 になる場合は、SchUseStrongCrypto を有効化して改善することが多い
- サービス再起動よりも OS 再起動が効くケースがある（追加の再起動で直った報告もある）
- 今後の運用安定性を考えると、ActiveX 依存の GUI から、PowerShell スクリプト方式への移行が有効
コメント