MDTサーバー移行手順：Windows Server 2012 R2から2022へ（WSMT・WDS・DeploymentShare完全移行ガイド）

Windows Server 2012 R2 Standard 上で稼働している MDT（Microsoft Deployment Toolkit）サーバーを、Windows Server 2022 Standard へ「機能を失わずに」移行するための実務手順をまとめます。WSMT（Windows Server Migration Tools）で引き継げる範囲と、DeploymentShare や WDS（PXE/RemoteInstall）を確実に移すための作業順・確認ポイントを、手順書として具体的に解説します。

結論：WSMTで“OS側”を引き継ぎ、MDT固有の“資産”はコピー＋再生成で仕上げる

MDTサーバー移行で重要なのは、「Windowsのロール/設定」と「MDTが持つコンテンツ（DeploymentShare等）」を分けて扱うことです。WSMTはロール/機能やOS設定、データ/共有の移行に有効ですが、MDTのDeploymentShare内コンテンツや運用上のクセ（パス参照・WDS連携・ブートイメージ差し替え）は、結局のところファイルコピーと再設定が必要になります。したがって、方針としてはWSMT＝OS側の引っ越し補助、DeploymentShare/RemoteInstall＝バックアップ＆コピーで確実に移す、最後にブートイメージ再生成とPXE動作確認が王道です。

移行対象	具体例	推奨手段	失敗しやすいポイント
Windowsのロール/機能・設定	DHCP、ファイル共有設定、OS設定（IPConfig等）	WSMT（Export/Import）＋必要に応じてロール個別手順	移行できない/推奨されないロールを無理にまとめて移そうとして詰まる
MDTのDeploymentShare	Task Sequence、アプリ/ドライバ、Scripts、Control、Boot 等	Robocopy等でコピー（ACL含める）→ MDTで“開く” → Update Deployment Share	サーバー名変更で WinPE が DeployRoot に接続できず停止
WDSのRemoteInstall	Boot/Installイメージ、PXE設定、RemInstフォルダ	WDSロール導入→ initialize-server で RemInst 指定 → RemoteInstall をコピー	旧サーバーと新サーバーが同時にPXE応答して混乱（切替順が重要）
MDT DB（利用している場合）	SQL Express/SQL Server上のMDTデータベース	SQLのバックアップ/復元＋接続文字列再設定	DBだけ移しても Rules/CustomSettings の参照が旧サーバーのまま

移行方式の選択：サーバー名/IPを変えるか、引き継ぐか

MDT移行でトラブルの多くは、「WinPE（LiteTouch）からDeploymentShareへ接続するUNCパス」が原因です。Bootstrap.ini の DeployRoot が \\旧サーバー名\DeploymentShare$ を指している場合、新サーバー名に変えるとブート後すぐに接続失敗します。したがって、切替方式は先に決めておくと作業が劇的に楽になります。

方式	メリット	デメリット	おすすめのケース
新サーバーを別名/IPで構築して切替	段階的に検証できる。ロールバックもしやすい。	DeployRoot等の参照先を更新してブートイメージ再生成が必須。	停止時間を短くしたい／検証環境で事前テストしたい
最終的に旧サーバー名/IPを新へ引継ぐ	DeployRootや運用手順の修正が最小化できる。	切替当日の操作がシビア（DNS/名前/IPの切替が絡む）。	参照箇所が多すぎる／現場で設定変更が難しい
DNSエイリアス（CNAME）やDFSで抽象化して引継ぐ	今後のサーバー更新が楽（“MDT用の名前”を固定できる）。	既存設定に手を入れる必要あり（ただし一度やれば強い）。	MDTを長期運用し、今後も入替が見込まれる

移行前チェックリスト（この確認で事故を減らす）

確認項目	確認方法	要注意の例	対処の方向性
Bootstrap.ini の DeployRoot	DeploymentShare\Control\Bootstrap.ini を確認	旧サーバー名を直書き	新サーバー名に変更 or エイリアス名に統一して再生成
CustomSettings.ini の参照	DeploymentShare\Control\CustomSettings.ini	SLShare/LogsShare が旧サーバー	共有先を新へ修正、または同名共有を新に作る
UEFI/BIOS の混在	対象端末の起動方式を確認	UEFIのみでPXEしたいのにBIOS向け設定	WDSのブートプログラム/アーキテクチャ整理
DHCPとPXE応答経路	DHCPが別サーバーか、IP Helperか等	旧WDSへ向く設定が残る	切替日にDHCP/ルータ設定を更新、二重応答を避ける
DeploymentShare のACL/共有権限	NTFSと共有権限を両方確認	コピーでACLが欠落	RobocopyでACL含めコピー＋共有権限再設定

手順1：旧サーバー側でバックアップ（実データの保全）を取る

WSMTを使う/使わないに関わらず、MDT移行は「ファイル資産が命」です。最低でも以下はバックアップ（コピー）しておくと、万一のときに復旧できます。

• DeploymentShare フォルダ一式（例：D:\DeploymentShare）
• WDSの RemoteInstall フォルダ一式（例：D:\RemoteInstall）
• MDT DB を使っている場合はSQLバックアップ
• カスタムスクリプト/追加ツール（独自に置いている場合）

DeploymentShare のコピー例（ACLも維持する）

切替当日までに「事前コピー → 差分コピー」の2段階にすると停止時間を短くできます。Robocopyはログを必ず残し、差分がゼロになるまで追い込みます。

REM 事前コピー（例：旧サーバーの共有から新サーバーのローカルへ）
robocopy \\OLDMDT\DeploymentShare$ D:\DeploymentShare /MIR /COPYALL /DCOPY:DAT /R:2 /W:5 /MT:32 /NP /LOG:C:\Temp\robocopy_DeploymentShare_pre.log

REM 切替直前の差分コピー（最終）
robocopy \\OLDMDT\DeploymentShare$ D:\DeploymentShare /MIR /COPYALL /DCOPY:DAT /R:2 /W:5 /MT:32 /NP /LOG:C:\Temp\robocopy_DeploymentShare_final.log

ポイントは、/COPYALL でACL（所有者/監査含む）も含めてコピーすることです。権限が強めに固定されている現場ほど、ACL欠落が展開失敗の原因になります。

WDS（RemoteInstall）を安全にコピーする

RemoteInstallをコピーする前に、旧サーバーのWDSを止めてファイルの競合/ロックを避けます。WDSは wdsutil で停止できます。

REM 旧サーバーでWDSを停止（管理者CMD）
wdsutil /Stop-Server

現状のWDS設定や登録イメージを記録しておきたい場合は、wdsutil /Get-Server /Show:All /detailed で情報を取得できます（テキストにリダイレクトして保管しておくと後で比較できます）。

REM 旧サーバーのWDS情報を取得して保存
wdsutil /Get-Server /Show:All /detailed > C:\Temp\wds_server_dump.txt

その後、RemoteInstallを新サーバーへコピーします（DeploymentShareと同様に事前コピー＋差分コピー推奨）。

robocopy \\OLDMDT\RemoteInstall$ D:\RemoteInstall /MIR /COPYALL /DCOPY:DAT /R:2 /W:5 /MT:32 /NP /LOG:C:\Temp\robocopy_RemoteInstall_pre.log

手順2：新サーバー（Windows Server 2022）の土台を作る

新サーバー側は、まずOSの最新更新を適用し、ドメイン参加、時刻同期、ウイルス対策/除外設定（BootフォルダやWIM生成が遅くならない範囲で）を整えます。MDTは「動けば良い」ではなく、更新・WIM生成・ネットワーク配布が安定して回ることが重要です。

MDTに必要なものをインストール

• Microsoft Deployment Toolkit（MDT）
• Windows ADK（導入するOSに合わせたもの）＋ WinPEアドオン（必要な構成の場合）
• WDSを使う場合：Windows Deployment Services（WDS）ロール

MDTのブートイメージ（LiteTouchPE）は、DeploymentShareの更新（Update Deployment Share）で生成されます。PowerShellで実行する場合も、同じ更新処理がブートイメージ作成に相当します。

手順3：WSMT（Windows Server Migration Tools）の準備と展開

WSMTは、ロール/機能/OS設定/データ/共有を新しいWindows Serverへ移行するための仕組みで、Windows Serverに組み込まれています。移行対象がMDT単体でも、サーバーが他ロール（DHCP、IIS、ファイルサーバー設定など）を兼務している場合はWSMTが効きます。

新サーバー（移行先）でWSMTをインストール

# 管理者 PowerShell（新サーバー）
Install-WindowsFeature Migration -IncludeManagementTools

WSMTはWindowsの機能としてインストールできます。

SmigDeploy.exeで“旧サーバー用”の移行ツールを作る

WSMTは、移行元が古いOSの場合、移行先サーバー上で SmigDeploy.exe により「移行元で実行するための展開フォルダ」を作り、それを移行元へコピーして登録します。手順の要点は次の2つです。

• 展開フォルダはネットワークパスにも出力できる
• ただし移行元での登録/実行はネットワーク上からできないため、移行元のローカルへコピーしてから実行する

REM 新サーバー（2022）側：展開フォルダを作成（例）
cd %Windir%\System32\ServerMigrationTools\

REM /os は移行元OSに合わせる（例：2012R2ならWS12R2）
SmigDeploy.exe /package /architecture amd64 /os WS12R2 /path \\NEWMDT\Share\WSMT

/os WS12R2 のような指定は、移行元がWindows Server 2012 R2の場合の指定例としてMicrosoftのQ&Aでも使われています。

旧サーバー（2012 R2）で SmigDeploy.exe を実行してコマンドレットを登録

新サーバーで作った展開フォルダ（例：SMT_WS12R2_amd64）を、旧サーバーのローカル（例：C:\WSMT）へコピーし、そこで SmigDeploy.exe を実行します。ネットワーク上からは登録/実行できない点が重要です。

REM 旧サーバー（2012R2）側：ローカルにコピーしたフォルダで実行
cd C:\WSMT\SMT_WS12R2_amd64
.\SmigDeploy.exe

手順4：WSMTでロール/設定をエクスポート → インポートする（必要な分だけ）

WSMTの基本は、旧サーバーで移行ストア（migration store）を作ってエクスポートし、新サーバーでインポートして適用する流れです。エクスポートには暗号化パスワードが必須で、インポート時も同じパスワードで復号します。

旧サーバー：移行ストアの作成とエクスポート

# 旧サーバー（2012R2）: 管理者PowerShell
$store = "C:\Temp\SmigStore"
New-Item -ItemType Directory -Path $store -Force | Out-Null

# 例1: DHCPを移行する場合（ロールがある環境のみ）

Export-SmigServerSetting -Feature "DHCP" -User All -Group -Path $store -Verbose

# 例2: IP構成を移行したい場合

Export-SmigServerSetting -IPConfig -Path $store -Password (Read-Host "Create a Password:" -AsSecureString) -Verbose

# 例3: 移行可能なWindows機能をまとめて取得してエクスポート

$c = Get-SmigServerFeature
Export-SmigServerSetting -Feature $c -Path $store -Verbose

上の例は、WSMTのコマンドレット例としてMicrosoft Learnにも掲載されているパターンです。環境によっては「DHCPは無い」「IPは固定で移し替える」などあるため、必要な項目だけを選んで実施してください。

新サーバー：インポートして適用

# 新サーバー（2022）: 管理者PowerShell
$store = "C:\Temp\SmigStore"   # 旧サーバーからコピーしてきた移行ストア

# 例: DHCPをインポート（該当環境のみ）

Import-SmigServerSetting -Feature "DHCP" -User All -Group -Path $store -Verbose

# 例: IPConfigをインポート（NICの割当が変わる場合はMACアドレスのマッピングも検討）

# Import-SmigServerSetting -IPConfig All -SourcePhysicalAddress "xx-xx-xx-xx-xx-xx" -TargetPhysicalAddress "yy-yy-yy-yy-yy-yy" -Path $store -Password (Read-Host "Enter a Password:" -AsSecureString) -Verbose

Importは「適用順が保証されない」ため、順序依存の設定は分割して複数回実行する考え方が安全です。また、機能のインストールを伴う場合、再起動後に -Force を付けて再実行が必要になるケースがあります。

手順5：DeploymentShareを新サーバーで“開く”→ ブートイメージを再生成する

ここからがMDT移行の本番です。WSMTがどうであれ、MDTの価値はDeploymentShare内の資産（Task Sequence、アプリ、ドライバ、Rules、スクリプト）にあります。MicrosoftのQ&Aでも、MDT/WDS移行は「新サーバーにWDS/MDTを入れて、Reminst と DeploymentShare をコピーする」流れが相談されています。

DeploymentShareの共有（Share）を作る

新サーバーに D:\DeploymentShare のようなパスでフォルダを用意し、共有名（例：DeploymentShare$）を旧サーバーに合わせます。旧サーバー名を変えられない事情がある場合ほど、共有名まで合わせると移行後の修正が減ります。

MDT WorkbenchでDeploymentShareを開く

新サーバーにMDTをインストール後、Deployment Workbench を起動し、Deployment Shares から「既存のDeploymentShareフォルダを開く（Open）」形で接続します。ここでTask Sequence等が見えれば、資産の大枠は移っています。

Update Deployment Share（最重要）

DeploymentShareの更新は、Windows PE ブートイメージ（WIM/ISO）を作り直す工程です。サーバー名変更、ADK更新、ドライバ変更などの影響を吸収するためにも、移行後は必ず実行します。GUIでもPowerShellでも構いません。

# MDT PowerShell（スナップイン/Providerが使える状態）で実行する例
Restore-MDTPersistentDrive -Verbose
Get-PSDrive -PSProvider Microsoft.BDD.PSSnapIn\MDTProvider

# DS001: は環境により異なる（Get-PSDriveの結果に合わせる）
Update-MDTDeploymentShare -Path "DS001:" -Force

Update-MDTDeploymentShare は、MDTのPowerShellコマンドレットとして提供されており、DeploymentShare更新（WinPEブートイメージ生成）に相当します。

手順6：WDS（PXE）を新サーバーで再構成し、RemoteInstallを引き継ぐ

WDSを使ってPXE展開している場合、WDSロールを新サーバーへ入れて初期化し、RemoteInstall（RemInst）を正しく参照させる必要があります。WDSの初期化は wdsutil /Initialize-Server で行い、/remInst でRemoteInstallフォルダのパスを指定します（ローカルパス指定が推奨）。

REM 新サーバー（2022）でWDSを初期化
wdsutil /Initialize-Server /remInst:D:\RemoteInstall

DHCPのRogue Detectionを有効にしている環境では、PXEサーバーの承認が必要になる場合があり、そのときは /Authorize を付ける選択肢があります（必要な場合のみ）。

二重PXE応答を避ける（切替の鉄則）

切替当日は、旧サーバーと新サーバーが同時にPXE応答しないようにします。旧側を wdsutil /Stop-Server で止めてから、新側を開始する運用が安全です。

RemoteInstallのコピー順

現場で事故が少ないのは、次の順です。

1. 旧サーバーのWDS停止
2. 新サーバーへRemoteInstallをコピー（事前コピー済なら差分のみ）
3. 新サーバーでWDSを初期化（remInst指定）
4. WDSコンソールでブートイメージ/インストールイメージを確認

また、WDSの初期化状態をやり直したい場合、wdsutil /Uninitialize-Server はサーバー状態を未構成に戻しますが、RemoteInstall共有フォルダの中身自体は変更しない、と明記されています。フォルダ中身を保全したまま“初期化し直す”用途で使える点は覚えておくと便利です。

切替当日の手順（ダウンタイム最小の実務フロー）

フェーズ	作業	ポイント
事前（数日前〜前日）	DeploymentShare/RemoteInstallの事前コピー、MDT/ADK/WDSの導入、Update Deployment Shareの試運転	この段階で“ブートできるか”まで検証しておくと切替が楽
切替直前	旧サーバーの変更凍結、最終差分Robocopy	ログを見て差分がほぼゼロであることを確認
切替	旧WDS停止 → 新WDS初期化/起動 → DHCP/IP Helper/ルータ設定を新へ向ける（環境依存）	二重応答だけは避ける
切替後	テスト端末でPXE→LiteTouch→展開完走、ログ確認、監視/バックアップ設定	UEFI端末/BIOS端末の両方で試すと安心

移行後の確認（ここまでやって“移行完了”）

確認項目	確認方法	OKの目安
Deployment Workbench起動	WorkbenchでDeploymentShareを開く	Task Sequence/Applications/Driversが参照できる
DeploymentShareの更新	Update Deployment Share（GUI/PowerShell）	Bootフォルダに新しいLiteTouchPEが生成される
WinPEがDeployRootへ接続	PXE→LiteTouch起動後の挙動	資格情報入力/自動ログイン後にウィザードが進む
WDSの起動と応答	PXEブート、WDSコンソールで状態確認	対象のブートイメージが表示され起動できる
展開テスト	代表的なTask Sequenceを1台で完走	ドライバ/アプリ/ドメイン参加まで成功

よくあるトラブルと対処（現場で刺さりがちなもの）

WinPEがDeploymentShareに繋がらない

• 原因候補：Bootstrap.ini の DeployRoot が旧サーバー名、または共有名が違う
• 対処：Bootstrap.ini/CustomSettings.ini を新環境に合わせて修正し、Update Deployment Shareでブートイメージを再生成（WDS側のブートイメージも差し替え）

PXEの応答が不安定/意図しないサーバーが応答する

• 原因候補：旧WDSと新WDSが同時に稼働、またはDHCP/ルータ側の転送設定が旧を向いている
• 対処：旧WDSを wdsutil /Stop-Server で停止し、新側だけにする。必要に応じてWDS初期化/再初期化を整理

WSMTインポートが途中で止まる/再起動が必要と言われる

• 原因候補：機能インストールを伴うため再起動が必要、または適用順序の問題
• 対処：再起動後に -Force 付きで再実行。順序依存の設定は分割して複数回インポート

移行を“次も楽にする”ためのオリジナル運用改善ポイント

• DeployRootを“サーバー名直書き”から卒業する：DNSエイリアス（例：\\MDTDeploy\DeploymentShare$）やDFS名前空間を使い、将来のリプレース時もBootイメージ修正を最小化します。
• DeploymentShare/RemoteInstallは別ボリュームに分離：バックアップ/復元、ストレージ拡張、切替の柔軟性が上がります。
• Robocopyの“事前コピー＋差分コピー”を標準手順化：毎回同じ手順で短時間切替ができます（ログが証跡にもなります）。
• テスト端末を2種類用意：UEFI端末とBIOS端末（または仮想BIOS）で一度ずつ完走テストすると、切替後の問い合わせが減ります。

MDTサーバー移行は、WSMTを上手く使いながらも「最後はDeploymentShareとWDSの整合性を手で合わせる」作業です。逆に言えば、ここまでの手順どおりに“コピー→開く→更新→PXE確認”を踏めば、Windows Server 2012 R2 から Windows Server 2022 への移行でも、Task Sequenceやカスタム運用を失わずに引き継げます。