Server Managerのダッシュボードが真っ白になるときは、いきなり再インストールや役割の入れ直しに進むより、まず「現在のユーザーの設定ファイルが壊れていないか」「WinRM/DCOM/権限でデータ取得に失敗していないか」「直前の更新やロール操作が引き金ではないか」を切り分けるのが近道です。Server Manager は管理対象サーバー一覧やコンソール設定をユーザープロファイル配下の Serverlist.xml と user.config に保存し、ダッシュボードのイベント・サービス・パフォーマンス情報はリモート管理やログ取得に依存するため、見た目が同じ“真っ白”でも原因は1つではありません。 (Microsoft Learn)
この記事では、Server Managerのダッシュボードが真っ白になるときに起きやすい条件、優先順位の高い確認ポイント、復旧までの現実的な手順を、公開品質でそのまま使える形に整理します。
Server Managerのダッシュボードが真っ白になるときの切り分け
| 見え方 | 本命になりやすい原因 | 最初の動き |
|---|---|---|
| 起動直後から全面が白い | 現在のユーザーの設定ファイルやプロファイル依存の不整合 | 別の管理者アカウントで再現確認し、設定ファイルを退避 |
| 一部タイルだけ空、リモートサーバーだけおかしい | WinRM/DCOM、ファイアウォール、権限、データ取得設定 | リモート管理設定とイベントログを確認 |
| 特定の役割ページだけ白い | 役割固有の不具合、更新やプロバイダーの影響 | 役割別ログと更新履歴を確認 |
| 情報が古い、止まって見える | 自動更新の仕様、手動更新が必要なページ | F5 と更新間隔を確認 |
この切り分けが効くのは、Server Manager がユーザーごとの設定ファイルを使い、イベント・サービス・パフォーマンスデータを別系統で収集し、さらに更新や役割ごとの不具合の影響も受けるからです。特に File and Storage Services、IPAM、Remote Desktop Services の役割ページは自動更新されないため、「壊れた」のではなく「更新されていないだけ」という誤判定も起きます。 (Microsoft Learn)
原因別に見る「本当に効く」対処
現在のユーザーだけで起きるなら、設定ファイルを最初に疑う
Server Manager は、管理対象サーバー一覧、コンソール設定、カスタムグループを Serverlist.xml と user.config に保存します。つまり、別の管理者アカウントでは正常に開けるのに、普段使いのアカウントだけ真っ白なら、OS 全体よりも現在のユーザープロファイル側を先に疑うほうが合理的です。逆にここを触る前にバックアップを取らないと、保存していたサーバー一覧やカスタムグループを一時的に失います。 (Microsoft Learn)
リモートサーバーだけおかしいなら、WinRM・DCOM・権限を疑う
Server Manager はリモート通信に WinRM と DCOM を使います。しかも、リモート管理の設定画面や Configure-SMRemoting.exe が効くのは WinRM を使う部分が中心で、DCOM を使う部分まで自動で面倒を見てくれるわけではありません。さらに、ビルトインの Administrator 以外のローカル管理者は、リモート管理が有効でも十分な権限を持てない場合があります。実務では「ドメイン管理者なら正常、ローカル管理者だと白い・取得失敗になる」という差分確認がかなり有効です。 (Microsoft Learn)
更新直後や特定ロールだけ白いなら、更新・役割固有の不具合を疑う
Server Manager の不具合は、ユーザー設定だけでなく更新や役割操作で発生することがあります。Microsoft は、Windows Server 2022 で Hyper-V 機能削除後に Server Manager が消える問題を更新で修正した記録を公開していますし、IIS を Server Manager から管理する場面で blank page が出る既知事象も案内しています。直前に Windows Update を入れた、機能を削除した、IIS など特定の役割ページだけが白いという場合は、設定ファイルよりも先に更新履歴と役割固有の問題を確認したほうが早いことがあります。 (Microsoft サポート)
管理端末の Server Manager が古いと、それだけでおかしく見えることがある
見落としやすいのが、古い Server Manager で新しい Windows Server を管理しているパターンです。Microsoft Learn でも、Server Manager は自分より新しい Windows Server を管理できないと案内されています。管理用 PC 側の RSAT や Server Manager が古いままなら、対象サーバー側が正常でも表示や取得でハマります。 (Microsoft Learn)
最短で復旧する手順
まずは F5 と別アカウント確認から始める
Server Manager は、Local Server のプロパティ表示が既定で約2分ごと、コンソール全体の更新間隔が既定で10分です。また、File and Storage Services、IPAM、Remote Desktop Services の役割ページは自動更新されません。つまり、表示が止まっているだけなら F5 か [Refresh] で戻ることがあります。パフォーマンス情報については、そもそも既定でパフォーマンスカウンターがオフのため、そこだけ空でも障害とは限りません。 (Microsoft Learn)
ここでの判断基準
- 別の管理者アカウントでは正常に開く
→ 現在ユーザーの設定ファイル・プロファイル依存を優先して切り分ける - ビルトイン Administrator やドメイン管理者では正常、普段使いのローカル管理者では異常
→ 権限や UAC の影響を疑う - ダッシュボード全体ではなく、特定の役割ページだけ白い
→ 役割固有の問題や更新影響を疑う - パフォーマンス欄だけ空
→ パフォーマンスカウンター未開始の可能性を先に見る
この段階で「どの軸で追うか」を決めるだけでも、無駄な再起動やロール再インストールをかなり減らせます。 (Microsoft Learn)
Server Manager の設定ファイルを退避する
現在のユーザーだけで再現するなら、次の2つを削除ではなく退避して再起動するのが安全です。
- Server Manager を閉じる
%APPDATA%\Microsoft\Windows\ServerManager\Serverlist.xmlをServerlist.xml.bakなどにリネームする%LOCALAPPDATA%\Microsoft_Corporation\ServerManager.exe_StrongName_...配下にあるuser.configをuser.config.bakなどにリネームする- Server Manager を再起動する
- 改善したら、必要に応じて元ファイルを比較し、サーバー一覧やカスタムグループを戻す
この手順は、Server Manager が保存している UI 状態をいったん切り離して再起動する、という考え方です。ロールや機能には手を入れないので影響が小さく、「真っ白」の切り分けとしては最優先に置きやすい方法です。ただし、ここにはサーバー一覧やカスタムグループが入っているため、バックアップなしで進めるのは避けてください。 (Microsoft Learn)
イベントログで失敗箇所を特定する
役割や機能の追加・削除、在庫収集、画面更新に絡む問題は、Event Viewer の Server Manager 系ログを見ると当たりを付けやすくなります。まず見る場所は次のとおりです。
Applications and Services Logs\Microsoft\Windows\ServerManager-MultiMachineApplications and Services Logs\Microsoft\Windows\ServerManager-MgmtProvider\OperationalApplications and Services Logs\Microsoft\Windows\ServerManager-DeploymentProvider\Operational
Microsoft Learn のトラブルシュートでは、役割や機能の問題で ServerManager-MultiMachine の 4000〜4099 を確認するよう案内しています。ダッシュボード自体が真っ白、更新に失敗する、役割ページでだけ落ちる、といった差分に応じて、MultiMachine・MgmtProvider・DeploymentProvider を見分けると切り分けが早くなります。 (Microsoft Learn)
リモート管理とファイアウォールを確認する
WinRM 側の基本確認は、まずこの2行で十分です。
Configure-SMRemoting.exe -get
Configure-SMRemoting.exe -enableこれで改善しない場合は、DCOM 系の通信が止まっていないかを見ます。Microsoft Learn では、少なくとも次の受信規則が有効か確認するよう案内しています。
COM+ Network Access (DCOM-In)Remote Event Log Management (NP-In)Remote Event Log Management (RPC)Remote Event Log Management (RPC-EPMAP)
また、ビルトイン Administrator 以外のローカル管理者は、リモート管理が有効でも十分な権限を持てない場合があります。ここでいきなり LocalAccountTokenFilterPolicy を変更するより、まずはビルトイン Administrator かドメイン管理者で正常表示するかを比べたほうが安全です。運用上どうしても標準ユーザーに閲覧させるなら、Enable-ServerManagerStandardUserRemoting のような正攻法を使うべきです。 (Microsoft Learn)
DISM と SFC で OS 側の破損を除外する
別アカウントでも真っ白、イベントログにも provider や component store 周りの失敗が出るなら、OS 側の破損も除外します。Microsoft は DISM を先に、その後に SFC を実行する順番を案内しています。
DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannowWindows Update 自体が壊れている場合は、DISM に修復ソースを指定する方法もあります。ログは %windir%\Logs\CBS\CBS.log で追えます。Server Manager の表示不具合でも、実際はコンポーネントストア破損が根本だった、というケースは珍しくありません。 (Microsoft サポート)
失敗しやすいポイント
Serverlist.xmlとuser.configをいきなり消して、保存していたサーバー一覧やカスタムグループを失うConfigure-SMRemoting.exe -enableだけで全部直ると思い込み、DCOM 側の受信規則や権限を見落とす- 古い RSAT や古い Server Manager で、新しい Windows Server を管理しようとしてハマる
- パフォーマンスタイルだけ空なのに、ダッシュボード全体の破損だと誤判定する
- 更新直後や役割削除直後なのに、既知の更新影響を見ずにユーザープロファイルだけを疑う
このあたりは、どれも現場で起きやすい“遠回り”です。特に Server Manager は UI の見た目と根本原因が一致しにくいので、「表示」「権限」「更新」「OS破損」を順番に潰すのが正解です。 (Microsoft Learn)
迷ったらこの順番で進めれば外しにくい
- F5 と別アカウント確認
Serverlist.xmlとuser.configを退避- Event Viewer の
ServerManager-MultiMachine、MgmtProvider、DeploymentProviderを確認 Configure-SMRemoting.exe -get/-enableとファイアウォール規則を確認- DISM → SFC の順で OS 破損を除外
- 更新履歴と、管理端末側の Server Manager / RSAT のバージョンを確認
この順番なら、影響の小さいところから順に切り分けられます。ダッシュボードが真っ白でも、最初に見るべきは Server Manager の保存設定と通信経路であって、いきなり大きな復旧作業ではありません。 (Microsoft Learn)
まとめ
Server Managerのダッシュボードが真っ白になる原因は、大きく分けると「現在ユーザーの設定破損」「WinRM/DCOM・権限の問題」「更新や役割固有の不具合」「OS 側の破損」です。最初にやるべきことは、別アカウント確認、設定ファイルの退避、イベントログ確認の3つです。ここまでで原因の軸が見えれば、余計な再インストールや役割の入れ直しを避けたまま、かなりの確率で復旧まで持っていけます。 (Microsoft Learn)
コメント