Proxmoxで学ぶ Windows Server AD #4　構築済みADから別のADへクライアント参加

はじめに

「Proxmoxで学ぶ Windows Server AD」シリーズへようこそ！

前回（#3）までで、Proxmox上にWindows Server 2025をインストールし、

ADを新規構築する基本手順を学びました。

これは、新しい環境を構築するには最適です。

しかし、多くのIT担当者が直面する現実的な課題は、

「既存の古いAD（例えば Windows Server 2016）からのリプレイス」ではないでしょうか？

その時、IT担当者として「ADサーバーを新しく立て直す手順は分かっているが、

既に参加している大量のクライアントPCは、どうやって安全に、新しいADに参加させ直せばいいのか？」

と不安に思いませんか？

もし、単純に古いドメインから離脱させ、新しいドメインに参加させようとすると…

• 「デスクトップのファイルが全部消えた！」
• 「今まで使っていたアプリの設定が初期化された！」

といったクレームが殺到し、IT部門がパンクする「最悪の結果（＝プロファイル初期化地獄）」に陥ります。

この記事では、Proxmoxという安全な演習環境を活かし、

この「プロファイル初期化地獄」を回避する「仕組み」として、

「古いWindows Server 2016 AD」から「新規構築するWindows Server 2025 AD」へ、

ユーザープロファイルを維持したまま移行する実践的な手順を解説します。

【重要】この記事の目的について

この記事は、AD移行の「技術的な仕組み（SIDとプロファイルのマッピング）」を理解するための学習・検証（ラボ）環境向けの手順です。

本番環境の移行（Production Migration）は、GPO、ファイルサーバーのACL、SID履歴（sIDHistory）、アプリケーション互換性など、膨大な追加考慮事項があります。

※この記事の手順をそのまま本番環境に適用しないでください。

1.この記事の対象読者

• Proxmox VE上にVMを構築できる方（本シリーズ#1〜#3履修者推奨）
• 現在 Windows Server 2016/2019 等の古いADを運用しており、
  Windows Server 2025 への移行（リプレイス）を検討している方
• ドメイン移行時の「プロファイル初期化問題」で困った経験がある方
• Profwiz などの移行ツールの基本的な動作を（安全な環境で）練習したい方

2. 前提とする環境・使用するツール

• 仮想化基盤: Proxmox VE（シリーズ#1で構築済み）
• 移行元AD: 既存の Windows Server 2016 AD（例: ad16.local）
• 移行先AD: 今回新規に構築する Windows Server 2025（例: ad25.test）
• クライアントPC: Windows 11など（ad16.local に参加済み）
• 使用ツール: Forensit User Profile Wizard (Profwiz)
  • ライセンス（重要）: 今回は「Freeware (Personal) Edition」を使用します。

  • ForensiT社の公式「Corporate User Guide」のFAQセクションに

    「“You are welcome to use the free Personal Edition…in your business”（ビジネス（商用環境）で無償のPersonal Editionを使用しても構いません）」と明確に記載されています。

  • したがって、手動での移行作業であれば、企業環境での利用もライセンス上許可されています。ただし、構成ファイル（Profwiz.config）やスクリプトを利用した自動展開・大規模展開（Answer Fileの使用など）は、有償の「Corporate Edition」の機能となります。
  • （根拠参照: ForensiT – Professional and Corporate Edition User Guide ※FAQセクションを参照）
  • 選定理由: なぜProfwizか？
  • Microsoft標準の「USMT」はPCリプレイス時のデータ移行（採取と復元）が主目的であり、
  • 「Transwiz」はプロファイルを別PCへ転送するツールです。
  • 今回の目的である「同一PC上で、既存プロファイルを新しいドメインSIDにその場で再ひも付け（マッピング）する」のに最適なツールがProfwizです。
• 関連ドキュメント（必読）:
  • Microsoft Learn: Active Directory ドメインの名前付けに関するベスト プラクティス
  • Microsoft Learn: ドメイン コントローラーの DNS クライアント設定のベスト プラクティス

3. 要約

この記事を読むことで、「Proxmox上に移行先となるWindows Server 2025 ADを、ベストプラクティスに沿って構築する手順」と、

「既存のWindows Server 2016 ADに参加済みのクライアントPCのプロファイル（デスクトップや設定）を維持したまま、新しいADへ移行させる具体的なステップ」を学べます。

本番環境で必須となるAD移行の核心技術（SIDマッピング）を、リスクゼロの演習環境で習得することを目指します。

4. 解決策のステップ（全6ステップ）

【ステップ1】移行前の準備と「証拠」の確保

移行作業の前に、移行元（クライアントPC）の現状を把握し、移行先（ad25.test）で受け入れる準備をします。

• 課題
  移行が成功したか客観的に判断し、移行ツールが正しく動作するための前提条件を整えたい。
• 手順
  1. 移行先ADでのユーザー作成: 移行先となるad25.test サーバー側で、クライアントPCを移行させるための「受け皿」となるユーザーアカウントを事前に作成しておきます。（例: ad25.test\Mamoru を作成）
     • ※Profwizは別名のアカウントにも割り当て可能ですが、今回の演習では混乱を避けるため、移行元（ad16.local\Mamoru）と同じ名前のアカウントを作成します。
  2. クライアントPCでの「証拠」確保: ad16.local に参加中のクライアントPCに、ad16.local\Mamoru でログインします。
  3. デスクトップに「ad16.local.txt」という名前のテキストファイルを作成します。
     （一目で判断するため）
  4. コマンドプロンプトで whoami /user を実行し、現在のユーザーの SID（例: S-1-5-21-....-1101）をメモしておきます。
     これが、移行後に変わることを確認します。
     • （コマンド参照: Microsoft Learn: whoami)

【ステップ2】移行先の「Windows Server 2025 AD」を構築する

ご提供いただいたメモに基づき、クライアントPCの「新しい受け皿」となる、Windows Server 2025 ADをProxmox上に構築します。

• 課題
  クライアントPCを移行させるための、まっさらな移行先（AD）が必要です。
• 解決策
  Proxmox上に、新しいWindows Server 2025のVMを立て、ad16.local とは別のドメイン名（ad25.test）でADを構築します。

• 手順

  1. VMの準備
     シリーズ#2の手順を参考に、
     Proxmox上に、Windows Server 2025のVMをもう1台作成します。（例: ホスト名 ad25-server）

  2. 固定IPと【最重要】DNS設定

     • 設定 → ネットワーク & インターネット → アダプターの詳細設定 → 対象NICのプロパティ → IPv4 を開きます。
     • IPアドレス: ad16.local のサーバーやルーターと重複しない、新しい固定IP（例: 192.168.1.12）を設定します。
     • 優先DNS: 192.168.1.12（自分自身の静的IPアドレス）を設定します。
       

       初心者の誤解を訂正（超重要）
       ADドメインコントローラー（DC）のNIC設定で、優先DNS（または代替DNS）にルーターや外部DNS（8.8.8.8等）を絶対に追加してはいけません。
       AD関連のすべての名前解決（SRVレコード検索など）が失敗し、ADが正常に機能しなくなります。
       DCは「内部DNSのみを参照」（つまり、自分自身または他の内部DC）させるのが鉄則です。

        

     • （根拠参照: Microsoft Learn: DCのDNSクライアント設定ベストプラクティス)
       

       ※本番環境への補足
       今回は単一DCのラボであるため自身のIPを指定しますが、
       本番の複数DC構成では、互いに他のDCを優先DNSに設定し、
       自身を代替DNS（または最後）に設定するのが一般的です。

     • もし、この設定（またはDHCPのまま）で役割を追加しようとすると、静的IPを促す以下の警告が表示されます。
       （※参考画像）

     

  3. 役割の追加（AD DS / DNS）
     サーバーマネージャーのダッシュボードから「役割と機能の追加」をクリックし、
     「Active Directory Domain Services」と「DNS Server」にチェックを入れ、インストールします。

  4. 新フォレストとして昇格

     インストール完了後、旗アイコン（通知）から「このサーバーをドメインコントローラーに昇格する」をクリックします。
     （※参考画像）
     
     

     • 配置構成: 「新しいフォレストを追加」を選択します。
     • ルートドメイン名: ad25.test を入力します。
       

       ※ドメイン名の補足

       Microsoftのベストプラクティスは、自社で取得済みのインターネットドメイン名（例: company.com）のサブドメイン（例: ad.company.com）を本番環境で使用することです。

       .local はmDNS（RFC 6762）と競合するため、本番環境では非推奨です。

       IETFは、隔離されたテスト環境向けに「.test」（RFC 2606）というTLDを予約しています。

       今回はこの規約に従い、テスト用として ad25.test を使用します。

  5. DNSオプションの警告

     DSRMパスワード設定後、DNSオプション画面で「DNSサーバーの委任を作成できませんでした…」という黄色の警告が表示されます。
     （※参考画像）
     

     • ※これはエラーではありません。「新規フォレストルート」を構築しているため、
       委任（お任せ）する先の親DNSゾーン（.test を管理するDNS）が存在しないのは当然です。
       したがって、これは「正常な警告」です。

     • これは、内部的にInstall-ADDSForestコマンドが実行される際、-CreateDnsDelegation パラメータが親ゾーンの不在を検知し、
       委任作成を自動的にスキップする正常な動作を示しています。
       「DNS 委任の作成」にチェックを入れずに「次へ」進みます。
     • （根拠参照: Microsoft Learn: Install-ADDSForest コマンドレットの仕様)

  6. インストール実行

     前提条件チェック後に「インストール」を実行します。
     サーバーは自動的に再起動します。
     （サインインは AD25\Administrator のようになります）

  7. 再起動後のDNSフォワーダー設定（詳細解説）
     

     DCが「外部インターネットの名前解決」を行うための設定をします。

     • 「DNS マネージャー」（サーバーマネージャー → ツール）を開きます。
     • サーバー名を右クリック → プロパティ → 「フォワーダー」タブを開きます。
     • 「編集」をクリックし、上位のDNS（ルーターのIPや 8.8.8.8 など）を追加します。
     • ※（フォワーダー vs ルートヒント）: この設定は「任意（推奨）」であり、「必須」ではありません。

     • 技術ポイント

       DNSサーバーは、フォワーダーが設定されていない場合、既定で「ルートヒント」タブにリストされているインターネットのルートDNSサーバー群に直接問い合わせ（再帰クエリ）を行います。

       フォワーダーは、その問い合わせを特定のサーバー（例: プロバイダのDNSや自社の集約DNS）に転送・集約させるための「最適化」設定です。

       今回のラボ環境では、設定しなくても外部の名前解決は可能です。

     • （根拠参照: Microsoft Learn: DNS フォワーダーの概要 / Microsoft Learn: ルート ヒントの概要)

【ステップ3】移行先AD（ad25.test）の「健康診断」を実行する

クライアントを移行させる前に、新しいAD（ad25.test）が正常に機能しているか診断します。

• 課題

  移行先ADが「異常」だと、移行作業は必ず失敗します。
  事前に、健康状態を確認が必須です。

• 手順

  ad25.test サーバー上で、PowerShellまたはコマンドプロンプトを起動します。

  1. 総合診断 (DC健全性)

     dcdiag を実行します。「dcdiag はすべてのテストに合格しました」と表示されることを確認します。

     • （コマンド参照: Microsoft Learn: dcdiag)

  2. DNS診断（DCホスト名）

     nslookup ad25-server.ad25.test を実行します（ad25-server はDCのホスト名）。
     192.168.1.12 が正しく返ってくることを確認します。

  3. DNS診断（SRVレコード）

     nslookup -type=SRV _ldap._tcp.dc._msdcs.ad25.test を実行します。
     これは「DCのLDAPサービスはどこですか？」というADの根幹となる問い合わせで、
     ad25-server.ad25.test (ホスト名)が返ってくることを確認します。

  4. イベントログ

     イベントビューアーで「Directory Service」「DNS Server」にエラーが出ていないことを確認します。

【ステップ4】「SID問題」と「手動コピーがダメな理由」

Q:なぜ手動（ドメイン離脱→参加）だとプロファイルが消える（ように見える）のでしょうか？

• 課題

  手動でドメインに参加し直すと、デスクトップが初期化されてしまいます。

• 解決策

  Windowsはユーザーを「名前（Mamoru）」ではなく
  「SID（セキュリティ識別子）」という固有番号で管理しています。

  • ad16.local の Mamoru（例: S-1-5-21-....-1101）
  • ad25.test の Mamoru（例: S-1-5-21-….-1601）この2つは、名前が同じでもSIDが全くの別物です。
• 初心者の誤解を訂正（プロファイル初期化のメカニズム）
  Windowsは、どのSIDがどのプロファイルフォルダ（C:\Users\…）を使うかを、レジストリで厳密に管理しています。

  • 管理場所

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

  • 仕組み

    このキーの配下には、S-1-5-21-....-1101 のようなSID名のサブキーが並んでいます。

  • そのサブキーの中にある ProfileImagePath という値（REG_EXPAND_SZ）が、
    実際のフォルダパス（例: C:\Users\Mamoru.ad16.local）を指しています。
  • （根拠参照: Microsoft Learn: ユーザー プロファイル レジストリ キー)

  • 手動移行時の失敗
    ドメインを離脱し、ad25.test に参加し直すと、OSは新しいSID（-1601）でログイン処理をします。
    しかし、ProfileList にはそのSIDの記録がないため、OSは「新しく来たユーザーだ」と判断し、
    新しいプロファイルフォルダ（例: C:\Users\Mamoru.ad25.test）を作成してしまいます。
    これが「デスクトップが初期化された」状態の正体です。

  • リスク（手動コピペ）
    古いフォルダ（Mamoru.ad16.local）から手動でコピペしても、
    この ProfileList の紐付けや、プロファイル内の NTUSER.DAT（レジストリハイブ）は古いSIDのままなので、プロファイルは破損します。

• 解決策

  「Forensit Profwiz」を使います。
  これは、データをコピーするのではなく、この「ProfileList の紐付け」と関連する権限を、古いSID（-1101）から新しいSID（-1601）へ安全に「再割り当て（re-assign）」する専用ツールです。
  これにより、OSは新しいSIDでログインしても、既存のプロファイルフォルダ（Mamoru.ad16.local）をそのまま使い続けることができます。

【ステップ5】Profwizによるドメイン移行の実行

いよいよ、クライアントPCを ad16.local から ad25.test へ移行します。

• 課題

  安全かつ確実に、プロファイルを維持したままドメインを移行させます。

• 手順

  ad16.local\Mamoru でログインした状態で、Profwizを実行します。

  1. クライアントPCで「Forensit Profwiz」をダウンロードします。
  2. （重要）バックアップ: 念のため、システムの復元ポイントを作成するか、プロファイルデータをバックアップします。
  3. （重要）管理者権限: Profwizのインストーラー（または Profwiz.exe）を右クリック → 「管理者として実行」します。
  4. ウィザードが起動したら「次へ」。
  5. 「Computer Domain」の画面で、移行先（ad25.test）のドメイン名と、そのドメインの管理者アカウント（例: Administrator@ad25.test とそのパスワード）を入力します。
  6. 「次へ」進むと、PC上のローカルプロファイル一覧が表示されます。
  7. 移行したいプロファイル（例: AD16\Mamoru）を選択します。
  8. 「Enter the domain user account name」に、移行先（ad25.test）でのユーザー名（例: Mamoru）を入力します。（※ステップ1で ad25.test 側で作成したアカウント）
  9. 「Join Domain」にチェックが入っていることを確認し、「次へ」進めます。
  10. 処理が実行され、PCが自動的に再起動されます。

【ステップ6】移行後の「検証チェックリスト」

再起動後、ログイン画面が ad25.test ドメインに切り替わっています。

• 課題
  

  移行が本当に成功し、プロファイルが維持され、AD機能が正常か確認する。

• 手順
  ad25.test\Mamoru として、パスワードを入力しログインします。

  1. （視覚確認）

     デスクトップに、ステップ1で作成した「これはad16.localのファイルです.txt」が、そのまま残っていることを確認します。

  2. （SID確認）

     コマンドプロンプトで whoami /user を実行します。
     ステップ1でメモしたSIDとは別の、新しいSID（ad25.test\Mamoru のSID）が表示されることを確認します。

  3. （プロファイルパス確認）

     C:\Users\ フォルダを確認します。Profwizが正しく動作すれば、既存のプロファイルフォルダ（例: C:\Users\Mamoru.ad16.local）がそのまま再利用されます。
     フォルダ名が Mamoru.ad25.test になっていないことを確認します。（※ステップ4の ProfileList が正しく書き換わった証拠です）

  4. （GPO確認）

     コマンドプロンプトで gpresult /r を実行します。
     「適用されたグループ ポリシー オジェクト」に、ad25.test の「Default Domain Policy」が表示されていることを確認します。

     • （コマンド参照: Microsoft Learn: gpresult)

  5. （サーバー側確認）

     ad25.test サーバー側で「Active Directory ユーザーとコンピューター」を開きます。

     • 既定では「CN=Computers」コンテナ内に、クライアントPCのオブジェクトが新規に「作成」されていることを確認します。
       （※本番環境でこの既定の場所を変更するには redircmp コマンドを使います）
     • （コマンド参照: Microsoft Learn: redircmp)

5. まとめ

今回の演習で、技術的な正確性を高めた重要なステップを完了しました。

【ステップ1】

 移行前の準備（移行先ユーザー作成、証拠確保）を行いました。

【ステップ2】

「移行先AD（ad25.test）」を、正しいDNS設定（内部DNSのみ参照）とドメイン命名（.testの使い分け）、警告の正しい理解（DNS委任の根拠）、フォワーダーとルートヒントの仕組みに基づいて構築しました。

【ステップ3】

dcdiag や nslookup（ホスト名・SRV）を使い、ADの「健康診断」を行いました。

【ステップ4】

AD移行の核心である「SID問題」と、その技術的根拠「ProfileList」および「ProfileImagePath」、そしてProfwizがなぜ最適か（in-place re-assign）を詳細に学びました。

【ステップ5】

「Profwiz」を管理者権限で実行し、プロファイルのSIDマッピングを行いました。

【ステップ6】

gpresult やプロファイルパスの確認を行い、 移行後も正常に動作していることを確認しました。

AD移行の核心は、「クライアント（利用者）の業務影響をゼロにすること」です。

今回の演習は、そのための最も重要な「SIDマッピング」の仕組みを、より安全で正確な手順で学ぶものでした。

終わりに

Proxmox上で、安全にAD移行の演習ができました。

しかし、記事を読んだ方の中には、

「ウチの本番環境は、GPO（グループポリシー）が複雑に絡んでいる…」

「ファイルサーバーのアクセス権（ACL）はどうなるんだ？」

「SID履歴（SID History）は移行しなくていいのか？」

といった、不安が湧いてきたかもしれません。

その通り、今回のProfwizによる作業は、あくまで「クライアントPC上のローカルプロファイル」の付け替えです。

本番移行では、サーバー側で「ファイルサーバー等のリソースアクセス権」を維持するために、

ADMT（Active Directory Migration Tool）などを使って、

ユーザーアカウント自体にsIDHistory（古いSID情報）を持たせる作業が別途必要になります。

これらは層が異なる、より高度な作業です。

（根拠参照: Microsoft Learn: Active Directory Migration Tool (ADMT) ガイド）

まずは第一歩として、Proxmox環境でファイルサーバーを立ててみるなど、次のステップの学習に進んでみてください。

もし、実際の業務でAD移行プロジェクトを推進するにあたり、

「自社の複雑な環境で、何から手をつければいいか分からない」

「移行プロジェクトの専門家にサポートしてほしい」

とお考えの場合は、ぜひ弊社にご相談ください。

お客様の環境に合わせた最適な移行プランニングや、技術支援ワークショップ（有償）をご提供しています。

ご興味のある方は、ぜひお気軽にお問い合わせください。