Windows Admin CenterでWindows Server 2008 R2に接続できない「WMF 5 not installed」対処法：Storage Migrationの盲点と切り分け

Windows Admin Center（WAC）の Storage Migration で Windows Server 2008 R2 から 2019 へ移行しようとした際、接続時に「WMF 5 not installed」と表示されて先へ進めないことがあります。WMF 5.1 を入れたはずなのに弾かれる場合に、最短で復旧しやすい“盲点”と、再発しにくい切り分け方法を整理します。

発生している現象を整理する

まずは状況を「症状」「実施済み対策」「成立している通信」に分解すると、原因の当たりが付けやすくなります。今回のケースは、いわゆる「2008 R2 側の WMF は入っているのに、WAC が古い状態を見ている（または再判定できていない）」パターンに合致しやすい構図です。

項目	内容（今回の前提）	意味合い
目的	WAC の Storage Migration で 2008 R2 → 2019 にファイルサーバー移行	WAC 側は PowerShell/WinRM 前提で接続判定を行う
症状	WAC から 2008 R2 に接続できず「WMF 5 not installed」と表示	WAC が「PowerShell 5.1 が使えない」と判断している
2008 R2 側の対応	最新パッチ、.NET 4.8、WMF 5.1（KB3191566）導入、WinRM 初期化済み	“導入したつもり”ではなく “実際に 5.1 と判定されるか” が重要
ネットワーク	FW 無効、同一セグメント、ローカル管理者で接続	疎通問題より、認証・権限・サービス状態・キャッシュの疑いが濃い
成立している接続	2019 → 2008 R2 の WMI/CIM は動作	WMI が動いても WAC の WinRM/PowerShell 接続が動くとは限らない

結論として効きやすい対処：WAC 側を再起動する

この症状で最初に試す価値が高いのは、WAC サーバー（ゲートウェイ）自体の再起動です。環境によっては「WAC の再起動だけ」で、WMF 5.1 導入後の状態を正しく再取得できるようになり、接続と転送が進み始めます。

ポイント：2008 R2 側に WMF 5.1 を導入した後、WAC が以前の情報（WMF 未導入時の状態）を掴んだままになり、接続判定が更新されないことがあります。WAC 側を再起動すると、最新状態を取り直して接続できるようになるケースがあります。

「再起動」といってもどこを再起動するべきか

優先度順に、実施候補を並べます。現場でよく効くのは上から順です。

優先	対象	やること	狙い
高	WAC サーバー（ゲートウェイ）	OS 再起動	WAC の接続判定・セッション・状態情報を確実にリセット
中	WAC のゲートウェイサービス	サービス再起動（名称は環境で異なるためサービス一覧で確認）	“サーバー再起動ほど重くなく”接続判定を更新できる場合がある
中	WAC 画面（ブラウザ）	サインアウト→サインイン、キャッシュ影響が疑わしければ強制リロード	UI 側の表示だけ古いケースを除外
低	2008 R2 側	OS 再起動	WMF 導入直後の保留状態（Pending Reboot）を解消する目的

すでに 2008 R2 は再起動済みで、なお「WAC だけが WMF 未導入扱い」をしている場合ほど、WAC 側再起動が刺さりやすい印象です。

なぜ WAC 側の再起動が効くのか

「WMF 5.1 を入れたのに、なぜ管理画面が WMF 未導入と判断するのか？」は、現場で非常に混乱しやすいポイントです。ありがちな要因は大きく次の系統に分かれます。

系統	起きていること	結果として見える症状	再起動で改善しやすい理由
状態情報のキャッシュ	WAC がサーバー情報（PowerShell/WMF 要件）を内部的にキャッシュしている	WMF を入れた後も「未導入」表示が残る	再起動でキャッシュが破棄され、再検出が走る
セッションの使い回し	以前の失敗セッション（または古い条件で作られた接続）を保持している	同じエラーが繰り返される	再起動でセッションが切れ、作り直される
更新直後の判定不整合	2008 R2 側は WMF 導入済みでも、サービス再起動や保留更新で整合が取れていない	PowerShell で見える情報と WAC 表示がズレる	再起動で双方の“読み直し”が揃いやすい

特に Storage Migration は、単にサーバー一覧に追加できるかだけでなく、移行用の情報収集・認証・実行のために複数の判定を内部で行います。2008 R2 のような古い OS では、WMF 更新の影響が “すぐに反映されない” ケースが混ざりやすく、ここが盲点になりがちです。

2008 R2 側で最低限チェックしたいポイント

WAC 再起動で直る可能性が高いとはいえ、根本原因の切り分けのために、2008 R2 側の状態を「事実ベース」で確認しておくと、再発時にも短時間で復旧できます。ここでは、現場での確認頻度が高いものを優先して並べます。

WMF 5.1 が“導入済み”ではなく“有効化されている”か

まずは PowerShell のバージョンが本当に 5.1 になっているかを確認します。

$PSVersionTable
$PSVersionTable.PSVersion

期待する状態の目安は以下です。

確認項目	期待値の目安	期待と違う場合に疑うこと
PSVersionTable.PSVersion	5.1.x	WMF 5.1 が正しく入っていない／保留更新／再起動待ち
PowerShell が起動できるか	エラーなく起動	.NET 依存や更新不整合、モジュール破損

加えて、HotFix の導入状況を確認して「KB が入ったこと」も押さえます。

wmic qfe | find "3191566"
Get-HotFix -Id KB3191566

ここで KB が見えない場合は、そもそも適用に失敗している可能性があります（GUI 上は入っているように見えても、実際の QFE と整合しないケースがゼロではありません）。

適用した WMF 5.1 パッケージが合っているか

2008 R2 は実運用では x64 がほとんどです。WMF 5.1 を複数台に横展開したときに、まれに「別アーキテクチャのものを当てていた」「ファイルサーバーだけ適用対象が違っていた」などが起きます。確信が持てない場合は、“該当サーバー上で PS 5.1 と確認できるか”に立ち返るのが確実です。

保留中の更新と再起動待ちが残っていないか

Windows Update や .NET、WMF のようなコンポーネント更新は、見た目上“インストール済み”でも内部的に「再起動待ち」「ファイル置換待ち」の状態が残っていると、接続判定が不安定になります。以下の観点で確認します。

直近で Windows Update を適用した場合、再起動を済ませたか
.NET 更新直後に PowerShell/WinRM を触っていないか（更新直後は不整合が出やすい）
イベントログ（System）に更新関連の失敗や保留の痕跡がないか

「2008 R2 は再起動済み」のつもりでも、運用上 “更新適用 → すぐ作業” を繰り返すと、どこかで保留が残りやすいので注意が必要です。

WinRM（WSMan）が本当に応答しているか

WAC が見ているのは WMI ではなく、基本的には WinRM/PowerShell Remoting の世界です。以下で WSMan の応答を確認します。

winrm quickconfig
winrm enumerate winrm/config/listener

さらに、WAC 側（WAC サーバー）から 2008 R2 宛てにテストします。

Test-WSMan -ComputerName &lt;2008R2のホスト名またはIP&gt;

ここが通らない場合、WAC が「WMF 未導入」と言っているように見えても、実態は “WSMan 経路で情報取得できない” というケースがあり得ます。逆にここが通っていて PS 5.1 も確認できているなら、WAC 側の状態情報が古い（または WAC 側の条件に引っかかっている）可能性が一段高くなります。

WAC 側で見落としがちな確認ポイント

次に、WAC 側（WAC サーバー／ゲートウェイ）で確認したい事項です。今回の結論にも直結しますが、WAC は「UI の表示」と「内部の接続状態」がズレることがあるため、WAC 側の切り分けが効きます。

WAC を再起動しても直らない場合のチェック

チェック観点	確認内容	対処の方向性
接続情報の持ち方	2008 R2 をいったん WAC から削除し、再登録しても同じか	古い判定情報を引きずる場合は再登録で改善することがある
名前解決	WAC サーバーから 2008 R2 のホスト名解決が安定しているか	IP で登録して挙動比較（DNS/hosts/逆引きの揺れを潰す）
認証の種類	ドメイン参加か、ワークグループか。ローカル管理者での接続か	ワークグループは TrustedHosts や資格情報委任の影響を受けやすい
権限の実態	“ローカル管理者”でも UAC リモート制限でフル権限になっていない可能性	ローカルアカウント運用は追加設定が必要になることがある
拡張機能と依存	Storage Migration 関連の拡張やコンポーネントの状態	拡張更新、WAC の更新、再起動で改善する場合がある
WAC のリソース	WAC サーバーが高負荷（メモリ逼迫、CPU高騰）で状態が不安定	一時的に再起動で復旧、恒久的にはリソース増強や同居サービス見直し

「WMI/CIM は動くのに WAC はダメ」のとき、WAC 側では実際に WSMan 経由で PowerShell を呼び出して要件確認しているため、WMI で問題がなくても別系統で詰まることが珍しくありません。

WMI/CIM は通るのに WAC だけが弾く理由

ここは検索でもよく引っかかる論点なので、整理しておきます。

技術要素	主な用途	通っていても安心できない理由
WMI/CIM	情報取得（サービス状態、OS情報など）	WAC の機能は PowerShell Remoting 前提が多く、WMI 成功＝WAC 成功ではない
WinRM/WSMan	PowerShell Remoting、WAC の管理操作の基盤	リスナー、認証、暗号化、TrustedHosts など、WMI と別の条件がある
PowerShell（WMF）	リモート実行・モジュール実行	WAC が必要とする cmdlet / モジュールが PS 2.0 だと使えない

つまり「2019 → 2008 R2 の WMI が動く」は、ネットワークの基本疎通がある程度成立している証拠にはなりますが、WAC の要件（WMF/WinRM/認証）を満たしている証拠にはなりません。逆に言えば、今回のように WMF を入れても WAC が弾く場合は、WAC が参照している判定経路（WSMan/PS）のどこかで古い状態を見ている、もしくは判定処理自体が失敗して “WMF 未導入” というメッセージに丸め込まれていることがあります。

切り分けを最短で終わらせるコマンド集

「GUI の表示」より「コマンドで事実を固める」ほうが、復旧も再発防止も速くなります。以下は現場で効く組み合わせです。

目的	実行場所	コマンド例	見たいポイント
WMF/PowerShell の実態確認	2008 R2	`$PSVersionTable.PSVersion`	5.1 になっているか
WMF 5.1（KB）の確認	2008 R2	`Get-HotFix -Id KB3191566`	KB が実際に入っているか
WinRM リスナーの確認	2008 R2	`winrm enumerate winrm/config/listener`	HTTP/HTTPS のリスナーが存在するか
WSMan の応答確認	WAC サーバー	`Test-WSMan -ComputerName <2008R2>`	WAC 側から WSMan が応答するか
PowerShell Remoting の疎通	WAC サーバー	`Enter-PSSession -ComputerName <2008R2> -Credential (Get-Credential)`	対話セッションが確立できるか（認証と権限の検証）
WinRM サービス状態	2008 R2	`sc query winrm`	RUNNING かどうか

上のテストがすべて良好（PS 5.1、KB 検出、WSMan 応答、PSSession 接続可能）にもかかわらず WAC だけが「WMF 5 not installed」と言うなら、WAC 側の再起動・再登録・サービス再起動がかなり有力になります。

併せて押さえておくと強い“落とし穴”

今回の事例の主因は「WAC 側の再起動で解消することがある」ですが、同じメッセージに見えても別原因だった、ということもあり得ます。よくある落とし穴を、症状から逆引きできるようにまとめます。

ありがちな状況	実態として起きていること	対処の方向性
WMF を入れたのに PSVersion が 2.0 のまま	WMF の導入が完了していない／前提更新不足／再起動待ちが残っている	PSVersionTable で確認し、更新適用と再起動を完了させる
Test-WSMan が失敗する	WinRM リスナーが無い／WinRM 停止／ネットワークやポートの問題	WinRM の設定とサービス、疎通（ポート）を見直す
Enter-PSSession が資格情報エラーになる	認証方式（Kerberos/NTLM）や TrustedHosts の条件、時刻ずれが影響	ドメインなら Kerberos 前提に寄せる／ワークグループなら TrustedHosts を整理
ローカル管理者なのに操作が弾かれる	UAC のリモート制限により “管理者でも昇格していない状態” になっている	ローカルアカウント運用を見直すか、必要に応じてポリシー・レジストリを検討
WAC 上の表示だけが古い	WAC がノード情報をキャッシュし続けている	WAC 再起動、対象サーバーの再登録で更新させる

特にローカル管理者での運用は、環境差（ドメイン参加の有無、ポリシー、UAC 設定）で挙動が変わりやすい領域です。切り分けの段階では、可能であれば ドメイン管理下のアカウントで同様の接続テストを一度行い、「ローカルアカウント固有の問題かどうか」を早めに見極めると時間を短縮できます。

Storage Migration を安定して進めるための実務ポイント

接続できるようになって転送が動き出した後も、2008 R2 → 2019 の移行では “途中で止まる”“棚卸しが終わらない”“カットオーバーで想定外の差分が出る” といった運用上の罠が出やすいです。接続問題と同時に、移行の成功率を上げるためのポイントも押さえておきます。

移行前の棚卸しで確認すべきこと

観点	確認内容	理由
共有の棚卸し	共有名、パス、コメント、権限（共有/NTFS）、隠し共有の有無	移行後の “見える/見えない” トラブルの大半は権限と共有定義の差分
長いパス	深い階層・長いファイル名が多い領域の有無	コピー工程やアプリ側の互換性でボトルネックになりやすい
常時オープン	常時接続しているクライアントやアプリの有無	カットオーバー時に差分が出やすい（開いたまま書き込み続ける）
ウイルス対策	コピー先でリアルタイムスキャンが極端に遅くならないか	大量ファイル移行でスループットが落ちやすい

移行中に見ると役立つログ・観測ポイント

「止まった」と見えるときでも、実際には待ち状態やリトライ中のことがあります。WAC 画面だけに頼らず、OS 側の観測点を持つと復旧が早くなります。

観測ポイント	見る場所	わかること
イベントログ	2008 R2 / 2019 の Event Viewer（System / Application）	WinRM、認証、サービス失敗、更新不整合の兆候
サービス状態	services.msc、または sc query	WinRM や関連サービスが落ちていないか
ネットワーク	WAC サーバーからの疎通、名前解決	一時的な DNS 揺れや経路変化で切れるケースの検出
リソース	タスクマネージャー、リソースモニター	転送が遅いのか止まっているのか（I/O や CPU が詰まっていないか）

最短で復旧させるためのチェックリスト

最後に、今回の症状（「WMF 5 not installed」）を前提に、現場での“最短ルート”をチェックリスト化します。作業メモとしてそのまま使えるよう、判断基準も添えています。

やること	判断基準	補足
2008 R2 で PSVersionTable を確認する	5.1 である	ここが 5.1 でなければ WAC 側の問題ではない可能性が高い
WAC サーバーから Test-WSMan を実行する	応答が返る	WSMan が死んでいると、WAC の表示が誤誘導になることがある
WAC サーバーを再起動する	接続判定が更新される	WMF 導入後の “盲点”。最初に試す価値が高い
2008 R2 を WAC から削除→再登録する	表示と判定が変わる	キャッシュ/登録情報の引きずりを除外
認証条件を変えて再テストする	ドメイン/ローカルで結果が変わる	ローカルアカウント固有の制限が原因かを切り分け

まとめ

Windows Server 2008 R2 は更新やコンポーネント差分が絡むと、導入したはずの WMF 5.1 が “別の層からはまだ見えない” 状態に陥ることがあります。今回の「WMF 5 not installed」は、2008 R2 側の WMF を疑い続けてハマりやすい一方で、WAC サーバー（ゲートウェイ）側の再起動で接続判定が更新され、あっさり解消するケースがあります。

まずは WAC 側再起動で状況が変わるかを確認し、並行して PSVersionTable と WSMan の疎通で事実を固める。これが、同種トラブルを最短で片付けるための実務的なルートです。

この記事を書いた人

佐藤健司

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