アップグレードインストールを開始する前に、以下のアップグレード前のステップを実行して、各サーバセットでアップグレードの準備を行います。
ステップ |
詳細 |
---|---|
AD LDSインスタンスのバックアップ |
ヘルスチェックユーティリティを開き、AD LDSインスタンスのバックアップチェックを実行して、現在のAD LDSインスタンスのバックアップを作成します。 |
展開計画の作成 |
管理サーバとユーザインタフェース(アシスタント管理者クライアントコンピュータ)をアップグレードするための展開計画を作成します。詳細については、「DRAアップグレードの計画」を参照してください。 |
セカンダリ管理サーバ1台を、前のバージョンのDRAを実行するための専用サーバにする |
オプション: セカンダリ管理サーバ1台を、サイトのアップグレード中に前のバージョンのDRAを実行するための専用のサーバにします。 |
このMMSにとって必要な変更を加える |
このMMSにとって必要な委任、構成、またはポリシー設定に対する変更を加えます。これらの設定を変更するには、プライマリ管理サーバを使用してください。 |
MMSを同期化する |
サーバセットを同期して、すべての管理サーバが最新の構成とセキュリティ設定を持つようにします。 |
プライマリサーバのレジストリをバックアップする |
プライマリ管理サーバのレジストリをバックアップします。レジストリ設定をバックアップしておくと、以前の構成およびセキュリティ設定を簡単に復元できます。 |
gMSAをDRAユーザアカウントに変換する |
オプション: DRAサービスアカウントのgroup-managed service account (グループ管理されたサービスアカウント)(gMSA)を使用している場合は、アップグレードの前にgMSAアカウントをDRAユーザアカウントに変更してください。アップグレード後、アカウントをgMSAに戻す必要があります。 |
メモ:AD LDSインスタンスを復元する必要がある場合、次の操作を行ってください。
[Computer Management]>[Services]で、現在のAD LDSインスタンスを停止します。NetIQDRASecureStoragexxxxxという別のタイトルになります。
以下に示されているように、現在の adamnts.ditファイルをバックアップの adamnts.ditファイルに置き換えます。
現在のファイルの場所: %ProgramData%/NetIQ/DRA/<DRAInstanceName>/data/
バックアップファイルの場所:%ProgramData%/NetIQ/ADLDS/
AD LDSインスタンスを再起動します。
アップグレードの最中に、1つ以上のセカンダリ管理サーバをローカルで前バージョンのDRAを実行する専用のサーバとして使用すれば、ダウンタイムとリモートサイトへのコストのかかる接続を最小限に抑えることができます。この手順はオプションですが、これによってアシスタント管理者は、展開が完了するまでの間アップグレードプロセス全体を通じて、前バージョンのDRAを使用できるようになります。
以下のアップグレード要件のうち1つ以上があてはまる場合は、このオプションの使用を考慮してください。
ほとんどまたはまったくダウンタイムが必要ない。
多数のアシスタント管理者をサポートする必要があり、すべてのクライアントコンピュータを即座にアップグレードすることは不可能です。
プライマリ管理サーバをアップグレードした後も、前バージョンのDRAへのアクセスをサポートし続ける必要がある。
複数のサイトにまたがるMMSが環境に含まれている。
新規のセカンダリ管理サーバをインストールすることも、前バージョンのDRAを実行している既存のセカンダリサーバを指定することもできます。このサーバをアップグレードする場合は、このサーバを最後にアップグレードしなければなりません。アップグレードしない場合は、アップグレードが正常に完了した後で、このサーバから完全にDRAをアンインストールします。
新規のセカンダリ管理サーバをローカルサイトにインストールすれば、コストのかかるリモートサイトへの接続が不要になり、アシスタント管理者が中断なしで前バージョンのDRAの使用を続行できます。複数のサイトにまたがるMMSが環境に含まれている場合は、このオプションを考慮する必要があります。たとえば、ロンドンサイトにあるプライマリ管理サーバと東京サイトにあるセカンダリ管理サーバでMMSが構成されている場合は、ロンドンサイトにセカンダリサーバをインストールして対応するMMSに追加するのが得策です。この追加されたサーバにより、ロンドンサイトからのアシスタント管理者はアップグレードが完了するまでの間、前バージョンのDRAを使い続けられるようになります。
既存のセカンダリ管理サーバを、前バージョンのDRA専用のサーバとして使用することができます。セカンダリ管理サーバをアップグレードする予定がないサイトについては、このオプションを考慮する必要があります。既存のセカンダリサーバを専用サーバにできない場合は、新規の管理サーバをこの目的のためにインストールすることを考慮してください。1つ以上のセカンダリサーバを前バージョンのDRAを実行するための専用サーバにすれば、アップグレードが完了するまでの間、アシスタント管理者が中断なしで前バージョンのDRAを使い続けることができます。このオプションは、中央管理モデルを採用している非常に大規模な環境に適しています。
前バージョンのDRAのレジストリをバックアップする前、つまりアップグレードプロセスを開始する前に、サーバセットの同期をとって各管理サーバの設定およびセキュリティ設定を最新の状態にする必要があります。
メモ:このMMSの委任、設定、またはポリシーの設定に必要な変更を加えてください。これらの設定の変更には、プライマリ管理サーバを使用してください。プライマリ管理サーバをアップグレードした後で、委任、設定、またはポリシーの設定を、前バージョンのDRAを実行している管理サーバと同期させることはできません。
既存のサーバセットを同期させるには、次の手順を実行します。
プライマリ管理サーバにBuilt-in Adminとしてログオンします。
Delegation and Configuration Console (委任および環境設定コンソール)を開き、[Configuration Management (環境設定管理)]を展開します。
[管理サーバ]をクリックします。
右側のウィンドウで、このサーバセットに属する適切なプライマリ管理サーバを選択します。
[プロパティ]をクリックします。
[同期スケジュール]タブで、[今すぐ更新]をクリックします。
同期が正しく完了したことと、すべてのセカンダリ管理サーバが使用可能であることを確認します。
管理サーバのレジストリをバックアップすれば、確実に以前の構成に戻すことができます。たとえば、現バージョンのDRAを完全にアンインストールして前バージョンのDRAを使用しなければならなくなった場合、前のレジストリ設定のバックアップがあれば、前の構成とセキュリティ設定を簡単に復旧できます。
ただし、レジストリの編集には注意が必要です。レジストリ内にエラーがあると、管理サーバが予期したとおりに動作しない場合があります。アップグレードプロセス中にエラーが発生した場合は、レジストリ設定のバックアップを使用して、レジストリを復元できます。詳細については、『レジストリエディタのヘルプ』を参照してください。
重要:レジストリを復元するときは、DRAサーバのバージョン、WindowsのOS名、および管理対象のドメイン構成が完全に同じである必要があります。
重要:アップグレードする前に、DRAをホストしているマシンのWindows OSをバックアップするか、マシンの仮想マシンスナップショットイメージを作成してください。
管理サーバのレジストリをバックアップするには、次の手順を実行します。
regedit.exeを実行します。
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mission Critical Software\OnePointノードを右クリックし、[エクスポート]を選択します。
レジストリキーを保存するファイルの名前と場所を指定し、[保存]をクリックします。