WSUS 管理コンソールが予期しないエラーで起動できない：No such host is known（System.Net.Sockets.SocketException）原因と対処法

下流（Downstream）WSUS サーバーで、WSUS 管理コンソールを開いた瞬間に「予期しないエラー」や System.Net.Sockets.SocketException: No such host is known が出てサインインできない場合、原因は MMC に残った接続先情報の破損、DNS の名前解決不良、または IIS/WSUS の初期構成・アプリプール異常に集約されます。ログの読み方から復旧手順まで、現場で再現しやすい順に整理します。

症状の整理：表示されるエラーと「どこで落ちているか」

今回のパターンは、コンソール起動直後に次のようなメッセージが出て MMC が継続できない状態です。

• “The WSUS administration console has encountered an unexpected error…”
• System.Net.Sockets.SocketException: No such host is known
• スタックトレースに System.Net.Dns.GetAddrInfo / GetHostEntry が含まれる

見えている現象	内部で起きやすいこと	最初に疑うポイント
No such host is known（ホストが見つからない）	コンソールが接続しようとしたサーバー名/FQDN を DNS 解決できず例外で停止	MMC の保存接続先、DNS 設定、検索サフィックス、hosts
コンソールは起動するが接続時に落ちる	IIS の WSUS Web サービスが 503/404 で応答、またはアプリプールが即リサイクル	IIS（WSUS Administration / WsusPool）、URL の疎通
昨日まで動いていたのに突然発生	DNS 変更・NIC 追加・IP 変更・VM 複製などで名前解決がずれた／WsusPool がメモリ制限で落ち始めた	最近の変更点、イベントログ（WAS/IIS/WSUS）

仕組みを理解する：WSUS 管理コンソールが最初にやること

WSUS 管理コンソールは MMC のスナップインとして動作し、裏側では「WSUS 管理 API（Update Services Administration）」を使って WSUS サーバーへ接続します。接続先の解決と到達性が取れないと、コンソールはサインイン画面に到達する前に落ちることがあります。

• コンソールは「最後に接続した WSUS サーバー名」などをユーザーごとに保持します（その値が壊れる/古くなると、起動時点で誤ったホストへ向かい名前解決で停止します）。
• WSUS は IIS 上で Web サービスとして提供され、既定では 8530（HTTP）/8531（HTTPS）を使う構成が一般的です（環境によって 80/443 のこともあります）。
• 下流 WSUS（レプリカ/ダウンストリーム）の場合でも、コンソールの初期化で「設定された上流名」や「ローカル WSUS 名」を参照する場面があり、名前解決不良があると例外が露呈しやすくなります。

確認対象	代表的な URL/場所	意味
WSUS Web サービス（API）	http://localhost:8530/ClientWebService/client.asmx（例）	ここが応答しないと管理コンソールは接続できません
SelfUpdate	http://localhost:8530/Selfupdate/（例）	クライアントが自己更新するためのエンドポイント。IIS 構成ずれの早期発見に役立ちます
IIS ログ	C:\inetpub\logs\LogFiles\W3SVC*	503/404/500 などを時刻で追うと「IIS 側で落ちているか」が分かります

復旧までの最短ルート：切り分けはこの順番が効く

「No such host is known」が出ている以上、まずは名前解決の失敗を疑うのが正攻法です。ただし、現場では MMC の保存接続先が壊れているだけで DNS 以前の問題になっていることも多いので、次の順に潰すと復旧が早いです。

手順	狙い	うまくいった時の変化
MMC の接続先情報をリセット	「間違ったホスト名に接続して落ちる」を即排除	コンソールが開き、接続先を選べる/正しいサーバーへ接続できる
DNS/名前解決を確認	GetHostEntry 例外の根を断つ	FQDN/短縮名ともに安定して解決し、疎通も取れる
IIS と WSUS Web サービスの疎通確認	Web サービス不調（503 等）を切り分け	URL にアクセスすると asmx が表示される/エラーが消える
post-install と IIS 構成を点検	インストール直後の未完了・設定ずれを修正	WSUS サービスが安定、イベントログのエラーが減る
WsusPool の Private Memory Limit を見直す	アプリプールの連続リサイクルを止める	コンソール接続が安定し、IIS 503 が収束する

MMC 側の接続先情報をリセットする（最初にやる価値が高い）

エラー文が案内する %APPDATA%\Microsoft\MMC 配下のファイル削除は、場当たり的に見えて実は合理的です。WSUS コンソールは「前回接続したサーバー名」や表示状態をユーザーごとに保存するため、ここが壊れると起動直後から誤った名前解決に突っ込みます。

削除が不安な場合は、まずは削除ではなくリネームで退避してください（戻したい時に復元できます）。

rem 現在のユーザーの MMC 保存フォルダへ移動
cd /d "%APPDATA%\Microsoft\MMC"

rem 退避用フォルダを作成
mkdir backup_wsus_mmc

rem wsus 関連ファイルを退避（環境によりファイル名は異なります）
move wsus* backup_wsus_mmc\

その後、スタートメニューから WSUS 管理コンソールを起動し、接続先に 正しい WSUS サーバー名（可能なら FQDN） を指定します。もし「サーバー名を打った瞬間に落ちる」のであれば、次の DNS 確認へ進みます。

「No such host is known」の本丸：DNS/名前解決を徹底確認する

スタックトレースに Dns.GetAddrInfo / GetHostEntry が出る場合、ほぼ間違いなく「指定した名前が解決できない」か「解決結果が意図と違う」状態です。WSUS では短縮名と FQDN が混在しがちなので、短縮名・FQDN・逆引きまでセットで確認すると事故が減ります。

確認	コマンド例	期待する結果	ダメだった時の対処の方向性
短縮名の名前解決	nslookup wsus01	A レコードが返る	DNS サーバー設定、検索サフィックス、hosts を見直す
FQDN の名前解決	nslookup wsus01.contoso.local	正しい IP が返る	DNS レコード修正、重複登録の整理、IP 変更の反映
PowerShell での確認	Resolve-DnsName wsus01.contoso.local	レコード詳細が取得できる	DNS クライアント/サフィックス/名前解決順序を再確認
疎通（ポート含む）	Test-NetConnection wsus01.contoso.local -Port 8530	TcpTestSucceeded : True	FW、IIS バインド、プロキシ、NW 分離を確認
逆引き（任意だが有効）	nslookup <WSUSのIP>	想定のホスト名へ戻る	PTR 未整備は直す。証明書/監査/一部機能で副作用を減らせます

特にハマりやすい DNS/名前解決の落とし穴

• 検索サフィックスが無い：短縮名で接続したつもりが、意図しない DNS サフィックスで引かれて失敗します。ipconfig /all の「DNS サフィックス」や「接続固有の DNS サフィックス」を確認してください。
• NIC が複数/仮想 NIC の追加：優先 DNS が意図しない NIC 側を参照し、社内 DNS ではなく別系統に問い合わせて NXDOMAIN になることがあります。
• VM の複製・スナップショット復元：IP と DNS 登録がズレたまま残り、別マシンの A レコードを参照してしまうことがあります。
• hosts に古い記述が残っている：短縮名だけ hosts で固定され、FQDN と整合しないケースがあります（特にテスト中に手動追加した環境）。
• プロキシ名の解決不良：WSUS がプロキシ利用の構成で、プロキシの FQDN が解決できないと同期や一部処理が不安定になります。

DNS 設定を直した後は、名前解決キャッシュの影響を切るために次も実施してから再テストすると判断が早くなります。

ipconfig /flushdns
ipconfig /registerdns

IIS と WSUS Web サービスが動いているかを「URL で」確認する

DNS が正しくても、IIS 側で WSUS の Web サービスが応答できていないとコンソール接続は失敗します。コンソールが落ちる場合でも、ブラウザでローカル確認できるため切り分けに強いです。

確認 URL（例）	正常時の目安	異常時によくある原因
http://localhost:8530/ClientWebService/client.asmx	Web サービスのページが表示される	WsusPool 停止、IIS サイト停止、バインド/ポート競合、証明書設定ミス
http://localhost:8530/SimpleAuthWebService/SimpleAuth.asmx	asmx が表示される	WSUS Web サービス自体の不調、アプリプールの連続リサイクル
http://localhost:8530/selfupdate/	ディレクトリ一覧やファイル取得ができる（構成により表示は異なる）	SelfUpdate 仮想ディレクトリの欠落、IIS の権限/機能不足

URL が 503 になる場合は、アプリプール停止やメモリ制限リサイクルが疑わしいです。404 の場合は仮想ディレクトリ欠落や IIS 構成ずれ、500 の場合は .NET/権限/アプリの例外などが疑わしいため、IIS ログとイベントログを合わせて見ます。

まず見るログ（コンソールが使えない時ほど重要）

• イベントビューアー：Windows ログ（アプリケーション/システム）に加えて、IIS/WSUS 関連のログに警告・エラーが出ていないか確認します。
• IIS ログ：C:\inetpub\logs\LogFiles 配下。対象 URL にアクセスした時刻のステータス（200/503/404）を追います。
• HTTPERR：%WINDIR%\System32\LogFiles\HTTPERR。カーネル側で弾かれている場合（キュー飽和など）が見えます。
• WSUS ログ：C:\Program Files\Update Services\LogFiles 配下（構成により場所は変わります）。同期失敗や DB 接続失敗の痕跡が出ます。

インストール直後や構築途中なら post-install 未完了を疑う

下流 WSUS を入れたばかり、または役割の追加直後であれば、post-install（後処理）が未完了/失敗のままになっていると、管理 API や仮想ディレクトリが整わずコンソールが不安定になります。IIS の状態が正しくても「WSUS として成立していない」ことがあるため、ここは必ず押さえます。

実行可否やオプションは環境（WID/SQL、コンテンツ格納先）で変わりますが、代表的には wsusutil.exe を使います。コマンドは C:\Program Files\Update Services\Tools にあります。

rem 例：コンテンツ格納先を指定して post-install を実施（例として D:\WSUS を指定）
"C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall CONTENT_DIR=D:\WSUS

post-install 後は WSUS サービスと IIS の再起動で状態を揃えます。

net stop WsusService
net start WsusService
iisreset

なお、IIS のサイト構成が想定とズレている場合（例：WSUS 用サイトが停止、ポートが別用途に使われている、Default Web Site を無効化した影響が出ている等）は、post-install だけでは治らないことがあります。URL チェックで 404/503 が継続する場合は、IIS 側の修正が必要です。

WsusPool の Private Memory Limit が原因で「接続できたりできなかったり」する

WSUS のトラブルで非常に多いのが、IIS のアプリケーションプール WsusPool がメモリ制限に達して頻繁にリサイクルし、管理コンソールが接続の途中で落ちるパターンです。特に更新プログラム数が多い環境、クリーンアップ不足、DB が肥大化した環境で発生しやすく、VM のスペック（例：4CPU/16GB）が十分でも起こり得ます。

設定項目	チェック観点	切り分け時の現実的な設定例
Private Memory Limit（KB）	制限到達でリサイクル→接続断の原因	0（無制限）にして挙動を見る、または十分大きくする
Queue Length	キュー枯渇で 503 が出やすい	既定より増やす（例：2000 など）
Idle Time-out	アイドルで停止→次回接続でタイムアウト	運用に合わせて延長/無効化を検討

「Private Memory Limit が原因か」を確かめるコツは、コンソールを起動して落ちた時刻と、イベントログに出る アプリプールのリサイクル/停止の時刻が一致するかを見ることです。一致するなら、まずは制限を緩めて安定化させ、その後に DB メンテナンスで根治を狙う流れが安全です。

コンソールが死んでいても実施できる WSUS メンテナンス

WSUS はメンテ不足で DB とコンテンツが肥大化し、結果として WsusPool のメモリ消費増大や応答遅延を引き起こします。コンソールが開けない状況でも、PowerShell と SQL（WID/SQL Server）でできることから先に進められます。

PowerShell（クリーンアップ）

管理コンソールの「クリーンアップウィザード」と同等の処理は PowerShell でも呼び出せます。実行時間が長くなることがあるため、業務時間外や十分な空き時間で実施してください。

PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command ^
  "Import-Module UpdateServices; ^
   $wsus = Get-WsusServer -Name localhost -PortNumber 8530; ^
   Invoke-WsusServerCleanup -WsusServer $wsus -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -CleanupObsoleteComputers -CleanupExpiredUpdates -DeclineSupersededUpdates"

ポートが 8531（HTTPS）や 80/443 の場合は、-PortNumber を環境に合わせてください。ここでエラーが出る場合は、WSUS サービスや IIS の根本不調（DB 接続不可など）が残っている可能性があります。

DB インデックス最適化（再構築/再編成）

WSUS の応答が遅い・タイムアウトする場合、DB の断片化が影響していることがあります。一般的な「WSUS 用の SQL メンテナンススクリプト（インデックス再編成/統計更新）」を定期実行する運用は、結果としてコンソール不調の予防にもなります。

WID（Windows Internal Database）の場合、接続先が通常の localhost ではなく名前付きパイプになる点に注意してください。

rem WID へ接続してスクリプトを流す例（環境によりパイプ名は異なる場合があります）
sqlcmd -S np:\\.\pipe\MICROSOFT##WID\tsql\query -E -d SUSDB -i C:\Scripts\WsusReindex.sql

SQL Server を使っている場合は、対象インスタンスに合わせて -S を指定します。DB メンテナンス後は、WsusPool の安定度が上がることが多いです。

下流（Downstream）構成なら、上流 WSUS への名前解決も忘れずに

下流 WSUS は上流からメタデータや更新プログラムを同期します。コンソールのエラーが「ローカルの接続」で落ちているように見えても、構成によっては初期化時に上流設定を参照し、そこで名前解決に失敗して例外が露出することがあります。

• 上流 WSUS の FQDN が解決できるか（下流側で nslookup）
• 同期先のポート（8530/8531 など）に到達できるか（Test-NetConnection）
• SSL を使うなら、証明書の CN/SAN とアクセス名が一致しているか（別名で接続すると別のトラブルを呼びます）

再発防止：同じ事故を繰り返さないための運用ポイント

一度復旧しても、WSUS は「静かに劣化して突然コンソールが死ぬ」ことがあります。次の対策は、トラブルの再発率を大きく下げます。

対策	狙い	具体例
接続名を FQDN に統一	検索サフィックス依存を排除	コンソールもクライアントも wsus01.contoso.local で統一
WSUS 用 DNS 名（CNAME）を用意	将来の移設・更改を簡単に	wsus.contoso.local を CNAME で固定し、実体サーバーの変更に耐える
WsusPool の監視	連続リサイクルを早期検知	イベントログや IIS ログで 503 とリサイクルを監視
定期メンテ（クリーンアップ + DB）	肥大化・断片化の抑制	月次でクリーンアップ、四半期で DB 最適化を検討

よくある質問（現場で詰まりやすい点）

Q. %APPDATA%\Microsoft\MMC の wsus 関連ファイルを消すと、WSUS の設定自体が消えますか？
A. 消えるのは「そのユーザーの MMC 表示状態や最後に接続したサーバー情報」です。WSUS サーバー側の設定や更新データベースが消えることはありません。まずはリネーム退避で試すのが安全です。

Q. DNS は引けるのに No such host is known が出ます。
A. よくあるのは「解決できているが別の IP に解決している」「短縮名だけ別ドメインに飛ぶ」「hosts が優先されている」などです。nslookup の結果の IP と、実際のサーバー IP、さらに Test-NetConnection のポート疎通をセットで確認してください。

Q. WsusPool の Private Memory Limit を 0（無制限）にするのは不安です。
A. 切り分けとしては非常に有効です。まず無制限で「落ちる現象が止まるか」を見て原因を確定し、その後に DB メンテナンスや不要更新の整理でメモリ使用量そのものを下げ、最終的に運用ポリシーに合わせた値へ戻すと安全に着地できます。

Q. それでも復旧しない場合、最後に何をすべきですか？
A. URL チェックがすべて失敗し、post-install も通らず、WSUS サービスも安定しない場合は、DB/役割の破損の可能性があります。構成とデータ保持要件を確認した上で、WSUS の役割削除→再インストール（または新サーバーへ再構築）を検討します。下流 WSUS であれば、上流から再同期できるため再構築が現実的なケースも多いです。

「No such host is known」は表面的には DNS のメッセージですが、実務上は MMC の保存接続先 → DNS → IIS/WSUS → WsusPool → メンテナンスの順に潰すと短時間で収束しやすい問題です。まずは “どの名前を解決しようとして落ちているか” を特定し、URL で WSUS Web サービスの生存確認まで一気に進めてください。