Policy Analyzerでドライブマッピングが0件？GPPドライブマップが旧ファイルサーバーのまま残る原因とReplaceで解決する手順

ファイルサーバー移行後、ドライブマッピング用のGPOを新サーバー向けに修正したのに、クライアントでは旧サーバーに割り当てられ続ける。さらにPolicy Analyzerで確認しようとすると「0件（結果なし）」になって原因が追えない――この現象はGPP（基本設定）の仕様を知ると一気に整理できます。この記事では、なぜ0件になるのか、なぜ旧割り当てが残るのか、そしてReplaceで確実に切り替える手順をまとめます。

起きている症状を整理する

今回のトラブルは、見た目は別件に見えても、実は「ドライブマッピングがGPP（Group Policy Preferences / グループポリシーの基本設定）で配布されている」ことが共通点です。

• GPOは新ファイルサーバーのUNCパスに修正済みのはずなのに、クライアント側では旧サーバーへドライブが割り当てられる
• gpupdate /force や再起動でも改善しない
• GPOバックアップをPolicy Analyzerに取り込むと、ドライブマップが見つからない／Policy Viewerが0件になる

結論から言うと、Policy Analyzerの「0件」は設定が無いのではなく、解析の守備範囲の問題で起きやすい現象です。そして、旧割り当てが残るのはGPPドライブマップの「操作（Action）」がUpdateのままだと切り替えに失敗するケースがあるためです。

Policy Analyzerで「ドライブマッピングが0件」になる理由

Policy Analyzerはとても便利なツールですが、主戦場は「Administrative Templates（管理用テンプレート）」などのポリシー（いわゆる“レジストリに書き込む設定”）です。一方で、ドライブマップは多くの環境でGPP（基本設定 / Preferences）として配布され、これは同じGPO内でも別の仕組み・別の保存形式で管理されます。

観点	Administrative Templates（ポリシー）	GPP（基本設定 / Preferences）
代表例	パスワードポリシー、Windowsの制限、セキュリティ設定 など	ドライブマップ、ショートカット、プリンター、ファイル配布、レジストリ設定 など
主な保存物	registry.pol、テンプレート設定、セキュリティテンプレート など	GPO配下のPreferencesフォルダーにあるXML
Policy Analyzerの得意分野	比較・差分・棚卸しが得意	項目によっては表示されない／0件になりやすい
今回の結論	Policy Analyzerに出ない＝設定が無い、ではない	ドライブマップは対象外扱いになりやすいので、別の方法で確認する

つまり、GPMC（グループポリシーの管理）で「ユーザーの構成 > 基本設定 > Windows の設定 > ドライブ マップ」で作った設定が、Policy AnalyzerのPolicy Viewerで0件になっても不思議ではありません。見えていないだけで、クライアントには適用され続けます。

GPPドライブマップはどこに入っているのか

GPPの設定は、GPOのバックアップやSYSVOL配下にXMLとして保存されます。代表的には次のような場所にあります（環境により多少異なります）。

• ドメイン側（SYSVOL）例：\\\\<domain>\\SYSVOL\\<domain>\\Policies\\{GUID}\\User\\Preferences\\Drives\\Drives.xml
• GPOバックアップ例：バックアップフォルダー内のUser\\Preferences\\Drives\\Drives.xml

「旧サーバーのUNCがどこかに残っているのでは？」という調査は、Policy AnalyzerよりもこのXMLを直接検索する方が早いことが多いです（後半でPowerShell例を載せます）。

旧ファイルサーバーの割り当てが残る“本命”原因：ActionがUpdateのまま

GPPのドライブマップには、各アイテムに「操作（Action）」があります。ここがUpdate（更新）のままだと、移行時の“旧→新”切り替えで期待通りに置き換わらず、結果として旧サーバーの割り当てが残ることがあります。

Action	挙動のイメージ	移行時の相性	よくある落とし穴
Update（更新）	既存を「更新」する（無ければ作る）	△（残存が起きやすい）	条件や状態によって“更新したつもり”で旧割り当てが残ることがある
Replace（置換）	一度削除して作り直す	◎（切り替えに強い）	ログオンのたびに再作成が走るため、環境によっては再接続の瞬断が気になる場合がある
Create（作成）	無ければ作成、既にあれば何もしない	×（切り替えに不向き）	旧ドライブが残っていると新が作られない／更新されない
Delete（削除）	指定のドライブマップを削除する	◎（掃除役として有効）	ターゲットを誤ると必要なドライブまで消す

移行の文脈では、Updateは「旧設定を上書きしたい」という意図に合いそうに見えます。しかし実際は、クライアント側に残っている接続情報や、アイテム判定の仕様の関係で、上書きされずに残るケースが発生します。ここをReplaceにすると“削除→再作成”になるため、切り替えの成功率が大きく上がります。

最短で解決する手順：ドライブマップのActionをReplaceに変更する

手順はシンプルです。ドライブマッピングを定義しているGPOで、該当するドライブマップ項目のActionをUpdateからReplaceに変更します。

GPMCでの変更手順

1. グループポリシー管理（GPMC）を開く
2. 対象のGPOを編集する
3. 「ユーザーの構成」→「基本設定」→「Windows の設定」→「ドライブ マップ」を開く
4. 該当するドライブマップ項目を右クリックして「プロパティ」
5. 「操作（Action）」を Update（更新） から Replace（置換） に変更
6. 必要に応じて「再接続（Reconnect）」や「ラベル」も見直し、保存

ポイントは「旧サーバーのドライブと同じドライブレターで置換する」ことです。旧環境でX:が旧サーバー、移行後もX:を維持するなら、ReplaceでX:を作り直すのが最も安定します。もし移行に伴いドライブレターも変える場合は、旧レターを消すためのDeleteアイテムを併用すると事故が減ります。

クライアントでの反映確認のコツ

ドライブマップは「ユーザー設定」なので、確認は次の順で進めると手戻りが少なくなります。

確認アクション	狙い	補足
サインアウト → サインイン	ユーザーポリシー/基本設定の再適用を確実に走らせる	可能なら2回繰り返すと状況がはっきりする
gpupdate /force	ポリシー更新を手動で促す	ユーザー側も更新されるが、ログオン処理が絡む設定はサインインが確実
gpresult /h	どのGPOがユーザーに適用されているかを証拠として残す	「適用済みGPO」と「除外されたGPO（理由付き）」を確認
net use	実際のドライブ接続先を確認する	表示されるUNCが旧サーバーのままか/変わったかを見る

Replaceに変更すると、多くの環境ではサインイン直後のタイミングで新サーバーへ切り替わります。gpresultと実際の割り当て先が食い違って見えるケースでも、Replaceで揃うことがよくあります。

それでも旧サーバーのままなら：よく効く切り分けチェック

Replaceにしても切り替わらない場合は、「旧割り当てが別経路で作られている」か「別のGPOが上書きしている」か「クライアント側に残骸がある」ことが多いです。以下を上から順に潰すと、原因に最短で近づけます。

GPPドライブマップの「共通」タブを確認する

Actionだけ直しても反映しないときは、ドライブマップ項目の「共通」タブにあるオプションが効いている可能性があります。移行や切り替えのタイミングでは、ここが原因で“更新されない／消えない”が起きがちです。

オプション	何が起きるか	移行時のおすすめ
一度だけ適用して再適用しない（Apply once and do not reapply）	初回成功後、以後の更新で同じ項目が再実行されなくなる	移行時は基本的にオフ（オンだと旧→新の切り替えが走らないことがある）
この項目が適用されなくなったら削除する（Remove this item when it is no longer applied）	スコープ外（OU移動/グループ変更/フィルタ変更など）になったときに自動で掃除する	旧GPOを外す設計にするならオン推奨（残存マッピング対策に効く）
ログオンしたユーザーのセキュリティ コンテキストで実行する	実行主体がユーザーになり、共有のアクセス制御と整合しやすい	通常はオンで問題になりにくいが、権限設計によってはログにエラーが出るためイベントログで確認

特に「一度だけ適用」は便利そうに見えて、運用変更や移行の場面では最大の落とし穴になりがちです。切り替え用途のドライブマップ項目では、意図がない限りチェックを外しておくのが安全です。

適用されているGPOが想定通りかを確認する

まずは“どのGPOが、どのユーザーに”適用されているかを確定させます。

gpresult /h C:\temp\gpresult.html
start C:\temp\gpresult.html

• 「適用されたグループポリシーオブジェクト」に目的のGPOが入っているか
• 同じドライブレターを扱う別GPOが存在しないか
• 除外されている場合、セキュリティフィルタ/リンク/OU/ループバックなど理由が説明されているか

同じドライブレターを配っているGPOが複数ないか

ドライブマップは「同じレター」に対して複数の指示が来ると、リンク順や適用順、Item-level targetingの条件次第で結果がぶれます。

ありがちな状態	起きること	対策
旧サーバー向けGPOが別OUにも残っている	ユーザーの所属OU/グループで旧GPOが生き残り、旧割り当てが復活する	旧GPOを無効化/リンク解除するか、Deleteで掃除してから切り替える
部門別GPOと全社GPOで同じレターを使っている	ログオンのたびに結果が変わる/端末やユーザーで差が出る	レターの責任範囲を整理し、重複をなくす
Item-level targetingで旧サーバー向け条件が残っている	特定ユーザーだけ旧サーバーへ戻る	ターゲット条件（グループ、OU、IP、端末名など）を見直す

ログオンスクリプトや手動割り当てが混ざっていないか

GPPが原因だと思っていても、実はログオンスクリプト（BAT/VBS/PowerShell）や古い運用手順でnet useしているケースがあります。次の観点で棚卸ししてください。

• ユーザーの「ログオン スクリプト」がAD属性（profileタブ等）に設定されていないか
• 別のGPOでスクリプト配布が動いていないか
• 端末に常駐する社内ツールがマッピングを行っていないか

クライアントに残った永続マッピングを消してから再適用する

旧サーバーへの接続が“永続”として残っていると、見た目上GPOを変えても旧マッピングが居座ることがあります。切り分けとしては一度消してしまうのが確実です（業務影響が出ない時間帯で実施してください）。

net use
net use X: /delete /y

上記で消えない場合、ユーザープロファイル側の情報が残っていることがあります。代表例として、次のレジストリ配下にドライブレターのキーが残ります。

HKEY_CURRENT_USER\Network\X

レジストリ操作は誤るとユーザー環境に影響するため、基本はGPPのReplace/必要ならDeleteで制御し、どうしても残骸が消えない端末だけを個別対応する、という順序がおすすめです。

イベントログで「GPPドライブマップが動いているか」を見る

適用の成否を最短で判断するには、イベントログが役立ちます。クライアントで次を確認してください。

• イベント ビューアー → 「アプリケーションとサービス ログ」 → 「Microsoft」 → 「Windows」 → 「GroupPolicy」 → 「Operational」

ここにエラーや警告が出ていれば、到達できないUNC、権限不足、名前解決失敗などが見つかります。ファイルサーバー移行直後はDNSやSPN、共有/NTFS権限のズレが原因で「新サーバーに繋がらない→結果として旧が残る」ように見えることもあります。

Policy Analyzerの代わりに使える「旧サーバー名の残存チェック」

Policy AnalyzerでGPPが追えないなら、発想を切り替えて「GPOバックアップやSYSVOLのXMLを全文検索」するのが実務的です。特に、旧サーバー名が複数のGPOに散っているケースでは効果が高いです。

PowerShellでGPP XMLから旧サーバー名を検索する

管理端末からSYSVOLを検索できる権限がある前提で、次のようなコマンドで“旧サーバー名を含むXML”を洗い出せます。環境に合わせてドメイン名や文字列を置き換えてください。

$domain = "example.local"
$old = "\\OLD-FS01"
$root = "\\$domain\SYSVOL\$domain\Policies"

Get-ChildItem -Path $root -Recurse -Filter *.xml -ErrorAction SilentlyContinue |
Select-String -Pattern [regex]::Escape($old) |
Select-Object Path, LineNumber, Line

結果にPreferences\Drives\Drives.xmlが出てくれば、まさにドライブマッピングが旧サーバーを指している証拠です。ドライブ以外（ショートカット、ファイル配布、環境変数など）に旧UNCが残っていることもあるので、移行時は“ドライブだけ直したつもり”を防ぐ目的でも有効です。

移行時におすすめの運用：Replaceで切り替え、落ち着いたら設計を固める

Replaceは移行の切り替えに強い一方、運用フェーズでは「毎回作り直すのは避けたい」という考え方もあります。そこで、次のように段階を分けると、トラブルが減りやすいです。

フェーズ	推奨Action	狙い	メモ
切り替え期間（旧→新）	Replace（＋必要ならDelete）	旧割り当ての残存を許さず確実に新へ	短期的に確実性を優先
安定運用	Update（またはCreate）	無用な再作成を減らし、ログオン負荷を抑える	環境によりReplace継続でも問題ない場合もある
撤去	Delete	不要になったレター/共有を掃除	Item-level targetingで対象を絞ると安全

「Replaceで直ったから終わり」でも良いのですが、移行が終わったら“次の移行を楽にする設計”も合わせて見直すと、将来の工数が大きく下がります。

次回の移行を楽にする設計ポイント

サーバー名直書きを減らす（DFS名前空間の活用）

ドライブマッピングのパスに\\FS01\Shareのようにサーバー名を直書きすると、移行のたびにGPO・スクリプト・ショートカットの全面改修になります。可能ならDFS名前空間（例：\\example.local\DFS\Share）に寄せると、切り替えをDFS側で吸収でき、GPOを触る回数が減ります。

「適用対象」を明確にし、重複をなくす

ドライブレターは資産です。全社共通、部門別、プロジェクト別などの責任範囲が曖昧だと、移行時に競合が起きやすくなります。

• ドライブレターの用途と担当（どのGPOが配布するか）を表で管理する
• GPOを「共有単位」ではなく「利用者単位」で設計し、重複を避ける
• Item-level targetingは強力だが、条件が増えるほど“誰に効いているか”が追いにくくなるため、最小限にする

まとめ

Policy Analyzerでドライブマッピングが0件になるのは、設定が消えているのではなく、GPP（基本設定）のドライブマップが解析対象外になりやすいことが主因です。そして、ファイルサーバー移行後も旧サーバーに割り当てられる問題は、GPPドライブマップのActionがUpdateのままだと切り替えに失敗し、旧マッピングが残るケースがあることが多いです。

最短の解決は、該当ドライブマップのActionをReplaceに変更して“削除→再作成”で確実に切り替えること。加えて、gpresult・net use・イベントログ・SYSVOLのXML検索を組み合わせれば、競合GPOや旧UNCの残存も一気に見えるようになります。