ADMTで旧ドメインから新ドメインへ移行する手順｜唯一のDC兼ファイルサーバーを安全に分離する方法

ADMTでドメイン移行を進めたいのに、旧ドメインにDCが1台しかなく、そのDCが共有フォルダーのファイルサーバーも兼務している――この構成は移行でつまずきやすい代表例です。この記事では「DCをADMTで移行できるのか？」から、安全に切り替える現実的な手順までを具体的に解説します。

状況整理：domain1.comに「唯一のDC兼ファイルサーバー」があると何が難しいのか

domain1.com（旧ドメイン）から domain2.com（新ドメイン）へユーザー・コンピューター・サーバーを移行する場合、通常はADMT（Active Directory Migration Tool）とSecurity Translation（セキュリティ変換）を組み合わせ、段階的に切り替えます。

ところが、旧ドメイン側が「DCが1台しかない」うえに、そのDCがファイルサーバー（共有）も兼務していると、移行のボトルネックが一気に増えます。

論点	なぜ問題になるか	よくある失敗
DCを別ドメインへ「移す」	DCは別ドメインへ参加できない（メンバーサーバーではない）	無理に手順を進めて認証基盤が崩れる
唯一のDCを降格	降格すると旧ドメイン自体を維持できなくなる可能性が高い	ログオン不可／DNS崩壊／業務停止
ファイル共有の権限	ACLに旧ドメインSIDが大量に残る（切替でアクセス不能になりやすい）	移行後に「共有が全部開けない」
切替タイミング	AD移行とデータ移行の順序が絡み、戻しにくい	週末切替で想定外が出て復旧できない

結論から言うと、「DC移行」と「ファイル移行」は分けて考えるのが、安全かつ成功率が高い進め方です。

結論：DC（AD DS役割あり）のままADMTでコンピューター移行＋セキュリティ変換はしない

ADMTのコンピューター移行は、基本的にクライアントPCやメンバーサーバーを対象とします。ドメインコントローラー（AD DSを持つサーバー）を「DCのまま」別ドメインへ移行する対象にはしません。

DCを別ドメインへ移すという発想自体は、最終的には次の流れに近い形になります。

• 旧DCからAD DSを削除（降格）し、DCではなくす
• メンバーサーバーとしてターゲットドメイン（domain2.com）へ参加させる
• 必要ならターゲット側でAD DSを再インストール（昇格）する

しかし、旧ドメインにDCが1台しかない状態で降格すると、旧ドメインの認証・DNS・グループポリシー配布などが一気に崩れるリスクが高く、移行途中の運用が成立しません。したがって、実務上のベストは「旧DC兼ファイルサーバーを丸ごと別ドメインへ移す」のではなく、役割を分離して新環境へ段階移行することです。

おすすめの考え方：役割分離（DCとファイルを分ける）で事故を避ける

この構成で現実的にうまくいく手順は、ざっくり言うと次の2本立てです。

やること	狙い	ポイント
新ドメイン側に新しいDC群を構築	domain2.comの認証基盤を先に完成させる	切替前に“新ドメインだけで動ける状態”を作る
ファイル共有は新しいファイルサーバーへ移す	「DC兼務」の爆弾を先に外す	データ移行と権限移行を段階化できる

特に重要なのは、ファイルサービスを先に逃がすことです。旧DCを触らざるを得ない範囲が減り、AD移行の失敗が即業務停止につながる確率が下がります。

全体像：安全寄りの移行シナリオ（推奨）

フェーズ別の全体手順

フェーズ	主作業	ゴール	落とし穴	対策
準備	バックアップ、名前解決、信頼関係、移行設計	移行が「戻せる」状態	バックアウト手順が曖昧	切替単位（部署/OU）で戻し方を決める
新ドメイン構築	domain2.comにDC、DNS、OU設計、GPO準備	新側単体で認証運用可能	OU/GPOの移植漏れ	GPMCでバックアップ/移行表（置換表）を活用
ADMT移行	グループ→ユーザー→コンピューターの順に移行	新ドメインでログオン可能	権限が旧SIDのままでアクセス不可	SIDHistoryとSecurity Translationを計画的に使う
ファイル移行	新ファイルサーバーへデータ複製、権限調整	共有の実体が新サーバーへ	共有権限（Share ACL）だけ欠落	共有設定の移行方式を事前に決める
切替	UNC/ドライブマップ/DFS/ログオンスクリプトの切替	利用者が新環境へ自然移行	一部端末だけ古い参照先	DNS/DFS/ログオンスクリプトで吸収
撤去	旧ドメインの整理、旧DC降格/廃止	domain1.comを安全に退役	残骸（サービス/タスク/アプリ）が旧ドメイン依存	段階撤去と棚卸しを徹底

ADMTで移行できるもの・できないものを先に整理する

移行で混乱しやすいのは「ADMTで何でも移せる」と思い込むことです。まずは対象物を仕分けします。

対象	ADMTで移行	補足
ユーザー	可能	パスワード移行が必要ならPES等の仕組みを検討
グループ	可能	順序が重要（先にグループ、次にユーザーが鉄則）
コンピューター（PC/メンバーサーバー）	可能	再起動やプロファイル、ローカルグループ権限に注意
ドメインコントローラー（DC）	対象外	降格→メンバー化→参加→必要に応じて昇格が基本
ファイルデータ（実体）	不可（別手段）	Robocopy/Storage Migration Service/バックアップ復元等
GPO	不可（別手段）	GPMCでバックアップ/復元＋移行表で参照置換が一般的

ADMT移行の順番がすべてを決める（おすすめ順）

フォレスト間移行（domain1.com → domain2.com）が前提のケースでは、信頼関係（Forest Trustなど）を構成し、ADMTで段階移行します。ポイントは順番です。

順番	対象	理由	現場でのコツ
先	グループ（特にアクセス制御に使うもの）	ACLやローカルグループに紐づくため	AGDLPなど運用ルールがあるなら先に新側へ合わせる
次	ユーザー	グループへの所属を新側で再現しやすい	メール/UPN/ログオン名の変更方針を事前決定
次	コンピューター（PC/メンバーサーバー）	ユーザー移行後の方が切替時の混乱が少ない	端末移行は部門単位で波状に行う
最後	権限の最終置換・旧SIDの掃除	切替直後は旧＋新が混在するため	“Addで共存→安定後にReplace/Remove”が事故りにくい

Security Translation（セキュリティ変換）を「何のために使うか」を明確にする

Security Translationは、移行後に困りがちな「アクセス権」を救うための武器ですが、使い方を間違えると混乱を広げます。狙いはシンプルで、旧ドメインのSIDで設定されている権限を、新ドメインのSIDへ追従させることです。

代表的な使い方（実務で多いモードの考え方）

モードの考え方	状態	向いているタイミング	注意点
Add（追加）	ACLに「旧＋新」を共存させる	切替期間（共存期間）	ACLが肥大化しやすいので最終的に整理が必要
Replace（置換）	旧SIDを新SIDに置き換える	新ドメイン運用が安定した後	戻しにくい。適用範囲を絞って段階実施が安全
Remove（削除）	旧SIDをACLから消す	旧ドメイン撤去直前/直後	監査や運用の都合で、削除前に棚卸しが必要

「最初からReplaceで一気に」よりも、Addで滑らかに切替→安定後にReplace/Removeで掃除の方が、利用者影響と復旧難易度のバランスが取りやすいです。

ファイル共有移行の代表的な2択：Robocopyか、移行支援機能か

選択肢A：Robocopyでデータ移行（NTFS権限もコピー）

もっとも手堅いのがRobocopyです。NTFSのアクセス権（ACL）を含めてコピーでき、繰り返し実行（差分同期）もしやすいため、切替当日のダウンタイムを短くできます。

ただし、実務でよく刺さるのが次のポイントです。

• 共有（Share）権限は自動で移らないことが多い（別途作り直しが必要）
• 所有者（Owner）や監査（SACL）まで含めるかは要件次第
• 移行元・移行先でウイルス対策やインデックスが走ると速度が読めない

例として、運用でよく使う考え方のコマンド例です（環境に合わせて調整してください）。

robocopy \\OldFileServer\Share D:\Share /MIR /COPYALL /DCOPY:T /R:2 /W:5 /ZB /NP /LOG:D:\log\share_mig.log

上記のように「ミラーリング＋ACL保持」を基本にしつつ、最初に全量を流して、切替前日に差分を流す、といった二段構えにすると安定します。

選択肢B：移行支援機能で“共有設定ごと”移す（対応環境なら強力）

Windows Serverのバージョンや要件が合うなら、共有名・共有権限・ローカル設定までまとめて移せる仕組み（例：Storage Migration Serviceなど）を使うと、手作業が大きく減ります。

• 共有設定（Share）とNTFS（ACL）の二重管理をまとめて移しやすい
• 切替の「名前/IP引継ぎ」まで含められる構成もある
• ただし、事前検証と要件確認（対応OS/権限/ネットワーク）が必須

どちらを選んでも、最終的には「新ドメインSIDでアクセスできる状態」を作る必要があるため、ADMTのセキュリティ変換（特にAdd）と相性が良いです。

「この案ならOK」とされやすい進め方：新ファイルサーバーを一時的に旧ドメインへ参加させる

旧DC兼ファイルサーバーをいきなり触るのではなく、新しいファイルサーバーを用意して、先にデータと権限の受け皿を作る方法が、現場では最も事故が少ないです。手順は次のイメージです。

手順	やること	意図	効果
準備	新ファイルサーバーを構築し、いったん旧ドメイン(domain1.com)に参加	旧SIDの世界で正しくアクセスできる状態を作る	コピー後の整合性確認がしやすい
移行	旧DC兼ファイル → 新ファイルへRobocopyでデータ移行	データを先に“安全な器”へ逃がす	旧DCへの依存を減らす
共存準備	ADMTのSecurity Translation（Addなど）でACLに新SIDを追記	切替期間のアクセス断を防ぐ	旧＋新の両方で開ける状態に寄せられる
切替	新ファイルサーバーを新ドメイン(domain2.com)へ移行（離脱→参加、またはADMTでコンピューター移行）	ファイルの実体はそのまま、所属ドメインだけ切り替える	利用者の影響を最小化しやすい

この進め方の強みは、「データ移行」と「認証基盤の切替」を分離できることです。旧DCが1台しかない状況でも、ファイル共有の業務停止リスクを先に下げられます。

「単一DC」をどう扱うのが現実的か：移行中に旧ドメインを壊さない

旧ドメインがDC1台しかない場合、もっとも危険なのは「とにかく降格して移そう」とすることです。まずは旧ドメインの寿命（いつまで必要か）を決め、そこまで安全に運用できる設計にします。

現実的な選択肢

選択肢	概要	メリット	デメリット/注意
一時的に旧ドメインにDCを追加	仮想でもよいのでDCを増やし冗長化	旧DCを後で安全に降格できる	追加DCの設計・バックアップが必要
旧DCは当面DCのまま残し、ファイルだけ新へ退避	旧DCは触る範囲を最小化	短期的な事故が減る	旧ドメインを“維持”する運用が残る
旧DCを降格してメンバー化→移行→必要なら再昇格	理論上の手順	「サーバー1台を丸ごと移す」発想に近い	単一DCでは非推奨（旧ドメイン崩壊の危険）

多くのケースでおすすめは、「旧ドメインに一時DC追加」または「旧DCは置いたままファイルを先に退避」です。特に、旧DCがDNSも兼務している場合、降格による影響が連鎖しやすいため注意が必要です。

ファイル共有の切替を楽にする小技：DFS名前空間（可能なら）

利用者が参照しているパスが \\OldServer\Share のようにサーバー名直指定だと、切替当日の変更範囲が膨らみがちです。可能であれば、DFS名前空間を使って、利用者の参照先を \\domain.local\Share のような論理パスに寄せると、サーバー切替の痛みを減らせます。

• クライアントは「DFSのパス」を使い続ける
• 裏側の参照先（ターゲット）だけを新ファイルサーバーへ切り替える
• 移行後のリネームやCNAME運用より、設計としてスッキリしやすい

切替当日に慌てないためのチェックリスト（実務向け）

「ADの移行が終わった＝完了」ではなく、利用者視点での“動作確認項目”を先に揃えておくと成功率が上がります。

領域	確認項目	具体例
認証/ログオン	新ドメインでログオンできる	UPN、ログオン名、パスワード同期の有無
端末	ドメイン参加後のプロファイル	ユーザープロファイル移行、ローカル管理者権限
共有	主要フォルダーにアクセスできる	部署フォルダー、個人フォルダー、アプリ共有
マップドライブ	ログオンスクリプト/GPOで新参照へ	旧UNCが残っていないか、複数GPOの競合
アプリ/サービス	サービスアカウントの所属ドメイン	タスクスケジューラ、Windowsサービス、IIS AppPool
権限	Security Translationの適用漏れ	ローカルグループ、レジストリ権限、共有権限

よくある落とし穴と、回避のための具体策

落とし穴：移行したのに「共有が開けない」

原因の多くは、ACLが旧ドメインSIDのまま、または共有権限だけ作り忘れです。

• 対策：切替前にテストユーザー（新ドメイン）で主要共有の読み書きを検証
• 対策：Security Translationは範囲を絞って試行し、ログと結果を確認してから拡大
• 対策：共有権限（Share）は、棚卸し→再作成→レビューの流れを作る

落とし穴：サービスやタスクが旧ドメインアカウントで止まる

サーバー移行後、サービスアカウントが旧ドメインに紐づいたままだと、パスワードやログオン権限の問題で停止します。

• 対策：移行前に「どのサービス/タスクがどのアカウントか」を一覧化
• 対策：新ドメイン側で専用のサービスアカウントを用意し、最小権限で再設定
• 対策：Security Translationで“ローカル権限”が追従しても、アプリ側設定が旧ドメイン文字列のままのことがある

落とし穴：切替後に「一部の端末だけ」おかしい

端末が新ドメイン参加済みでも、古い資格情報や古いGPOが残ると、挙動が端末ごとに割れます。

• 対策：端末移行は“一括”よりも、部門単位で波状にして、テンプレ化した手順で回す
• 対策：ログオンスクリプト、GPO、ドライブマップは「旧参照が残らない」設計にする
• 対策：DNSの名前解決（旧→新）の設計は、切替前に必ず見える化する

まとめ：単一DC兼ファイルサーバーのドメイン移行は「分離」が最短ルート

• DCはDCのままADMTで移行する対象ではない（降格→参加→必要なら昇格が基本）
• 旧ドメインがDC1台しかないなら、降格は特に危険。旧ドメインの維持策（追加DCや段階撤去）を先に考える
• 成功率が高いのは、新ファイルサーバーを用意してデータを先に移し、Security Translationで権限を寄せてからドメイン切替
• Robocopyは強力だが、共有権限は別途設計・再設定が必要になりやすい
• 最終的には「Addで共存→安定後にReplace/Removeで整理」という二段階が、業務影響を抑えやすい

この構成の移行は、技術よりも「順序」と「戻し方」で成否が決まります。まずはファイルの受け皿を作って旧DCの負荷を下げ、ADMTで段階移行しながら、セキュリティ変換で“アクセスできる状態”を積み上げていくのが、最も安全で現実的なルートです。