2.3 製品アップグレード

この章は、統制のとれた段階を追って分散環境をアップグレードまたは移行するのに役立つプロセスを提供します。

この章では、環境内に複数の管理サーバがあり、一部のサーバはリモートサイトにあるものと想定しています。この構成は、マルチマスタセット(MMS)と呼ばれます。MMSは、1つのプライマリ管理サーバと1つ以上の関連セカンダリ管理サーバで構成されます。MMSの仕組みについては、『Directory and Resource Administrator管理者ガイド』の「Configuring the Multi-Master Set」を参照してください。

2.3.1 DRAアップグレードの計画

NetIQAdminInstallationKit.msiを実行して、DRAインストールメディアを解凍し、正常性検査ユーティリティをインストールして実行します。

アップグレードプロセスを開始する前に、DRAの展開計画を作成してください。展開を計画する際には、以下のガイドラインを考慮してください。

アップグレードを本番環境に適用する前に、アップグレードプロセスを実験環境でテストしてください。テストにより、通常の管理業務に影響を与えることなく、予期しない問題を見つけて解決することができます。
「必要なネットワークポートおよびプロトコル」を参照してください。
各MMSに依存するAAの数を調べます。大多数のAAが特定のサーバまたはサーバセットに依存している場合は、まず最初にそれらのサーバをピーク時以外の時間帯にアップグレードします。
どのAAがDelegation and Configurationコンソールを必要としているかを調べます。この情報は、次のいずれかの方法で取得できます。
- どのAAがビルトインAAグループに関連付けられているかを調べます。
- どのAAがビルトインActiveViewに関連付けられているかを調べます。
- DRAのレポート機能を使用して、セキュリティモデルレポート(ActiveView Assistant Admin DetailsレポートやAssistant Admin Groupsなど)を生成します。
これらのAAに、ユーザインターフェイスのアップグレード計画を知らせてください。
どのAAがプライマリ管理サーバへの接続を必要としているかを調べます。プライマリ管理サーバのアップグレードに対応して、これらのAAのクライアントコンピュータをアップグレードする必要があります。

これらのAAに、管理サーバおよびユーザインターフェイスのアップグレード計画を知らせてください。
アップグレードプロセスを開始する前に、委任、設定、またはポリシーの変更を実装する必要があるかどうかを調べます。環境によっては、この決定をサイトごとに行うことができます。
ダウンタイムを最小限に抑えるために、クライアントコンピュータと管理サーバのアップグレードを調整します。同じ管理サーバまたはクライアントコンピュータ上で旧バージョンのDRAと現バージョンのDRAを実行することはできません。

2.3.2 アップグレード前のタスク

アップグレードインストールを開始する前に、以下のアップグレード前のステップを実行して、各サーバセットでアップグレードの準備を行います。

ステップ	詳細
AD LDSインスタンスのバックアップ	ヘルスチェックユーティリティを開き、AD LDSインスタンスのバックアップチェックを実行して、現在のAD LDSインスタンスのバックアップを作成します。
展開計画の作成	管理サーバとユーザインターフェイス(AAクライアントコンピュータ)をアップグレードするための展開計画を作成します。詳細については、「DRAアップグレードの計画」を参照してください。
セカンダリ管理サーバ1台を、前のバージョンのDRAを実行するための専用サーバにする	オプション: セカンダリ管理サーバ1台を、サイトのアップグレード中に前のバージョンのDRAを実行するための専用のサーバにします。
このMMSにとって必要な変更を加える	このMMSにとって必要な委任、構成、またはポリシー設定に対する変更を加えます。これらの設定を変更するには、プライマリ管理サーバを使用してください。
MMSを同期する	サーバセットを同期して、すべての管理サーバが最新の構成とセキュリティ設定を持つようにします。
プライマリサーバのレジストリをバックアップする	プライマリ管理サーバのレジストリをバックアップします。レジストリ設定をバックアップしておくと、以前の構成およびセキュリティ設定を簡単に復元できます。

メモ:AD LDSインスタンスのバックアップを復元する必要がある場合、次の操作を行います。

［Computer Management］>［Services］で、現在のAD LDSインスタンスを停止します。NetIQDRASecureStoragexxxxxという別のタイトルになります。
以下に示されているように、現在の adamnts.ditファイルをバックアップの adamnts.ditファイルに置き換えます。
- 現在のファイルの場所: %ProgramData%/NetIQ/DRA/<DRAInstanceName>/data/
- バックアップファイルの場所:%ProgramData%/NetIQ/ADLDS/
AD LDSインスタンスを再起動します。

前バージョンのDRAを実行する専用ローカル管理サーバの使用

アップグレードの最中に、１つ以上のセカンダリ管理サーバをローカルで前バージョンのDRAを実行する専用のサーバとして使用すれば、ダウンタイムとリモートサイトへのコストのかかる接続を最小限に抑えることができます。この手順はオプションですが、これによってAAは、展開が完了するまでの間アップグレードプロセス全体を通じて、前バージョンのDRAを使用できるようになります。

以下のアップグレード要件のうち１つ以上があてはまる場合は、このオプションの使用を考慮してください。

ほとんどまたはまったくダウンタイムが必要ない。
多数のAAをサポートする必要があり、すべてのクライアントコンピュータを即座にアップグレードすることは不可能。
プライマリ管理サーバをアップグレードした後も、前バージョンのDRAへのアクセスをサポートし続ける必要がある。
複数のサイトにまたがるMMSが環境に含まれている。

新規のセカンダリ管理サーバをインストールすることも、前バージョンのDRAを実行している既存のセカンダリサーバを指定することもできます。このサーバをアップグレードする場合は、このサーバを最後にアップグレードしなければなりません。アップグレードしない場合は、アップグレードが正常に完了した後で、このサーバから完全にDRAをアンインストールします。

新規のセカンダリサーバの設定

新規のセカンダリ管理サーバをローカルサイトにインストールすれば、コストのかかるリモートサイトへの接続が不要になり、AAが中断なしで前バージョンのDRAの使用を続行できます。複数のサイトにまたがるMMSが環境に含まれている場合は、このオプションを考慮する必要があります。たとえば、ロンドンサイトにあるプライマリ管理サーバと東京サイトにあるセカンダリ管理サーバでMMSが構成されている場合は、ロンドンサイトにセカンダリサーバをインストールして対応するMMSに追加するのが得策です。この追加されたサーバにより、ロンドンサイトからのAAはアップグレードが完了するまでの間前バージョンのDRAを使い続けられるようになります。

既存のセカンダリサーバの使用

既存のセカンダリ管理サーバを、前バージョンのDRA専用のサーバとして使用することができます。セカンダリ管理サーバをアップグレードする予定がないサイトについては、このオプションを考慮する必要があります。既存のセカンダリサーバを専用サーバにできない場合は、新規の管理サーバをこの目的のためにインストールすることを考慮してください。1つ以上のセカンダリサーバを前バージョンのDRAを実行するための専用サーバにすれば、アップグレードが完了するまでの間、AAが中断なしで前バージョンのDRAを使い続けることができます。このオプションは、中央管理モデルを採用している非常に大規模な環境に適しています。

前バージョンのDRAサーバセットの同期

前バージョンのDRAのレジストリをバックアップする前、つまりアップグレードプロセスを開始する前に、サーバセットの同期をとって各管理サーバの設定およびセキュリティ設定を最新の状態にする必要があります。

メモ:このMMSの委任、設定、またはポリシーの設定に必要な変更を加えてください。これらの設定の変更には、プライマリ管理サーバを使用してください。プライマリ管理サーバをアップグレードした後で、委任、設定、またはポリシーの設定を、前バージョンのDRAを実行している管理サーバと同期させることはできません。

既存のサーバセットを同期させるには、次の手順を実行します。

プライマリ管理サーバにBuilt-in Adminとしてログオンします。
MMCインターフェイスを起動します。
左側のウィンドウで、［環境設定管理］を展開します。
［管理サーバ］をクリックします。
右側のウィンドウで、このサーバセットに属する適切なプライマリ管理サーバを選択します。
［プロパティ］をクリックします。
［同期スケジュール］タブで、［今すぐ更新］をクリックします。
同期が正しく完了したことと、すべてのセカンダリ管理サーバが使用可能であることを確認します。

管理サーバのレジストリのバックアップ

管理サーバのレジストリをバックアップすれば、確実に以前の構成に戻すことができます。たとえば、現バージョンのDRAを完全にアンインストールして前バージョンのDRAを使用しなければならなくなった場合、前のレジストリ設定のバックアップがあれば、前の構成とセキュリティ設定を簡単に復旧できます。

ただし、レジストリの編集には注意が必要です。レジストリ内にエラーがあると、管理サーバが予期したとおりに動作しない場合があります。アップグレードプロセス中にエラーが発生した場合は、レジストリ設定のバックアップを使用して、レジストリを復元できます。詳細については、レジストリエディタのヘルプを参照してください。

重要:レジストリを復元するときは、DRAサーバのバージョン、WindowsのOS名、および管理対象のドメイン構成が完全に同じである必要があります。

重要:アップグレードする前に、DRAをホストしているマシンのWindows OSをバックアップするか、マシンの仮想マシンスナップショットイメージを作成してください。

管理サーバのレジストリをバックアップするには、次の手順を実行します。

regedit.exeを実行します。
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mission Critical Software\OnePointノードを右クリックし、［エクスポート］を選択します。
レジストリキーを保存するファイルの名前と場所を指定し、［保存］をクリックします。

2.3.3 DRA管理サーバのアップグレード

次のチェックリストで、アップグレードプロセス全体について説明します。このプロセスを使用して、環境内の各サーバセットをアップグレードしてください。まだ行っていない場合は、正常性検査ユーティリティを使用して、現在のAD LDSインスタンスのバックアップを作成します。

アップグレードプロセスを複数の段階に分けて、一度の1つのMMSをアップグレードすることもできます。アップグレードプロセスでは、旧バージョンのDRAを実行するセカンダリサーバと現バージョンのDRAを実行するサーバを一時的に同じMMSに含めることもできます。DRAは、旧バージョンのDRAを実行する管理サーバと現バージョンのDRAを実行するサーバとの同期をサポートしています。ただし、同じ管理サーバまたはクライアントコンピュータ上で旧バージョンのDRAと現バージョンのDRAを実行することはできません。

DRA 9.2以降のバージョンでは、ワークフロー自動化サーバの構成は、レジストリではなくAD LDSに保存されます。DRA 9.1以前からDRA 9.2以降に更新すると、レジストリ構成が自動的にAD LDSに移動し、すべてのセカンダリサーバに複製されます。

警告:セカンダリ管理サーバは、そのMMSのプライマリ管理サーバをアップグレードするまでアップグレードしないでください。

ステップ	詳細
正常性検査ユーティリティを実行する	スタンドアロンのDRA正常性検査ユーティリティをインストールし、サービスアカウントを使用して実行します。問題があれば解決します。
テストアップグレードを実行する	潜在的な問題を見つけて実働時のダウン時間を最小限に抑えるために、実験環境でテストアップグレードを実行します。
アップグレードの順序を決定する	サーバセットをアップグレードする順序を決定します。
アップグレードのために各MMSを準備する	アップグレードに備えて各MMSの準備を整えます。詳細については、「アップグレード前のタスク」を参照してください。
プライマリサーバをアップグレードする	適切なMMS内のプライマリ管理サーバをアップグレードします。
新規セカンダリサーバをインストールする	(オプション) リモートサイトでのダウンタイムを最小限に抑えるには、最新バージョンのDRAを実行するローカルのセカンダリ管理サーバをインストールします。
ユーザインターフェイスを展開する	ユーザインターフェイスをAssistant Administratorに展開します。
セカンダリサーバをアップグレードする	MMS内のセカンダリ管理サーバをアップグレードします。
DRA Reportingをアップグレードする	DRA Reportingをアップグレードします。
REST拡張機能をアップグレードする	DRA REST拡張機能インストーラを実行します。
正常性検査ユーティリティを実行する	アップグレードの一部としてインストールされた正常性検査ユーティリティを実行します。問題があれば解決します。

プライマリ管理サーバのアップグレード

MMSの準備が整ったら、プライマリ管理サーバをアップグレードします。プライマリ管理サーバのアップグレードが完了するまでは、AAクライアントコンピュータ上のユーザインターフェイスをアップグレードしないでください。詳細については、DRAユーザインターフェイスの展開を参照してください。

メモ:アップグレードの考慮事項と手順の詳細については、『Directory and Resource Administratorリリースノート』を参照してください。

アップグレードを始める前に、アップグレードが開始されることをAAに通知してください。セカンダリ管理サーバを前バージョンのDRAを実行するための専用サーバにした場合は、AAがアップグレード中に前バージョンのDRAを使い続けられるようにするために、そのサーバのことも知らせてください。

メモ:プライマリ管理サーバをアップグレードした後に、そのサーバの委任、構成、またはポリシー設定を、前バージョンのDRAを実行している管理サーバと同期することはできません。

現バージョンのDRAのローカルセカンダリ管理サーバのインストール

ローカルサイトで現バージョンのDRAを実行する新規のセカンダリ管理サーバをインストールすれば、コストのかかるリモートサイトへの接続を最小限に抑えるとともに全体的なダウンタイムを短縮することができ、ユーザインターフェイスの展開をより迅速に進められます。この手順はオプションですが、これによってAAは、展開が完了するまでの間アップグレードプロセス全体を通じて、前バージョンのDRAを使用できるようになります。

以下のアップグレード要件のうち１つ以上があてはまる場合は、このオプションの使用を考慮してください。

ほとんどまたはまったくダウンタイムが必要ない。
多数のAAをサポートする必要があり、すべてのクライアントコンピュータを即座にアップグレードすることは不可能。
プライマリ管理サーバをアップグレードした後も、前バージョンのDRAへのアクセスをサポートし続ける必要がある。
複数のサイトにまたがるMMSが環境に含まれている。

たとえば、ロンドンサイトにあるプライマリ管理サーバと東京サイトにあるセカンダリ管理サーバでMMSが設定されている場合は、東京サイトにセカンダリサーバをインストールして対応するMMSに追加するのが得策です。この追加されたサーバは東京での日常的な管理負荷のバランスをとり、アップグレードが完了するまでの間、どちらのサイトのAAも前バージョンのDRAと現バージョンのDRAの両方を使用できるようになります。さらに、現在のDRAのユーザインターフェイスを即座に展開できるので、AAがダウンタイムを経験することもありません。ユーザインターフェイスのアップグレードの詳細については、DRAユーザインターフェイスの展開を参照してください。

DRAユーザインターフェイスの展開

通常は、プライマリ管理サーバと１つのセカンダリ管理サーバをアップグレードした後で、現在のDRAのユーザインターフェイスを展開しなければなりません。ただし、プライマリ管理サーバを使用する必要があるAAのクライアントコンピュータは、Delegation and Configurationコンソールをインストールして最初にアップグレードしてください。詳細については、DRAアップグレードの計画を参照してください。

CLIまたはADSIプロバイダを通じて頻繁にバッチ処理を実行する場合や、頻繁にレポートを生成する場合は、これらのユーザインターフェイスを専用のセカンダリ管理サーバにインストールすることを考慮してください。それにより、MMS全体の負荷バランスが適切に保たれます。

DRAユーザインターフェイスのインストールをAAに任せることも、グループポリシーを通じてこれらのインターフェイスを展開することもできます。また、Webコンソールを複数のAAに簡単かつ迅速に展開できます。

メモ:同じDRAサーバ上に複数のバージョンのDRAコンポーネントを同時に実行することはできません。AAクライアントコンピュータを徐々にアップグレードするよう計画している場合は、現バージョンのDRAを実行する管理サーバに即座にアクセスできるようにするために、Webコンソールの展開を考慮してください。

セカンダリ管理サーバのアップグレード

セカンダリ管理サーバのアップグレードでは、管理上のニーズに合わせて各サーバを必要に応じてアップグレードできます。また、DRAユーザインターフェイスのアップグレードと展開の計画についても検討してください。詳細については、DRAユーザインターフェイスの展開を参照してください。

たとえば、典型的なアップグレードパスには、次の手順が含まれます。

１つのセカンダリ管理サーバをアップグレードします。
このサーバを使用するAAに対して、適切なユーザインターフェイス(Account and Resource Managementコンソールなど)をインストールするように指示します。
MMS全体をアップグレードするまで、上記のステップ1とステップ2を繰り返します。

アップグレードを始める前に、アップグレードが開始されることをAAに通知してください。セカンダリ管理サーバを前バージョンのDRAを実行するための専用サーバにした場合は、AAがアップグレード中に前バージョンのDRAを使い続けられるようにするために、そのサーバのことも知らせてください。このMMSのアップグレードが完了し、すべてのAAクライアントコンピュータがアップグレード済みのユーザインターフェイスを実行するようになったら、残っている前バージョンのサーバをオフラインにしてください。

DRA Reportingコンポーネントのアップグレード

DRA Reportingをアップグレードする前に、環境がNRC 3.2の最低要件を満たしていることを確認します。インストール要件とアップグレードの考慮事項の詳細については、DRAマニュアルサイトの『 Reporting Center Guide』を参照してください。

ステップ	詳細
DRA Reportingサポートを無効にする	レポーティングコレクタがアップグレード処理中に実行されないように、Delegation and Configurationコンソールの［Reporting Service Configuration］ウィンドウでDRA Reportingサポートを無効にします。
適切な資格情報を使用してSQLインスタンスサーバにログオンする	レポーティングデータベース用のSQLインスタンスをインストールしたMicrosoft Windowsサーバに、管理者アカウントを使用してログオンします。このアカウントにローカル管理者権限とSQL Serverのシステム管理者権限があることを確認します。
DRA Reportingセットアップを実行する	インストールキットのDRAReportingSetup.exeを実行し、インストールウィザードの指示に従います。
NRCセットアップを実行する	条件付き: NRC Webサービスを別のコンピュータにインストールした場合は、Webサービスをインストールしたコンピュータにログオンし、NRCSetup.exeを実行してNRC Webサービスをアップグレードします。メモ:構成データベースを別のサーバにインストールした場合は、構成データベースを先にアップグレードする必要があります
クライアントコンピュータでNRCセットアップを実行する	すべてのNRC WebサービスクライアントコンピュータでNRCSetup.exeを実行します。
DRA Reportingサポートを有効にする	プライマリ管理サーバで、Delegation and Configurationコンソールでレポートを有効にします。

SSRS統合を使用している場合は、レポートを再展開する必要があります。レポートの再展開の詳細については、DRAマニュアルサイトの『NetIQ Reporting Center Reporting Guide』を参照してください。

2.3.4 DRA REST拡張機能のアップグレード

WebコンソールおよびREST拡張機能をDirectory and Resource Administrator 9.2にアップグレードするには、DRA 9.0.1以降のバージョンを使用している必要があります。要件については、「DRA Webコンソールおよび拡張の要件」を参照してください。

DRA Webコンソールおよび拡張機能をアップグレードするには、次の手順を実行します。

DRAインストールキットをダウンロードした後、インストールメディアを解凍した場所に移動し、DRARESTExtensionsInstaller.exeファイルを右クリックし、［管理者として実行］を選択します。
インストールウィザードの指示に従い、インストールが完了したら［終了］をクリックします。

インストールウィザードの手順の詳細については、新しいインストールの手順(DRA REST拡張機能のインストール)を参照してください。

2.3.5 カスタムコンテンツのアップグレード

新しいバージョンのDRAにアップグレードするときに、WebサーバでWebコンソールに対して加えたすべてのカスタマイズを保持したい場合があります。これを簡単に行えるように、DRA REST拡張機能インストーラには、カスタマイズアップグレードユーティリティが組み込まれています。このユーティリティは、REST拡張機能をアップグレードするためにWebサーバでDRARESTExtensionsInstaller.exeを実行したときに、自動的に実行されます。また、このユーティリティは、インストールとは無関係にDRAインストールディレクトリから手動で再実行することもできます。

カスタマイズアップグレードユーティリティのプロセスの一部として、アップグレード開始前にカスタマイズがバックアップされます。アップグレードプロセス中、このユーティリティは、アップグレードによって加えられたすべての変更をログファイルに記録し、自動更新できないカスタマイズ項目についての警告も記録します。

ベストプラクティスとして、アップグレード後にログを確認することをお勧めします。必要に応じて、バックアップフォルダからアップグレード前のカスタマイズをコピーしてカスタマイズをロールバックすることができます。カスタマイズアップグレードユーティリティが開いたら、アップグレードされたカスタマイズを入れるフォルダパスを定義できます。また、自動入力されるデフォルトのパスを使用することもできます。

アップグレードされたカスタマイズおよびカスタマイズのバックアップのためのデフォルトパスは次のとおりです。

デフォルトのカスタムフォルダパス: C:\inetpub\wwwroot\DRAClient\components\lib\ui-templates\custom
デフォルトのバックアップフォルダ: $CustomFolderPath\custom_upgrade_$VERSIONFROM_to_$VERSIONTO_backup