web-dev-qa-db-ja.com

SBS2011から2012 R2および新しいドメインへのADの移行

既存のSBS2011サーバーがあり、新しい2012 R2サーバーに移行したいと考えています。理想的には、これを新しいドメインで行います-1. OUを再編成して、「SBS」という名前の付いたものを削除します(つまり、すべてのユーザーがユーザーに属していない、SBSUsersにいるなど)。 ..)および2. 2.ベストプラクティスに沿ったドメイン名(name.localではなくsubdomain.ourdomain.com)に移動します。

私はこの移行を行うための最良の方法を見つけ出そうとしています。私が読んだことのほとんどは、新しいDC=を既存のドメインに追加し、それを昇格させ、すべてを同期させてから、古いドメインを降格させることによって移行することです。しかし、これはどちらにも対処しません私たちの懸念の再:命名または再編成。

フォレストをまたぐことも考えましたが、ADMT(2012ではサポートされていません)または有料のツール(オプションではない可能性があります。非営利団体であり、予算が最小限であるため)このため)。

最後に、ユーザーをエクスポートしてインポートすることもできましたが、これにはユーザー、コンピューター、グループなどのさまざまな手順が含まれるようで、メッシュがどの程度うまく機能するかについて心配しています。また、私が知る限り、上記のツールがなければ(そして多分それでもないかもしれませんが)、すべてのユーザーにパスワードをリセットさせなければ、それを行うことはできません。

ExchangeはOffice 365に移行するため、ここでは変数ではありません(私はそうは思いません!)。簡単にするために、他のすべてが並べ替えられるまで、今のところSSOを追加しないでください。

すべての基準を満たすことができるオプションが欠けていますか?ドメイン名を変更し、SBSではなく標準のOUレイアウトを維持し、高価なサードパーティツールを購入せず、ユーザーアカウント/パスワードに影響を与えません。 ?

5
teleute00

Exchange 2007以降のバージョンでは、 domain rename を実行できません。オンプレミスのExchangeを廃止することになると言っているので、それは要因ではありません。これにより、新しいフォレストやドメインを作成するよりもはるかに簡単なプロセスになると思います。

  • Office 365への移行を完了し、SBS 2011環境からExchangeを削除します。

  • 一時的なDC=を既存のドメインに追加し、AD(およびすべてのFSMOの役割)をSBSサーバーから移行して、SBSサーバーをプロセスのドメインメンバーに降格します。(この後、移行を完了するには21日かかります)。

  • ドメインの名前変更を実行します。

  • 永続的なW2K12 R2 DCを追加し、一時的なDCを降格/削除します。

  • ADのOU(GPOなど)を好きな名前に変更/移動します。

  • SBSマシンから他の機能を移行し、廃止します。

一時的なDCは厳密には必要ありませんが、おそらく私はそうします(私が迷信なので)。ドメイン名の変更は難しいように見えますが、Exchangeがなければ実際には非常に簡単です。関係するすべてのユーザーが、分離されたネットワーク上の仮想マシンを使用して環境をモックアップして試してみます(できれば、運用ネットワークから「収集」して仮想環境に配置したADの実際のコピーを使用してください)。

これを行うときにも、SBS 2011セットアップによって作成された既定の証明機関を破棄する必要があります。 エンタープライズCAの使用停止 も、実際には何も使用していないことを前提として、それほど難しくありません。 (そうであれば、どのような移行戦略をとっても、それについて心配する必要があります。)

完了したら、素敵な光沢のある新しいドメイン名が作成されます。OUは希望どおりになり、すべてのユーザーパスワードは変更されず、すべてのドメインメンバーのコンピューターは完全なドメイン信頼を保持します。

本番ドメインの名前変更と移行が適切に計画、テスト、実行されると、完了するまでに数時間しかかかりませんでした。 (明らかに、実際に実際のことを行う場合、事前の計画とテストに費やす時間は莫大な利益をもたらします。)

(また、古いSBSマシンによってエクスポートされた共有を反映した新しいW2K12R2マシン上の共有をエクスポートし、SBSマシンを DNSエイリアス として新しいサーバーに追加します。次に、既存のショートカット、UNCなどは、移行後に「正常に動作」します。)

編集:

なぜドメイン名の変更に気を取られるのかわかりません。あなたはそれを計画し、系統的に実行する必要がありますが、それは私にとって苦痛ではありませんでした。私は3つの本番ドメインの名前変更を行いましたが、問題はありませんでした(変更が必要な組み込みデバイスで長い間忘れられていたFQDNを使用していたことを除きます)。 2つの環境にはExchange 2003があり、1つにはありませんでした。 1つには単一のDCがあり、他の2つには複数のDCがありました。最初の2つ(Exchangeがあった環境)をVMでモックアップしましたが、3つ目はモックアップなしで実稼働ネットワーク上で実行しました(非常に単純なため、単一のDC、Exchangeなし)。

上記の「ドメイン名の変更を実行する」の箇条書きは、次の手順に分かれています。

Microsoftの記事に関しては、私は次のようにしています: ドメイン名の変更の仕組み 記事にはlotの余分な背景が含まれていますが、基本的なそこにステップがあります。

単一のDCを含む単一のドメインフォレストの場合、プロセスはかなり簡単です。

  • エンタープライズCAルートを廃止します。

  • 新しいドメイン名の新しいAD統合DNSゾーンを作成します。

  • フォレストの機能レベルをWindows 2003以降に設定します。

  • rendom /listを実行して、フォレストの説明ファイル(Domainlist.xml)を生成します。

  • Domainlist.xmlファイルを編集して、新しいDNSおよびNetBIOSドメイン名を反映します。

  • rendom /showforestを実行してDomainlist.xmlファイルを「わかりやすい」方法で表示し、出力を確認して適切に編集したことを確認します。

  • rendom /uploadコマンドを実行して、新しいドメイン名をActive Directoryにインストールします。この時点では名前の変更は行われません。ADで名前を変更する準備をしているだけです。マルチDC環境では、すべてのDCへの名前変更指示の複製が開始されます。

  • rendom /prepareコマンドを実行して、名前を変更する準備ができていることを確認します。マルチDC環境では、このコマンドは各DCをチェックして、すべてが名前変更指示を受け取っていることを確認します。すべてのDCが名前変更指示を複製するまで、名前変更を開始できません。(変更はすべてのADデータベースレプリカにほぼ同時に発生します。)rendom /prepareを実行すると、rendom /cleanを実行するまで、新しいドメインをフォレストに追加したり、DCをドメインに追加したりできません(下記を参照)。 )。

  • rendom /executeコマンドを実行して、名前の変更を実行します。これは、DCに名前変更を実行するように指示します。各DCは、ADデータベースをシングルユーザーメンテナンスモードに切り替え、名前を変更してから、再起動して通常の動作状態に戻します。

  • すべてのDCが名前変更を完了したら、適切な古いドメイン名と新しいドメイン名を使用して 'Gpfixup' を実行し、古いドメイン名への参照をグループポリシーオブジェクトの新しい名前に更新します。

  • それぞれのプライマリDNSサフィックスを変更するDC 自動的に変更されないため 。Microsoftがこれらの変更を自動的に行わなかった理由はわかりませんが、実際には変更されていません't。この変更を行った後、DCを再起動します。

  • すべてのドメインメンバーコンピューターを2回再起動します。これはすぐに実行する必要はありません(ドメインをこの状態で数週間維持しました)。ドメインメンバーのコンピューターは、ドメイン名の変更が行われたことを「検出」し、これらの2つの再起動中に自動的に更新されます。

  • すべてのドメインメンバーコンピューターを再起動したら、rendom /cleanコマンドを2回実行して、ADから名前変更の指示を消去し、ドメインを通常の動作状態に戻します。

  • 非ドメインメンバーレコードをADから移行したら、ADから古いドメインのDNSゾーンを削除します。

私が言ったように、単一のドメイン、単一のDC環境はシンプルです。ドメインの名前変更指示の複製や、すべてのDCに接続できることを心配する必要がないためです。

副作用に関する限り:

  • ドメインのDFSルート名が変更されることを認識する必要があります。ドメインDFSパスからのグループポリシーソフトウェアインストールがある場合、ソフトウェアの再インストールが表示されます(グループポリシークライアントはソフトウェアがインストールされていないと見なすため)。

  • ドメインを/cleanするのが早すぎる場合(すべてのメンバーコンピューターが2回再起動される前)、手動でドメインに参加解除して再参加する必要があるマシンが存在する状態になる可能性があります。

  • 大規模な環境では、新しいDNSゾーンにデータが入力されている間、レプリケーショントラフィックが増加します。

5
Evan Anderson