none
ADの分離移行 RRS feed

  • 質問

  • こんにちは。谷口と申します。

    現在、ADの移行計画中です。

    私のスキルレベルとして、単一ドメインは構築、移行したことがあるのですが、フォレストや信頼関係は触ったことがありません。

    現状でWAN経由で親会社のADに参加しています。自社で新規にADサーバをたててそちらに移行したいのですが、どのような方法が最適でしょうか。

    クライアントの移行作業をなるべく少なくしたいのと、移行手順の難しさでバランスをとりたいと思います。

    新規サーバ:2008SV

    クライアント:30台

    ■方法A:自社サーバに自社ADを作る。ユーザアカウントを従来SIDと同じで作成する。※こんなことが実現可能ですか?

    クライアントでドメイン解除->再起動->ネットワーク設定変更と自社ADへ参加->再起動-> 従来プロファイルでログインができる?

    ■方法B:自社サーバに自社ADを作る。親会社のADサーバにフォレスト?を作り自社ADと信頼関係?を作る。ユーザアカウントとコンピュータアカウントを自社ADにドラッグ&ドロップで移行する。※こんなことが実現可能ですか?

    クライアントでドメイン解除->再起動->ネットワーク設定変更と自社ADへ参加->再起動-> 従来プロファイルでログインができる?

    ■方法C:自社サーバに自社ADを作る。ユーザアカウントが従来SIDと違うで作成されてしまう。

    クライアントでドメイン解除->再起動->ネットワーク設定変更と自社ADへ参加->再起動-> 新規ユーザプロファイルでログイン

    C-1:-> ユーザプロファイルの移行、OutlookExpressの移行

    C-2:-> OutlookExpressの移行、デスクトップ、IME辞書、お気に入り、マイドキュメントの移行

    ■方法D:その他の方法

    何かいい方法があるでしょうか

    2011年2月9日 7:36

回答

  • チャブーンです。

    元のドメイン(フォレスト)環境と信頼関係が構築できること、また元のドメインのドメイン管理者アカウントを使うことができる、という条件が整っていれば、別のフォレストで(ドメイン名は異なりますが)ドメインコントローラを構成して、信頼関係を結んだうえ、ADMTを使ってアカウントやコンピュータの移行を行ってください。

    http://social.technet.microsoft.com/Forums/ja-JP/windowsserver2008r2ja/thread/c7dfec12-f12b-4708-99f4-1d25f77d5737

    このとき、SID履歴を利用した移行、を行うことで、以前のドメイン環境のSIDと移行先のドメイン環境のSIDを関連付けた移行を行うことができます。これを行うには "フォレスト間の信頼に対するSIDフィルタの削除" を行う必要があります。したの情報も参考にしていただくといいように思います。

    http://technet.microsoft.com/ja-jp/library/cc974455(WS.10).aspx

    2011年2月10日 0:54
    モデレータ
  • こんばんは。北川です。
    ひさびさの投稿ですが、よろしくお願いいたします。

    ADMT の話題でしたので、つい、投稿させていただきました。
    まず、ADMT の操作に関してですが、慣れているとそれほど難しいものではございませんが、
    初めて操作される方には、注意点が多く、非常に難しいかと思われます。

    何が言いたいかというと、ここでアドバイス頂いたことができるかは、ご自身で検証環境でお試しいただくことをお勧めいたします。
    (これが、現実の移行作業時にかなり役に立つと感じますので、ぜひ、検証してみてください。)

    ADMT の各シナリオについては、Active Directory 移行ガイドにまとめています。

    - Active Directory 移行ツール (ADMT) ガイド : Active Directory ドメインの移行と再構築
    <http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=6d710919-1ba5-41ca-b2f3-c11bcb4857af>

    まずは、こちらを一通り目を通されるとよいと思います。
    (ページ数が非常に多く誠に恐れ入りますが、逆に言うとそれだけ注意点があるという事です)
    必要なレジストリ設定や、アクセス権などなど、必要な前提条件が記載されています。
    トラブルが発生した際のエラーコードおよび対処方法も一部記載がございます。

    さて、前置きが非常に長くなり、誠に恐れ入りますが、ご質問の本題に入りたいと思います。
    ご質問は、チャブーンさんがご紹介していただいた、コンピュータの移行ウィザードを実施した場合についてですね。

    (1) 各ユーザーのローカル ユーザーのプロファイル移行
    これは実施できません。ADMT のコンピューターの移行ウィザードで実施できるプロファイルの移行は、ADMT のデータベースをもとに変換しています。
    ADMT のデータベースは移行したユーザーやグループのみが登録されており、各コンピュータのローカル ユーザーは含まれません。
    その為、ドメイン アカウントであれば、プロファイルの変換ができますが、ローカル ユーザーのプロファイル変換はできません。

    ローカル ユーザーのプロファイルを変換したい場合は、セキュリティ変換ウィザードを使用します。
    セキュリティ変換ウィザードはコンピュータの移行ウィザードのサブセットの一つですが、ADMT で移行したユーザー以外も変換することが出来ます。
    それは追加で SID マップファイルを作成することで、セキュリティ変換を実施することが出来ます。
    (ADMT ガイド P.243 に記載があります。1 行 1 ユーザーで、移行元ユーザーの SID,移行先ユーザーの SID という形で、カンマ区切りで記載します)
    SID は PsGetSid.exe で確認することが出来ます。
    http://technet.microsoft.com/ja-jp/sysinternals/bb897417

    なお、パスワードや証明書などは移行できないので、事前に証明書のエクスポートなど準備をお願いいたします。
    (PES による、AD アカウントのパスワード移行ではなく、クレデンシャル マネージャで保存したパスワードや、インポートした証明書のことを指しています)

    (2) ドメインの再参加
    はい。コンピュータの移行ウィザードで自動的にドメインが変更されます。
    しかし、ADMT を実行するユーザーが対象の端末に管理者権限が必要です。
    また、ADMT Agent を SMB を使用してファイルコピーしますので、クライアント側の Windows ファイアウォールの設定変更も必要になるケースが多いです。

    (3) 共有フォルダやファイルセキュリティ
    これは、移行元のリソース サーバーということであれば、sIDHistory を移行していれば、アクセスすることが出来ます。
    しかし、チャブーンさんのご指摘の通り、GUI などで信頼関係を作成したうえで(もちろん、コマンドラインでも OK です)、
    netdom trust コマンドで SID Filter を無効化する必要があります。
    (既定では SID Filter は有効です。)

    ご注意いただきたいのは、sIDHistory を用いたアクセスは恒久的なアクセス手法として運用するのではなく、
    アクセス権の設定変更が間に合わないなどの一時的な暫定処置としてお考えください。
    ある程度移行が落ち着いたら、sIDHistory を使用しなくてもアクセスできる環境を整えるようにしていただくことをお勧めいたします。
    (sIDHistory を移行するとトークンサイズも大きくなりがちなので、今まで必要のなかった Kerberos に関するチューニングが必要になるケースがあります。これは環境によりますので、必要でない場合もありますし、それ以前にチューニング済みの環境もあると思います。)
    (これはデメリットとしてお伝えしているのではなく、注意事項です。sIDHistory を移行するメリットと比べたら、通常は小さいデメリットです)

    長文になりましたが、ご参考になれば幸いです。
    我々がコメントすると、そのあとにコメントが続かない可能性があり、コメントするべきか悩むところですが、
    具体的なお困りごとを記載いただくと、実環境で移行経験のある方のコメントが頂けるかと思います。

    P.S. ADMT を使った移行経験がないとのことですので、たぶん、私のコメントで不明な点が多数あるかと存じます。
    一度、検証環境でお試しいただくことが、近道だと思います。しかし、なかなか環境を作るのは難しいかと思います。
    もし、ご自身で実施するのが困難な場合、ベンダーさんにお願いするのも一つだと思いますし、
    特に、移行にこだわらず、手作業でも構わなければ、台数が少ない場合は、手作業で作り直しっていう事も現実的にはあるのではとも感じています。

    2011年2月22日 16:43
  • チャブーンです。

    返信が遅れました。

    詳しいところはMSFT 北川さんのコメントを参考にしていただければと思いますが、SID履歴を使った移行の場合、こういうメリットがあります。

    「各PCのローカルユーザプロファイルの移行」を個別に行う必要がなくなります。SID履歴により、移行前アカウントのプロファイルを移行後のアカウントがそのまま使うことができます。ただ、これは移行前ドメインと信頼関係がなくなるとアウトになるので、完全な移行には「セキュリティの変換ウィザード」を使って移行先アカウントのSIDに内部的に切り替える必要があります。

    共有フォルダやファイルのアクセス許可設定も、うえと同じ考え方となります。同様に「セキュリティの変換ウィザード」が最終的には必要です。

    なお、手順のうえで、手動で「クライアントやメンバサーバをドメインに再参加」させる必要はありません。「コンピュータの移行ウィザード」を正しい手順で行えば、自動的に移行先ドメインに参加した状態になります。

    ひと言で言えるような話しではないので、資料を確認していただき、できればご自身で検証いただくと、内容がよく分かると思います。

    2011年2月23日 0:36
    モデレータ
  • チャブーンです。

    ちょっと訂正がてら、コメントします。

    > 4) 移行前と同様のアクセスが可能。
    >   フォレスト間の信頼関係が切れると共有フォルダ・ローカルプロファイルなどがアクセス不能になる。

    sIDHistoryが有効になっている場合、「移行先ドメインアカウント」であれば信頼関係が切れてもアクセスはできます。したの資料に書いてあるとおりです。

    http://207.46.16.252/ja-jp/library/cc974338(WS.10).aspx

    ----
    移行元ドメインを解除すると、[セキュリティの変換ウィザード] を使用して変換しなかった共有ローカル グループとローカル グループでは、グループ メンバーが "不明なアカウント" として表示されます。これは、移行元ドメインからのメンバー名が解決されないためです。これらのグループ メンバーシップはまだ存在していますが、それがユーザーに影響することはありません。セキュリティ識別子 (SID) の履歴によって実現しているアクセスが無効になるため、"不明なアカウント" のエントリは削除しないでください。これらのエントリを削除するには、[セキュリティの変換ウィザード] を実行します。
    ----

    「セキュリティ変換のウィザード」を実行しなければならない理由は、セキュリティ上の理由は当然ですが、セキュリティトークンがもてるSIDの数に制限があり、特殊な状況で問題になるためです。したの資料にかいてあるとおりとなります。

    http://support.microsoft.com/kb/322970/ja

    ですから「(5) 信頼関係を切っても良いように、共有フォルダのアクセス権のつけかえ(subinaclや cacls)」は普通の作業の中では不要となります。(うえの資料にある)チューニングもたいていは不要になるでしょう。

    2011年3月1日 15:25
    モデレータ

すべての返信

  • あまり参考になりそうなコメントできないですが、

    きっと 方法C にならざるを得ない気がします。

     

    方法A では そもそも SIDは管理者権限を持つユーザであっても任意に設定は出来ないので、同一SIDを保持は出来ません。

    出来る方法があったらごめんなさい。でもきっと出来ないと思います。

     

    方法B では 結局のところ親会社のADとの関連性を断ち切らないなら、という範囲で可能です。

    そもそもとして、 ADドメインを構築すると まず大枠で”フォレスト”が構成され、その中に”ドメイン”が出来ます。

    親会社さんが oya.local というドメイン名でADを構築したら、 oya.local フォレストが出来上がっています。

    親会社とのドメインコントローラ的な意味で関係性を断ち切らないままで問題ないなら、サブドメインを構成する方法が想定されます。

    自分の会社で oya.localフォレストのサブドメインとして ko.oya.local ドメインを作成する方法です。

    この場合、自動的に oya.localのドメインコントローラと ko.oya.local ドメインコントローラは oya.localフォレスト内の信頼関係にあります。

    同じフォレスト内の別ドメインになら、既存のADユーザを移動できたような気がします。すみませんやったことないのできっとできます的な感じです。

    で、ko.oya.localドメインの管理権限を委任して貰えば、自社ドメイン(とはいえ親会社ドメインのサブドメイン)の管理を自分で出来るようになると思います。

    ただし、この場合スキーママスタは親会社にあるので、AD連携する製品を導入するたびにお互いに影響しあう関係になります。

    通信も切るわけにいかないという現状と同じ足枷が付きます。親会社のドメインコントローラがWindows 2008 でなかったらそもそもADスキーマ拡張作業のために

    親会社側と調整を取らねばなりません。

     

    方法C 完全に自社内に独立した ADフォレスト・ドメイン  ko.local を構築するという意味では、完全に親会社から独立したAD環境となりますので、

    自由度が大幅に広がります。親会社側からの運用ポリシー的な縛りとかなければ、ですが。

    クライアントは oya.local からワークグループへ、そして ko.local へと参加ドメインの変更が必要です。

    user1@oya.local と user1@ko.local は別物なのでプロファイル移行が必要です。

     

    方法D ちゃんと理解していない検証もしていない発言なので さっぱり的外れかもしれませんが、

    親会社のドメインコントローラが Windows 2008 R2 になっている。

    自社のドメインコントローラも Windows 2008 R2 にする。

    となったら、 自社内に ko.local ドメインを立てて フェデレーションサービス使うと何とかなったりしないのかしら?

    たしかフォレスト間のユーザ移動とかあったような・・・ 間違いだったらすみません。

     

     

     

    2011年2月9日 8:08
  • チャブーンです。

    元のドメイン(フォレスト)環境と信頼関係が構築できること、また元のドメインのドメイン管理者アカウントを使うことができる、という条件が整っていれば、別のフォレストで(ドメイン名は異なりますが)ドメインコントローラを構成して、信頼関係を結んだうえ、ADMTを使ってアカウントやコンピュータの移行を行ってください。

    http://social.technet.microsoft.com/Forums/ja-JP/windowsserver2008r2ja/thread/c7dfec12-f12b-4708-99f4-1d25f77d5737

    このとき、SID履歴を利用した移行、を行うことで、以前のドメイン環境のSIDと移行先のドメイン環境のSIDを関連付けた移行を行うことができます。これを行うには "フォレスト間の信頼に対するSIDフィルタの削除" を行う必要があります。したの情報も参考にしていただくといいように思います。

    http://technet.microsoft.com/ja-jp/library/cc974455(WS.10).aspx

    2011年2月10日 0:54
    モデレータ
  • こんにちは、フォーラムオペレーターの三沢健二です。

    SHIMSOFT さん、チャブーン さん、アドバイスありがとうございます。

    今回は チャブーン さんのアドバイスが分かりやすかったのではないかと思いましたので、勝手ながら [回答としてマーク] を付けさせていただきました。
    もしよろしければ、その後実際に行われた移行方法などをお知らせいただければと思います。


    今後とも TechNet Forum をよろしくお願いします。

    ______________________________________
    日本マイクロソフト株式会社 フォーラム オペレーター 三沢健二

    2011年2月17日 5:17
    モデレータ
  • チャブーンさん返信ありがとうございます。

    この移行手順の場合、

    * 各PCのローカルユーザプロファイルの移行:必要(各PCの操作が必要)  ※2011/02/23訂正:各PCに保存されているドメインユーザのローカルプロファイル

    * ドメインへの参加手順:不要(各PCは勝手に旧ドメイン=> 新ドメイン所属になっている)

    * 共有フォルダやファイルセキュリティ:移行必要なし(SID履歴で実現できる)

    という認識でよろしいでしょうか。

     

    2011年2月22日 1:11
  • こんばんは。北川です。
    ひさびさの投稿ですが、よろしくお願いいたします。

    ADMT の話題でしたので、つい、投稿させていただきました。
    まず、ADMT の操作に関してですが、慣れているとそれほど難しいものではございませんが、
    初めて操作される方には、注意点が多く、非常に難しいかと思われます。

    何が言いたいかというと、ここでアドバイス頂いたことができるかは、ご自身で検証環境でお試しいただくことをお勧めいたします。
    (これが、現実の移行作業時にかなり役に立つと感じますので、ぜひ、検証してみてください。)

    ADMT の各シナリオについては、Active Directory 移行ガイドにまとめています。

    - Active Directory 移行ツール (ADMT) ガイド : Active Directory ドメインの移行と再構築
    <http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=6d710919-1ba5-41ca-b2f3-c11bcb4857af>

    まずは、こちらを一通り目を通されるとよいと思います。
    (ページ数が非常に多く誠に恐れ入りますが、逆に言うとそれだけ注意点があるという事です)
    必要なレジストリ設定や、アクセス権などなど、必要な前提条件が記載されています。
    トラブルが発生した際のエラーコードおよび対処方法も一部記載がございます。

    さて、前置きが非常に長くなり、誠に恐れ入りますが、ご質問の本題に入りたいと思います。
    ご質問は、チャブーンさんがご紹介していただいた、コンピュータの移行ウィザードを実施した場合についてですね。

    (1) 各ユーザーのローカル ユーザーのプロファイル移行
    これは実施できません。ADMT のコンピューターの移行ウィザードで実施できるプロファイルの移行は、ADMT のデータベースをもとに変換しています。
    ADMT のデータベースは移行したユーザーやグループのみが登録されており、各コンピュータのローカル ユーザーは含まれません。
    その為、ドメイン アカウントであれば、プロファイルの変換ができますが、ローカル ユーザーのプロファイル変換はできません。

    ローカル ユーザーのプロファイルを変換したい場合は、セキュリティ変換ウィザードを使用します。
    セキュリティ変換ウィザードはコンピュータの移行ウィザードのサブセットの一つですが、ADMT で移行したユーザー以外も変換することが出来ます。
    それは追加で SID マップファイルを作成することで、セキュリティ変換を実施することが出来ます。
    (ADMT ガイド P.243 に記載があります。1 行 1 ユーザーで、移行元ユーザーの SID,移行先ユーザーの SID という形で、カンマ区切りで記載します)
    SID は PsGetSid.exe で確認することが出来ます。
    http://technet.microsoft.com/ja-jp/sysinternals/bb897417

    なお、パスワードや証明書などは移行できないので、事前に証明書のエクスポートなど準備をお願いいたします。
    (PES による、AD アカウントのパスワード移行ではなく、クレデンシャル マネージャで保存したパスワードや、インポートした証明書のことを指しています)

    (2) ドメインの再参加
    はい。コンピュータの移行ウィザードで自動的にドメインが変更されます。
    しかし、ADMT を実行するユーザーが対象の端末に管理者権限が必要です。
    また、ADMT Agent を SMB を使用してファイルコピーしますので、クライアント側の Windows ファイアウォールの設定変更も必要になるケースが多いです。

    (3) 共有フォルダやファイルセキュリティ
    これは、移行元のリソース サーバーということであれば、sIDHistory を移行していれば、アクセスすることが出来ます。
    しかし、チャブーンさんのご指摘の通り、GUI などで信頼関係を作成したうえで(もちろん、コマンドラインでも OK です)、
    netdom trust コマンドで SID Filter を無効化する必要があります。
    (既定では SID Filter は有効です。)

    ご注意いただきたいのは、sIDHistory を用いたアクセスは恒久的なアクセス手法として運用するのではなく、
    アクセス権の設定変更が間に合わないなどの一時的な暫定処置としてお考えください。
    ある程度移行が落ち着いたら、sIDHistory を使用しなくてもアクセスできる環境を整えるようにしていただくことをお勧めいたします。
    (sIDHistory を移行するとトークンサイズも大きくなりがちなので、今まで必要のなかった Kerberos に関するチューニングが必要になるケースがあります。これは環境によりますので、必要でない場合もありますし、それ以前にチューニング済みの環境もあると思います。)
    (これはデメリットとしてお伝えしているのではなく、注意事項です。sIDHistory を移行するメリットと比べたら、通常は小さいデメリットです)

    長文になりましたが、ご参考になれば幸いです。
    我々がコメントすると、そのあとにコメントが続かない可能性があり、コメントするべきか悩むところですが、
    具体的なお困りごとを記載いただくと、実環境で移行経験のある方のコメントが頂けるかと思います。

    P.S. ADMT を使った移行経験がないとのことですので、たぶん、私のコメントで不明な点が多数あるかと存じます。
    一度、検証環境でお試しいただくことが、近道だと思います。しかし、なかなか環境を作るのは難しいかと思います。
    もし、ご自身で実施するのが困難な場合、ベンダーさんにお願いするのも一つだと思いますし、
    特に、移行にこだわらず、手作業でも構わなければ、台数が少ない場合は、手作業で作り直しっていう事も現実的にはあるのではとも感じています。

    2011年2月22日 16:43
  • チャブーンです。

    返信が遅れました。

    詳しいところはMSFT 北川さんのコメントを参考にしていただければと思いますが、SID履歴を使った移行の場合、こういうメリットがあります。

    「各PCのローカルユーザプロファイルの移行」を個別に行う必要がなくなります。SID履歴により、移行前アカウントのプロファイルを移行後のアカウントがそのまま使うことができます。ただ、これは移行前ドメインと信頼関係がなくなるとアウトになるので、完全な移行には「セキュリティの変換ウィザード」を使って移行先アカウントのSIDに内部的に切り替える必要があります。

    共有フォルダやファイルのアクセス許可設定も、うえと同じ考え方となります。同様に「セキュリティの変換ウィザード」が最終的には必要です。

    なお、手順のうえで、手動で「クライアントやメンバサーバをドメインに再参加」させる必要はありません。「コンピュータの移行ウィザード」を正しい手順で行えば、自動的に移行先ドメインに参加した状態になります。

    ひと言で言えるような話しではないので、資料を確認していただき、できればご自身で検証いただくと、内容がよく分かると思います。

    2011年2月23日 0:36
    モデレータ
  • 返信ありがとうございます。

    紹介いただいた資料270ページもあります@@。読むだけで勉強になりそうです。これだけあるとテスト環境で作業しないと理解できなさそうですね。

    http://technet.microsoft.com/ja-jp/sysinternals/bb897417 ADMTmigguide(日本語版)

    http://technet.microsoft.com/ja-jp/library/cc974332(WS.10).aspx ADMT ガイド : Active Directory ドメインの移行と再構築

     

    この掲示板で得た情報をまとめると、(また聞きなので誤りがあると思いますが、資料を見ながら検討したいと思います。)

    (1) 新規フォレストで新規ドメインサーバを構築する。既存フォレストと新規フォレストで信頼関係を結ぶ。

    (2) ADMTを新規ドメインサーバにインストールする。

    (3) 既存ユーザアカウントとコンピュータアカウントを移行する。(SIDHistoryを使う)

      SMB経由で、移行したコンピュータアカウントにADMT agentがコピーされて実行される

      => 各PCで所属ドメインの移行と、ローカルプロファイルの変換が行われる。

      ※パスワードの保存や証明書は手動で移行する必要があるかもしれない?

    (4) 移行前と同様のアクセスが可能。

      フォレスト間の信頼関係が切れると共有フォルダ・ローカルプロファイルなどがアクセス不能になる。

      ※SIDHistoryを使うと、チューニングが必要になるかもしれない?

    (5) 信頼関係を切っても良いように、共有フォルダのアクセス権のつけかえ(subinaclや cacls)

      ※各PCのローカルプロファイルの移行も手動で行う必要があるかもしれない?

     

    2011年2月23日 5:40
  • チャブーンです。

    ちょっと訂正がてら、コメントします。

    > 4) 移行前と同様のアクセスが可能。
    >   フォレスト間の信頼関係が切れると共有フォルダ・ローカルプロファイルなどがアクセス不能になる。

    sIDHistoryが有効になっている場合、「移行先ドメインアカウント」であれば信頼関係が切れてもアクセスはできます。したの資料に書いてあるとおりです。

    http://207.46.16.252/ja-jp/library/cc974338(WS.10).aspx

    ----
    移行元ドメインを解除すると、[セキュリティの変換ウィザード] を使用して変換しなかった共有ローカル グループとローカル グループでは、グループ メンバーが "不明なアカウント" として表示されます。これは、移行元ドメインからのメンバー名が解決されないためです。これらのグループ メンバーシップはまだ存在していますが、それがユーザーに影響することはありません。セキュリティ識別子 (SID) の履歴によって実現しているアクセスが無効になるため、"不明なアカウント" のエントリは削除しないでください。これらのエントリを削除するには、[セキュリティの変換ウィザード] を実行します。
    ----

    「セキュリティ変換のウィザード」を実行しなければならない理由は、セキュリティ上の理由は当然ですが、セキュリティトークンがもてるSIDの数に制限があり、特殊な状況で問題になるためです。したの資料にかいてあるとおりとなります。

    http://support.microsoft.com/kb/322970/ja

    ですから「(5) 信頼関係を切っても良いように、共有フォルダのアクセス権のつけかえ(subinaclや cacls)」は普通の作業の中では不要となります。(うえの資料にある)チューニングもたいていは不要になるでしょう。

    2011年3月1日 15:25
    モデレータ
  • こんにちは。谷口です。

    北川さん、SHIMSOFTさん、チャブーンさん、回答ありがとうございました。

    今回は、クライアントPCのローカルプロファイルを移行を手動で行いましたが、信頼関係を結べばADMTでできるということが分かっただけでもよしとします。

    大変勉強になりました。検証機会があればADMTを使ってみたいですね。

    (1) クライアントPCのローカルプロファイル移行、所属ドメインの変更が自動で行われる点

    (2) 新ADに同じユーザを作成しなくても良い点(移行される点)

    (3) クライアントPCのローカルプロファイルの場所が変わらない点(混乱の原因になるかもしれない) 

    あと、富士通さんがADMTについて画像付きでまとめていましたので、ご紹介しておきます。

    http://primeserver.fujitsu.com/primergy/technical/construct/ Windows Server 2008 / 2008 R2 Active Directory移行の手引き

    > まず、ADMT の操作に関してですが、慣れているとそれほど難しいものではございませんが、
    > 初めて操作される方には、注意点が多く、非常に難しいかと思われます。
    > ご自身で検証環境でお試しいただくことをお勧めいたします。



    2011年4月1日 3:19