次のチェックリストで、アップグレードプロセス全体について説明します。このプロセスを使用して、環境内の各サーバセットをアップグレードしてください。まだ行っていない場合は、正常性検査ユーティリティを使用して、現在のAD LDSインスタンスのバックアップを作成します。
警告:セカンダリ管理サーバは、そのMMSのプライマリ管理サーバをアップグレードするまでアップグレードしないでください。
アップグレードプロセスを複数の段階に分けて、一度に1つのMMSをアップグレードすることもできます。アップグレードプロセスでは、旧バージョンのDRAを実行するセカンダリサーバと現バージョンのDRAを実行するサーバを一時的に同じMMSに含めることもできます。DRAは、旧バージョンのDRAを実行する管理サーバと現バージョンのDRAを実行するサーバとの同期をサポートしています。ただし、同じ管理サーバまたはクライアントコンピュータ上で旧バージョンのDRAと現バージョンのDRAを実行することはできません。
重要:DRAアップグレードインストールでは、DRA 9.xバージョンからDRA 10.xバージョンにDRAサーバをアップグレードした場合、次の変更が行われます。
UCHおよびワークフロー自動化サーバのユーザ環境設定をWebコンソールからDelegation and Configuration Console (委任および環境設定コンソール)に移動します
古いWebコンポーネントをサーバから削除します。
管理対象のテナントを削除します。
テナントの追加の詳細については、『DRA管理者ガイド』の「Managing Tenants (テナントの管理)」を参照してください。
以前のリリースでAccount and Resource Managementコンソールをインストールしており、DRA 10.xバージョンにアップグレードする場合には、Account and Resource Managementコンソールが削除されます。
MMSのアップグレード時には、プライマリサーバが最初にアップグレードされ、続いてセカンダリサーバがアップグレードされます。セカンダリサーバで一時的なグループの割り当てを正常に複製するには、マルチマスタ同期スケジュールを手動で実行、またはスケジュールされた実行を待機します。
Exchange 2010はDRA 10ではサポートされていないため、DRA 9.xからアップグレードした場合、Exchangeが無効になります。アップグレード後も引き続きExchangeの操作を実行するには、Delegation and Configuration Console (委任および環境設定コンソール)の［Enable Exchange Policy (Exchangeポリシーの有効化)］オプションを無効にし、再度有効にします。ポリシーをリセットするには、両方の変更が「適用」されている必要があります。
このポリシーの設定の詳細については、「Enabling Microsoft Exchange (Microsoft Exchangeの有効化)」を参照してください。
|
ステップ |
詳細 |
|---|---|
|
正常性検査ユーティリティを実行する |
スタンドアロンのDRA正常性検査ユーティリティをインストールし、サービスアカウントを使用して実行します。問題があれば解決します。 |
|
テストアップグレードを実行する |
潜在的な問題を見つけて実働時のダウン時間を最小限に抑えるために、実験環境でテストアップグレードを実行します。 |
|
アップグレードの順序を決定する |
サーバセットをアップグレードする順序を決定します。 |
|
アップグレードのために各MMSを準備する |
アップグレードに備えて各MMSの準備を整えます。詳細については、「アップグレード前のタスク」を参照してください。 |
|
プライマリサーバをアップグレードする |
適切なMMS内のプライマリ管理サーバをアップグレードします。詳細については、「プライマリ管理サーバのアップグレード」を参照してください。 |
|
新規セカンダリサーバをインストールする |
(オプション)リモートサイトでのダウンタイムを最小限に抑えるには、最新バージョンのDRAを実行するローカルのセカンダリ管理サーバをインストールします。詳細については、「現バージョンのDRAのローカルセカンダリ管理サーバのインストール」を参照してください。 |
|
ユーザインタフェースを展開する |
ユーザインタフェースをアシスタント管理者に展開します。詳細については、「DRAユーザインタフェースの展開」を参照してください。 |
|
セカンダリサーバをアップグレードする |
MMS内のセカンダリ管理サーバをアップグレードします。詳細については、「セカンダリ管理サーバのアップグレード」を参照してください。 |
|
DRA Reportingをアップグレードする |
DRA Reportingをアップグレードします。詳細については、「Reportingのアップグレード」を参照してください。 |
|
正常性検査ユーティリティを実行する |
アップグレードの一部としてインストールされた正常性検査ユーティリティを実行します。問題があれば解決します。 |
|
Azureテナントの追加 (アップグレード後) |
(オプション、アップグレード後)アップグレード前にAzureテナントの管理をしていた場合は、アップグレード中にテナントが削除されます。これらのテナントを再度追加し、Delegation and Configuration Console (委任および環境設定コンソール)から完全なアカウントキャッシュの更新を実行する必要があります。詳細については、『DRA管理者ガイド』の「Managing Tenants (テナントの管理)」を参照してください。 |
MMSの準備が整ったら、プライマリ管理サーバをアップグレードします。プライマリ管理サーバのアップグレードが完了するまでは、クライアントコンピュータ上のユーザインタフェースをアップグレードしないでください。詳細については、「DRAユーザインタフェースの展開」を参照してください。
メモ:アップグレードの考慮事項と手順の詳細については、『Directory and Resource Administratorリリースノート』を参照してください。
アップグレードを始める前に、アップグレードの開始時期をアシスタント管理者に通知してください。セカンダリ管理サーバを前バージョンのDRAを実行するための専用サーバにした場合は、アシスタント管理者がアップグレード中に前バージョンのDRAを使い続けられるようにするために、そのサーバのことも知らせてください。
メモ:プライマリ管理サーバをアップグレードした後に、そのサーバの委任、構成、またはポリシー設定を、前バージョンのDRAを実行している管理サーバと同期することはできません。
ローカルサイトで現バージョンのDRAを実行する新規のセカンダリ管理サーバをインストールすれば、コストのかかるリモートサイトへの接続を最小限に抑えるとともに全体的なダウンタイムを短縮することができ、ユーザインタフェースの展開をより迅速に進められます。この手順はオプションですが、これによってアシスタント管理者は、展開が完了するまでの間アップグレードプロセス全体を通じて、現行バージョンと前バージョンの両方のDRAを使用できるようになります。
以下のアップグレード要件のうち１つ以上があてはまる場合は、このオプションの使用を考慮してください。
ほとんどまたはまったくダウンタイムが必要ない。
多数のアシスタント管理者をサポートする必要があり、すべてのクライアントコンピュータを即座にアップグレードすることは不可能です。
プライマリ管理サーバをアップグレードした後も、前バージョンのDRAへのアクセスをサポートし続ける必要がある。
複数のサイトにまたがるMMSが環境に含まれている。
たとえば、ロンドンサイトにあるプライマリ管理サーバと東京サイトにあるセカンダリ管理サーバでMMSが設定されている場合は、東京サイトにセカンダリサーバをインストールして対応するMMSに追加するのが得策です。この追加されたサーバは東京での日常的な管理負荷のバランスをとり、アップグレードが完了するまでの間、どちらのサイトのアシスタント管理者も前バージョンのDRAと現バージョンのDRAの両方を使用できるようになります。さらに、現在のDRAのユーザインタフェースを即座に展開できるので、アシスタント管理者がダウンタイムを経験することもありません。ユーザインタフェースのアップグレードの詳細については、「DRAユーザインタフェースの展開」を参照してください。
通常は、プライマリ管理サーバと１つのセカンダリ管理サーバをアップグレードした後で、現在のDRAのユーザインタフェースを展開しなければなりません。ただし、プライマリ管理サーバを使用する必要があるアシスタント管理者のクライアントコンピュータは、Delegation and Configuration console (委任および環境設定コンソール)をインストールして最初にアップグレードしてください。詳細については、「DRAアップグレードの計画」を参照してください。
CLI、ADSIプロバイダ、PowerShellを通じて頻繁にバッチ処理を実行する場合や、頻繁にレポートを生成する場合は、これらのユーザインタフェースを専用のセカンダリ管理サーバにインストールすることを考慮してください。それにより、MMS全体の負荷バランスが適切に保たれます。
DRAユーザインタフェースのインストールをアシスタント管理者に任せることも、グループポリシーを通じてこれらのインタフェースを展開することもできます。また、Webコンソールを複数のアシスタント管理者に簡単かつ迅速に展開できます。
メモ:同じDRAサーバ上に複数のバージョンのDRAコンポーネントを同時に実行することはできません。アシスタント管理者のクライアントコンピュータを徐々にアップグレードするよう計画している場合、現バージョンのDRAを実行する管理サーバに即座にアクセスできるようにするために、Webコンソールの展開を考慮してください。
セカンダリ管理サーバのアップグレードでは、管理上のニーズに合わせて各サーバを必要に応じてアップグレードできます。また、DRAユーザインタフェースのアップグレードと展開の計画についても検討してください。詳細については、「DRAユーザインタフェースの展開」を参照してください。
たとえば、典型的なアップグレードパスには、次の手順が含まれます。
１つのセカンダリ管理サーバをアップグレードします。
このサーバを使用するアシスタント管理者に、Webコンソールなどの適切なユーザインタフェースのインストールを指示します。
MMS全体をアップグレードするまで、上記のステップ1とステップ2を繰り返します。
アップグレードを始める前に、アップグレードの開始時期をアシスタント管理者に通知してください。セカンダリ管理サーバを前バージョンのDRAを実行するための専用サーバにした場合は、アシスタント管理者がアップグレード中に前バージョンのDRAを使い続けられるようにするために、そのサーバのことも知らせてください。このMMSのアップグレードが完了し、すべてのアシスタント管理者クライアントコンピュータがアップグレード済みのユーザインタフェースを実行するようになったら、残っている前バージョンのサーバをオフラインにしてください。