16 スキーマ、データおよびクローン・システムのアップグレード

この章では、スキーマやデータをアップグレードする方法、および停止時間ゼロのアップグレード・メソッドを使用している場合にクローン・システムを作成およびアップグレードする方法を説明します。これが対象のエンタープライズに適切な方法であることを確認するために、停止時間ゼロのアップグレード・メソッドに関するすべての情報を確認することをお薦めします。内容は次のとおりです。

停止時間ゼロのアップグレードを開始する前の前提条件
停止時間ゼロのアップグレードに向けた元のインストールの準備
停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング
宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得
LDAPディレクトリ・サーバーの新しいブランチへの構成データおよびポリシー・データのコピー
クローニングされたコンポーネントおよびサービスの構成
停止時間ゼロのアップグレード中のスキーマのアップグレード
環境の正常な動作の検証
クローニングされたアイデンティティ・システムのアップグレード
アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更
SDKおよびアイデンティティ・システムのカスタマイズのアップグレード
クローニングされたアクセス・システムのアップグレード
SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

注意:

インプレース・アップグレードを行う場合は、この章はスキップしてください。

16.1 停止時間ゼロのアップグレードを開始する前の前提条件

停止時間ゼロのアップグレードを開始する前に、次の情報を把握しておくことをお薦めします。

アップグレードの計画、概念と方法、およびアップグレード処理など、このマニュアルの第I部で説明されているデプロイに関する一般的な情報。
第II部および第III部で説明されているインプレース・アップグレードの詳細。これには、選択するアップグレード・メソッドにかかわらず関連するいくつかの準備タスクも含まれます。
このマニュアルの第IV部で説明されている、手動によるカスタマイズのアップグレード・タスクの実行に関する詳細。これらのタスクは、使用するアップグレード・メソッドにかかわらず、手動で実行する必要があります。
第V部で説明されている一般的な検証タスク。停止時間ゼロのアップグレード・メソッドで実行するタスクは、「環境の正常な動作の検証」で説明されています。
この章、および第15章と第17章に記載されている停止時間ゼロのアップグレードに関するすべての情報。

この章では、Oracle Access Manager 10.1.4のコンポーネントやシステム・コンソールを指している場合でも、新しい製品の用語を使用しています。以前の製品の用語（COREidサーバーおよびAccess Manager）は、アップグレード前の元のインスタンスや元のコンポーネント・インスタンスのクローンを指す場合に使用しています。COREidシステム・コンソールという名前は、以前の（元の）システム・コンソールを使用して実行するアクティビティを指す場合に使用しています。Oracle Access Managerの名前の変更の詳細は、「製品およびコンポーネントの名前の変更」を参照してください。

16.2 停止時間ゼロのアップグレードに向けた元のインストールの準備

この項では、停止時間ゼロのアップグレード・メソッドのために作成するクローン・システムに関連した一意の計画および準備タスクについて説明します。すべての準備手順を実行しないと、問題からのリカバリやアップグレードが失敗した後のロールバックができなくなる可能性があります。

まず、作成するクローンの新しいコンポーネント・プロファイルを追加する必要があります。これを実行するには、既存の（元の）COREidシステム・コンソールを使用します。また、LDAPディレクトリ・サーバーの新しいブランチに作成する元のoblixツリーのコピーに、新しいLDAPディレクトリ・サーバー・プロファイルを追加する必要があります。

新しいプロファイルを作成する際は、元のCOREidシステム・コンソールを使用します。アイデンティティ・システムとアクセス・システムの混合の場合は、元のアクセス・システム・コンソールも使用します。次に例を示します。

アイデンティティ・システムのみ: 次のタスクの概要の1～6のタスクを実行する必要があります。
アイデンティティ・システムおよびアクセス・システムの混合: 次のタスクの概要のすべてのタスクを実行する必要があります。

注意:

タスクの概要には、タスク、およびそのタスクの実行に必要な情報が記載されている項へのリンクが含まれています。次のタスクの概要のように、一部の概要では、説明が実際の項タイトルかつリンクになっています。

タスクの概要: 停止時間ゼロのアップグレードに向けた元のインストールの準備

ホスト・コンピュータをOracle Access Manager 10g（10.1.4.0.1）のサポート・レベルまで上げる
ディレクトリ・サーバー・インスタンスおよびデータの準備
デプロイへの新しいハードウェアまたは以前のインスタンスの追加
システム・コンソールでの計画済COREidサーバー・クローンのプロファイルの追加
システム・コンソールでの計画済WebPassクローンのプロファイルの追加
WebPassクローンのプロファイルとCOREidサーバー・クローンのプロファイルの関連付け
クローニングされたCOREidサーバーの新規ディレクトリ・サーバー・プロファイルの追加

アイデンティティ・システムおよびアクセス・システムの混合の場合: タスク1～7を実行後に次のタスクを実行

アクセス・サーバー・クローンのプロファイルの追加

注意:

Access Managerで使用されるディレクトリ・サーバー・プロファイルに関連するのは、Access Managerのシステム・コンソールのプロファイルのみです。

アクセス・システム・クローンの新規ディレクトリ・サーバー・プロファイルの作成
元のWebGateとアクセス・サーバー・クローンの関連付け: WebGateのアップグレードを延期してWebGateをクローニングしないため、このタスクを実行します。

16.2.1 ホスト・コンピュータをOracle Access Manager 10g（10.1.4.0.1）のサポート・レベルまで上げる

アップグレードを開始する前に、以前のコンポーネントおよびLDAPディレクトリ・サーバーをホスティングしているすべてのコンピュータが、Oracle Access Manager 10g（10.1.4.2.0）でサポートされていることを確認する必要があります。デプロイに新しいコンピュータを追加する場合や、オペレーティング・システムまたはWebサーバーをアップグレードする場合は、アップグレードを開始する前にそれらのシステムを設定することをお薦めします。

最新のサポート情報は、次に示すOracle MetaLinkのWebサイトで確認できます。

     http://metalink.oracle.com

サポートを確認してホスト・コンピュータをサポート・レベルまで上げる

次のようにして、最新のサポート情報をOracle MetaLinkで確認します。
1. Oracle MetaLinkへ移動します。
```
http://metalink.oracle.com
```
2. 指示に従ってOracle MetaLinkにログインします。
3. 「Certify」タブをクリックします。
4. 「View Certifications by Product」をクリックします。
5. 「Application Server」オプションを選択し、「Submit」をクリックします。
6. 「Oracle Identity Manager」を選択し、「Submit」をクリックします。
7. 「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」（html）をクリックして「Oracle Identity Management」ページを表示します。
8. 「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。
ベンダーのマニュアルに記載されている指示に従い、必要に応じて、ホスト・コンピュータのオペレーティング・システム、Webサーバーまたはディレクトリ・サーバーをアップグレードします。
クローン・コンポーネントまたは別の以前のインスタンスをホスティングするために新しいインスタンスを追加し、「デプロイへの新しいハードウェアまたは以前のインスタンスの追加」を参照します。

古いシステムを現在のサポート・レベルに上げる方法の説明は、このマニュアルの対象外です。ホスト・コンピュータ、オペレーティング・システムおよびWebサーバーのアップグレード方法の詳細は、ベンダーのマニュアルを参照してください。

16.2.2 ディレクトリ・サーバー・インスタンスおよびデータの準備

この項では、実行するタスクの概要を説明します。

ディレクトリ接続用の一意のネームスペース: 各ディレクトリ・サーバー・プロファイルには接続情報が含まれます。これには、プロファイル名、適用対象のドメインまたはネームスペース、ディレクトリ・タイプ、および一連の操作要件（読取り、書込み、検索など）が含まれます。クローンで使用する新しいディレクトリ・サーバー・プロファイルを追加する前に、ディレクトリ・サーバーでネームスペースが一意であることを確認することをお薦めします。

オブジェクト・クラス・レベルでのチャレンジ/レスポンス・フレーズの構成: チャレンジ属性およびレスポンス属性が（オブジェクト・クラス・レベルではなく）「従業員」タブ・レベルで構成されている場合、構成データのアップグレードが正しく実行されない可能性があります。このタスクのその他のアクティビティを開始する前に、チャレンジ属性およびレスポンス属性がオブジェクト・クラス・レベルで構成されていることを確認することをお薦めします。

ディレクトリ・インスタンスの準備: ディレクトリ・サーバーの検索サイズ制限パラメータの変更、および特定のディレクトリ・サーバー・タイプに関連するその他のタスクの実行が含まれます。

レプリケートされた環境: レプリケートされた環境がある場合は、マスターで作業する前にレプリケーション承諾を無効化し、レプリカに変更を送信する準備ができたら承諾を有効化できます。たとえば、スキーマのアップグレード前に無効化し、データのアップグレード後に有効化します。

次にリストされている第5章の項を確認し、必要に応じてタスクを実行することをお薦めします。

タスクの概要: 停止時間ゼロのアップグレード前のディレクトリ・サーバー・インスタンスの準備

16.2.3 デプロイへの新しいハードウェアまたは以前のインスタンスの追加

この手順はオプションです。様々な理由で、アップグレードの開始前に、既存のデプロイへの新しいハードウェアまたは以前のインスタンスの追加を検討する場合があります。次に例を示します。

ホスト・コンピュータまたは以前のコンポーネント・インスタンスをさらに追加してデプロイを拡張する場合。
元のインスタンスがWindowsプラットフォームでIIS Webサーバーを使用して実行されている場合、クローンを別のコンピュータ・ホストに配置する必要があります。

この場合、新しいホストに以前のコンポーネント・インスタンスを（クローンとして）インストールし、元のファイル・システムからクローンのファイル・システムにカスタマイズと構成の変更をコピーする必要があります。既存のコンポーネントとの通信にインスタンスで簡易モードまたは証明書モードを使用する場合には、元のインスタンスから新しくインストールされたインスタンスに\configサブディレクトリをコピーし、すべての証明書を正常な状態に維持する必要があります。

これらのタスクは、その他のアップグレード・アクティビティを開始する前に実行することをお薦めします。コンポーネントを追加する場合は、追加する以前の各コンポーネントの完全なインストールを実行することをお薦めします。次の手順に従って、ハードウェアの追加、その他の以前のコンポーネント・インスタンスのインストールおよび設定を実行できます。

アップグレード前のハードウェアおよびその他のコンポーネント・インスタンスの追加

その他の以前のコンポーネントまたはクローン・コンポーネントをホスティングするために新しいハードウェアを追加する前に、次の項のハードウェアに関する考慮事項を確認してください。
- 停止時間ゼロのアップグレードのハードウェア要件
- ホスト・コンピュータをOracle Access Manager 10g（10.1.4.0.1）のサポート・レベルまで上げる
以前のOracle COREidまたはOblix NetPointのインストレーション・ガイドの準備の章の説明に従って、必要に応じて、コンポーネントをホスティングするために新しいシステムを設定します。
以前のOblix NetPointまたはOracle COREidのインストレーション・ガイドの説明、および次の考慮事項を参考にして、その他の以前のコンポーネントをインストールします。
- すべてのコンポーネント: 以前のOracle COREidまたはOblix NetPointのインストレーション・ガイドの準備の章の説明に従って、インストールする特定のコンポーネントの前提タスクを実行します。
- すべてのコンポーネント: 以前のインストールの適切な指定内容に基づいて、質問に答えてアクティビティを実行します。
- アイデンティティ・サーバー: このLDAPディレクトリ・サーバーの最初のアイデンティティ・サーバーであるかどうかを質問された場合は、Noと答えます。
コンポーネントのインストールが成功し、以前のすべてのコンポーネントが正常に動作していることを確認します。
新しいインスタンスの元のシステム・コンソールにプロファイルを追加してから、計画済のすべてのクローン・プロファイルを追加します。

16.2.4 システム・コンソールでの計画済COREidサーバー・クローンのプロファイルの追加

元のCOREidサーバー・インスタンスをクローニングする前に、元のCOREidシステム・コンソールにクローン用のエントリを追加する必要があります。COREidシステム・コンソールにアクセスできるのは、マスター管理者およびマスター・アイデンティティ（またはマスター・アクセス）管理者のみです。

クローンの詳細は、次の例外を除き、元のインスタンスと同一である必要があります。

インスタンス名はクローンごとに変えることをお薦めします。同じインスタンス名を使用する場合は、そのクローンを別のホストに移動することをお薦めします。
クローン・インスタンスがその他のクローン・インスタンスと通信するには、別々のポート番号が必要です。
ホスト・コンピュータの名前が異なる場合があります。

COREidサーバーのクローン用にエントリを追加するには、NetPoint管理者またはマスター・アイデンティティ管理者のログイン証明書および権限のいずれかが必要です。

次の手順では、リリース6.1.1のインストールを使用します。リリースや詳細はユーザーによって異なります。詳細は、Oracle COREidの管理ガイドを参照してください。

システム・コンソールへのCOREidサーバー・クローンのプロファイルの追加

ブラウザで、元のCOREidシステム・コンソールへのパスを使用します。次に例を示します。
```
   https://hostname:port/identity/oblix
```
このサンプルURLで、hostnameはWebPassがインストールされているコンピュータの名前、portはWebPassのWebサーバー・ポートです。HTTPまたはHTTPSプロトコルを使用してログインできます。
COREidシステム・コンソールをクリックして、マスター管理者またはマスター・アイデンティティ管理者として認可されているユーザーとしてログインします。
システム・コンソールで、「システム管理」→「システム構成」をクリックします。
左側のナビゲーション・ペインで「COREidサーバーの構成」を選択します。

すべてのCOREidサーバーをリスト・ページが表示されたら、既存のCOREidサーバーの名前をダブルクリックして指定内容を表示し、参照用に印刷します。

注意:

LDAPディレクトリ・サーバーの構成ページで、インスタンスとLDAPディレクトリ・サーバーの間で使用されているトランスポート・セキュリティ・モードを含むディレクトリ・サーバー詳細を確認できます。たとえば、「ディレクトリ・オプションの構成」をクリックして、「ディレクトリ・サーバーの構成」ページのディレクトリ・サーバー詳細の下にある「ディレクトリ・サーバー・セキュリティ・モード」を探します。詳細は、LDAPディレクトリ・サーバー・プロファイルの名前をクリックします。

「システム管理」→「システム構成」をクリックして「COREidサーバーの構成」を選択し、「追加」ボタンをクリックします。
新規COREidサーバーの追加ページで、次のようにクローンの詳細を入力します。
- 名前: クローン・インスタンスの一意の名前で、クローンのポート番号を含めることができます。たとえば、clone_ois_7022のようになります。
- ホスト名: クローニングされたCOREidサーバーが実行されるコンピュータの名前で、元のインスタンスとは異なるホストにできます。
- ポート: クローニングされたCOREidサーバーの新しいポート番号。たとえば、7022のようになります。
- 残りは、元のCOREidサーバー・インスタンスの情報とクローンの情報を同一にする必要があります。
図16-1に、値が入力されたサンプル・ページを示します。

図16-1 クローンの詳細が入力されたリリース6.1.1の新規COREidサーバーの追加ページのサンプル

「図16-1 クローンの詳細が入力されたリリース6.1.1の新規COREidサーバーの追加ページのサンプル」の説明
「保存」をクリックして終了し、新しい情報を保存します（保存せずに終了する場合は「取消」）。
この手順のステップを繰り返して、追加およびアップグレードされるクローニングされた各COREidサーバーの新しいインスタンスを定義します。
次のように続行します。
1. 成功: 「システム・コンソールでの計画済WebPassクローンのプロファイルの追加」に進みます。
2. 失敗: システム・コンソールのエントリに問題がある場合は、「システム・コンソールへの入力情報に関する問題からのリカバリ」を参照します。

16.2.5 システム・コンソールでの計画済WebPassクローンのプロファイルの追加

既存のWebPassインスタンスをクローニングする前に、元のCOREidシステム・コンソールで既存のWebPassの指定内容をミラー化するエントリを追加する必要があります。COREidシステム・コンソールにアクセスできるのは、マスター管理者およびマスター・アイデンティティ（またはマスター・アクセス）管理者のみです。

コンポーネントをクローニングする際には、Windowsレジストリは更新されません。IIS Webサーバーでは、レジストリのWebコンポーネントのエントリが必要なため、これが原因で問題が発生する可能性があります。元のWebコンポーネントでIIS Webサーバーを使用している場合には、新しいIIS Webサーバー・インストールがある別のWindowsホストにクローンを格納する必要があります。このような場合、コンピュータのホスト名はクローンとは異なります。

元のインスタンスの詳細とクローン・インスタンスの詳細には、クローン・インスタンス名およびそのクローンのWebサーバー・ポート番号の違いあります。

インスタンス名はクローンごとに変えることをお薦めします。同じインスタンス名を使用する場合は、そのクローンを別のホストに移動することをお薦めします。
クローン・インスタンスがその他のクローン・インスタンスと通信するには、別々のポート番号が必要です。
ホスト・コンピュータの名前が異なる場合があります。

WebPassクローン用にエントリを追加するには、NetPoint管理者またはマスター・アイデンティティ管理者のログイン証明書および権限のいずれかが必要です。次の手順は、リリース6.1.1のインストールに基づいており、実行が必要なステップを説明します。詳細は、Oracle COREidの管理ガイドを参照してください。

システム・コンソールでのクローン用のWebPassプロファイルの追加

COREidシステム・コンソールで、「システム管理」タブ→「システム構成」タブをクリックし、左側の列の「Webパス」をクリックします。

「すべてのWebパスをリスト」ページが表示されます。
WebPassインスタンスの名前をクリックして指定内容を表示し、参照用に印刷します。
「すべてのWebパスをリスト」ページで「追加」をクリックします。

「新規Webパスの追加」ページが表示されます。

「新規Webパスの追加」ページで、次のようにクローンの情報を入力します。

名前: WebPassインスタンス・クローンの名前で、クローンのポート番号を含めることができます。たとえば、clone_webpass_84のようになります。

注意:

このインスタンスに付けて保存する名前は変更できません。名前を変更するには、インスタンスを削除して、別の名前で再構成する必要があります。

ホスト名: クローニングされたWebPassインスタンスが実行されるコンピュータの名前で、元のインスタンスのホストと異なる場合があります。
ポート: クローニングされたWebPassおよび新しいWebサーバーの新しいポート番号。たとえば、84のようになります。
残りは、クローンの情報を元のWebPassインスタンスの情報と同一にする必要があります。

図16-2 クローンの詳細が入力されたリリース6.1.1の「新規Webパスの追加」ページのサンプル

「図16-2 クローンの詳細が入力されたリリース6.1.1の「新規Webパスの追加」ページのサンプル」の説明

「保存」をクリックして、クローニングされたWebPassの詳細の定義を終了します（または、保存せずに終了する場合は「取消」）。
この手順のステップを繰り返して、元のインストールの各WebPassのクローン・インスタンスを定義します。
次のように続行します。
1. 成功: 「WebPassクローンのプロファイルとCOREidサーバー・クローンのプロファイルの関連付け」に進みます。
2. 失敗: システム・コンソールのエントリに問題がある場合は、「システム・コンソールへの入力情報に関する問題からのリカバリ」を参照します。

16.2.6 WebPassクローンのプロファイルとCOREidサーバー・クローンのプロファイルの関連付け

システム・コンソールを使用して、COREidサーバー・クローンとWebPassクローンを関連付ける必要があります。クローンの関連付けでは、元のCOREidサーバーとWebPassの関連付けをミラー化する必要があります。そのため、2つの手順を実行する必要があります。

次のタスクの概要は、リリース6.1.1のインストールに基づいており、実行が必要なステップを説明します。詳細は、Oracle COREidの管理ガイドを参照してください。

タスクの概要: COREidサーバー・クローンとWebPassクローンの関連付け

WebPassと関連付けられた既存のCOREidサーバーの詳細の表示
COREidサーバー・クローンとWebPassクローンの関連付け

16.2.6.1 WebPassと関連付けられた既存のCOREidサーバーの詳細の表示

次の手順では、特定のWebPassインスタンスと関連付けられた既存のCOREidサーバーの詳細を表示する方法を説明します。この情報は、2通りに活用できます。

クローン環境: クローン環境に、元のインストールと同じ関連付けが含まれていることを確認できます。
元の環境: WebPassと関連付けられている元のCOREidサーバーをアップグレードし、その他のCOREidサーバー・インスタンスをアップグレードする前に、関連付けられたWebPassをアップグレードします。

既存のCOREidサーバーとWebPassの関連付けの表示

COREidシステム・コンソールで、「システム管理」タブ→「システム構成」タブをクリックし、左側のナビゲーション・ペインの「Webパスの構成」をクリックします。

「すべてのWebパスをリスト」ページが表示されます。このページで、WebPassを追加、変更または削除できます。
「すべてのWebパスをリスト」ページで、（クローンではなく）元のWebPassの名前をクリックします。

「Webパスの詳細」ページが表示されます。
アイデンティティ・サーバーをリスト・ボタンをクリックします。

既存のWebPassに構成されたプライマリ・サーバーおよびセカンダリ・サーバーがリストされたページが表示されます。
参照用に印刷し、必要な場合には、COREidサーバーの名前をクリックして詳細を表示します。

「アイデンティティ・サーバーの詳細」ページが表示されます。

16.2.6.2 COREidサーバー・クローンとWebPassクローンの関連付け

次の手順でアクティビティを実行し、COREidサーバー・クローンを適切なWebPassクローンと関連付けます。前の手順「WebPassと関連付けられた既存のCOREidサーバーの詳細の表示」で収集した情報に基づいて関連付けを決定します。

COREidサーバー・クローンとWebPassクローンの関連付け

COREidシステム・コンソールで、「システム管理」タブ→「システム構成」タブをクリックし、左側のナビゲーション・ペインの「Webパスの構成」をクリックします。
「すべてのWebパスをリスト」ページで、WebPassクローンの名前をクリックします。
「Webパスの詳細」ページで、「COREidサーバーのリスト」をクリックして、WebPassに関連付けられているプライマリおよびセカンダリ・サーバーがリストされているページを表示します（空の場合もあります）。
「追加」をクリックします。
「サーバーの選択」ドロップダウン・リストで、WebPassクローンと関連付けるCOREidサーバー・クローンを選択します。
元の関連付けの情報に基づいて、そのクローンCOREidサーバーがプライマリ・サーバーとセカンダリ・サーバーのいずれであるかを特定し、その関連付けのこの情報およびその他の情報が元の関連付けをミラー化していることを確認します。

この情報は、COREid関連のロード・バランシングおよびフェイルオーバーに必要です。
「追加」をクリックして、このCOREidサーバー・クローンをWebPassクローンに関連付けます（または、この操作を終了してもう一度やり直すには「取消」をクリックします）。
この手順のステップを繰り返して、すべてのCOREidサーバー・クローンと、停止時間ゼロのアップグレード中に使用するWebPassクローンを関連付けます。

16.2.7 クローニングされたCOREidサーバーの新規ディレクトリ・サーバー・プロファイルの追加

計画済のクローン用に新しいディレクトリ・サーバー・プロファイルを追加するためにこの手順を実行する必要があるのは、元のディレクトリ・サーバー・プロファイルがCOREidサーバー（Access Managerおよびアクセス・サーバー）ごとに異なる場合のみです。すべての既存のCOREidサーバーおよびアクセス・サーバーにより、元のディレクトリ・サーバー・プロファイルが使用されている場合は、このタスクをスキップできます。

COREidシステム・コンソールにアクセスできるのは、マスター管理者およびマスター・アイデンティティ管理者のみです。元のインスタンスの既存のディレクトリ・プロファイルと同じ数だけ、クローン・インスタンスのディレクトリ・プロファイルを追加する必要があります。プロファイルが対応できるのはクローン・インスタンスのみで、元のプロファイルとは異なる名前が付けられます。

新しいブランチは、元のoblix構成およびポリシー・ブランチが存在するのと同じLDAPディレクトリ・サーバーに作成されます。LDAPディレクトリ・サーバーのコンピュータ名、または新しいブランチのポート番号は変更されません。

元のインストールにデータベース・インスタンス・プロファイルが構成されている場合、アイデンティティ・サーバーおよびアクセス・サーバー用に作成する新しいLDAPディレクトリ・サーバー・プロファイルでは、同じデータベース・インスタンスが使用されます。ただし、データベース・インスタンス・プロファイルでは、新しいブランチのネームスペース（ユーザー・データの検索ベースとも呼ばれる）が使用されます。

複数の検索ベース（非結合検索ベースとも呼ばれる）がある場合には、新しいプロファイルでは元のプロファイルで使用されているのと同じ非結合検索ベースが使用されます。非結合検索ベースは手動で設定する必要があります。

次の手順では、リリース6.1.1のシステム・コンソールを使用します。環境や詳細はユーザーによって異なります。詳細は、以前のNetPointまたはOracle COREidの管理ガイドを参照してください。

アイデンティティ・システム・クローン用の新しいLDAPディレクトリ・サーバー・プロファイルの入力

「ディレクトリ・サーバー・インスタンスおよびデータの準備」の説明に従って、ディレクトリ・サーバーが準備されていることを確認します。
COREidシステム・コンソールで、「システム管理」タブ→「システム構成」タブをクリックし、左側の列の「ディレクトリ・オプションの構成」をクリックします。
左側の列の「ディレクトリ・オプションの構成」をクリックします。
サーバー・プロファイルの構成ページで、既存のディレクトリ・プロファイルの名前をクリックして指定内容を表示し、参照用に印刷します。
ディレクトリ・サーバー・プロファイルの構成ページで、ラベル「LDAPディレクトリ・サーバー・プロファイルの構成」の下にある「追加」ボタンをクリックし、「ディレクトリ・サーバー・プロファイルの作成」ページを表示します。

「ディレクトリ・サーバー・プロファイルの作成」ページで、このプロファイルの名前、元の検索ベース、このプロファイルを使用するクローン・サーバーを追加し、元のプロファイルを参照してLDAPディレクトリ・サーバーの詳細を入力します。

名前: このプロファイルの名前。クローンにより使用されます（たとえば、クローニングされたCOREidサーバー・インスタンスにより使用されます）。

この名前は、情報提供のみを目的としています。アイデンティティ・システムでは、COREidシステムのインストール中に自動的に作成されるすべてのデフォルトのLDAPディレクトリ・サーバー・プロファイルに、デフォルトの<Identity Server id>というネーミング規則が使用されます。ただし、このプロファイルを使用するのはクローン・コンポーネントのみです。

ネームスペース: 元のLDAPディレクトリ・サーバー・プロファイルに指定された元の検索ベース。新しいブランチと元のブランチの両方によって使用されます。

注意:

このネームスペースが、その他のLDAPディレクトリ・サーバー・プロファイルのネームスペースと重複しないように注意してください。ネームスペースが重複するとエントリが重複します。ネームスペースの重複の例外として、Microsoft Active DirectoryサブドメインのLDAPディレクトリ・サーバー・プロファイルと、oblix構成ベース（構成DNとも呼ばれる）を含むLDAPディレクトリ・サーバー・プロファイルがあげられます。

このページの「使用」領域で、（元のサーバーではなく）このプロファイルを使用するクローン・サーバーを選択します。
残りの詳細は、クローン・プロファイルを元のプロファイルと同一にする必要があります。

「プロファイルの有効化」の隣にあるオプションをクリックします。

クローン・プロファイルは図16-3のようになります。

図16-3 リリース6.1.1のクローンの「ディレクトリ・サーバー・プロファイルの作成」ページのサンプル

「図16-3 リリース6.1.1のクローンの「ディレクトリ・サーバー・プロファイルの作成」ページのサンプル」の説明
必要に応じて、「保存」、「取消」または「リセット」を選択します。

「OK」をクリックして追加を確認します。

注意:

クローンを使用する準備ができるまで、新しいプロファイルを有効化するために、アイデンティティ・サーバーまたはアクセス・サーバーを再起動しないでください。

次のように続行します。
1. 成功（アイデンティティ・システムのみ）: 新しいディレクトリ・サーバー・プロファイルを作成して、既存の各ディレクトリ・サーバー・プロファイルのクローン・インスタンスに対応するには、必要に応じてこの手順全体を繰り返します。「宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得」を参照してください。
2. 成功（アイデンティティ・システムおよびアクセス・システムの混合）: 「アクセス・サーバー・クローンのプロファイルの追加」に進みます。
3. 失敗: 「システム・コンソールへの入力情報に関する問題からのリカバリ」に進みます。

詳細は、以前のNetPointまたはOracle COREidの管理ガイドを参照してください。

16.2.8 Access Managerクローンのエントリの概要

Access Managerのシステム・コンソールにはエントリはなく、Access Managerのクローンにエントリは必要ありません。Access Managerが使用するディレクトリ・プロファイルに関連するのは、Access Managerに関連するシステム・コンソールのエントリのみです。次のように続行します。

アイデンティティ・システムのみ: 「停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング」に進みます。
アイデンティティ・システムおよびアクセス・システムの混合: 次の項の「アクセス・サーバー・クローンのプロファイルの追加」に進みます。

16.2.9 アクセス・サーバー・クローンのプロファイルの追加

次のタスクは、元のインストールがアイデンティティ・システムとアクセス・システムの混合デプロイの場合にのみ実行します。それ以外の場合は、「停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング」にスキップします。

アクセス・サーバー・クローンを作成する前に、アクセス・システム・コンソールで各クローン用に新しいインスタンスを追加する必要があります。クローンの指定内容の大部分は、クローンが一時的に置き換えられる元のアクセス・サーバーの指定内容をミラー化する必要があります。

インスタンス名はクローンごとに変えることをお薦めします。同じインスタンス名を使用する場合は、そのクローンを別のホストに移動することをお薦めします。
クローン・インスタンスがその他のクローン・インスタンスと通信するには、別々のポート番号が必要です。
ホスト・コンピュータの名前が異なる場合があります。

アクセス・サーバーのクローン用にエントリを追加するには、NetPoint管理者またはマスター・アクセス管理者のログイン証明書および権限のいずれかが必要です。

次の手順では、リリース6.1.1のインストールを使用します。リリースや詳細はユーザーによって異なります。詳細は、以前のNetPointまたはOracle COREidの管理ガイドを参照してください。

計画済の各アクセス・サーバー・クローンのプロファイルを追加する手順

ブラウザで、元のアクセス・システム・コンソールに移動します。次に例を示します。
```
     http://hostname:port/access/oblix
```
このサンプルURLで、hostnameはWebサーバーをホスティングするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/access/oblixはアクセス・システム・コンソールに接続します。
「アクセス・システム・コンソール」リンクをクリックします。
アクセス・システム・コンソールで、サイド・ナビゲーション・バーが表示されたら、「アクセス・システム構成」タブ→「アクセス・サーバー構成」をクリックします。
既存のアクセス・サーバー・インスタンスの名前をクリックして指定内容を表示し、参照用に印刷します。
サイド・ナビゲーション・バーで「アクセス・サーバー構成」をクリックして、「追加」をクリックします。
「新規アクセス・サーバーの追加」ページで、次のようにクローンの詳細を入力します。
- 名前: クローンのアクセス・サーバー・インスタンスの名前。必要な場合には、クローンのポート番号を含めることができます。たとえば、clone_aaa_7023のようになります。
- ホスト名: クローニングされたアクセス・サーバーが実行されるコンピュータの名前。既存のアクセス・サーバーのホストと異なるホストにすることもできます。
- ポート: クローニングされたアクセス・サーバーの新しいポート番号。たとえば、7023のようになります。
- 残りは、クローンの情報を元のアクセス・サーバー・インスタンスの情報と同一にする必要があります。
  
  図16-4に、この例の入力が完了したページを示します。詳細はユーザーによって異なります。
  
  図16-4 リリース6.1.1のクローンの「新規アクセス・サーバーの追加」ページのサンプル
  
  「図16-4 リリース6.1.1のクローンの「新規アクセス・サーバーの追加」ページのサンプル」の説明
「保存」をクリックして、クローニングされたアクセス・サーバーの詳細の定義を終了します（または、保存せずに終了する場合は「取消」）。
この手順のステップを繰り返し、停止時間ゼロのメソッドを使用してアップグレードするクローニングされた各アクセス・サーバーの新しいインスタンスを定義します。
次のように続行します。
1. 成功: 「アクセス・システム・クローンの新規ディレクトリ・サーバー・プロファイルの作成」に進みます。
2. 失敗: システム・コンソールのエントリに問題がある場合は、「システム・コンソールへの入力情報に関する問題からのリカバリ」を参照します。

16.2.10 アクセス・システム・クローンの新規ディレクトリ・サーバー・プロファイルの作成

アイデンティティ・システムおよびアクセス・システムの混合デプロイでは、アクセス・サーバー・インスタンスの計画済クローン用の新しいディレクトリ・プロファイル・インスタンスの作成が必要な場合があります。このタスクを実行するのは、元のディレクトリ・プロファイルがCOREidサーバー（Access Managerおよびアクセス・サーバー）ごとに異なる場合のみです。すべての既存のCOREidサーバーおよびアクセス・サーバーにより、元のディレクトリ・プロファイルが使用されている場合は、このタスクをスキップできます。

アクセス・システム・コンソールにアクセスできるのは、マスター管理者およびマスター・アクセス管理者のみです。元のインスタンスの既存のディレクトリ・サーバー・プロファイルと同じ数だけ、クローン・インスタンスのディレクトリ・サーバー・プロファイルを追加する必要があります。プロファイルが対応できるのはクローン・インスタンスのみで、元のプロファイルとは異なる名前が付けられます。

デフォルトのディレクトリ・プロファイルは、アクセス・サーバーのインストール中にアクセス・サーバー用に作成されます。アクセス・システム・コンソールで使用可能なLDAPディレクトリ・サーバーの詳細およびディレクトリ・サーバー・プロファイルには、構成データおよびポリシー・データのディレクトリ・プロファイルが含まれます。

複数のアクセス・サーバー・インスタンスをインストールする場合、各サーバーでは、同じデフォルトのLDAPディレクトリ・サーバー・プロファイルが使用されます。特定のアクセス・サーバー・インスタンスの共有LDAPディレクトリ・サーバー・プロファイルを変更すると、その他すべてのアクセス・サーバー・インスタンスが影響を受けます。これらのサーバーのプロファイルを変更しなくても、次の操作を実行すると警告が表示されます。

サーバー構成の表示
サーバーの再起動
サーバーの再構成

各ディレクトリ・サーバー・プロファイルには、接続情報が含まれます。これには、プロファイル名、適用対象のドメインまたはネームスペース、ディレクトリ・タイプ、および一連の操作要件（読取り、書込み、検索など）が含まれます。クローンで使用する新しいディレクトリ・サーバー・プロファイルを追加する前に、ディレクトリ・サーバーでネームスペースが一意であることを確認することをお薦めします。

次の手順では、元のアクセス・システム・コンソールを使用して、アクセス・システム・クローンのディレクトリ・サーバー・プロファイルを追加する方法を説明します。この例では、リリース6.1.1のアクセス・システムを使用します。アクセス・システムのリリースや詳細はユーザーによって異なります。

クローニングされたアクセス・システム・コンポーネントのディレクトリ・プロファイルを追加する手順

「ディレクトリ・サーバー・インスタンスおよびデータの準備」の説明に従って、ディレクトリ・サーバーが準備されていることを確認します。
元のアクセス・システム・コンソールから、「システム構成」→「サーバー設定の表示」をクリックします。

「サーバー設定の表示」ページが表示されます。
「LDAPディレクトリ・サーバー・プロファイルの構成」ラベルの下で、Access Managerのディレクトリ・プロファイルの名前をクリックして元の指定内容を表示し、参照用に印刷します。
左側の列の「サーバー設定の表示」をクリックし、「LDAPディレクトリ・サーバー・プロファイルの構成」ラベルの下にある「追加」をクリックして、「ディレクトリ・サーバー・プロファイルの作成」ページを表示します。
「ディレクトリ・サーバー・プロファイルの作成」ページで、このクローン・プロファイルの名前とネームスペースを入力して、このプロファイルを使用するクローン・サーバーを選択し、元のプロファイルを参照してLDAPディレクトリ・サーバーの詳細を入力します。
- 名前: クローニングされたアクセス・システム・コンポーネントによって使用されるこのプロファイルの名前。
- ネームスペース: ユーザー・データの元の検索ベース。
- このページの「使用」領域で、（元のサーバーではなく）このプロファイルを使用するクローン・サーバーを選択します。
- 残りの詳細は、このプロファイルを元のプロファイルと同一にする必要があります。
「プロファイルの有効化」を選択します。
必要に応じて、「保存」、「取消」または「リセット」を選択します。

「OK」をクリックして追加を確認します。

注意:

クローンを使用する準備ができるまで、新しいプロファイルを有効化するために、Access Manager Webサーバーまたはアクセス・サーバー・サービスを再起動しないでください。

この手順のステップをすべて繰り返して、Access Managerにより使用される元の各プロファイルの新しいプロファイル・インスタンスを作成します。
この手順のステップを繰り返し、元のアクセス・サーバーにより使用される既存のディレクトリ・サーバー・プロファイルと同じ数だけ、アクセス・サーバー・クローンの新しいディレクトリ・サーバー・プロファイルを作成します。

次のように続行します。

成功: 「元のWebGateとアクセス・サーバー・クローンの関連付け」に進みます。

注意:

Access Managerのシステム・コンソールにはエントリはなく、Access Managerのクローンにエントリは必要ありません。Access Managerが使用するディレクトリ・プロファイルに関連するのは、Access Managerに関連するシステム・コンソールのエントリのみです。

失敗: システム・コンソールのエントリに問題がある場合は、「システム・コンソールへの入力情報に関する問題からのリカバリ」を参照します。

16.2.11 元のWebGateとアクセス・サーバー・クローンの関連付け

WebGateインスタンスのクローンを作成しないでください。かわりに、元のWebGateを構成して、クローニングされたアクセス・サーバーと連動することをお薦めします。

セカンダリ・サーバーとしてのクローニングされたアクセス・サーバーと連動するには、元の各WebGateを再構成する必要があります。これは、元の各WebGateのセカンダリ・アクセス・サーバーとしてクローンのアクセス・サーバーを追加することで、手動で実行されます。

一般的に、以前のアクセス・サーバーには、後続のWebGateとの互換性はありません。たとえば、リリース6.1.1のアクセス・サーバーの場合、リリース6.5以降のWebGateとの互換性はありません。ただし、以前のアクセス・サーバーをアップグレードすると、以前のカスタム・プラグインおよび以前のWebGateとの下位互換性が自動的に備わります。そのため、元のWebGateのアップグレードを延期できます。下位互換性の詳細は、第4章を参照してください。

元のWebGateのクローンを作成しないでください。かわりに、元のWebGateを構成して、クローニングされたアクセス・サーバーと連動させます。ある時点で元の環境とクローン環境の分離を決定した場合は、「元の環境とクローン環境の分離の概要」を参照してください。

注意:

WebGateが1つのみの場合は、そのWebGateのアップグレード中（またはロールバック中）は停止します。停止を避けるため、WebGateを複数用意することをお薦めします。

この手順では、リリース6.1.1のシステム・コンソールを使用します。システムや詳細はユーザーによって異なります。詳細は、以前のNetPointまたはOracle COREidの管理ガイドを参照してください。代替手順は、「元のWebGateおよびクローンのアクセス・サーバーを関連付ける代替手順」を参照してください。

アクセス・サーバー・クローンを元のWebGateと関連付ける手順

アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・ゲート構成」をクリックします。
すべてのNetPointアクセス・ゲートをリスト・ページで元のWebGateの名前をクリックします。
「追加」をクリックし、元のWebGateと通信するためにアクセス・サーバー・クローンを構成します。
「サーバーの選択」リストからアクセス・サーバー・クローンを選択します。
「優先順位の選択」オプションから「セカンダリ」を選択します。
「接続数」フィールドに、このWebGateクローンでアクセス・サーバー・クローンに対して確立できる接続の最大数を入力します。

デフォルトは1です。ページは、図16-5のサンプルのようになります。

図16-5 元のWebGateをアクセス・サーバー・クローンと関連付ける際のリリース6.1.1のサンプル・ページ

「図16-5 元のWebGateをアクセス・サーバー・クローンと関連付ける際のリリース6.1.1のサンプル・ページ」の説明
「追加」をクリックしてこのサーバーの構成を完了するか、「戻る」をクリックして前の画面に戻ります。
リンクをクリックしてサマリーを表示し、今後の使用に備えてこのページを印刷します。
ステップ3～ステップ7を繰り返し、必要な場合には、別の元のWebGateとアクセス・サーバー・クローンを関連付けます。
次のように続行します。
1. 成功: 「停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング」に進みます。
2. 失敗: システム・コンソールのエントリに問題がある場合は、「システム・コンソールへの入力情報に関する問題からのリカバリ」を参照します。

16.2.11.1 元のWebGateおよびクローンのアクセス・サーバーを関連付ける代替手順

WebGateが大量にある場合は、この代替方法を使用して、元のWebGateとアクセス・サーバー・クローンを関連付けた方が簡単な場合があります。この代替方法には、次のldifテンプレートの変更およびインポートが含まれます。

注意:

このテンプレートでは、一度に1つのWebGateのみが構成されます。複数のWebGateを構成するには、個々のWebGateテンプレートを作成して連結する必要があります。

例16-1 WebGateを再構成するLDIFテンプレート

Entry 1
dn: obname=%UniqueIdentifier%,obapp=PSC,o=Oblix,%OblixBase%

obname: %UniqueIdentifier%
obMaxAAAServerConnections: %NoOfConnections%
obServerID: obname=%AAASeverId%,obapp=PSC,o=Oblix,%OblixBase%
objectClass: top
objectClass: oblixAAAServerIDNode
obver: %OAMVer%

Entry 2
dn: obname=%WebGateId%,obapp=PSC,o=Oblix,%OblixBase%
changetype: modify
replace: %ServerType%
%ServerType%: %ExistingAAAS%:%UniqueIdentifier%

次の手順では、WebGateテンプレートを編集して、アクセス・サーバーとWebGateを関連付ける方法を説明します。

注意:

Entry 2の編集時には、%AAASeverId%および%WebGateId%を一意の識別子として一緒に使用できます。WebGateにその内部で動作する既存のアクセス・サーバーが構成されていない場合、Entry 2のreplace: %ServerType%をadd: %ServerType%に置き換える必要があります。

環境に合せてテンプレートを編集する手順

Entry 1を次のように編集します。
- %UniqueIdentifier%を選択した一意のタイプスタンプに置き換えます。次に例を示します。
```
20070101T44444444444
```
- %OblixBase%を元のOblixベースに置き換えます。次に例を示します。
```
o=company,c=us
```
- %AAASeverId%をクローンのアクセス・サーバー識別子に置き換えます。次に例を示します。
```
AAA_new
```
- %NoOfConnections%を名前付きアクセス・サーバーに対する最大接続数に置き換えます。次に例を示します。
```
1
```
- %OAMVer%を現在のWebGateリリースに置き換えます。次に例を示します。
```
6.1.0
```
  リリース番号の詳細は、表15-2「MigrateOAMの引数および指定内容のサマリー」の-fオプションについての説明を参照してください。
Entry 2を次のように編集します。
- %OblixBase%を元のOblixベースに置き換えます。次に例を示します。
```
o=company,c=us
```
- %WebGateId%を、WebGateの設定時にシステム・コンソールに入力したWebGate名に置き換えます。次に例を示します。
```
WebGate_one
```
- プライマリ・サーバー接続の場合は、%ServerType%をobAAAPrimaryServerIDに置き換えます（WebGateへのセカンダリ・サーバー接続の場合はobAAASecondaryServerIDに置き換えます）。
- %ExistingAAAS%を%ServerType%属性の値に置き換えます。次に例を示します。
```
obAAAPrimaryServerID
```
  リリース番号の指定の詳細は、表15-2「MigrateOAMの引数および指定内容のサマリー」の-fオプションについての説明を参照してください。
- %UniqueIdentifier%をEntry 1で指定したタイムスタンプと置き換えます。次に例を示します。
```
20070101T44444444444
```
編集したファイルを例16-2のファイルと比較します。
このLDIFファイルをLDAPディレクトリ・サーバーにインポートします。
アクセス・システム・コンソールに関連付けが表示されることを確認します。
再構成する次のWebGateに対してこの手順全体を繰り返します。

例16-2 編集したWebGateテンプレートのサンプル

Entry 1

dn: obname=20070101T44444444445,obapp=PSC,o=Oblix,o=company,c=us
obname: 20070101T44444444445
obMaxAAAServerConnections: 1
obServerID: obname=Reconf_AAA2,obapp=PSC,o=Oblix,o=company,c=us
objectClass: top
objectClass: oblixAAAServerIDNode
obver: 6.1.0

Entry 2
dn: obname=Reconf_WG,obapp=PSC,o=Oblix,o=company,c=us
changetype: modify
replace: obAAAPrimaryServerID
obAAAPrimaryServerID: 20070228T21065545822:20070101T44444444445

16.2.12 システム・コンソールへの入力情報に関する問題からのリカバリ

クローン・インスタンスのエントリに問題がある場合は、プロファイルの入力中に「取消」ボタンをクリックして、最初からプロファイルを入力しなおします。

情報の入力後に問題を見つけた場合は、システム・コンソールでプロファイルを編集するか、プロファイルをすべて削除して、クローン用の新しいプロファイルを作成できます。

クローンの詳細の入力中における問題からのリカバリ

システム・コンソールを使用して、以前のNetPointまたはOracle COREidの管理ガイドの説明に従って、適切に次のアクティビティを実行します。
- 情報を再選択または再入力するか、「取消」ボタンをクリックします。
- 保存したプロファイルを変更するには、プロファイルを選択して「変更」ボタンをクリックします。
- プロファイルを削除するには、プロファイルを選択して「削除」ボタンをクリックします。
必要な場合には、システム・コンソールでクローンの情報を再入力します。

16.2.13 クローンの詳細入力後における開始点へのロールバック

ロールバックを行うと、元の構成の元の設定のみの開始点に戻ります。すべてのクローン・エントリが削除され、クローン環境に加えたその他の変更内容もすべて削除されます。

この段階でロールバックするには、クローンおよびクローン用に作成されたWebサーバー・インスタンスを削除します。クローン・コンポーネント用の元のシステム・コンソールに追加されたエントリも削除する必要があります。

クローンの詳細の入力後に開始点へロールバックする手順

元のシステム・コンソールで、すべてのクローン用に追加されたエントリを削除します。
クローン環境をサポートするために行ったその他すべての変更を元に戻します。
元のインストールを使用して続行するか、新しくアップグレードを開始します。

16.3 停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング

この項では、停止時間ゼロのアップグレードの実行時に、元のコンポーネント・インスタンスをクローニングする方法を説明します。アップグレードしているデプロイの元の各コンポーネント・インスタンスのクローンを作成する必要があります。元のインスタンスは変更されず、クローンに対する操作の実行中もユーザーへのサービスを提供し続けます。

クローニングされたWebコンポーネント用に新しいWebサーバー・インスタンスが必要です。元のWebサーバー・インスタンスを使用するOracle Access Managerに保護された別のアプリケーションがある場合は、そのアプリケーションもクローニングする必要があります。これらのクローニングされたアプリケーションでは、クローニングされたWebコンポーネント用に作成したWebサーバー・インスタンスが使用されます。詳細は、「停止時間ゼロのアップグレードのWebサーバー要件」を参照してください。

詳細は、次の項を参照してください。

クローン作成の概要
ファイル・システムの設定およびクローン・インスタンスの作成
クローニングされたWebコンポーネントの新しいWebサーバー・インスタンスの作成

16.3.1 クローン作成の概要

クローン・インスタンスを、元のコンポーネントをホスティングしているのと同じコンピュータに配置することをお薦めします。ただし、これは必須ではありません。新しいコンピュータを追加して別の以前のインスタンスをインストールする場合は、クローンを作成する前に実行しておくことをお薦めします。詳細は、「デプロイへの新しいハードウェアまたは以前のインスタンスの追加」を参照してください。

計画済の各Oracle Access Managerクローンのシステム・コンソールにエントリを追加したら、元のコンポーネントをクローニングできます。クローンのファイル・システム・ディレクトリ構造の作成から開始します。その後、元の各コンポーネントのファイル・システム・ディレクトリを、クローンのファイル・システムにコピーします。各クローン・インスタンスにより、インスタンスのアップグレード中にソース情報が提供されます。

注意:

コンポーネントのクローニングは、この項の説明に従って実行する手動タスクです。停止時間ゼロのアップグレード用にディレクトリをクローニングする際は、np_syncを使用しないでください。WebGateインスタンスはクローニングしないでください。

図16-6で、左側（元のディレクトリ）にサンプルのインストールを示します。この例では、元のトップレベルのファイル・システム・パスはnp611という名前です。ツリー構造のコンポーネント・ディレクトリおよびサブディレクトリを表示するために開かれています。この例には、各コンポーネント（_01および_02というラベル）の2つのインスタンスが含まれています。環境はユーザーによって異なります。図16-6の中央には、コンテナとして作成されたクローン・フォルダがあります。右には、元のコンポーネント・サブディレクトリを適切なクローン・フォルダにコピーすることで移入した後の、クローン構造の様子が示されています。

図16-6 ファイル・システムの元のディレクトリ階層およびクローンのディレクトリ階層

「図16-6 ファイル・システムの元のディレクトリ階層およびクローンのディレクトリ階層」の説明

クローン作成のガイドライン

クローンの作成時には次のガイドラインに従うことをお薦めします。

クローンは、元のコンポーネント・インスタンスをホスティングしているコンピュータの同じディスク・パーティションに配置することも、別のパーティションに配置することもできます。詳細は、「停止時間ゼロのアップグレードのハードウェア要件」を参照してください。
クローンのファイル・システム名には、ファイル・システムの元のディレクトリ名と比較して、少なくとも1つの相違点が必要です。たとえば、clone_npなど、トップレベルでクローン・ディレクトリに異なる名前を付けます。

クローンのファイル・システム・ディレクトリでは、元のインスタンスと同じ構造を使用できます。これは、推奨の方法でもあります。ただし、クローンのファイル・システムで元の構造を維持する必要はありません。後続の停止時間ゼロのアップグレード・タスク中に、クローンを設定するために10g（10.1.4.0.1）のライブラリおよびファイルを抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用するよう指示されます。

注意:

以前のWebGateのクローンは作成しません。そのため、ファイル・システムのクローン・ディレクトリにはWebGateのディレクトリは含まれません。

クローンのディレクトリ・パスにリリース番号を含めると、クローンのアップグレード後に混乱する可能性があります。クローニングされたパス名では、リリース番号を除外できます。
元のインストールに別々にインストールされたSoftware Developer Kit（SDK）がある場合は、そのSDKもクローニングする必要があります。

16.3.2 ファイル・システムの設定およびクローン・インスタンスの作成

この項の手順では、元のコンポーネント（WebGateを除く）をクローニングするステップごとの手順を説明します。

表16-1には、この手順で使用されるサンプルのパス名がまとめられています。この例では、元のディレクトリ構造は、ロード・バランシングを可能にするために、各コンポーネント（この例では_01および_02というラベル）に2つのインスタンスが含まれるよう設定されています。サンプルのクローンのファイル・システム構造は、元の構造に一致しています。環境はユーザーによって異なります。

表16-1 停止時間ゼロのアップグレードの元のパス名およびクローンのパス名のサンプル

	元のファイル・システム・ディレクトリ構造	クローンのファイル・システム・ディレクトリ構造
	注意: このサンプルの元のファイル・システムでは、各コンポーネントに個別に格納された2つのインスタンスが含まれています。 np611 aaa_01 aaa_02 ois_01 ois_02 webcomponent_01 webcomponent_02 webgate_01 webgate_02 SDK 注意: 元のインストールに別々にインストールされたSoftware Developer Kit（SDK）がある場合は、そのSDKもクローニングする必要があります。	移入できるように、元のファイル・システムをミラー化するクローンのファイル・システムを作成します。次に例を示します。 clone_np aaa_01 aaa_02 ois_01 ois_02 webcomponent_01 webcomponent_02 webgate_01 webgate_02 asdk_01\ 注意: クローンのトップレベルのファイル・システム・ディレクトリのみは、元のディレクトリと異なる名前にする必要があります。クローンのサブディレクトリには、元のサブディレクトリの名前を付けることができます。

元のファイル・システム・ディレクトリ構造

クローンのファイル・システム・ディレクトリ構造

注意: このサンプルの元のファイル・システムでは、各コンポーネントに個別に格納された2つのインスタンスが含まれています。

np611

aaa_01

aaa_02

ois_01

ois_02

webcomponent_01

webcomponent_02

webgate_01

webgate_02

SDK

注意: 元のインストールに別々にインストールされたSoftware Developer Kit（SDK）がある場合は、そのSDKもクローニングする必要があります。

移入できるように、元のファイル・システムをミラー化するクローンのファイル・システムを作成します。次に例を示します。

clone_np

aaa_01

aaa_02

ois_01

ois_02

webcomponent_01

webcomponent_02

webgate_01

webgate_02

asdk_01\

注意: クローンのトップレベルのファイル・システム・ディレクトリのみは、元のディレクトリと異なる名前にする必要があります。クローンのサブディレクトリには、元のサブディレクトリの名前を付けることができます。

バックアップ・コピー: クローンのファイル・システムに、ホスト上の元の各インスタンスのコピーを移入すると、クローン・インスタンスは元のインスタンスのバックアップ・コピーになります。後続のタスクで、各クローン・サブディレクトリの名前を変更して、クローン・アップグレードのソースを作成します。ソースはバックアップ・コピーになり、10.1.4.2.0のツール、ライブラリおよびファイルが含まれるコピー先をソースの情報に基づいてアップグレードしている間は変更されません。元のファイル・システムは、クローンのアップグレード中は変更されません。

停止時間ゼロのアップグレード・メソッドに使用されるサンプルのパス名は、各コンポーネントの複数のインスタンスを含む環境であることを表します。すべてのインスタンスに必要な処理を捕捉するために、複数のインスタンスを表すサンプルが選択されています。サンプルのパス名は、インストールへの特定のコンポーネントの配布を推奨するものではありません。

追加されたコンポーネント: Oracle Access Managerコンポーネントの旧リリースの別のインスタンスをインストールして、クローンとして使用できます。たとえば、元のインスタンスがWindowsプラットフォームでIIS Webサーバーを使用して実行されている場合、クローンを別のホスト・コンピュータに配置する必要があります。新しいホストに以前のインスタンスをインストールしたら、インストーラを削除して、元のインスタンスから新しくインストールしたクローンにすべてのカスタマイズと構成の変更をコピーする必要があります。既存のコンポーネントとの通信にインスタンスで簡易モードまたは証明書モードを使用する場合には、元のインスタンスから新しくインストールされたインスタンスに\configサブディレクトリをコピーし、すべての証明書を正常な状態に維持する必要があります。

次の手順では、サンプルのパス名をユーザーのデプロイの適切な名前に置き換えます。環境はユーザーごとに異なり、単一ホスト上に1つのコンポーネントの複数のインスタンスが含まれない場合や、単一のホスト上にすべてのコンポーネントが含まれない場合もあります。

停止時間ゼロのアップグレードに向けて以前のコンポーネント・インスタンスをクローニングする手順

クローンのコンテナとして機能する、新しいトップレベルのファイル・システム・ディレクトリを作成します。具体的には次のとおりです。

クローン用のコンテナを作成します。次に例を示します。

元のトップレベルのディレクトリ: np611

作成するクローン: clone_np
元のファイル・システムにある各インスタンスのクローンのCOREidサーバーのファイル・システム・ディレクトリを作成します。次に例を示します。

元のCOREidサーバーのファイル・システム作成するクローンのファイル・システム

np611\ois_01 clone_np\ois_01

np611\ois_02 clone_np\ois_02

	元のCOREidサーバーのファイル・システム	作成するクローンのファイル・システム
	np611\ois_01	clone_np\ois_01
	np611\ois_02	clone_np\ois_02

クローンのWebコンポーネントのファイル・システム・ディレクトリを必要に応じて作成し、クローニングされたサブディレクトリ用のコンテナを用意します。次に例を示します。

	元のWebコンポーネントのファイル・システム	作成するクローンのファイル・システム
	np611\webcomponent_01	clone_np\webcomponent_01
	np611\webcomponent_02	clone_np\webcomponent_02

クローンのアクセス・サーバー・ディレクトリを必要に応じて作成し、クローニングされたサブディレクトリ用のコンテナを用意します。次に例を示します。

元のアクセス・サーバーのファイル・システム作成するクローンのファイル・システム

np611\aaa_01 clone_np\aaa_01

np611\aaa_02 clone_np\aaa_02
クローンのWebGateディレクトリは作成しないでください。

	元のアクセス・サーバーのファイル・システム	作成するクローンのファイル・システム
	np611\aaa_01	clone_np\aaa_01
	np611\aaa_02	clone_np\aaa_02

SDK: 元のインストールにSDKが含まれている場合には、クローンのアクセスSDKディレクトリを作成します。次に例を示します。

	元のSDKのファイル・システム	作成するクローンのファイル・システム
	np611\asdk_01\AccessServerSDK	clone_np\asdk_01\AccessServerSDK
	np611\asdk_02\AccessServerSDK	clone_np\asdk_02\AccessServerSDK

元のコンポーネント・インスタンスをクローン構造にコピーして、クローンのファイル・システム・ディレクトリに移入します。具体的には次のとおりです。

元の各COREidサーバーのサブディレクトリをクローン構造にコピーします。次に例を示します。

	元のCOREidサーバー・ディレクトリのコピー	コピー先のクローンのファイル・システム
	np611\ois_01\identity	clone_np\ois_01\identity
	np611\ois_02\identity	clone_np\ois_02\identity

元の各WebPassディレクトリをクローン構造にコピーします。次に例を示します。

	元のWebPassディレクトリのコピー	コピー先のクローンのファイル・システム
	np611\webcomponent_01\identity	clone_np\webcomponent_01\identity
	np611\webcomponent_02\identity	clone_np\webcomponent_02\identity

元の各Access Manager構造をクローン構造にコピーします。次に例を示します。

	元のAccess Managerディレクトリのコピー	コピー先のクローンのファイル・システム
	np611\webcomponent_01\access	clone_np\webcomponent_01\access
	np611\webcomponent_02\access	clone_np\webcomponent_02\access

元の各アクセス・サーバー・インスタンスをクローン構造にコピーします。次に例を示します。

	元のアクセス・サーバー・ディレクトリのコピー	コピー先のクローンのファイル・システム
	np611\aaa_01\access	clone_np\aaa_01\access
	np611\aaa_02\access	clone_np\aaa_02\access

元のWebGateディレクトリはクローン・ディレクトリにコピーしないでください。

SDK: 元のSDKディレクトリをクローン・ディレクトリにコピーします。次に例を示します。

	元のSDKディレクトリのコピー	コピー先のクローンのファイル・システム
	np611\asdk_01\AccessServerSDK	clone_np\asdk_01\AccessServerSDK
	np611\asdk_02\AccessServerSDK	clone_np\asdk_02\AccessServerSDK

元のデプロイのすべてのホストに対してステップ1および2を繰り返し、元の各コンポーネント・インスタンスのクローンを作成します。
クローニング後、「クローニングされたWebコンポーネントの新しいWebサーバー・インスタンスの作成」に進みます。

16.3.3 クローニングされたWebコンポーネントの新しいWebサーバー・インスタンスの作成

クローニングされたWebコンポーネントには、新しいWebサーバー・インスタンスが必要です。この新しいWebサーバー・インスタンスは、元のインストールのアップグレード中に、アップグレード済のクローンにより使用されます。詳細は、「停止時間ゼロのアップグレードのハードウェア要件」を参照してください。

Oracle Access Managerに保護された別のアプリケーションがある場合は、これらのアプリケーションもクローニングし、クローン用に構成されたWebサーバー・インスタンスを使用するよう構成する必要があります。

1つのWebサーバー・インスタンスで複数のWebコンポーネントに対応している場合は、最初のWebコンポーネント（WebPassなど）をアップグレードする前にWebサーバーを停止し、最後に処理されたWebコンポーネントをアップグレードするまで停止しておく必要があります。後続の手順で、Webサーバーを停止するよう指示されます。すべてのWebサーバー要件の詳細は、「停止時間ゼロのアップグレードのWebサーバー要件」を参照してください。

クローニングされたWebコンポーネント用の新しいWebサーバー・インスタンスを作成する手順

Oracle MetaLinkに移動し、新しいWebサーバーがOracle Access Managerリリース10.1.4パッチ・セット1（10.1.4.2.0）でサポートされていることを確認します。
1. 次のURLのOracle MetaLinkへ移動します。
```
https://metalink.oracle.com
```
2. 指示に従ってOracle MetaLinkにログインします。
3. 「Certify」タブをクリックします。
4. 「View Certifications by Product」をクリックします。
5. 「Application Server」オプションを選択し、「Submit」をクリックします。
6. 「Oracle Identity Manager」を選択し、「Submit」をクリックします。
7. 「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」（html）をクリックして「Oracle Identity Management」ページを表示します。
8. 「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。
Webサーバーのベンダーのドキュメントを参照して、新しいWebサーバー・インスタンスをインストールします。Webサーバーのインストールは、このマニュアルの対象外です。
元のOracle Access ManagerインストールおよびこのWebサーバーに保護されたその他のアプリケーションのクローンを作成し、Oracle Access ManagerクローンのWebサーバー・インスタンスを使用するようにアプリケーションのクローンを構成します。

16.3.4 コンポーネントのクローニング後における変更内容のロールバック

クローニングしたインスタンスに問題がある場合は、次の手順のステップ1を実行してリカバリし、新しく開始することができます。それ以外の場合は、すべてのステップを実行して変更内容をすべてロールバックし、元のインストールに戻ります。

すべてのステップを実行すると、クローニングされたコンポーネントのすべてのトレース内容が削除されます。この場合は、停止時間ゼロのアップグレードを最初からやり直すか、このマニュアルで説明されているインプレース・メソッドを使用します。または、元の環境を使用して続行します。

コンポーネント・インスタンスのクローニング後にリカバリまたはロールバックする手順

クローン・サービスおよびWebサーバーを停止し、ホスト・コンピュータからクローニングされたファイル・システム・ディレクトリを削除します。

注意:

クローニングを続行するには、「停止時間ゼロのアップグレードに向けて以前のコンポーネント・インスタンスをクローニングする手順」に戻ります。

クローニングされたWebコンポーネント用のWebサーバー・インスタンスを削除します。
Webサーバー・インスタンスと連動しているクローニングされたアプリケーションをすべて削除します。
各ホスト・コンピュータのそれぞれのクローンに対してすべてのステップを繰り返します。
元のシステム・コンソールで、以前のNetPointまたはOracle COREidの管理ガイドの指示に従って、クローンのエントリを削除します。
元の設定が正常に動作していることを確認します。

16.4 宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得

小規模なサンドボックス・タイプのデプロイであるか、完全な本番デプロイであるかにかかわらず、アップグレードするデプロイのすべてのインスタンスに対してこのタスクを実行する必要があります。

停止時間ゼロのアップグレード・メソッドをサポートするツールは、Oracle Access Managerリリース10.1.4パッチ・セット1（10.1.4.2.0）に同梱されています。10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイル（インスタンスとも呼ばれる）を抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）をインスタンスに適用して、停止時間ゼロのアップグレード・ツールを取得します。その他の情報は次の項に記載されています。

宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出
ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用

前の項で情報を確認できます。ただし、それらのタスクを今は実行しないでください。ディレクトリ・サーバーへの新しいブランチの作成、スキーマのアップグレード、クローン・インスタンスのアップグレードまたは元のインスタンスのアップグレード時に、それらのタスクを参照するよう指示されるまでは実行しません。情報が重複しないよう、次の項からもこの項を参照しています。

トピックの概要: 宛先の作成およびツールの取得を説明する項

この章
第17章
- 元のアイデンティティ・システムのアップグレード
- 元のアクセス・システムのアップグレード

16.4.1 宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出

停止時間ゼロのアップグレード・アクティビティを実行する前に、宛先のファイル・システム・パスを作成し、関連するコンポーネント用の適切なOracle Access Manager 10g（10.1.4.0.1）のライブラリおよびファイルを抽出する必要があります。宛先を作成したら、リリース10.1.4パッチ・セット1（10.1.4.2.0）をインスタンスに適用できます。

このタスクは、LDAPディレクトリ・サーバーに新しいブランチを作成する前かスキーマをアップグレードする前で、各クローンまたは元のインスタンスをアップグレードする前に実行します。

宛先パス名: クローンおよび元のインスタンスのアップグレード用にライブラリとファイルを抽出する前に、ソースを作成する必要があります。割り当てる宛先パスは、ソースを作成するために名前を変更する前のクローンまたは元のパスに正確に一致する必要があります。ライブラリおよびファイルの抽出中に、次のようなデフォルトのファイル・システムのディレクトリ・パスが提供されます。

Windowsプラットフォーム: \Program Files\NetPoint\

UNIXプラットフォーム: /opt/netpoint/（すべて小文字）

デフォルトのパス名を変更して、エンタープライズの要件に合せることができます。デフォルトの名前を変更した場合は、すべてのプラットフォームで一貫したネーミング規則を使用することをお薦めします。たとえば、Windowsオペレーティング・システムではパス名に空白を使用できますが、UNIXベースのシステムでは使用できません。一貫性を保つために、すべてのプラットフォームで、パス名に空白ではなくアンダースコアを使用することをお薦めします。

次のパス名の指定は、個々のコンポーネントの特定に役立ちます。

変更するかどうかにかかわらず、すべてのアイデンティティ・システムのパス名（Webコンポーネントのパス名も含む）には\identityが自動的に追加されます。たとえば、COREidサーバーはclone_np\identityにインストールされます。
変更するかどうかにかかわらず、すべてのアクセス・システムのパス名（Webコンポーネントのパス名も含む）には\accessが自動的に追加されます。たとえば、アクセス・サーバーはclone_np\accessにインストールされます。
\webcomponentは、WebPassおよびポリシー・マネージャのデフォルト・パスの一部です。ただし、\identityまたは\accessが自動的に追加されます。\webcomponentを削除すると自動的には追加されません。
- WebPassは、clone_np\webcomponent\identityにインストールされます。
- ポリシー・マネージャ（以前のAccess Manager）は、clone_np\webcomponent\accessにインストールされます。
WebGateのデフォルトのパス名は、プラットフォームおよびWebサーバー・タイプによって異なります。次に、元のデプロイがnp611としてインストールされている場合の例をいくつか示します。
- Win32 ISAPI WebGate: \np611\webgate
- Win32 OHS2 WebGate: \np611\WebComponent\access
- Win32 NSAPI WebGate: \np611\WebGate\access
- Linux Apache2 WebGate: /home/np611/webgate
- Linux OHS2 WebGate: /home/np611/webgate
- このようになります。

停止時間ゼロのメソッドを使用すると、元のアクセス・システムがアップグレードされるまでWebGateのアップグレードは延期されます。停止時間ゼロのアップグレード・タスクの最後まで使用することはありませんが、最新のWebGateをインストールできます。ソースおよび宛先作成の詳細は、「停止時間ゼロのメソッドの準備タスク」を参照してください。

10g（10.1.4.0.1）コンポーネントの抽出およびパッチの適用を開始する前に、次の情報を確認してください。

場所および詳細: ライブラリおよびファイルは、特定の場所および構成の詳細とともに抽出されます。転送できない詳細もあります。たとえば、Windowsプラットフォームでは、レジストリ・エントリは元の場所を指しています。そのため、ある場所からライブラリおよびファイルをコピーして、それらを別の場所で使用することはできません。

停止時間ゼロのアップグレードの実行に必要な10g（10.1.4.2.0）のツールを取得するには、インストールされた各インスタンスの10g（10.1.4.0.1）のコンポーネント・ライブラリを抽出して、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する必要があります。パッチを適用したら、（クローン・インスタンス用であるか元のインスタンス用であるかにかかわらず）アップグレードに必要な10g（10.1.4.2.0）のファイルおよびツールを取得できます。10g（10.1.4.2.0）のファイル・システム・ディレクトリは、以前のインスタンスのアップグレード中に使用される宛先になります。具体的には次のとおりです。

各クローン・インスタンスのアップグレードの場合: まず、既存のクローンのファイル・システム名を変更し、アップグレード用にソースを作成します。10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルをクローンのファイル・システムに抽出し、10g（10.1.4.2.0）のパッチを適用します。たとえば、COREidサーバーのクローンをアップグレードしている場合は、10.1.4のライブラリおよびファイルがclone_np\identityという名前のファイル・システム・ディレクトリに抽出されます。
元の各インスタンスのアップグレードの場合: まず、既存の元のファイル・システム名を変更し、アップグレード用のソースを作成します。10g（10.1.4.0.1）のコンポーネント・ライブラリを元のファイル・システム・ディレクトリ（np611\identityなど）に抽出し、10g（10.1.4.2.0）のパッチを適用します。

言語: 以前のインストールに英語以外の言語が含まれる場合、抽出する10g（10.1.4.0.1）のライブラリおよびファイルにも、元のインスタンスと同じ言語パックを含める必要があります。

設定および検証の注意事項: 10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用しても、インスタンスは完全には構成されません。ただし、アップグレードするインスタンスの宛先ディレクトリを含み、停止時間ゼロのアップグレード・アクティビティの実行に必要なものはすべて揃っています。

不要なスキーマのクリーン・アップ: アイデンティティ・サーバーおよびポリシー・マネージャのコンポーネント・ライブラリとファイルを抽出したら、obmigratedsparams.lstファイルのkCleanupObsoleteSchemaパラメータをfalseに設定します。これにより、不要なスキーマがクリーン・アップされます。そのため、元のシステムがクローニングされたシステムと共存できるようになります。アイデンティティ・システムのみの場合は、アイデンティティ・サーバー用のステップのみを実行します。

WebGate: これらのアップグレードは、その他すべてのコンポーネントがアップグレードされるまで延期できます。元のWebGateインスタンスをアップグレードする際にのみ、10g（10.1.4.0.1）のWebGateのライブラリおよびファイルを抽出し、パッチを適用します。クローンのデプロイと元のデプロイを分離する場合は、新しいWebGateをアップグレード済のクローン・システムに追加して、元のWebGateと置き換える必要があります。詳細は、「元の環境とクローン環境の分離の概要」を参照してください。

次のタスクの概要では、停止時間ゼロのアウトオブプレース・アップグレードをサポートする特定の抽出要件を説明します。完全なコンポーネントのインストールは実行しません。かわりに、コンポーネント・ライブラリおよびファイルのみを抽出し、インストール・プロセスを停止します。

注意:

後続の停止時間ゼロのアップグレード・タスク中に実行を指示されるまで、10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを抽出しないでください。コンポーネント・ライブラリおよびファイルのみを抽出し、完全なインストールは実行しません。

タスクの概要: 宛先の作成

ホスト・コンピュータがOracle Access Manager 10g（10.1.4.0.1）のすべての要件を満たしていることを確認します。

詳細は、「停止時間ゼロのアップグレードのハードウェア要件」および「ホスト・コンピュータをOracle Access Manager 10g（10.1.4.0.1）のサポート・レベルまで上げる」を参照してください。
後続の手順で実行を指示されたら、アップグレードするインスタンス（クローン・インスタンスであるか元のインスタンスであるかにかかわらず）をホスティングしているコンピュータで、次の抽出タスクを実行します。
1. この手順の参照元の説明に従って、前提タスクを実行します。
2. インスタンスおよびプラットフォームに適したOracle Access Manager 10g（10.1.4.0.1）のコンポーネント・インストーラを選択し、起動します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
3. ライセンスおよび言語に関する質問に答えます。言語の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
4. インストール・ディレクトリを質問されたら、インスタンスの宛先パスを指定します（一般的に、ソースを作成するために名前を変更する前のクローンまたは元のインスタンスの名前に一致させる必要があります）。たとえば、\clone_npのようになります。
5. まだ書き込んでいない場合は、計画ドキュメントに宛先パスを書き込みます。たとえば、\clone_np\identityのようになります。
  
  コンポーネント・ライブラリおよびファイルのインストール（抽出）中であることが通知されます。これには、数秒かかります。
6. すべてのコンポーネント・ライブラリおよびファイルが抽出されたら、「取消」をクリックします。
  
  注意:
  インストールを続行しないでください。パッチの適用に必要なものはすべて揃っています。
7. 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」に進みます。

16.4.2 ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用

10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを抽出し、（クローンのアップグレードであるか元のアップグレードであるかにかかわらず）アップグレード用の宛先パスを作成したら、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する必要があります。宛先にパッチ・セットを適用し、停止時間ゼロのアウトオブプレース・アップグレードに必要なスクリプトおよびユーティリティを取得します。パッチを適用しても、ファイル・システム・パスは変更されません。

コンポーネント・ライブラリおよびファイルにパッチを適用すると、パッチを削除する際にリストアする必要のあるファイルを含むバックアップ・フォルダが作成されます。このバックアップ・フォルダは、\oblixディレクトリと同じレベルのidentity|accessフォルダに格納されます。たとえば、アイデンティティ・サーバーにパッチを適用すると、バックアップ・ディレクトリは次の場所に格納されます。

IdentityServer_install_dir\identity\backup-Oracle-101401RCn-binary_parameter
IdentityServer_install_dir\identity\backup-Oracle-101401RCn-message_
en-us

リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用および条件の削除

Oracle Access Managerリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する前に、ホスト・コンピュータが10g（10.1.4.2.0）のサポート要件を満たしていることを確認する必要があります。また、次の条件も適用されます。

Oracle Access Manager 10g（10.1.4.0.1）をインストールしてリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用すると、10g（10.1.4.2.0）の機能を使用できても、コンポーネント・インスタンスは10g（10.1.4.0.1）とみなされます。この場合は、10g（10.1.4.0.1）に後続のパッチ・セットを適用する前に、リリース10.1.4パッチ・セット1（10.1.4.2.0）を削除する必要があります。
停止時間ゼロのアップグレード・メソッドを使用してアップグレードする際には、Oracle Access Manager 10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを抽出し、アップグレード前にリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。アップグレード時には、10g（10.1.4.2.0）のMigrateOAMスクリプトを使用して、以前のコンポーネント・インスタンスをアップグレードします。そのため、アップグレードしたコンポーネントは10g（10.1.4.2.0）リリースとみなされます。この場合、10g（10.1.4.0.1）に後続のパッチを適用する前には、リリース10.1.4パッチ・セット1（10.1.4.2.0）を削除できません。
インプレース・アップグレード・メソッドを使用してアップグレードする際には、10g（10.1.4.0.1）のインストーラを使用します。結果のインスタンスは、リリース10g（10.1.4.0.1）です。インプレース・アップグレード後は、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用することをお薦めします。この場合、10g（10.1.4.2.0）の機能を使用できても、コンポーネント・インスタンスは10g（10.1.4.0.1）とみなされます。10g（10.1.4.0.1）に後続のパッチを適用する前に、リリース10.1.4パッチ・セット1（10.1.4.2.0）を削除する必要があります。

次の手順では、パッチ・セットを取得するステップ、およびパッチ・セットが適切に適用されたことを検証するステップを説明します。パッチ・セット適用の詳細な説明は、サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)を参照してください。

リリース10.1.4パッチ・セット1（10.1.4.2.0）を取得および適用する手順

Oracle MetaLinkのWebサイトに移動して「5957301」を選択し、次のようにしてリリース10.1.4パッチ・セット1（10.1.4.2.0）を取得します。
1. Oracle MetaLinkへ移動します。
```
 https://metalink.oracle.com
```
2. 指示に従ってOracle MetaLinkにログインします。
3. 「Patches & Updates」タブをクリックします。
4. 「Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs」をクリックします。
5. ラベル「Latest Oracle Server/Tools Patchsets」の下の「Oracle Oblix COREid」をクリックします。
6. ページ下部の表から、10g（10.1.4.0.1）の最新のパッチ・セットを探して選択します。たとえば、リリース10.1.4パッチ・セット1（10.1.4.2.0）を入手するには「5957301」を選択します。
7. 「Platform or Language」リストから、ユーザーの環境に適したプラットフォームを選択し、「Download」をクリックします。
8. パッチ・セットのドキュメントで、パッチ・セット・パッケージの適用または削除に関する説明を確認します。また、このパッチ・セットで修正された不具合も確認できます。
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)の指示に従い、リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルに適用します。
- アイデンティティ・サーバー
- WebPass
- ポリシー・マネージャ
- アクセス・サーバー
- WebGate
宛先パスのバージョン・ファイルが、10g（10.1.4.2.0）（npversion_component.txt）に更新されていることを確認します。次に例を示します。

IdentityServer_install_dir\identity\oblix\config\np1014_is.txt

WebPass_install_dir\webcomponent\identity\oblix\config\np1014_wp.txt

PolicyManager_install_dir\webcomponent\access\oblix\config\np1014_am.txt

AccessServer_install_dir\access\oblix\config\np1014_aaa.txt

WebGate_install_dir\webgate\identity\oblix\config\np1014_wg.txt
Component_install_dir\identityまたはComponent_install_dir\accessを探して、Install_Logのファイルの履歴が自動的に更新されたことを検証します。
パッチ操作中に作成されたバックアップ・ファイルを探します。次に例を示します。

IdentityServer_install_dir\identity\backup-Oracle-101401RCn-binary_parameter
IdentityServer_install_dir\identity\backup-Oracle-101401RCn-message_en-us
ベンダーのドキュメントおよび「既存のWebサーバー構成ファイルのバックアップ」で詳細を参照し、Webサーバー構成ファイルをバックアップします。
Windows: 「Windowsレジストリ・データのバックアップ」の説明に従って、パッチを適用したコンポーネントの更新されたレジストリ・データをバックアップします。

16.5 LDAPディレクトリ・サーバーの新しいブランチへの構成データおよびポリシー・データのコピー

クローンの作成後、LDAPディレクトリ・サーバーに新しいブランチを作成し、元のoblixブランチから新しいブランチに構成データおよびポリシー・データをコピーする必要があります。コピーされる情報には、ワークフローの指定内容、およびアイデンティティ・システムやアクセス・システムの外観と機能を制御する構成データなどの詳細が含まれます。

データのコピーを新しいブランチに移入したら、新しいブランチを使用するようにクローニングされたコンポーネントを再構成します。元のインストールでは、継続して元のブランチが使用されます。最後の停止時間ゼロのアップグレード・タスクの間のみ、新しいブランチを使用するよう元のコンポーネントをアップグレードおよび再構成します。

完全な説明は、次の各項を参照してください。

LDAPディレクトリ・サーバーへの新しいブランチの作成および移入の概要
新しいoblixブランチの作成および移入

「新しいoblixブランチへの変更内容のロールバック」の項も参照が必要になる場合があります。

16.5.1 LDAPディレクトリ・サーバーへの新しいブランチの作成および移入の概要

Oracle Access Managerでは、単一のディレクトリ・サーバー上のユーザー・データ、Oracle Access Managerの構成データおよびポリシー・データのソートがサポートされています。また、ユーザー・データをあるディレクトリ・サーバー・タイプに個別に格納することや、Oracle Access Managerの構成データとポリシー・データを異なるタイプのディレクトリ・サーバーに格納することも可能です。たとえば、ユーザー・データをActive Directoryに、Oracle Access Managerの構成データとポリシー・データをADAM（またはOracle Internet Directory）に格納できます。

ユーザー・データを構成データおよびポリシー・データとは異なるディレクトリ・サーバー・タイプに格納する場合は、次のガイドラインに注意してください。

すべてのユーザー・データが同じディレクトリ・サーバー・タイプに格納されていることを確認します。
構成データおよびポリシー・データが同じディレクトリ・サーバー・タイプに格納されていることを確認します。

新しいブランチ・ノードを手動で作成して、構成データおよびポリシー・データのコピーを格納する必要があります。一般的に、元の構成ベース（構成DNとも呼ばれる）およびポリシー・ベース（ポリシーDNとも呼ばれる）の子ノードとして作成されます。データを別々に格納したら、パラレル・ノードを作成できます。

アイデンティティ・システムのみ: アイデンティティ・システムのみの場合、ポリシー・データはありません。この場合、この手順は、最初にインストールおよび設定されたCOREidサーバーのクローンに対してのみ実行します。この場合は構成データがコピーされます。

アイデンティティ・システムおよびアクセス・システムの混合: 構成データとポリシー・データが同じLDAPディレクトリ・サーバー・ノードに一緒に格納されているアイデンティティ・システムおよびアクセス・システムの混合の場合は、どちらのデータも同時にコピーされます。ただし、ポリシー・データが別のブランチまたは別のディレクトリ・インスタンスに格納されている場合は、最初にインストールされたAccess Managerのクローンにこの操作を繰り返してポリシー・データを新しいブランチにコピーする必要があります。

すべての環境で操作を一時停止: この手順は、LDAPディレクトリ・サーバーの情報を変更、追加または削除する操作を一時停止するようすべての管理者に通知してから開始することをお薦めします。データのコピーの時点から停止時間ゼロのアップグレード・アクティビティが完了するまで、一時停止させる必要があります。次に、一時停止する必要のある操作のリストの一部を示します。

ワークフロー・チケットの処理
ワークフローの作成、変更または削除などアプレット・ベースの変更
ユーザー・プロファイルの変更
チャレンジ属性およびレスポンス属性の変更
新しいポリシーの作成、変更または削除
認証スキームの作成、変更または削除
ホスト識別子の作成
ディレクトリ・サーバー・プロファイルの削除の作成
オブジェクト・クラスの更新
アクセス属性コントロールや委任管理者の更新または検索ベースの設定
LDAPディレクトリ・サーバーの情報を変更、追加または削除するその他すべての操作

操作を一時停止したら、構成データおよびポリシー・データ用に新しいノードを作成します。ディレクトリ・サーバー・インスタンスおよび以前のOracle Access Managerのデータを、LDAPディレクトリ・サーバーの元のブランチにバックアップすることをお薦めします。

注意:

データに影響を与える操作の一時停止を自動的に強制するツールはありません。クローン・システムのアップグレード後で、元のシステムのアップグレード前に元の環境のデータが変更された場合には、実行可能な代替方法があります。詳細は、「元のインスタンスのアップグレード前における元のブランチに対する変更内容取得の概要」を参照してください。

ツールの取得: 新しいブランチに移入する前に、「宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得」の説明に従って、10g（10.1.4.0.1）のアイデンティティ・サーバーのコンポーネント・ライブラリおよびファイルを抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する必要があります。その後、10g（10.1.4.2.0）のアイデンティティ・サーバーのディレクトリから、MkbranchモードでMigrateOAMスクリプトを実行します。

アイデンティティ・システムおよびアクセス・システムの混合の場合は、10g（10.1.4.0.1）のポリシー・マネージャのコンポーネント・ライブラリおよびファイルを抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する必要があります。その後、10g（10.1.4.2.0）のポリシー・マネージャのファイル・システム・ディレクトリから、MkbranchモードでMigrateOAMスクリプトを実行します。

ライブラリおよびファイルを抽出する際には、任意のインストール・パスを指定できます。ライブラリおよびファイルの抽出後は、10g（10.1.4.2.0）のMigrateOAMスクリプトは、次のサンプルのようなパスに配置されます。

Windows:

1014\identity\oblix\tools\migration_tools\MigrateOAM.bat
1014\webcomponent\access\oblix\tools\migration_tools\MigrateOAM.bat

Linux:

/home/1014/identity/oblix/tools/migration_tools/MigrateOAM.sh
/home//1014/webcomponent/access/oblix\tools\migration_tools/
MigrateOAM.sh

この場合は、ソースを作成する必要も、既存のインスタンスの後に宛先を指定する必要もありません。次に、サンプルのパス名のそれぞれの意味を示します。

1014\identityは、10g（10.1.4.2.0）のアイデンティティ・サーバーのコンポーネント・ライブラリおよびファイルが存在するファイル・システム・ディレクトリを表します。
1014\webcomponent\accessは、10g（10.1.4.2.0）のポリシー・マネージャ（以前のAccess Managerコンポーネント）のコンポーネント・ライブラリおよびファイルが存在するファイル・システム・ディレクトリを表します。

MigrateOAMの使用: 表16-2に、LDAPディレクトリ・サーバーの元のブランチから新しいブランチに、構成データおよびポリシー・データをコピーするために指定する必要のある引数を示します。新しいブランチ・ノードは、スクリプトを使用する前にLDAPディレクトリ・サーバーに存在している必要があります。MigrateOAMスクリプトにより、新しい構成DNおよびポリシーDNを要求するユーティリティがコールされ、LDAPディレクトリ・サーバーの元のブランチから新しいブランチに構成データおよびポリシー・データが自動的にコピーされます。タスクを説明するために、サンプルのファイル・システム・パスの名前が表示されます。詳細はユーザーによって異なります。

表16-2 MkbranchモードのMigrateOAMコマンドのサマリー

MkbranchモードのMigrateOAMのパラメータ	値および操作
-M Mkbranch	モードとしてMkbranchを指定します。Mkbranchモードは、元のブランチからLDAPディレクトリ・サーバーの新しいブランチに、スキーマおよび構成データとポリシー・データをコピーする際に必要です。
-C component	構成データおよびポリシー・データをコピーするためにOIS（アイデンティティ・サーバー）を指定します。構成データとは別に格納されているポリシー・データをコピーするためにAM（Access Manager）を指定します。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	このデータの最終的なアップグレード後のリリースとして1014を指定します。
-S "source directory"	クローニングされたアイデンティティ・サーバーまたはAccess Managerを含むディレクトリへのフルパスを引用符で囲んで指定します。次に例を示します。アイデンティティ・サーバー: -S "C:\clone_np\ois_01\identity" Access Manager: -S "C:\clone_np\webcomponent_01\access"
-D "destination directory"	指定したコンポーネントの最新のMigrateOAMスクリプトを含むディレクトリへのフルパスを引用符で囲んで指定します。次に例を示します。アイデンティティ・サーバー: -D "C:\1014\identity" Access Manager: -D "C:\1014\webcomponent\access"
-I "installation directory"	インストール・ディレクトリは、指定した宛先と同一である必要があります。次に例を示します。アイデンティティ・サーバー: -D "C:\1014\identity" Access Manager: -D "C:\1014\webcomponent\access"

構成データの完全なコマンドおよびオプションは、連続した1行として入力する必要があります。

実行中は、メッセージでプロセスを把握でき、新しいConfigDNの場所を指定するよう要求されます。この場合は、構成DNにより、コピーした情報が格納されるディレクトリ・ツリーの新しいノードが定義されます。

構成データおよびポリシー・データが別々に格納されている場合は、最初にインストールされたAccess ManagerのクローンにMkbranchコマンドが実行される際に、新しいポリシー・ベースを要求されます。この場合は、ポリシー・ベースにより、コピーした情報が格納されるディレクトリ・ツリーの新しいノードが定義されます。

検索ベース、構成DNとポリシーDNの詳細、およびユーザー・データ、構成データとポリシー・データの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

16.5.2 新しい`oblix`ブランチの作成および移入

この項の手順は、LDAPディレクトリ・サーバーに新しいブランチを作成し、元のブランチから構成データとポリシー・データのコピーを移入する際に参照します。

注意:

ここでアクティビティを実行する前に、新しいブランチの作成に関するすべての情報を確認することをお薦めします。

次の手順には、元のブランチと新しいブランチの両方に対する構成DNおよびポリシーDNのサンプルが含まれています。また、最初にインストールされたCOREidサーバーおよびAccess Managerのクローンのサンプルのパス名だけでなく、抽出してパッチを適用するライブラリおよびファイルのサンプルのパス名も含まれています。環境および指定内容はユーザーによって異なります。

既存の構成データおよびポリシー・データを新しいブランチにコピーする手順

「ディレクトリ・サーバー・インスタンスおよびデータの準備」の説明に従って、ディレクトリ・サーバーが準備されていることを確認します。
すべてのコンポーネントをアップグレードして、新しいブランチ（クローンおよび元のインスタンスを含む）を使用するよう構成するまで、LDAPディレクトリ・サーバーの構成データやポリシー・データを追加、変更または削除する操作を一時停止するよう管理者に通知します。詳細は、この項の前述の操作リストを参照してください。
構成データおよびポリシー・データを一緒に格納: LDAPディレクトリ・サーバーに、コピーした構成データを格納するための新しいノードを作成します。次に例を示します。

元の構成DN: o=company,c=us
新しい構成DN: o=Newbranch,o=company,c=us
構成データおよびポリシー・データを別々に格納: 構成データに対してステップ3を実行し、LDAPディレクトリ・サーバーに（元のポリシー・ベースの子ノードとして）新しいノードを作成し、コピーしたポリシー・データを格納します。次に例を示します。

元のポリシー・ベース: o=Policy_base,o=company,c=us
新しいポリシー・ベース: o=NewPolicyBase,o=Policy_base,o=company,c=us
LDAPディレクトリ・サーバーの元のブランチをバックアップして、第5章の項の説明に従って次のタスクを実行します。
最初にインストールおよび設定されたCOREidサーバーのクローンをホスティングしているコンピュータで、次の操作を実行します。
1. 宛先の作成: 10g（10.1.4.0.1）のアイデンティティ・サーバーのコンポーネント・ライブラリおよびファイルを、新しい宛先パスに抽出します。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。次に例を示します。
  
  1014\identity
2. ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、リリース10.1.4パッチ・セット1（10.1.4.2.0）を、抽出したアイデンティティ・サーバーのコンポーネント・ライブラリおよびファイルに適用します。
アイデンティティ・サーバー・インスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むファイル・システム・パスに変更します。次に例を示します。
```
    cd 1014\identity\oblix\tools\migration_tools
```

次のコマンドを改行せずに1行で入力して、MigrateOAMをMkbranchモードで実行し、リクエストされたら新しい構成DNを指定します。次に例を示します。

     1014\identity\oblix\tools\migration_tools>MigrateOAM.bat -M Mkbranch 
     -C OIS -F 610 -T 1014 -S "C:\clone_np\ois_01\identity" -D "C:\1014\
     \identity" -I "C:\1014\identity"

     ...
     Enter new ConfigDN : o=Newbranch,o=company,c=us
     The tool ran successfully
     Press enter key to continue ... ENTER
     ...
     Importing data to directory server.....
     The tool ran successfully
     Press enter key to continue ... ENTER

次のように続行します。

コピーが成功しデータを一緒に（またはアイデンティティ・システムのみ）格納する場合: データがLDAPディレクトリ・サーバーにインポートされたこと、およびツールが正常に実行されたことを示すメッセージが表示されます。クローニングされたコンポーネントを新しいブランチを使用するように構成する前に、「環境の正常な動作の検証」に進みます。

注意:

その他のCOREidサーバー・インスタンスにこのステップを繰り返さないでください。新しいブランチの作成を、単一のCOREidサーバーで実行するのは一度のみです。構成データおよびポリシー・データが別々に格納されたアイデンティティ・システムとアクセス・システムの混合の場合は、ステップ9を実行します。

コピーが成功しデータを別々に格納する場合: 構成データおよびポリシー・データが、アイデンティティ・システムとアクセス・システムの混合に別々に格納されている場合は、ステップ9に進みます。
コピーが失敗した場合: 「新しいブランチへの移入に関する問題からのリカバリ」のアクティビティを実行します。また、destination_dir/oblix/tools/MakeBranch.logのMakeBranch.logファイルも参照してください。

最初にインストールおよび設定されたAccess Managerのクローンをホスティングしているコンピュータで、次の操作を実行します。
1. 宛先の作成:10g（10.1.4.0.1）のポリシー・マネージャのコンポーネント・ライブラリおよびファイルを、新しい宛先パスに抽出します。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。次に例を示します。
  
  1014\webcomponent
2. ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、リリース10.1.4パッチ・セット1（10.1.4.2.0）を、抽出したポリシー・マネージャのコンポーネント・ライブラリおよびファイルに適用します。

別々に格納されている場合は、次のようにしてポリシー・データをコピーします。

ポリシー・マネージャ・インスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むファイル・システム・パスに変更します。次に例を示します。
```
cd 1014\webcomponent\access\oblix\tools\migration_tools
```

ポリシー・マネージャに対してMigrateOAMをMkbranchモードで実行し、個別に格納されているポリシー・データを新しいブランチにコピーして環境に合せてプロンプトに答えます。次に例を示します。

1014\webcomponent\access\oblix\tools\migration_tools>MigrateOAM.bat -M 
Mkbranch -C AM -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\access" -D
"C:\1014\webcomponent\access" -I "C:\1014\webcomponent\access"

...
Enter new Policy Base : o=NewPolicyBase,o=Policy_base,o=company,c=us
The tool ran successfully
Press enter key to continue ... ENTER
...
Importing data to directory server.....
The tool ran successfully
Press enter key to continue ... ENTER
....

コピーの成功: データがLDAPディレクトリ・サーバーにインポートされたこと、およびツールが正常に実行されたことを示すメッセージが表示されます。クローニングされたコンポーネントを新しいブランチを使用するように構成する前に、「環境の正常な動作の検証」に進みます。

注意:

その他のAccess Managerインスタンスにこのステップを繰り返さないでください。新しいブランチの作成を、単一のAccess Managerで実行するのは一度のみです。

コピーが失敗した場合: 「新しいブランチへの移入に関する問題からのリカバリ」のアクティビティを実行します。また、destination_dir/oblix/tools/MakeBranch.logのMakeBranch.logファイルも参照してください。

16.5.3 新しいブランチへの移入に関する問題からのリカバリ

Mkbranch操作中にディレクトリ接続に失敗した場合は、LDAPディレクトリ・サーバーが稼働中かつオンラインであることを確認します。

destination_dir/oblix/tools/MakeBranch.logのMakeBranch.logファイルを確認して、障害の場所を特定できます。たとえば、setup.xmlが読み込まれていない可能性があります。

「LDAPディレクトリ・サーバーの新しいブランチへの構成データおよびポリシー・データのコピー」の手順を新しく試行できるように、LDAPディレクトリ・サーバーに追加した新しい構成ノードおよびポリシー・ノードを削除できます。

アップグレードを中止して以前のリリースに戻す場合は、「新しいoblixブランチへの変更内容のロールバック」を参照してください。

16.5.4 新しい`oblix`ブランチへの変更内容のロールバック

新しいブランチへの移入後に問題がある場合は、変更内容のロールバックが必要な場合があります。

ステップ1を実行してLDAPディレクトリ・サーバーに追加した新しいノードを削除し、ブランチを新しく作成および移入します。次の手順のステップをすべて実行すると、停止時間ゼロのアップグレード用の環境への変更をすべて元に戻し、元の設定およびリリースに戻すことができます。

すべての変更内容のロールバック後、使用できるのは元のインストールおよびリリースのみです。この場合、元のインストールを使用するか、インプレース・アップグレードを開始するか、停止時間ゼロのアップグレードを最初から再開できます。

新しいoblixブランチへの変更内容をロールバックする手順

新しい構成DNおよびポリシーDN用に追加された、LDAPディレクトリ・サーバーのブランチを削除します。
ホスト・コンピュータから次のものを削除します。
- クローンのファイル・システム・ディレクトリ
- リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイル
- 追加またはアップグレード・プロセスの一部として自動的に追加された任意のファイル・システム・ディレクトリ
- クローン用のWebサーバー・インスタンス、およびOracle Access Managerにより保護されこのWebサーバーと連動しているクローニングされたアプリケーション
元のシステム・コンソールから、すべてのクローン・プロファイルを削除します。
元の設定が正常に動作していることを確認します。

16.6 クローニングされたコンポーネントおよびサービスの構成

この項のアクティビティは、LDAPディレクトリ・サーバーに、構成データおよびポリシー・データのコピーを含む新しいブランチを作成した後にのみ実行します。

クローニングされたコンポーネントがすべて適切に構成されていること、およびアイデンティティ・システムとアクセス・システムが新しいブランチのデータを使用して動作するよう構成されていることを確認するには、クローニングされたすべてのコンポーネント・インスタンスに対してこの項のタスクを実行します。次に示すタスクの概要の個々のトピックでは、準備ができたら実行できるステップごとの手順を説明しています。

タスクの概要: 新しいブランチを使用するためのクローニングされたコンポーネントの再構成

クローニングされたCOREidサーバーのサービスおよび詳細の構成
クローニングされたCOREidサーバーと連動するためのクローニングされたWebPassインスタンスの構成
クローニングされたCOREidシステムで新しいブランチを使用するための設定
クローニングされたAccess Managerで新しいブランチを使用するための設定
クローニングされたアクセス・サーバーの構成

注意:
WebGateはクローニングしないでください。SDKを再構成する必要はありません。
再構成されたクローンに対する変更内容のロールバック

設定ファイルの削除: 前述の概要で説明した一部のタスクの開始時に、次の項目を削除するよう指示されます。

setup.*
configInfo.*
\ldapサブディレクトリ（存在する場合）

再構成および設定の実行中に、これらのファイルの新しいバージョンが生成されます。タスク3および4で実行するブラウザ・ベースの設定手順の最後に、これらのファイルには新しい構成DNおよびポリシーDNが格納されます。指示された時にこれらのファイルを削除すると、アイデンティティ・サーバーのサービスが設定後に開始されます。

16.6.1 クローニングされたCOREidサーバーのサービスおよび詳細の構成

次の手順は、クローニングされた各COREidサーバーのファイル・システム・ディレクトリ内で使用可能なコマンドライン・ツールを使用して実行します。Windowsシステムでは、まずクローンのCOREidサーバーのサービスを構成する必要があります。すべてのシステムで、システム・コンソールのそのクローンに関する情報に基づいて、クローニングされたコンポーネントを構成する必要があります。

注意:

ツール名のoisという略語はOracle Identity Serverを表します。

Windows: クローニングされたCOREidサーバー・サービスのエントリをWindowsレジストリに追加するには、まず、config_ois.exeを実行します。config_ois.exeツールは、クローンのファイル・システム・ディレクトリ\identity\oblix\apps\common\binに格納されています。次に示すサンプルのパスには、ロード・バランシングに使用されるCOREidサーバーのクローンが2つ含まれています。環境はユーザーによって異なります。次に例を示します。

clone_np\ois_01\identity\oblix\apps\common\bin\config_ois.exe
clone_np\ois_02\identity\oblix\apps\common\bin\config_ois.exe

表16-3に、config_oisツールで使用するオプションおよびパラメータをリストします。COREidサーバーのクローンが複数ある場合は、各インスタンスに対してこのタスクを個別に実行する必要があります。

表16-3 config_oisのオプション（Windowsのみ）

コマンド・オプション	操作
-i "clone_dir"	クローニングされたCOREidサーバーへの完全なディレクトリ・パスを引用符で囲んで指定します。次に例を示します。 Windows: -i "C:\clone_np\ois_01\identity" UNIX: -i "/home/clone_np/ois_01/identity"
-v clone_COREidServer_service	クローニングされたCOREidサーバー・サービスの一意の名前を指定します。
-a install	実行する処理を指定します。この場合は、処理としてインストールが指定されています。

コマンド・オプション

操作

-i "clone_dir"

クローニングされたCOREidサーバーへの完全なディレクトリ・パスを引用符で囲んで指定します。次に例を示します。

Windows: -i "C:\clone_np\ois_01\identity"

UNIX: -i "/home/clone_np/ois_01/identity"

-v clone_COREidServer_service

クローニングされたCOREidサーバー・サービスの一意の名前を指定します。

-a install

実行する処理を指定します。この場合は、処理としてインストールが指定されています。

コマンドは、改行せずに1行で入力する必要があります。コマンドを実行すると、メッセージで状況を把握できます。

注意:

対象のインスタンスのシステム・コンソールに入力されている内容に基づいて、各クローン・インスタンスの情報を指定してください。

すべてのプラットフォーム: setup_ois（Windows）およびstart_setup_ois（Windows以外）を実行して、ホスト名、ポートおよびクローニングされたインスタンスのその他の詳細を構成します。このツールを実行する際には、-iオプションのみを使用し、表16-4に示されているように、クローニングされたインスタンスのファイル・システム・パスを指定します。

表16-4 setup_oisおよびstart_setup_oisパラメータ

コマンド・オプション	操作
-i "clone_dir"	クローニングされたCOREidサーバーへの完全なファイル・システム・パスを引用符で囲んで指定します。次に例を示します。 Windows: -i "C:\clone_np\ois_01\identity" UNIX: -i "/home/clone_np/ois_01/identity"

コマンド・オプション

操作

-i "clone_dir"

クローニングされたCOREidサーバーへの完全なファイル・システム・パスを引用符で囲んで指定します。次に例を示します。

Windows: -i "C:\clone_np\ois_01\identity"

UNIX: -i "/home/clone_np/ois_01/identity"

コマンドおよびパラメータは1行で入力してください。クローニングされたインスタンスの次のような詳細を指定するよう要求されます。

クローンCOREidの一意の識別子
クローンのCOREidサーバーのホスト名
クローンのCOREidサーバーがリスニングするポート。
クローンのセキュリティ・モード。
これが最初にインストールされたCOREidサーバーであるかどうか: 答えはNo

システム・コンソールのインスタンスの情報に基づいて、各クローン・インスタンスの情報を指定してください。これが最初にインストールされたCOREidサーバーかどうかについて指定を求められた場合は、Noと答えます。COREidサーバーのクローンが複数ある場合は、各インスタンスに対してこのタスクを個別に実行する必要があります。

コマンドが終了したら、クローンは、指定した情報に基づいて再構成されています。clone_dir\identity\oblix\configファイル・システム・ディレクトリのois_server_config.xmlファイルには、指定した詳細が反映されます。これらのツールの詳細は、Oblix NetPointまたはOracle COREidの管理ガイドを参照してください。

ブラウザベースの設定: クローニングされたCOREidサーバーを再構成したら、クローニングされたWebPassを再構成する必要があります。WebPassを再構成した後には、クローニングされたアイデンティティ・システムに対してブラウザベースの設定を実行する必要もあります。詳細は、必要な時に後続の項で説明します。

アイデンティティ・システムおよびアクセス・システムの混合の監査ポリシー・データ: 表16-5に示されているように、アイデンティティ・システムおよびアクセス・システムの混合におけるCOREidサーバーの再構成中に、監査ポリシーの値が元のデフォルト値に戻る場合があります。次の再構成手順のステップ1では、外部ツールを使用して、監査ポリシー・データをLightweight Directory Interchange Format（LDIF）ファイルにエクスポートするよう指示しています。クローンの再構成後に、このデータをインポートします。LDIFファイルはASCII形式のファイルで、外部ツールを使用して、Lightweight Directory Access Protocol（LDAP）サーバーとのデータの交換や同期に使用できます。外部ツールの使用方法の詳細は、このマニュアルの対象外です。

表16-5 COREidサーバー・クローンの再構成前後の監査ポリシーの例

	イベント名	アプリケーション監査の有効化	監査成功	監査失敗
再構成前	検索	○	○	○
再構成後	検索	○	X	○

次の手順における特定のファイル・システム・パスおよびその他の詳細は例です。詳細はユーザーによって異なります。

クローニングされたCOREidサーバー・サービスを再構成する手順

アイデンティティ・システムおよびアクセス・システムの混合における監査ポリシーの修正: クローニングされたCOREidサーバーをホスティングしているコンピュータで、LDIFファイルをバックアップするために次のノードをエクスポートします（このステップを実行するのは一度のみです）。

obname=common,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN

obname=corpdir,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN

obname=objservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN

obname=userservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN

obname=groupservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN

クローニングされたCOREidサーバー・インスタンスをホスティングしているコンピュータで、ファイル・システム・パス\identity\oblix\configディレクトリから次のファイルを削除します。次に例を示します。

clone_np\ois_01\identity\oblix\config
- setup.xml*
- configInfo.xml*
- \ldapサブディレクトリ（存在する場合）
Windows（config_ois）: このクローン用にレジストリ・エントリを設定するために、次のステップを実行します。
1. このクローンのconfig_oisツールが含まれるファイル・システム・パスに変更します。次に例を示します。
```
cd \clone_np\ois_01\identity\oblix\apps\common\bin\config_ois.exe
```
2. クローニングされたインスタンスの指定内容で、-i、-vおよび-aパラメータを使用してconfig_ois.exeツールを実行します。次に例を示します。
```
config_ois.exe -i "C:\clone_np\ois_01\identity" -v clone_COREid_Service -a install
```
3. COREidサーバー・サービスのエントリがWindowsレジストリに追加されたこと、およびコンポーネントのmessagedll.dllライブラリがWindows/system32/messagedll.dllディレクトリにコピーされたことを確認します。
COREidサーバーの設定ツールが含まれるクローニングされたファイル・システム・パスに変更します。

Windows: clone_np\ois_01\identity\oblix\tools\setup\setup_ois

UNIX: /home/clone_np/ois_01/identity/oblix/tools/setup/start_setup_ois
次のコマンド・パラメータを使用してツールを実行し、クローニングされたCOREidサーバー・サービスおよび環境に合せて指定内容を入力します。

Windows:
```
   setup_ois.exe -i "C:\clone_np\ois_01\identity"
```
UNIX:
```
   ./start_setup_ois -i "/home/clone_np/ois_01/identity"
```
画面のプロンプトに従い、クローニングされたCOREidサーバー・インスタンスおよびCOREidサーバー・サービスの詳細を答えます。
1. COREidの一意の識別子: システム・コンソールに入力したクローンのCOREidサービスの名前を入力します。
2. COREidサーバーのホスト名: クローンのCOREidサーバーが存在するDNSホスト名を入力します。
3. COREidサーバーのポート: クローンのCOREidサーバーがリスニングするポートをシステム・コンソールに指定されているように入力します。
4. セキュリティ・モード[open\simple\cert]: システム・コンソールに指定されているモードを入力します。
5. COREidサーバーとディレクトリ・サーバー間にSSLを設定するかどうか[y/n]: 元の接続に合せて適切に答えます。
6. 最初のCOREidサーバー: これが最初にインストールされたCOREidサーバーかどうかについて指定を求められた場合は、Noと答えます。
クローンのファイル・システム・パスのois_server_config.xmlファイルを確認: ステップ6で指定した詳細が含まれていることを確認するために、\identity\oblix\configファイル・システム・ディレクトリを確認します。
次のように続行します。
- 成功: ステップ7で説明したファイルに情報が表示された場合、操作は成功です。ステップ9に進みます。
- 失敗: ステップ7で説明したファイルに構成DNが表示されない場合、操作は失敗です。この場合は、「再構成されたクローンに対する変更内容のロールバック」を参照してください。
クローニングされたCOREidサーバー・サービスを再開し、次のように続行します。
- 成功: アイデンティティ・システムおよびアクセス・システムの混合の場合は、ステップ10に進みます。それ以外の場合は、ステップ11にスキップします。
- 失敗: クローニングされたCOREidサーバー・サービスが実行されていることを確認します。
ステップ2～7を繰り返して、クローニングされたすべてのCOREidサーバー・インスタンスを構成および確認します。

クローニングされたすべてのCOREidサーバー・インスタンスを構成した後にのみ、ステップ11に進みます。

アイデンティティ・システムおよびアクセス・システムの混合における監査ポリシーの修正: 次のステップを（一度のみ）実行して、デフォルトの監査ポリシー・データを元の監査ポリシー・データと置き換えます。

ディレクトリの新しいブランチから次のノード（新しい構成DN）を削除します。

obname=common,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN

obname=corpdir,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN

obname=objservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN

obname=userservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN

obname=groupservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN

ステップ1の監査ポリシー・データの修正用に作成したLDIFファイルをインポートします。

「クローニングされたCOREidサーバーと連動するためのクローニングされたWebPassインスタンスの構成」に進みます。

16.6.2 クローニングされたCOREidサーバーと連動するためのクローニングされたWebPassインスタンス の構成

クローニングされたWebPassのファイル・システム・ディレクトリに格納されているコマンドライン・ツールを使用して、この項の手順を実行します。このツールを使用すると、クローニングされたCOREidサーバーと通信するように、クローニングされたWebPassを再構成できます。このタスクは、次のフェーズに分かれています。

Webサーバーの構成
WebPassの設定

Webサーバーの構成: WebPassクローンと連動するように新しいWebサーバー・インスタンスを構成するために使用されるツールは、クローニングされたWebPassのファイル・システム・パスに格納されています。次に例を示します。

Windows: clone_np\webcomponent_01\identity\oblix\apps\common\
bin\toolname

UNIXベースのシステム: /home/clone_np/webcomponent_01/identity/oblix/tools/
setup/InstallTools/toolname

この例のUNIXベースのシステムという用語は、LinuxやSolarisなどのサポートされているプラットフォームを意味します。サンプルのパスclone_np\webcomponent_01\identityは、このホストのクローニングされた2つのWebPassインスタンスの1つを表します。Webサーバー構成ツールの名前は、使用しているWebサーバーのタイプにより異なります。次に例を示します。

EditObjConfは、Sun（以前のNetscape/iPlanet）Webサーバーに使用されます。
EditHttpConfは、Apache、Oracle HTTP Server（OHS）およびIBM HTTP（HIS）Webサーバーに使用されます。
configureIIS4webpass.batは、Microsoft Internet Information Server（Windows環境のIIS Webサーバー）に使用されます。

Webサーバーの構成ツールは対話型です。リクエストされたWebPassクローンの詳細をすべて指定する必要があります。

更新中に、Webサーバー構成ファイルが自動的にバックアップされます。バックアップ・ファイルは、元の構成ファイルと同じディレクトリに格納されます。たとえば、Webサーバー・インスタンスがApacheの場合、バックアップ・ファイルはhttp.conf.ORIG、http.conf.ORIG1、http.conf.ORIG2です。iPlanet/SunOne Webサーバーを使用している場合、構成ファイルはmagnus.confおよびobj.confで、次の場所に格納されます。

iPlanet/SunOne: WebServer_install_dir/https-instanceName/config

Webサーバー・インスタンスは、Webサーバー構成ファイルを更新するたびに再起動する必要があります。変更内容は、Webサーバーが再起動されるまで反映されません。

WebPassの設定: WebサーバーがWebPassクローンと連動するように構成したら、WebPass設定ツールを使用して、クローニングされたWebPassとクローニングされたCOREidサーバーが通信できるようにします。ツールはクローニングされた各WebPassのファイル・システム・パスに格納されていますが、プラットフォームによって名前が異なります。次に例を示します。

Windows: clone_np\webcomponent_01\identity\oblix\tools\setup\setup_
webpass

UNIX: /home/clone_np/webcomponent_01/identity/oblix/tools/setup/start_setup_
webpass

この例のUNIXは、LinuxやSolarisなどのサポートされているUNIXベースのプラットフォームを意味します。表16-6に、ツールのオプションを示します。このツールを実行した場合、指定できるのは-iオプションのみで、その他すべての情報は自動的にリクエストされます。WebPassのクローン・インスタンスが複数ある場合は、各クローン・インスタンスに対してこの操作を繰り返す必要があります。

表16-6 setup_webpassおよびstart_setup_webpassのオプション

コマンド・オプション	操作
-i "WebPass_clone_dir"	クローニングされたWebPassが格納されている完全なディレクトリ・パスを引用符で囲んで指定します。次に例を示します。 Windows: -i "C:\clone_np\webcomponent_01\identity" UNIX: -i "/home/clone_np/webcomponent_01/identity"
-q -n WebPass _name	WebPassクローンの一意の名前を指定します。
-h clone_COREidServer_Hostname	クローニングされたCOREidサーバーが存在するコンピュータ名を指定します。
-p clone_COREidServer_port_#	クローニングされたCOREidサーバーが存在するコンピュータのポート番号を指定します。
-s mode	クローニングされたCOREidサーバーおよびWebPassのトランスポート・セキュリティ・モードを、open、simpleまたはcertのいずれかで指定します。
-P simple\|cert mode password	簡易または証明書トランスポート・セキュリティ・モードのパスワードを指定します。
-c request\|install	証明書のリクエストまたはインストールを指定します。

コマンドは、改行せずに1行で入力する必要があります。コマンドを実行すると、メッセージで進行状況が通知され、WebPassクローンの情報の指定を求められる場合があります。特定のインスタンスおよび環境の情報を指定してください。

次の手順では、実行する必要のあるステップを説明します。ステップ1～4は、Webサーバーの再構成に関連しています。この例では、EditObjConfを使用します。ステップ5～8ではWebPassの再構成を説明します。すべてのWebPassのクローン・インスタンスを再構成した後に、ステップ9を実行します。次のステップのパスおよびホスト名は例としてあげられています。詳細はユーザーによって異なります。

クローニングされたWebPassがクローニングされたCOREidサーバーと連動するように変更する手順

クローニングされたWebPass Webサーバー構成更新ツールが含まれるファイル・システム・パスに変更します。次に例を示します。

cd
Windows: clone_np\webcomponent_01\identity\oblix\apps\common\
bin\toolname

UNIX: /home/clone_np/webcomponent_ 01/identity/oblix/tools/setup/
InstallTools/toolname

このサンプルのパスで、clone_np\webcomponent_01\identityはクローニングされたWebPassが存在するファイル・システムで、EditObjConfはこの（Sun）WebサーバーのWebサーバー構成更新ツールの名前です。

クローニングされたWebPassの指定内容で、-f、-dおよび-iオプションを使用して更新ツールを実行し、環境の詳細に合せてプロンプトに答えます。次に例を示します。

Windows:

     EditObjConf.exe -f "C:\clone_Webserver_config_dir" -d "C:\clone_np\
     webcomponent_01\identity" -i

UNIX:

     ./EditObjConf -f "/home/clone_Webserver_config_dir" -d "/home/clone_np/
     webcomponent_01/identity" -i

この操作中に自動的に作成されるWebサーバー構成ファイルのバックアップの場所を記録します。
Webサーバーを再起動します。
次のように続行します。
- 成功: この操作が成功したことを示すステータス・メッセージが表示されます。その後、Webサーバー構成ファイルのバックアップ・コピーを、更新済のバージョンと比較できます。ステップ5に進みます。
- 失敗: 「再構成されたクローンに対する変更内容のロールバック」に進みます。
クローニングされたWebPassインスタンスの設定ユーティリティが含まれるファイル・システム・パスに変更します。次に例を示します。

cd
Windows: clone_np\webcomponent_01\identity\oblix\tools\setup\setup_
webpass

UNIX: /home/clone_np/webcomponent_01/identity/oblix/tools/setup/start_setup_
webpass
次のオプション（表16-6も参照）、およびクローン環境の指定内容を使用してツールを実行します。次に例を示します。
```
   setup_webpass -i "C:\clone_np\webcomponent_01\identity"
```
画面のプロンプトに従い、クローニングされたWebPassおよび関連付けられたCOREidサーバーのクローンの詳細を答えます。
1. WebPassの一意の識別子: システム・コンソールに表示されるクローンのWebPassの名前を入力します。
2. COREidサーバーのホスト名: 関連付けられたクローンのCOREidサーバーが存在するDNSホスト名を入力します。
3. COREidサーバーのポート: 関連付けられたクローンのCOREidサーバーがリスニングするポートをシステム・コンソールに指定されているように入力します。
4. セキュリティ・モード[open\simple\cert]: システム・コンソールに指定されているモードを入力します。
次のように続行します。
- 成功: ステップ9に進みます。
- 失敗: 「再構成されたクローンに対する変更内容のロールバック」に進みます。
この手順全体を繰り返し、クローニングされたWebPassをすべて再構成します。
クローニングされたWebPassインスタンスをすべて再構成したら、「クローニングされたCOREidシステムで新しいブランチを使用するための設定」に進みます。

16.6.3 クローニングされたCOREidシステムで新しいブランチを使用するための設定

クローニングされたCOREidサーバーおよびWebPassインスタンスをすべて構成したら、この項のタスクを実行して、クローニングされたCOREidシステムで新しい構成DNが使用されるように設定します。

このブラウザベースの設定中に、LDAPディレクトリ・サーバーのタイプ、ユーザー・データの場所、および元のCOREidシステムの設定時に定義された検索ベースなど、元のインストールの詳細の一部を指定する必要があります。これらの詳細は、最初にインストールされたCOREidサーバーの元のファイル・システム・パスのsetup.xmlファイルにあります。この例では、ファイルはnp611\ois_01\identity\oblix\config\setup.xmlに格納されます。COREidシステムの設定の詳細は、以前のNetPointまたはOracle COREidのインストレーション・ガイドを参照してください。

分割されたディレクトリ構成用の追加のディレクトリ・プロファイル: データが別々に格納されていると、COREidサーバーの再構成中に追加のディレクトリ・サーバー・プロファイルが作成される場合があります。たとえば、ユーザー・データがActive Directoryに、ポリシー・データと構成データがADAMに格納されている場合です。

すべてのディレクトリ・サーバー・プロファイルは、obcontainerId=DBAgents,o=Oblix,<Config DN>の下位のディレクトリ・サーバーに格納されます。システムの設定中にプロファイルが作成される場合、システム・コンソールの名前は、前述のノードの下位にあるバックエンドのディレクトリ・サーバーでの名前と同じになります。ただし、プロファイルを手動で作成すると、バックエンドのディレクトリ・サーバーのノード名にはタイムスタンプが使用されます。例16-3に、一般的な10.1.4インストールで作成されるディレクトリ・プロファイルを示します。

例16-3 Oracle Access ManagerのLDAPディレクトリ・プロファイル

obcontainerId=DBAgents,o=Oblix,dc=us,dc=oracle,dc=com
-obname=default-IDSERVER,obcontainerId=DBAgents, o=Oblix,dc=us,dc=oracle,dc=com
-obname=AccessManager_setup_user_profile,obcontainerId=DBAgents, o=Oblix,dc=us,
dc=oracle,dc=com
-obname=AccessServer_default_user_profile,obcontainerId=DBAgents, o=Oblix,dc=us,
dc=oracle,dc=com

クローンのCOREidサーバーおよびWebPassの設定後、元のCOREidサーバーのOblixベースのプロファイルを確認して削除する必要があります。これは、このプロファイルに新しい構成DNが含まれていないためです。Access Managerのクローンを設定する前に、元のAccess Managerのポリシー・ベースのプロファイルも削除する必要があります。これは、新しいポリシーDNが含まれていないためです。

注意:

元のCOREidサーバーおよびアクセス・サーバーのOblixベースとポリシー・ベースのプロファイルを削除する必要があるのは、データが分割されたディレクトリ・サーバー構成に格納されている場合のみです。

追加のディレクトリ・サーバー・プロファイルの削除ツール: プロファイルが一貫性のある状態の時に、システム・コンソールから削除できます。ただし、システム・コンソールを使用して古いプロファイルを削除できない場合には、外部ツールを使用して削除する必要があります。

注意:

外部ツールの使用方法の説明はこのマニュアルの対象外ですが、「代替方法: 外部LDPコンソールを使用したプロファイルの削除」で、LDPコンソール・プログラムを使用して追加のプロファイルを削除するステップの例を参照できます。これらは単なる例です。

次の手順では、新しいブランチ用にクローンのCOREidシステムを設定する際に実行する必要のあるステップを説明します。パスおよびホスト名は例としてあげられています。詳細はユーザーによって異なります。COREidシステムの設定の詳細は、Oblix NetPointまたはOracle COREidのインストレーション・ガイドを参照してください。

クローニングされたCOREidシステムが新しいブランチと連動するように設定する手順

元のCOREidサーバーのインストール・ディレクトリにあるsetup.xmlで、インストールの元の詳細を探します。次に例を示します。

元の詳細: np611\identity_01\oblix\config\setup.xml
クローンのWebPassに対応しているWebサーバーが稼働していることを確認し、通常どおり、クローニングされたCOREidシステム・コンソールに移動します。次に例を示します。

クローン:
```
   http://hostname:port/identity/oblix/
```
このサンプルURLで、hostnameはクローニングされたWebPass Webサーバーをホスティングするコンピュータ、portはWebPassクローンの新しいWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/identity/oblixはCOREidシステム・コンソールのリンクを含むクローニングされたCOREidのホームページに接続します。

クローニングされたWebPassによりクローニングされたCOREidサーバーに接続され、設定ページが起動されます。
COREid（アイデンティティ）システム・コンソールのリンクをクリックします。

クローンの「システム・コンソール」設定ページが表示されます。
「セットアップ」ボタンをクリックします。
画面の指示に従い、クローニングされたアイデンティティ・システムを設定します。
1. 新しいディレクトリ・ブランチのLDAPディレクトリ・サーバーの詳細を確認します。
2. ユーザー・データ用のルート・バインドDNを入力します。
3. 新しい構成DNおよび元のユーザー・データの検索ベースを入力します。次に例を示します。
  
  構成DN: o=Newbranch,o=company,c=us
  
  検索ベース: 元の検索ベースを指定
4. その他すべての詳細をそのままにして、この設定手順を終了します。
5. 画面のメッセージで指示されたら、クローンのCOREidサーバー・サービスを再開します。
\identity\oblix\configファイル・システム・ディレクトリに移動し、指定した新しい情報が次のファイルに表示されていることを確認します。
- setup.xml
- configInfo.xml
- \ldapディレクトリ
クローンのCOREidシステム・コンソールに移動し、クローニングされたCOREidサーバーのディレクトリ・サーバー・プロファイルに新しい構成DNが含まれていることを、次のようにして検証します。
1. 通常どおり、クローンのCOREidシステム・コンソールに移動します。
```
http://hostname:port/identity/oblix/
```
2. COREidシステム・コンソールで、「システム管理」タブ→「システム構成」タブをクリックします。
3. 左側の列で「ディレクトリ・オプションの構成」をクリックし、「プロファイルの構成」ページを表示します。
4. 既存のディレクトリ・プロファイルの名前をクリックして、指定内容を表示します。
5. 新しい構成DNがプロファイルに表示されることを確認します。

分割されたディレクトリ・サーバー構成の余分なディレクトリ・プロファイル: データが異なるディレクトリ・サーバーに格納されている場合は、次の手順を実行して、分割されたディレクトリ・サーバー環境の元（古い）の構成DNまたはポリシーDNを含むディレクトリ・プロファイルを削除します。

クローンのCOREidシステム・コンソールで、「システム管理」タブ→「システム構成」タブをクリックします。
「システム構成」タブの左側の列で、「ディレクトリ・オプションの構成」をクリックします。

ディレクトリ・サーバー・プロファイルの構成ページで、この再構成中に作成された新しいディレクトリ・プロファイルの名前の横にあるボックスを選択します。

注意:

元のLDAPディレクトリ・サーバー・プロファイル、またはクローニングされた設定用にユーザーやチームが追加したプロファイルは、選択または削除しないでください。

「削除」ボタンをクリックして、余分なLDAPディレクトリ・サーバー・プロファイルを削除します。

要求された場合は、「OK」をクリックして決定内容を確認します。

注意:

システム・コンソールを使用してプロファイルを削除できない場合には、「代替方法: 外部LDPコンソールを使用したプロファイルの削除」の説明に従って、外部ツールを使用して古いプロファイルを削除する必要があります。

クローニングされたCOREidサーバー・サービス（およびAccess Manager Webサーバー）を再開します。
次のように続行します。
- 構成の成功（アイデンティティ・システムのみ）: 「停止時間ゼロのアップグレード中のスキーマのアップグレード」に進みます。
- 構成の成功（アイデンティティ・システムおよびアクセス・システムの混合）: 「クローニングされたAccess Managerで新しいブランチを使用するための設定」に進みます。
- 構成の失敗: ステップ6で説明したファイルを削除して、「クローニングされたCOREidサーバーのサービスおよび詳細の構成」の説明に従って、setup_ois（Windows）またはstart_setup_ois（Windows以外）を再実行します。それ以外の場合は、「再構成されたクローンに対する変更内容のロールバック」を参照してください。

外部ツールを使用して余分なプロファイルを削除する必要がある場合は、次のサンプルの手順が役に立ちます。外部ツールの使用方法の詳細は、このマニュアルの対象外です。

代替方法: 外部LDPコンソールを使用したプロファイルの削除

ldp.exeを使用してコンソールを開きます。
「Connection」タブで「Connect」を選択します。
LDAPディレクトリ・サーバーのコンピュータ名およびポートを入力して、「OK」をクリックします。
「Connection」タブで「Bind」を選択します。
「User」テキスト・ボックスに、LDAPディレクトリ・サーバーのバインドDNおよびパスワードを入力し、ドメインが選択解除されていることを確認して「OK」をクリックします。

成功を示す、認証されたという内容のメッセージが表示されます。それ以外の場合はエラー・メッセージが表示されます。
次のように続行します。
- 成功: ステップ7に進みます。
- 失敗: バインド操作を再試行し、正確なバインドDNおよびパスワードを入力したことを確認してください。
「View」タブで「Tree」を選択します。
LDAPディレクトリ・サーバーの構成DN（アイデンティティ・サーバーまたはAccess ManagerのポリシーDN）を入力して、「OK」をクリックします。
ブランチの作成操作（Mkbranch）中に作成された新しいノードを選択します。
新しいノード内で、次の文字列で始まるノードを探します。
```
     obcontainerId=DBAgents,OU=Oblix,OU=NewNode.....
```
見つけたノード内で、属性値を検索して余分なプロファイルを確認します（多くの場合はプロファイル名で特定します）。
余分なプロファイルを削除することを確認したら、プロファイルを右クリックして「Delete」を選択します。
「DN」フィールドのノードが正しいものであることを検証し、すべてのボックス（「extended」、「synchronous」および「recursive」）を選択して「OK」をクリックします。
削除を確認するメッセージを受信したことを確認します。たとえば、「deleted 1 entries」などです。

16.6.4 クローニングされたAccess Managerで新しいブランチを使用するための設定

このタスクは、アイデンティティ・システムおよびアクセス・システムの混合の場合にのみ実行します。それ以外の場合は、「クローニングされたアイデンティティ・システムのアップグレード」にスキップします。

このタスクは2つの部分に分かれています。

タスクの概要: クローニングされたAccess Managerで新しいブランチを使用するための構成

クローニングされたAccess ManagerのWebサーバー構成ファイルの更新
クローニングされたAccess Managerで新しいブランチを使用するための設定

16.6.4.1 クローニングされたAccess ManagerのWebサーバー構成ファイルの更新

クローニングされたAccess ManagerがLDAPディレクトリ・サーバーの新しいブランチと連動するよう構成するために実行するステップは、クローニングされたCOREidシステムに対して実行したステップに似ています。ここでは、クローニングされたAccess Managerのファイル・システム・ディレクトリに用意されているツールを使用して、Webサーバー構成ファイルを更新します。

Webサーバーの構成: クローニングされたAccess Managerと連動するようWebサーバー構成を更新するために使用するツールは、クローニングされたAccess Managerのファイル・システム・パスに存在します。次に例を示します。

Windows: clone_np\webcomponent_01\access\oblix\apps\common\bin\toolname

UNIX: /home/clone_np/webcomponent_01/access/oblix/tools/setup/InstallTools/
toolname

サンプルのパスで、clone_np\webcomponent_01\accessは、クローニングされた2つのAccess Managerインスタンスの1つを表します。Webサーバー構成ツールの名前は、使用しているWebサーバーのタイプにより異なります。次に例を示します。

EditObjConfは、Sun（以前のNetscape/iPlanet）Webサーバーに使用されます。
EditHttpConfは、Apache、Oracle HTTP Server（OHS）およびIBM HTTP（HIS）Webサーバーに使用されます。
configureIIS4accesssystem.batは、Microsoft Internet Information Server（Windows環境のIIS Webサーバー）に使用されます。

コマンドは、改行せずに1行で入力する必要があります。更新中に、Webサーバー構成ファイルが自動的にバックアップされます。バックアップ・ファイルは、元の構成ファイルと同じディレクトリに格納されます。たとえば、Webサーバー・インスタンスがApacheの場合、バックアップ・ファイルはhttp.conf.ORIG、http.conf.ORIG1、http.conf.ORIG2です。iPlanet/SunOne Webサーバーを使用している場合、構成ファイルはmagnus.confおよびobj.confで、次の場所に格納されます。

iPlanet/SunOne: WebServer_install_dir/https-instanceName/config

次の手順では、実行する必要のあるステップを説明します。パスおよびホスト名は例としてあげられています。詳細はユーザーによって異なります。

クローニングされたAccess Manager Webサーバーを変更する手順

クローンのAccess Managerに対応しているWebサーバーの適切な更新ツールが含まれるファイル・システム・パスに変更します。次に例を示します。

cd
Windows: clone_np\webcomponent_01\access\oblix\apps\common\bin\
toolname

UNIX: /home/clone_np/webcomponent_01/access/oblix/tools/setup/InstallTools/
toolname
クローニングされたAccess Managerの指定内容で、-f、-dおよび-iオプションを使用してツールを実行し、環境に合せて詳細に関するプロンプトに応えます。次に例を示します。

Windows:
```
     EditObjConf.exe -f "C:\clone_Webserver_config_dir" -d "C:\clone_np\
     webcomponent_01\access" -i
```
UNIX:
```
     ./EditObjConf -f "/home/clone_Webserver_config_dir" -d "/home/clone_np/
     webcomponent_01\access" -i
```
サンプルのパス名で、clone_Webserver_config_dirは、クローニングされたAccess Managerで使用されるWebサーバー構成ファイルのディレクトリです。
この操作中に自動的に作成されるWebサーバー構成ファイルのバックアップの場所を記録します。
Webサーバー・インスタンスを再起動して、Access Manager Webサーバー構成の更新が成功したことを確認し、次のように続行します。
- 成功: 「クローニングされたAccess Managerで新しいブランチを使用するための設定」に進みます。
- 失敗: 「再構成されたクローンに対する変更内容のロールバック」に進みます。

16.6.4.2 クローニングされたAccess Managerで新しいブランチを使用するための設定

クローンのAccess Manager Webサーバー構成ファイルを更新したら、クローニングされたAccess Managerを設定する必要があります。このタスクを実行して、クローニングされたAccess Managerが新しい構成DNおよびポリシーDNを使用するよう設定します。

このブラウザベースの設定中には、元のインストールの詳細を指定する必要があります。たとえば、LDAPディレクトリ・サーバーのタイプ、ユーザー・データの場所、検索ベース、および元のCOREidシステムの設定時に定義された人オブジェクト・クラスを指定する必要があります。人オブジェクト・クラスおよびその他の詳細は、元のCOREidサーバーのファイル・システム内のsetup.xmlファイルにあります。たとえば、np611\ois_01\identity\oblix\config\ setup.xmlです。

注意:

開始リリースが6.1.1の場合、ファイルの名前はsetup.xmlおよびconfigInfo.xmlではなく、setup.lstとconfigInfo.lstになります。

また、構成データおよびポリシー・データが格納されているディレクトリの新しいブランチを含む、新しい情報を指定する必要があります。

次の手順では、実行する必要のあるステップを説明します。パスおよびホスト名は例としてあげられています。詳細はユーザーによって異なります。Access Managerの設定の詳細は、NetPointまたはOracle COREidのインストレーション・ガイドも参照してください。

クローニングされたAccess Managerが新しいブランチと連動するように設定する手順

元のCOREidサーバーのsetup.xmlファイルにある元のインストールの詳細を探します。次に例を示します。

元のインストール: np611\identity_01\oblix\config\setup.xml
クローニングされたAccess Managerインスタンスのファイル・システム・パスで次のファイルを削除します。具体的には次のとおりです。

clone_np\webcomponent_01\access\oblix\config
- setup.*
- setup_am.*
- configInfo
- \ldapサブディレクトリ（存在する場合）
Access Manager Webサーバーが稼働していることを確認します。
クローンのアクセス・システム・コンソールに移動します。
```
     http://hostname:port/access/oblix/
```
このサンプルURLで、hostnameはクローンのWebPassをホスティングするコンピュータ、portはWebPassクローンの新しいWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/access/oblixはクローンのアクセス・システム・コンソールに接続します。

WebPassにより、クローニングされたアクセス・システム・コンソールに接続されます。
クローンの「アクセス・システム・コンソール」リンクをクリックし、「セットアップ」ページを表示して「セットアップ」ボタンをクリックします。
次のようにして、Access Managerが新しい構成DNおよびポリシー・ベースを使用するよう設定します。
1. LDAPディレクトリ・サーバーのタイプ、およびユーザー・データと構成データの場所と詳細を含むLDAPディレクトリ・サーバーの詳細を入力して確認します。
2. ユーザー・データ（元の検索ベース）の情報、新しい構成DN、および新しいポリシーDN（ベース）を入力します。次に例を示します。
  
  検索ベース: 元の検索ベースを入力。
  
  構成DN: o=Newbranch,o=company,c=us
  
  ポリシー・ベース: o=NewPolicyBase,o=Policy_base,o=company,c=us
3. Access Managerの残りの設定ページに入力し、その他すべての詳細はそのままにします。
4. 元のCOREidシステムの設定中に選択した元の人オブジェクト・クラスを入力します。
5. 指示されたら、Webサーバーおよびアイデンティティ・サーバー・サービスを再開します。
6. Webサーバーを再起動したら、「次へ」をクリックして、デフォルトの「ポリシー・ドメイン・ルート」をそのまま使用します（または、元のインストールのルートを指定します）。
7. 続行しますが、NetPointのURLを保護するための認証スキームまたはポリシーは構成しないでください。
8. 設定が完了したら「完了」をクリックします。

次のようにして、ディレクトリ・サーバー・プロファイルに新しい構成DNおよびポリシー・ベースが含まれていることを確認します。

通常どおり、クローンのアクセス・システム・コンソールに移動します。
```
http://hostname:port/access/oblix/
```
「アクセス・システム・コンソール」→「システム構成」→「サーバー設定」をクリックします。
「ディレクトリ・サーバー」リンクをクリックして、「ディレクトリ・サーバー構成」ページを表示します。
ディレクトリの新しいブランチの正しい構成DNおよびポリシー・ベースであることを確認して、「取消」をクリックします。

分割されたディレクトリ・サーバー構成の余分なディレクトリ・プロファイル: Access Managerおよびアクセス・サーバーに追加された余分なディレクトリ・サーバー・プロファイルの有無を確認し、削除します。詳細は、「クローニングされたCOREidシステムで新しいブランチを使用するための設定」の余分なプロファイルに関する説明、および『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

注意:

次のように続行します。
- 成功: ステップ9に進みます。
- 失敗: ステップ2で説明したファイルを削除して、この手順の説明に従ってブラウザベースの設定を再実行します。それ以外の場合は、「再構成されたクローンに対する変更内容のロールバック」を実行してください。
このクローン・インスタンスの構成ファイルに、新しい構成DNが表示されていることを確認します。次に例を示します。

clone_np\webcomponent_01\access\oblix\config
- setup.*（setup.xmlはCOREidサーバーでの名前で、setup.lstはAccess Manager 7.0以前に使用されていました。）
- setup_am*
- configInfo
次のように続行します。
- 成功: ステップ9で説明したファイルに新しい構成DNおよびポリシー・ベースが表示された場合、操作は成功です。ステップ11に進みます。
- 失敗: ステップ9で説明したファイルに新しい構成DNおよびポリシー・ベースが表示されない場合、操作は失敗です。この場合は、この手順全体を再度実行してください。それ以外の場合は、「再構成されたクローンに対する変更内容のロールバック」を参照してください。
次の手順を繰り返し、クローニングされたすべてのAccess Managerインスタンスを再構成します。
- クローニングされたAccess ManagerのWebサーバー構成ファイルの更新
- クローニングされたAccess Managerで新しいブランチを使用するための設定
クローニングされたAccess Managerインスタンスをすべて再構成したら、「クローニングされたアクセス・サーバーの構成」に進みます。

16.6.5 クローニングされたアクセス・サーバーの構成

このタスクは、アイデンティティ・システムおよびアクセス・システムの混合がデプロイされている場合にのみ実行します。それ以外の場合は、「クローニングされたアイデンティティ・システムのアップグレード」にスキップします。

configureAAAserver.exeツール（Windows）を使用してこの手順を実行します。UNIXベースのプラットフォームでは、このツールはstart_configureAAAServerという名前です。このツールは、インスタンスのファイル・システム・パスに格納されています。ファイル名はプラットフォームによって異なります。次に例を示します。

Windows: clone_np\aaa_01\access\oblix\tools\configureAAAServer\
configureAAAServer.exe

UNIX: /home/clone_np/aaa_01/access/oblix/tools/configureAAAServer/
start_configureAAAServer

これらは対話型のツールです。ツールを実行すると、クローニングされたアクセス・サーバーの次の内容を含む詳細を指定するよう要求されます。

クローニングされたアクセス・サーバーのトランスポート・セキュリティ・モード
ユーザー・ディレクトリが実行されているセキュリティ・モード
ユーザー・ディレクトリが存在するホスト・コンピュータ
ユーザー・ディレクトリがリスニングするポート番号
ユーザー・ディレクトリのバインドDN
ユーザー・ディレクトリのパスワード
ユーザー・データのディレクトリ・タイプ
コピーされたoblix（構成）データの格納場所
新しい構成DN
新しいポリシー・ベース
クローニングされたアクセス・サーバーID
アクセス・サーバー・サービスの起動
フェイルオーバー情報の指定（必要な場合）

各クローンに対して入力する情報は、システム・コンソールに表示されるそのクローンの情報と一致する必要があります。

この再構成中に、クローニングされたアクセス・サーバーに余分なディレクトリ・プロファイルが作成される場合があります。再構成したアクセス・システムの検証時に、余分なディレクトリ・プロファイルを削除するよう指示されます。

次の手順のパスおよびホスト名はサンプルとしてあげられています。詳細はユーザーによって異なります。configureAAAserverツールおよびLDAPディレクトリ・サーバー構成の詳細は、NetPointまたはOracle COREidの管理ガイドを参照してください。

クローニングされたアクセス・サーバーが新しいブランチを使用するように再構成する手順

クローンのアクセス・サーバーのconfigureAAAserverツールが含まれるファイル・システム・パスに変更します。次に例を示します。

cd
Windows: clone_np\aaa_01\access\oblix\tools\configureAAAServer\
configureAAAServer.exe

UNIX: /home/clone_np/aaa_01/access/oblix/tools/configureAAAServer
/start_configureAAAServer

installオプションを使用してツールを実行します。次に例を示します。

Windows:

   configureAAAServer.exe install "C:\clone_np\aaa_01\access"

UNIX:

   ./start_configureAAAServer install "/home/clone_np/aaa_01/access"

画面のプロンプトを読み、要求された場合にはクローンの詳細を指定します。
- クローニングされたアクセス・サーバーのトランスポート・セキュリティ・モード
- ユーザー・ディレクトリが実行されているセキュリティ・モード
- ユーザー・ディレクトリが存在するホスト・コンピュータ
- ユーザー・ディレクトリがリスニングするポート番号
- ユーザー・ディレクトリのバインドDN
- ユーザー・ディレクトリのパスワード
- ユーザー・データのディレクトリ・タイプ
- コピーされたoblix（構成）データの格納場所
- 新しい構成DN
- 新しいポリシー・ベース
- クローニングされたアクセス・サーバーID
- アクセス・サーバー・サービスの起動
- フェイルオーバー情報の指定（必要な場合）
クローニングされたアクセス・サーバー・サービスの名前を入力し、サービスを再開します（フェイルオーバー情報を指定または更新しないでください）。
入力した情報が、（clone_np\aaa_01\access\oblix\config\aaa_server_config.xmlの）aaa_server_config.xmlファイルに含まれていることを確認します。
次のように続行します。
- 成功: ステップ6で説明したファイルに新しいポリシー・ベースが表示されている場合、操作は成功です。ステップ7に進みます。
- 失敗: ステップ5で説明した新しいファイルにポリシー・ベースが表示されない場合、操作は失敗です。この場合は、次のようにします。
  - 「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか移行ログ・ファイルを確認します。
  - イベントおよびアクセス・サーバーのログ出力ファイルを確認します。ロギングおよびログ出力ファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
  - 「再構成されたクローンに対する変更内容のロールバック」を参照します。

次のようにして、クローニングされたアクセス・サーバーのLDAPディレクトリ・サーバー・プロファイルに、新しい構成DNおよびポリシー・ベースが含まれていることを確認します。

通常どおり、クローンのアクセス・システム・コンソールに移動します。
```
http://hostname:port/acces/oblix/
```
「アクセス・システム・コンソール」→「システム構成」→「サーバー設定」をクリックします。
「ディレクトリ・サーバー」リンクをクリックして、「ディレクトリ・サーバー構成」ページを表示します。
コピーされたディレクトリの適切な新しい構成DNおよびポリシー・ベースであることを確認して、「取消」をクリックします。

注意:

次のように続行します。
- 成功: この手順全体を実行して各アクセス・サーバー・クローンを構成し、ステップ10に進みます。
- 失敗: 「再構成されたクローンに対する変更内容のロールバック」に進みます。
新しいポリシー・ベースにすべてのアクセス・サーバー・クローンを構成したら、「停止時間ゼロのアップグレード中のスキーマのアップグレード」に進みます。

16.6.6 環境の分離

このタスクはオプションです。アップグレードしたクローン環境で、テスト期間を延長する場合や、練習期間を設ける場合に便利です。このオプションのタスクを実行するかどうかにかかわらず、クローン環境および元の環境をアップグレードすると別々に動作します。このオプションのタスクを実行するかどうかにかかわらず、2つの環境ではアップグレードしたスキーマが共有されます。

このオプションのタスクは、LDAPディレクトリの新しいブランチを使用するようにクローンを再構成したら、いつでも実行できます。新しいWebGateをクローン環境に追加できます。ただし、新しいWebGateを追加できるのは、クローン設定全体をアップグレードした後です。それまでは、クローニングされたアクセス・サーバーに関連付けられている元のWebGateを保持しておきます。

クローン環境、元の環境、または両方の環境を、次のタイミングで分離することを選択できます。

クローンの再構成直後

注意:

クローン・システム全体をアップグレードするまでは、クローニングされたアクセス・サーバーに関連付けられている元のWebGateを保持しておきます。

クローンのアップグレード直後
分離しない

「元の環境とクローン環境の分離の概要」で説明されているように、元のシステム・コンソールからクローン・プロファイルが削除されている場合に、ロールバックしてクローンのアップグレードを再開するには、クローン・プロファイルを再入力する必要があります。また、元のブランチに追加された新しい情報を取得する場合には、クローン・インスタンスを再構成して再度アップグレードする必要があります。この場合には、元のシステム・コンソールのクローン・プロファイルが必要です。

環境の分離の詳細は、次の項を参照してください。

クローン設定の分離およびWebGateの範囲の指定
元の設定の分離の概要

16.6.6.1 クローン設定の分離およびWebGateの範囲の指定

このタスクはオプションです。この手順では、アップグレードしたクローン設定を分離する方法を説明します。

クローン設定を分離するには、元のインスタンス・プロファイルをクローンのシステム・コンソールから削除します。クローン設定内で、元のWebGateを新しいWebGateに置き換える必要があります。ただし、新しいWebGateをクローン環境に追加できるのは、クローン設定全体をアップグレードした後です。

アイデンティティ・システムのみの環境では、元のCOREidサーバーおよびWebPassプロファイルをクローンのシステム・コンソールで無効化または削除します。アイデンティティ・システムおよびアクセス・システムの混合の場合も、元のアクセス・サーバーをクローンのシステム・コンソールで無効化または削除します。

アクセス・サーバー・クローンに関連付けられた元のWebGateプロファイルを無効化または削除する前に、新しいWebGateインスタンスを追加して元の機能と置き換える必要があります。新しいWebGateをクローン環境に追加できるのは、クローン設定全体をアップグレードした後です。それまでは、クローニングされたアクセス・サーバーに関連付けられている元のWebGateを保持しておきます。

停止を避けるため、WebGateを複数用意することをお薦めします。または、アップグレードしたアクセス・サーバーと連動できるため、古いWebGateを残してアップグレードしないことも可能です。WebGateが1つのみの場合は、そのWebGateのアップグレード中（またはロールバック中）は停止します。

クローン設定を分離してWebGateの範囲を指定する手順

クローンのシステム・コンソールで、次の操作を実行します。
- 元のCOREidサーバーのプロファイルを無効化または削除
- 元のWebPassインスタンスのプロファイルを無効化または削除
- 元のディレクトリ・プロファイルを無効化または削除
- 元のアクセス・サーバーのプロファイルを無効化または削除
- クローン・システム全体をアップグレードするまで、クローンのアクセス・サーバーに関連付けられた元のWebGateのプロファイルを無効化または削除しないでください。

アップグレードしたクローン・システムをアップグレードおよび検証した後に、新しいWebGateを追加します。

クローンのアクセス・システム・コンソールで、新しいWebGateの指定内容を追加します。この内容は、クローンのアクセス・サーバーに関連付けられている元のWebGateの指定内容と一致する必要があります。

注意:

WebGateの名前およびポートは一意である必要があります。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

クローンのアクセス・システム・コンソールで、新しいWebGateをアクセス・サーバー・クローンに関連付けます。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、10g（10.1.4.0.1）のWebGateをインストールし、クローンのアクセス・システム・コンソールに追加したWebGate識別子を割り当てます。
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)の説明に従って、リリース10.1.4パッチ・セット1（10.1.4.2.0）を新しいWebGateに適用します。
ステップa～dを繰り返し、アップグレードしたクローン設定に、新しいWebGateを必要なだけ追加します。

クローン・システムをテストして、新しいWebGateと正常に連動していることを確認します。
クローンのアクセス・システム・コンソールで、アクセス・サーバー・クローンに関連付けられている元のすべてのWebGateのプロファイルを無効化します。

16.6.6.2 元の設定の分離の概要

このタスクはオプションです。

元の設定を分離するには、元のシステム・コンソールですべてのクローン・プロファイルを無効化または削除します。システム・コンソールには、Access Managerのプロファイルはありません。クローンのWebGateインスタンスまたはプロファイルもありません。

元の設定を分離する手順

元のシステム・コンソールで、次の操作を実行します。

元のシステム・コンソールでクローンのCOREidサーバー・プロファイルを無効化または削除
元のシステム・コンソールでクローンのWebPassプロファイルを無効化または削除
元のシステム・コンソールでクローンのディレクトリ・プロファイルを無効化または削除

元のシステム・コンソールでクローンのアクセス・サーバー・プロファイルを無効化または削除

注意:

新しいWebGateをクローン環境に追加できるのは、クローン設定全体をアップグレードした後です。それまでは、元のWebGateに関連付けられているクローニングされたアクセス・サーバー・プロファイルを保持しておきます。

元のシステムをテストして正常に動作していることを確認します。
元のインスタンスをアップグレードする前に、次のことを行うことをお薦めします。
- 元のシステムに加えられた変更内容を調整する必要があるかどうかを確認します。詳細は、「元のインスタンスのアップグレード前における元のブランチに対する変更内容取得の概要」を参照してください。
- クローン設定により顧客にサービスが提供されていることを確認します。詳細は、「アップグレードしたクローンを使用するためのドメイン・ネーム・システム（DNS）の再構成」を参照してください。

16.6.7 再構成されたクローンに対する変更内容のロールバック

ある問題からリカバリして停止時間ゼロのアップグレードを続行するには、ステップ1を実行し、クローンを再作成して再構成します。次の手順のすべてのステップを実行すると、ホスト・コンピュータおよびシステム・コンソールからクローン構成のトレース内容がすべて削除されます。

元のリリースを使用する場合（または、このマニュアルで説明されているインプレース・メソッドに切り替える場合）は、次の手順のすべてのステップを実行します。

再構成されたクローン・コンポーネントに対する変更内容をロールバックする手順

クローン・サービスおよびWebサーバーを停止し、クローンのファイル・システム・ディレクトリを削除します。
ホスト・コンピュータから次の項目を削除します。
- クローンのファイル・システム
- リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイル
- 追加またはアップグレード・プロセスの一部として自動的に追加された任意のファイル・システム・ディレクトリ
- クローンのWebサーバー・インスタンス
- 新しい構成DNおよびポリシーDN用に追加されたLDAPディレクトリ・サーバーのブランチ
元のシステム・コンソールから、すべてのクローン・プロファイルを削除します（存在する場合）。
元の設定が正常に動作していることを確認します。

16.7 停止時間ゼロのアップグレード中のスキーマのアップグレード

LDAPディレクトリ・サーバーの新しいブランチにあるデータを使用するよう、クローニングされた以前のコンポーネントを構成した後に、スキーマをアップグレードすることをお薦めします。スキーマは1つのみで、クローンおよび元のコンポーネントの両方で使用されています。

この操作では、スキーマのみをアップグレードします。アイデンティティ・システムのスキーマには、オブジェクト・クラスおよびその属性が含まれます。データの格納方法によっては、アクセス・システムのスキーマのアップグレードが必要な場合があります。詳細は、次の項を参照してください。

スキーマのアップグレードの概要
アイデンティティ・システムのスキーマのアップグレード
アクセス・システムのスキーマのアップグレード

16.7.1 スキーマのアップグレードの概要

この項では、スキーマのアップグレードの考慮事項および方法を説明します。最初にインストールされたCOREidサーバー、および最初にインストールされたAccess Managerという用語は、元の環境にインストールおよび設定されたそれぞれのコンポーネントの最初のインスタンスを表します。これらは、ディレクトリ・サーバーにスキーマを追加する際や、元のアイデンティティ・システムおよびアクセス・システムを最初に設定する際に使用されたインスタンスです。

スキーマのアップグレードには、10g（10.1.4.2.0）のMigrateOAMスクリプトを使用します。このスクリプトは、10g（10.1.4.0.1）のアイデンティティ・サーバーのライブラリおよびファイルを抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する際に作成された宛先のファイル・システム・パスで入手できます。

アクセス・システムのスキーマをアップグレードする必要がある場合にも、10g（10.1.4.0.1）のポリシー・マネージャのライブラリおよびファイルを抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する際に作成された宛先のファイル・システム・パスで入手可能な10g（10.1.4.2.0）のMigrateOAMスクリプトが必要です。

停止時間ゼロのアップグレード・メソッドを使用したスキーマのアップグレードに関するガイドライン

環境でのデータの格納方法によっては、スキーマのアップグレードを複数回実行する場合があります。次のガイドラインは、対象の環境におけるスキーマのアップグレード・メソッドを決定する際に役立ちます。

すべてのデータが一緒に格納されている場合: ユーザー・データ、構成データ（oblixデータと呼ばれる場合もある）およびポリシー・データが同じディレクトリ・サーバーに一緒に格納されている場合（または、アクセス・システムもポリシー・データもない場合）、最初にインストールされたCOREidサーバー・インスタンスのクローンに対してMigrateOAMをスキーマ・モードで実行し、単一のLDAPディレクトリ・サーバーのバインド資格証明を指定します。
ユーザー・データが構成データおよびポリシー・データとは別に格納されている場合: ユーザー・データと、構成データおよびポリシー・データが別のディレクトリ・サーバーに格納されている場合は、次のようにして、MigrateOAMをスキーマ・モードで実行する必要があります。
- ユーザー・データのバインド資格証明を使用して、最初にインストールされたCOREidサーバー・インスタンスのクローンに対して一度実行
- 構成データおよびポリシー・データの資格証明を使用して、最初にインストールされたCOREidサーバーのクローンに対してもう一度実行
すべてのデータが別々に格納されている場合: ユーザー・データ、構成データおよびポリシー・データがそれぞれ別々のディレクトリ・サーバーに格納されている場合は、次のようにして、MigrateOAMをスキーマ・モードで実行する必要があります。
- 最初にインストールされたCOREidサーバー・インスタンスのクローンおよびユーザー・データ資格証明に対して一度実行
- 最初にインストールされたCOREidサーバー・インスタンスのクローンおよび構成データ資格証明に対してもう一度実行
- 最初にインストールされたAccess Managerインスタンスのクローンおよびポリシー・データ資格証明に対して3度目の実行
ユーザー・データが複数のディレクトリ・サーバーに格納されている場合: 各ディレクトリ・サーバーには異なる資格証明があります。この場合には、ユーザー・データが格納されているディレクトリ・サーバーごとに一度、MigrateOAMをスキーマ・モードで実行する必要があります（また、スクリプトを実行するたびに、特定のディレクトリ・サーバーの資格証明を指定する必要があります）。

ユーザー・データが複数のディレクトリ・サーバーに分割されている場合は、スキーマをアップグレードする前に、最初のディレクトリ・サーバー・インスタンスを除くすべてのインスタンス用に適切なdirectoryserver_user_schema_add.ldifをアップロードする必要があります。最初のディレクトリ・サーバー・インスタンスは、元のCOREidサーバーを最初にインストールおよび設定した際に指定したインスタンスです。これは、最初のディレクトリ・サーバー・プロファイルの作成時です。その他のディレクトリ・サーバー・プロファイルは、後から追加されています。そのため、インストール中にアップロードされたスキーマは、その他のディレクトリ・サーバー・インスタンスには自動的にロードされていません。

各ldifファイルには、固有のディレクトリ・サーバー・タイプの接頭辞が付いています。directoryserver_user_schema_add.ldifファイルは、COREidServer_install_dir \identity\oblix\data\commonファイル・システム・ディレクトリのクローンに格納されています。多くの場合、ldapmodifyツールを使用して更新を行います。次に例を示します。
```
     ldapmodify –h DS_hostname -p DS_port_number -D bind_dn -w password -a –c
     -f iPlanet_user_schema_add.ldif
```
手動のスキーマ更新ファイルの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

この章の例では、構成データおよびポリシー・データが別々に格納されていると仮定しています。この場合、アイデンティティ・システムのスキーマと、アクセス・システムのスキーマを個別にアップグレードする必要があります。図16-7に、サンプルのスキーマのアップグレードに使用される2つのファイル・システム・ディレクトリを示します。

図16-7 新しい1014およびクローンのファイル・システム・ディレクトリ

「図16-7 新しい1014およびクローンのファイル・システム・ディレクトリ」の説明

図16-7に示されている例に基づいて、スキーマのアップグレード用のMigrateOAMスクリプトがdestination_dirに格納されます。次に例を示します。

1014\identity\oblix\tools\migration_tools\MigrateOAM.bat
1014\webcomponent\access\oblix\tools\migration_tools\MigrateOAM.bat

サンプルのパス名で、1014\identityは10g（10.1.4.2.0）のアイデンティティ・サーバーが格納されている場所で、1014\webcomponent\accessには10g（10.1.4.2.0）のポリシー・マネージャが格納されています。

表16-7に、スキーマ・モードのMigrateOAMスクリプトで指定する引数を示します。このスクリプトは、最初にインストールされたCOREidサーバー（および、ポリシー・データが別に格納されている場合は最初にインストールされたAccess Manager）のクローンに対してのみスキーマ・モードで実行します。

表16-7 スキーマ・モードのMigrateOAMスクリプトの構文

MigrateOAMのスキーマのアップグレード構文	値および操作
-M Schema	モードとしてSchemaを指定します。スキーマ・モードは、古いブランチだけでなく、ディレクトリの新しいブランチにあるスキーマのアップグレードにも必要です。これは一度にすべて実行されます。
-C component	アイデンティティ・システムのスキーマをアップグレードするにはOIS（Oracle Identity Server）を指定します。構成データとは別に格納されているアクセス・システムのスキーマをアップグレードするには、AM（Access Manager）を指定します。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	スキーマのアップグレード後のリリースとして1014を指定します。
-S "source directory"	クローニングされた以前のアイデンティティ・サーバーまたはAccess Managerを含むディレクトリへのフルパス名を引用符で囲んで指定します。次に例を示します。アイデンティティ・サーバー: -C OISの場合は-S "C:\clone_np\ois_01\identity" Access Manager: -C AMの場合は-S "C:\clone_np\webcomponent_01\access"
-D "destination directory"	指定したコンポーネントの10g（10.1.4.2.0）のMigrateOAMスクリプトを含むディレクトリへのフルパス名を引用符で囲んで指定します。次に例を示します。 -C OISの場合は-D "C:\1014\identity" -C AMの場合は-D "C:\1014\webcomponent\access"
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\1014\identity" -I "C:\1014\webcomponent\access"
-B "bind DN"	ディレクトリ情報ツリー（DTI）のユーザーおよび構成ブランチに対して完全な権限を持つ識別名を引用符で囲んで指定します（"cn=Directory Manager"など）。Oracle Access Managerが、このアカウントとしてLDAPディレクトリ・サーバーにアクセスします。
-W Bind password	バインドDNとして指定されたユーザーのパスワードを指定します。

スキーマのアップグレード・プロセスおよびメッセージは、開始リリース（6.1.1など）と最新リリースの間のすべてのリリースで繰り返されます。つまり、スキーマのアップグレード時には、一連の同じメッセージとプロンプトが何度も表示されます。最も短時間でアップグレードする場合は、確認モードではなく自動モードを使用することをお薦めします。また、プロセスはすべて実行することをお薦めします。詳細は、「スキーマ・モードの処理の概要」を参照してください。

スキーマのアップグレードの詳細および手順は、次の各項を参照してください。

アイデンティティ・システムのスキーマのアップグレード
アクセス・システムのスキーマのアップグレード

16.7.2 アイデンティティ・システムのスキーマのアップグレード

アイデンティティ・システムのスキーマをアップグレードするには、次の手順を実行します。クローンおよび元のコンポーネント・インスタンスの両方で、アップグレードしたスキーマが使用されます。

アップグレードしたスキーマには、以前のスキーマとの下位互換性機能があります。アップグレード前にサード・パーティのユーティリティを使用して以前のスキーマをバックアップしておけば、元のリリースにロールバックする場合に、バックアップ・コピーを回復できます。外部ユーティリティの詳細は、このマニュアルの対象外です。

データの格納方法によっては、アイデンティティ・システムのスキーマのアップグレードを複数回実行する必要があります。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したスキーマのアップグレードに関するガイドライン」を参照してください。

表16-7に示されているように、次の手順のパス名および開始リリースはサンプルです。パス名および開始リリースはユーザーごとに異なります。

注意:

次の手順を開始する前に、アップグレードに関するすべての情報を確認することをお薦めします。スキーマのアップグレードを自動的にロールバックする方法はありません。

アイデンティティ・システムのスキーマをアップグレードする手順

「以前のOracle Access Managerスキーマのバックアップ」の説明に従い、アップグレード前にスキーマをバックアップするアクティビティを実行します。
「ディレクトリ・サーバー・インスタンスおよびデータの準備」の説明に従って、ディレクトリ・サーバーが準備されていることを確認します。
ユーザー・データが複数のディレクトリ・サーバーに格納されている場合は、この項の冒頭の説明に従って、スキーマ更新ファイルをアップロードします。次に例を示します。

clone_np\ois_01\identity\oblix\data\common\iPlanet_user_
schema_add.ldif
```
   ldapmodify –h DS_hostname -p DS_port_number -D bind_dn -w password -a –c -f
   iPlanet_user_schema_add.ldif
```
10g（10.1.4.2.0）のアイデンティティ・サーバーのMigrateOAMスクリプトを含むファイル・システム・パスに変更します。次に例を示します。

1014\identity\oblix\tools\migration_tools\MigrateOAM.bat

MigrateOAMをスキーマ・モードで実行して、アイデンティティ・システムのスキーマのアップグレードを開始します。次に例を示します。

     MigrateOAM -M Schema -C OIS -F 610 -T 1014 -S "C:\clone_np\ois_01\
     identity" -D "C:\1014\identity" -I "C:\1014\identity" -b "cn=bindDN" 
     -W password

次のようにして、各手順のプロンプトに答えます。
1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。
2. プロセスをスキップしないでください。
ログ・ファイル（destination_dir\identity\oblix\tools\migration_tools\のobmigratenp.logおよびobmigrateschema.log）を参照して、エラーが発生していないことを確認します。詳細は、付録Cを参照してください。
アップグレードが成功したことを検証し、次のように続行します。
- 成功（データが一緒に格納されている場合またはアイデンティティ・システムのみの場合）: 「アイデンティティ・システムの動作の検証」に進みます。
- 成功（ポリシー・データが別に格納されている場合）: 「環境の正常な動作の検証」の説明に従って動作を検証する前に、「アクセス・システムのスキーマのアップグレード」に進みます。
- 失敗: 「スキーマのアップグレード後におけるロールバック」に進みます。

16.7.3 アクセス・システムのスキーマのアップグレード

このタスクは、クローン環境および元の環境が次の条件に当てはまる場合にのみ実行します。

アイデンティティ・システムおよびアクセス・システムの混合デプロイの場合
構成データがポリシー・データと別々に格納されている場合
ユーザー・データを含むLDAPディレクトリのアイデンティティ・システムのスキーマをアップグレードした場合

詳細は、「停止時間ゼロのアップグレード・メソッドを使用したスキーマのアップグレードに関するガイドライン」を参照してください。

対象の環境がこれらの条件に当てはまる場合、最初にインストールおよび設定されたAccess Managerのクローンを使用して次の手順のステップを実行します。10g（10.1.4.2.0）のポリシー・マネージャのディレクトリから、MigrateOAMスクリプトを実行します。これは、新しいポリシー・ブランチの作成に使用されたのと同じスクリプトです。このスクリプトは、1014\webcomponent\accessなど、最初にインストールされたAccess Managerのクローンをホスティングしているコンピュータのファイル・システム・ディレクトリにあらかじめ格納されています。

MigrateOAMをスキーマ・モードで実行してアクセス・システムのスキーマをアップグレードする方法は、MigrateOAMをスキーマ・モードで実行してアイデンティティ・システムのスキーマをアップグレードする方法に似ています。たとえば、表16-7に説明されているように、アクセス・システムの詳細は次のように指定します。

-C AM
-S "C:\clone_np\webcomponent_01\access"は、このホスト・コンピュータ上に存在する2つのAccess Managerインスタンスのクローンの一方のソース・ディレクトリです。
-D "C:\1014\webcomponent\access"は、アクセス・システムのスキーマのアップグレード先で、10g（10.1.4.2.0）のポリシー・マネージャのライブラリとファイル、およびMigrateOAMスクリプトが含まれています。
-I "C:\1014\webcomponent\access"は宛先と同じです。

アップグレードは、開始リリースと最新リリースの間のすべてのリリースで行われます。最も短時間でアップグレードする場合は、確認モードではなく自動モードを使用することをお薦めします。また、プロセスはすべて実行することをお薦めします。

表16-7に示されているように、次の手順のパス名および開始リリースはサンプルです。パス名および開始リリースはユーザーごとに異なります。

注意:

次の手順を開始する前に、アップグレードに関するすべての情報を確認することをお薦めします。

アクセス・システムのスキーマをアップグレードする手順

IIS Webサーバー: クローニングされたAccess ManagerがIIS Webサーバーと連動している場合には、この手順を開始する前に10g（10.1.4.2.0）のポリシー・マネージャのインストーラを削除します。次に例を示します。

Oracle_Access_Manager10_1_4_0_1__sparc-s2_NSAPI_Access_Manager.exe
10g（10.1.4.2.0）のポリシー・マネージャのMigrateOAMスクリプトを含むファイル・システム・パスに変更します。次に例を示します。

clone_np\1014\webcomponent\access\oblix\tools\migration_tools\
MigrateOAM.bat

MigrateOAMをスキーマ・モードで実行し、最初にインストールされたAccess Managerのクローンの引数を指定します。次に例を示します。

MigrateOAM -M Schema -C AM -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\
access" -D "C:\clone_np\1014\webcomponent\access" -I "C:\clone_np\1014\ 
webcomponent\access" -b "cn=bindDN" -W password

各プロセスを確認しなくてよいように、各手順に自動モードを使用します。
destination_dirのログ・ファイル（ogmigratenp.logおよびobmigrateschema.log）を参照して、エラーが発生していないかどうかを確認します。
アクセス・システムのスキーマのアップグレードが成功したことを検証し、次のように続行します。
- 成功: 「環境の正常な動作の検証」に進みます。
- 失敗: 「スキーマのアップグレード後におけるロールバック」に進みます。

16.8 環境の正常な動作の検証

この項のトピックでは、いくつかの重要な時点において、元の環境およびクローン環境の両方で正常な動作を検証する方法を説明します。実行するステップは、検証する環境（クローンの環境または元の環境）にかかわらず同一です。

検証ステップは、クローン環境と元の環境の両方で実行する必要があります。検証する環境のURLを使用してください。

クローン環境: クローニングされたシステム・コンソールのURLのみを使用します。
元の環境: 元のシステム・コンソールのURLのみを使用します。

タスクの概要: 正常な動作の検証

スキーマをアップグレードしたら、次の環境のURLを使用してクローン環境の動作を検証します。
- クローン環境
- 元の環境
クローンをアップグレードしたら、クローンのシステム・コンソールのURLを使用して検証アクティビティを実行します。
元の環境をアップグレードしたら、元のシステム・コンソールのURLを使用して検証タスクを実行します。

次に、この検証を実行する環境をまとめます。

アイデンティティ・システム: 「アイデンティティ・システムの動作の検証」の手順を実行します。
アイデンティティ・システムおよびアクセス・システムの混合: アイデンティティ・システムを検証する手順を実行し、「アクセス・システムの動作の検証」の手順を実行します。

16.8.1 アイデンティティ・システムの動作の検証

アイデンティティ・システムが正常に動作していることを検証するために、スキーマおよびデータに依存するCOREidシステム・コンソールおよびアプリケーションを使用してタスクを実行します。

次の手順ではステップ、およびアイデンティティ・システムの動作の検証のために実行するアクティビティの概要を説明します。ステップ6には、実行の必要があるアクティビティに関する推奨事項が記載されています。ただし、実行する実際のタスクは環境によって異なります。具体的には次のとおりです。

元のインストールを検証している場合には、元のコンポーネントの適切なURLを使用します。
クローニングされた設定を検証している場合には、クローン・コンポーネントのURLを使用します。

注意:

検証プロセス中は、データを変更しないことをお薦めします。既存のデータのみを使用してシステムを検証し、アップグレードが成功したかどうかを把握するのは重要なことです。

アイデンティティ・システムの正常な動作を検証する手順

アップグレードで影響を受けるCOREidシステムのアプリケーションと機能を特定し、これらをテストする計画を作成します。
COREidサーバー・サービスおよびWebPassのWebサーバー・インスタンスがすべて実行されていることを確認します。
設定（クローン設定と元の設定）の適切なURLを指定し、ブラウザからCOREidシステム・コンソールに移動します。次に例を示します。
```
     http://hostname:port/identity/oblix
```
このサンプルURLで、hostnameはWebサーバーをホスティングするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/identity/oblixはCOREidシステム・コンソールに接続します。

COREidのランディング・ページが表示されます。
ランディング・ページが表示されない場合: COREidサーバー・サービスおよびWebPassのWebサーバー・インスタンスが実行されていること、およびCOREidシステム・コンソールの正しいURLを入力したことを確認します。
マスター管理者としてログインします。
COREidシステム・コンソールまたはアプリケーションを使用して、次のタスクまたはそれ以外のタスクを実行し、スキーマのアップグレードが成功したことを検証します。
- ユーザー・マネージャ、グループ・マネージャまたは組織マネージャで、パネルを確認します。
- ユーザー・マネージャ、グループ・マネージャまたは組織マネージャの監査ポリシーを確認します。
- ユーザー・マネージャ、グループ・マネージャまたは組織マネージャの属性のアクセス制御ポリシーを確認します。
- 適切な場合は、マスター監査ポリシーおよびグローバル監査ポリシーを確認します。
- パスワードおよびロスト・パスワード・ポリシーを確認します。
- 任意のワークフロー構成の詳細を確認します。
- オブジェクト・クラス定義を確認します。
- アイデンティティ・サーバーおよびWebPassの定義、サーバー設定、管理情報、およびディレクトリ・オプションを確認します。
環境に応じて進めます。
- 成功: 環境および次に実行する必要のあるタスクに応じて続行します。次のタスクの詳細は、「停止時間ゼロのアップグレード・タスクおよび順序」を参照してください。
- 失敗: 「スキーマのアップグレード後におけるロールバック」に進みます。

16.8.2 アクセス・システムの動作の検証

この項のアクティビティは、アイデンティティ・システムおよびアクセス・システムの混合デプロイの場合にのみ実行します。それ以外の場合はこの項はスキップしてください。

アクセス・システムの動作を検証するために、スキーマおよびデータに依存するアクセス・システム・コンソールおよびアプリケーションでタスクを実行します。

元の設定を検証している場合には、元のコンポーネントのURLを使用します。
クローニングされた設定を検証している場合には、クローン・コンポーネントのURLを指定します。

次の手順ではステップ、およびアクセス・システムの動作の検証のために実行するアクティビティの概要を説明します。ステップ6には、実行の必要があるアクティビティに関する推奨事項が記載されています。ただし、実行する実際のタスクは設定によって異なります。次に例を示します。

注意:

アクセス・システムの正常な動作を検証する手順

影響を受けるアクセス・システムのアプリケーションおよび機能を特定し、それらをテストする計画を作成します。
Access Manager Webサーバー、およびWebPassのWebサーバー・インスタンスが実行されていることを確認します。
環境（クローン環境と元の環境）の適切なURLを指定し、ブラウザからアクセス・システム・コンソールに移動します。次に例を示します。
```
     http://hostname:port/access/oblix
```
このサンプルURLで、hostnameはWebサーバーをホスティングするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/access/oblixはアクセス・システム・コンソールに接続します。

アクセス・システムのランディング・ページが表示されます。
ランディング・ページが表示されない場合: アイデンティティ・サーバー・サービスおよびWebPassのWebサーバー・インスタンスが実行されていること、およびアクセス・システム・コンソールの正しいURLを入力したことを確認します。
アクセス・システム・コンソールにマスター管理者としてログインします。
次のタスクまたはその他のタスクを実行して、アップグレードしたスキーマを検証します。
- アクセス・サーバー、アクセス・サーバー・クラスタおよびAccess Clientの詳細を確認します。
- 影響を受ける認証および認可スキームの詳細を検証します。
- レポート・データを調査します。
- 影響を受けたポリシー・ドメインを確認します。
- ホスト識別子を確認します。
次のように続行します。
- 成功: 環境および次に実行する必要のあるタスクに応じて続行します。次のタスクの詳細は、「停止時間ゼロのアップグレード・タスクおよび順序」を参照してください。
- 失敗: 「スキーマのアップグレード後におけるロールバック」に進みます。

16.8.3 スキーマのアップグレード後におけるロールバック

この手順を実行すると、スキーマのアップグレードを除くすべての変更が元に戻り、元の設定を復元できます。このタスクを実行した後は、元の設定とアップグレードしたスキーマのみになります。

最新のスキーマには、以前のスキーマとの下位互換性機能があります。スキーマのアップグレードを自動的に元に戻すツールはありません。アップグレード前に外部ツールを使用してスキーマをバックアップしておけば、元のスキーマを回復できます。外部ツールの詳細は、このマニュアルの対象外です。

スキーマのアップグレード後にロールバックする手順

クローン・サービスおよびWebサーバーを停止します。
ホスト・コンピュータから次のものを削除します。
- クローンのファイル・システム・ディレクトリ
- リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイル
- 追加またはアップグレード・プロセスの一部として自動的に追加された任意のファイル・システム・ディレクトリ
- クローンのWebサーバー・インスタンス
- 新しい構成DNおよびポリシーDN用に追加されたLDAPディレクトリ・サーバーのブランチ
元のシステム・コンソールから、すべてのクローン・プロファイルを削除します。
アップグレード前に外部ツールを使用してスキーマをバックアップしておけば、元のスキーマを回復できます。
元の設定が正常に動作していることを確認します。

16.9 クローニングされたアイデンティティ・システムのアップグレード

スキーマをアップグレードして正常に動作していることを検証したら、クローニングされたアイデンティティ・システム・コンポーネントをアップグレードできます。

最初にインストールされたCOREidサーバーのクローンをアップグレードすると、LDAPディレクトリ・サーバーの新しいブランチに格納された構成データもアップグレードされます。アイデンティティ・システム・データの詳細は、「構成データおよびポリシー・データのアップグレードの概要」を参照してください。

実行が必要な一連のタスクは、次の項およびタスクの概要で説明されています。詳細は、バックグラウンドの詳細に関する個々の項、およびステップごとの手順を参照してください。

注意:

Oracle Access Managerの複数のWebコンポーネントに対応している単一のWebサーバー・インスタンスがある場合には、ホスト・コンピュータの対応している全Webコンポーネントがアップグレードされるまで停止しておく必要があります。

タスクの概要: クローニングされたアイデンティティ・システムのアップグレード

アイデンティティ・システムおよびアクセス・システムの混合: アクセス・サーバーのキャッシュ・フラッシュの停止
クローニングされたアイデンティティ・システム・コンポーネントのアップグレードに向けた準備。これには、最初にインストールされたCOREidサーバー・インスタンスのクローンのアップグレード前における構成データのバックアップが含まれます。
クローニングされたCOREidサーバーのアップグレード
クローニングされたWebPassインスタンスのアップグレード
アップグレード済のクローニングされたアイデンティティ・システムの検証
アップグレードしたアイデンティティ・システムのクローンのバックアップ
アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更
SDKおよびアイデンティティ・システムのカスタマイズのアップグレード

問題がある場合のリカバリの詳細は、「クローニングされたアイデンティティ・システムのアップグレードの失敗からのリカバリ」を参照してください。後続の内容を確認するには、「他の章の内容」を参照してください。

16.9.1 アクセス・サーバーのキャッシュ・フラッシュの停止

アイデンティティ・システムとアクセス・システムの混合デプロイの場合は、クローン・コンポーネントをアップグレードする前に、各COREidサーバー（クローンおよび元のCOREidサーバーの両方）のアクセス・サーバーのキャッシュ・フラッシュを停止する必要があります。これを実行するには、元の環境とクローン環境の両方で、次のディレクトリにbasedbparams.xmlファイルを配置します。

COREidServer_install_dir\identity\oblix\data\common\basedbparams.xml

また、次の手順の説明に従って、doAccessServerFlushパラメータをtrueからfalseに変更します。

アクセス・サーバーのキャッシュ・フラッシュを停止する手順

basedbparams.xmlファイルをファイル・システム・パス\identity\oblix\data\commonに配置します。次に例を示します。

clone_np\ois_01\identity\oblix\data\common\basedbparams.xml

np611\ois_01\identity\oblix\data\common\basedbparams.xml

basedbparams.xmlを開いて、doAccessServerFlushパラメータを次のように編集します。

変更前:

<SimpleList>    <NameValPair ParamName="doAccessServerFlush" Value="true" />
</SimpleList>

変更後:

<SimpleList>    <NameValPair ParamName="doAccessServerFlush" Value="false" />
</SimpleList>

COREidサーバー・サービスを（変更したインスタンスをホスティングしているコンピュータで）再開します。
クローニングされた各COREidサーバー（および元のCOREidサーバー）に対してこの手順を繰り返します。

16.9.2 クローニングされたアイデンティティ・システム・コンポーネントのアップグレードに向けた準備

コンポーネントをアップグレードに向けて準備する手順の詳細は、このマニュアルの第8章で説明されています。停止時間ゼロのアップグレードとインプレース・アップグレードのいずれを実行する場合でも、各クローンをアップグレードする前に、複数のクローン・コンポーネントに対して同じ準備タスクの大部分を実行する必要があります。

次に示すタスクの概要では、アップグレード前に各クローンに対して実行を指示されるタスクを説明します。これらは第8章の項です。

タスクの概要: クローニングされたアイデンティティ・システム・コンポーネントのアップグレードに向けた準備

カスタム・アイデンティティ・イベント・プラグインのコピー
以前のカスタマイズの準備
「ホスト・コンピュータでの準備」には、次の項が含まれます。
- パスワード・ファイルの読取り権限の変更
- 空きディスク領域の確認
リリース6.x環境での準備
マルチ言語インストールの準備

ファイル・システム・ディレクトリ、Webサーバー構成およびレジストリ詳細のバックアップ

注意:

停止時間ゼロのアップグレード・メソッドでは、ファイル・システム・ディレクトリのバックアップを作成する必要はありません。かわりに、バックアップとなるソースを作成します。

サーバーおよびサービスの停止
必要な管理権限でのログイン
最初にインストールされたCOREidサーバーのクローン: ステップ1～8のアクティビティに加え、第5章の「既存のOracle Access Managerデータのバックアップ」のアクティビティも実行します。この項には次の内容が含まれます。

16.9.3 クローニングされたCOREidサーバーのアップグレード

この項では、各コンピュータ・ホスト上の個々のCOREidサーバー・クローンをアップグレードするために、実行する必要のあるすべてのアクティビティを説明します。この項の最後には、すべてのアクティビティを詳細に説明したステップごとの手順が記載されています。

注意:

アクティビティを実行する前に、この項のすべての情報を確認することをお薦めします。

クローンをアップグレードする前に、次の考慮事項を確認してください。

最初にインストールされたCOREidサーバーのクローン: 最初にインストールしたCOREidサーバーのクローンをアップグレードする際には、コンポーネント固有のデータだけでなく、LDAPディレクトリ・サーバーの新しいブランチの構成データもアップグレードされます。このアップグレードを開始する前に、LDAPディレクトリ・サーバーの新しいブランチにある構成データをバックアップすることをお薦めします。

すべてのCOREidサーバー・クローン: その他のCOREidサーバー・クローンのアップグレード時には、構成データはアップグレードされません。ただし、各COREidサーバー・クローンのアップグレード時には、そのコンポーネント固有の構成がアップグレードされます。これには、Windowsのレジストリ・エントリ、プラグインおよびコンポーネントの構成ファイルが含まれます。

Windowsレジストリ・エントリ: 以前のリリースから最新のリリースにアップグレードすると、先にインストールされていたリリースのレジストリ・エントリが削除され、新しいエントリが最新リリース用に作成されます。インスタンスをアップグレードした後は、以前のリリースのレジストリ・エントリは使用できなくなります。アップグレード前に、ソースのレジストリをバックアップすることをお薦めします。詳細は、「ロールバック操作中における元のWindowsレジストリ・エントリの回復」を参照してください。

ソース、宛先およびツール: 10g（10.1.4.2.0）のMigrateOAMスクリプトが、クローニングされた各インスタンスに対して適切な場所にあることを確認するステップを実行して、アップグレードを開始します。これらのアクティビティは、「停止時間ゼロのメソッドの準備タスク」で説明されており、次のようにまとめることができます。

ソースの作成: クローンのパスで、アップグレード用のソースを作成するためのクローンが含まれるサブディレクトリの名前を変更します。ソースは、インスタンスのバックアップ・コピーとしても機能します。
宛先の作成: 10g（10.1.4.0.1）のアイデンティティ・サーバーのライブラリとファイルを抽出し、名前を変更する前のクローンのファイル・システム・ディレクトリと同じパスを指定します。
ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、停止時間ゼロのアップグレード用のツールを取得します。

表16-8には、実行を指示されるアクティビティを説明するために、実行する処理の進捗状況を説明する列にサンプルのファイル・システム・パス名がまとめられています。表16-8の後に詳細があります。サンプルのパス名はWindowsプラットフォーム用です。環境によってパスは異なります。

表16-8 クローンのCOREidサーバー・インスタンスのアップグレードに向けた準備アクティビティ

1 クローンのパス

2 ソースの作成

3 宛先の作成およびツールの取得

アイデンティティ・サーバー・インスタンス

clone_np\ois_01\identity

clone_np\ois_02\identity

各クローン・インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。

clone_np\ois_01\
identity_source

clone_np\ois_02\
identity_source

注意: このステップは、各クローン・インスタンスに対して実行します。

ソースの作成後（列2を参照）:

A. 10g（10.1.4.0.1）のアイデンティティ・サーバーのコンポーネント・ライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとしてクローンのパスを指定します。次に例を示します。

clone_np\ois_01\identity

注意: 10g（10.1.4.0.1）のインスタンスの宛先パスは、名前を変更する前のクローンのパスに正確に一致する必要があります（列1を参照）。

「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

B. リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、アップグレード用にツールを取得します。

「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」を参照してください。

C. ステップAおよびBを、各クローン・インスタンスに対して繰り返します。

表16-8には、個々のクローンのアップグレードを開始する前に、実行を指示される手順を説明するための情報がまとめられています。

列1のクローンのパス（左）は、クローニングされた個々のインスタンスのファイル・システム・パスを示しています。この例では、ロード・バランシングの目的で2つのインスタンスが使用されています。このサンプルはWindowsプラットフォーム用で、ユーザーの環境によって異なります。
列2のソースの作成（中央）には、クローンのアップグレード用にソース（兼バックアップ）を作成するために、各クローン・インスタンスのサブディレクトリ名を変更する方法の例が示されています。
列3の宛先の作成およびツールの取得（右）では、各インスタンスのアップグレード用の宛先を作成するため、および10g（10.1.4.2.0）のMigrateOAMスクリプトを取得するために実行する必要があるステップが説明されています。

表16-8に説明されているアクティビティを実行したら、10g（10.1.4.2.0）のMigrateOAMスクリプトおよび停止時間ゼロのアップグレードに必要なその他のファイルとユーティリティが、各COREidサーバー・クローンの宛先パスに配置されます。次に例を示します。

clone_np\ois_01\identity\oblix\tools\migration_tools\MigrateOAM.bat
clone_np\ois_02\identity\oblix\tools\migration_tools\MigrateOAM.bat

停止時間ゼロのアップグレード・ツール: 宛先パスのMigrateOAMスクリプトを使用し、各クローン・インスタンスに対して停止時間ゼロのアップグレードを開始します。表16-9に、クローンのアップグレードを実行するために10g（10.1.4.2.0）のMigrateOAMスクリプトで指定する引数を示します。

表16-9 COREidサーバー・クローンのアップグレード用のMigrateOAMスクリプトの引数

クローン・モードのMigrateOAMの構文	値および操作
10g（10.1.4.2.0）のインスタンスへの変更	Windows: clone_np\ois_01\identity\oblix\tools\migration_tools\MigrateOAM. bat UNIX: /home/clone_np/ois_01/identity/oblix/tools/migration_tools/MigrateOAM.sh
-M Clone	モードとしてCloneを指定します。クローン・モードはクローン・コンポーネントのアップグレードに必要です。
-C component	クローニングされたCOREidサーバーをアップグレードするにはOIS（Oracle Identity Server）を指定します。注意: WebPassクローンをアップグレードする前に、各コンピュータ上のすべてのCOREidサーバー・クローンをアップグレードしてください。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	このデータのアップグレード後のリリースとして1014を指定します。
-S "source directory"	名前を変更した以前のCOREidサーバー・ディレクトリへのフルパスを引用符で囲んで指定します（表16-8の列1を参照）。たとえば、Windowsプラットフォームの場合は次のように指定します。 -S "C:\clone_np\ois_01\identity_source" -S "C:\clone_np\ois_02\identity_source" このようになります。
-D "destination directory"	以前のインスタンス・ディレクトリと置き換えたクローニング済の10g（10.1.4.2.0）のアイデンティティ・サーバー・ディレクトリへのフルパスを引用符で囲んで指定します（表16-8の列1および4を参照）。次に例を示します。 -D "C:\clone_np\ois_01\identity" -D "C:\clone_np\ois_02\identity" このようになります。
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\clone_np\ois_01\identity" -I "C:\clone_np\ois_02\identity" このようになります。
-L "Languages"	適切なコードを引用符で囲み、アップグレードするインストール済のすべての言語を指定します。たとえば、英語は"en-us"、フランス語は"fr-fr"、ドイツ語は"de-de"です。

クローン・コンポーネントをアップグレードする際は、確認モードではなく自動モードを使用すること、およびプロセスをスキップしないことをお薦めします。アップグレード・プロセスは、開始リリース（6.1.1など）と最新リリースの間のすべてのリリースで繰り返されます。つまり、開始から最後までの各手順で、一連の同じメッセージとプロンプトが何度も表示されます。詳細は、「クローン・モードの処理の概要」を参照してください。

次の手順のディレクトリ・パス名、開始リリースおよび言語はサンプルとしてあげられています。詳細はユーザーによって異なります。

注意:

準備手順をスキップすると、アップグレードの問題からのリカバリや元のリリースへのロールバックができなくなる可能性があります。

各COREidサーバーのクローン・インスタンスをアップグレードする手順

すべてのCOREidサーバー・クローンの準備: ここで説明されているアクティビティをすべて実行します（「クローニングされたアイデンティティ・システム・コンポーネントのアップグレードに向けた準備」のリストと同じです。詳細は第8章に記載されています）。
最初にインストールされたCOREidサーバーのクローンの準備: ステップ1のタスクに加え、次のアクティビティも実行します（次の項に詳細が記載されています）。
ソースの作成: アップグレード用のソースを作成するためのクローンが含まれるサブディレクトリの名前を変更します。次に例を示します。

変更前: clone_np\ois_01\identity
変更後: clone_np\ois_01\identity_source
図clone_1014_ois_move.gifの説明
宛先の作成: クローンのトップレベルのファイル・システムで、10g（10.1.4.0.1）のアイデンティティ・サーバーのライブラリとファイルを抽出し、名前を変更する前のクローンのパスに完全に一致する宛先パスを指定します。次に例を示します。

宛先パス: clone_np\ois_01\identity

図clone_1014_ois_dest.gifの説明

抽出の詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。
ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。
このアップグレード用の10g（10.1.4.2.0）のアイデンティティ・サーバーのMigrateOAMスクリプトを含むdestination_dirに変更します。次に例を示します。
```
     cd clone_np\ois_01\identity\oblix\tools\migration_tools\MigrateOAM.bat
```
MigrateOAMスクリプトをクローン・モードで実行し、開始リリースおよびアップグレードするインスタンスのパス名を指定します。次に例を示します。
```
     MigrateOAM -M Clone -C OIS -F 610 -T 1014 -S "C:\clone_np\ois_01\identity_ 
     source" -D "C:\clone_np\ois_01\identity" -I "C:\clone_np\ois_01\identity"  
     -L "en-us"
```
1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。
2. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。
3. 画面のメッセージに従って完了します。
  
  図clone_1014_ois_end.gifの説明
次のようにして、アップグレードが成功したことを検証します（サービスを起動しないでください）。
1. アップグレード用に指定したdestination_dirのglobalparams.xmlファイルで、MigrateUserDataTo1014の値がfalseであることを確認します。次に例を示します。
  
  clone_np\ois_01\identity\oblix\apps\common\bin\globalparams.xml
```
<NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
```
2. 監査およびアクセス・レポート: 以前のインストールに監査およびアクセス・レポートが含まれている場合は、次のようにします。
  
  b1）その他のステップを実行する前に、「アイデンティティ・システムの監査およびアクセス・レポートのアップグレード」を確認します。
  
  b2）これが2回目以降のCOREidサーバーのアップグレードの場合は、「アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更」のアクティビティも実行する必要があります。
3. アップグレードしたCOREidサーバーのサービスが起動することを確認するため、それを起動します（起動後、その名前が最初に割り当てられた名前から変わっていないことに注意してください）。
4. アイデンティティ・サーバー・サービスが起動しない場合: イベントおよびアイデンティティ・サーバーのログ出力ファイルを確認します。ロギングおよびログ出力ファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
5. 「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか移行ログ・ファイルを確認します。
6. Windows: レジストリエディタ（regedit）を実行し、次の方法のいずれかを使用してレジストリ・エントリが更新されていることを検証します。
  
  「レジストリエディタ」ウィンドウで、「マイコンピュータ」→「HKEY_LOCAL_MACHINE」→「SYSTEM」→「CurrentControlSet」→「Services」をクリックし、「ObOISServer-<Service Name>」を探します。この中でイメージのパスを確認します。
  
  レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にある「ObOISServer-<Service Name>」のエントリを確認します。
7. 宛先パスのバージョン・ファイルが、10.1.4（npversion_component.txt）に更新されていることを確認します。次に例を示します。
  
  clone_np\ois_01\identity\oblix\config\np1014_is.txt
8. ois_server_config.xmlに、アップグレードしたインスタンスの正しい情報が含まれていることを確認します。
9. アップグレードが失敗した場合: 「クローニングされたアイデンティティ・システムのアップグレードの失敗からのリカバリ」に進みます。
10. アップグレードが成功した場合: ステップ9に進みます。
このホストに存在するクローニングされたその他のCOREidサーバー・インスタンスに対して、この手順のすべてのステップを繰り返します。
単一ホスト上のクローニングされたすべてのCOREidサーバーをアップグレードしたら、そのホストのWebPassインスタンスをアップグレードできます。詳細は、「クローニングされたWebPassインスタンスのアップグレード」を参照してください。

16.9.4 クローニングされたWebPassインスタンスのアップグレード

この項では、WebPassクローンのアップグレード・メソッドを説明します。WebPassクローンのアップグレード時に実行するアクティビティは、COREidサーバー・クローンのアップグレード時に実行したアクティビティに似ています。ソースと宛先を作成し、アップグレードに必要なツールを取得します。MigrateOAMをクローン・モードで実行します。

注意:

このアクティビティを開始する前に、クローンのアップグレードに関するすべての情報を確認することをお薦めします。

表16-10には、実行する一部のアクティビティを説明するために、実行する処理の進捗状況を説明する列にサンプルのパス名がまとめられています。表16-10の後に詳細があります。サンプルのパス名はWindowsプラットフォーム用です。環境によってパスは異なります。

表16-10 クローンのWebPassインスタンスのアップグレードに向けた準備アクティビティ

1 クローンのパス

2 ソースの作成

3 宛先の作成およびツールの取得:

WebPassインスタンス

clone_np\webcomponent_
01\identity

clone_np\webcomponent_
02\identity

各クローン・インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。

clone_np\webcomponent_
01\identity_source

clone_np\webcomponent_
02\identity_source

ソースの作成後（列2を参照）:

A. 10g（10.1.4.0.1）のWebPassのコンポーネント・ライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとしてクローンのパスを指定します。次に例を示します。

clone_np\webcomponent_01\identity

注意: 10g（10.1.4.0.1）のインスタンスの宛先パスは、名前を変更する前のクローンのパスに正確に一致する必要があります（列1を参照）。

「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

B. リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、ツールを取得します。

「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」を参照してください。

C. ステップAおよびBを、各クローン・インスタンスに対して繰り返します。

表16-10に説明されているソースおよび宛先作成の詳細は、「停止時間ゼロのメソッドの準備タスク」を参照してください。表16-10のアクティビティを実行すると、最新のMigrateOAMスクリプトがdestination_dirに格納されます。次に例を示します。

clone_np\webcomponent_01\identity\oblix\tools\migration_tools\MigrateOAM.bat
clone_np\webcomponent_02\identity\oblix\tools\migration_tools\MigrateOAM.bat

表16-11に、個々のWebPassのクローンのアップグレードを実行するために、10g（10.1.4.2.0）のMigrateOAMスクリプトで指定する引数を示します。

表16-11 WebPassクローンのアップグレード用のMigrateOAMスクリプト

クローン・モードのMigrateOAMの構文	値および操作
-M Clone	モードとしてCloneを指定します。クローン・モードはクローン・コンポーネントのアップグレードに必要です。
-C component	クローニングされたWebPassをアップグレードするにはWPを指定します。注意: アクセス・システム・クローンをアップグレードする前に、各コンピュータ上のすべてのWebPassクローンをアップグレードしてください。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	このデータのアップグレード後のリリースとして1014を指定します。
-S "source directory"	名前を変更した以前のWebPassディレクトリへのフルパスを引用符で囲んで指定します（表16-10の列2を参照）。複数のインスタンスがある場合は、次のようにします。 -S "C:\clone_np\webcomponent_01\identity_source" -S "C:\clone_np\webcomponent_02\identity_source" このようになります。
-D "destination directory"	以前のインスタンス・ディレクトリと置き換えたクローニング済の10g（10.1.4.2.0）のWebPassディレクトリへのフルパスを引用符で囲んで指定します（表16-10の列1および4を参照）。次に例を示します。 -D "C:\clone_np\webcomponent_01\identity" -D "C:\clone_np\webcomponent_02\identity" このようになります。
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\clone_np\webcomponent_01\identity" -I "C:\clone_np\webcomponent_02\identity" このようになります。注意: パス名およびディレクトリ・コンテンツの詳細は、表16-10を参照してください。
-L "Languages"	適切なコードを引用符で囲み、アップグレードするインストール済のすべての言語を指定します。たとえば、英語は"en-us"、フランス語は"fr-fr"、ドイツ語は"de-de"です。
-W "Web server type"	このクローンで使用するWebサーバーの適切なコードを引用符で囲んで指定します。"nsapi"、"apache2"、"isapi"、"apache"、"ihs"、"ohs"、"ohs2"、"domino"などです。

WebPassクローンをアップグレードしても、スキーマまたはデータには影響はありません。その他のコンポーネントのアップグレードと同じように、WebPassのアップグレードにも、コンポーネント固有の構成のアップグレード、パラメータ・カタログおよびメッセージ・ファイルのアップグレードが含まれます。すべてのWebコンポーネントのアップグレードと同じように、WebPassのアップグレードにも、Webサーバー構成の変更が含まれます。

開始リリースから最後までの各手順で、メッセージとプロンプトが表示されます。最も短時間でアップグレードする場合は、確認モードではなく自動モードを使用し、プロセスをスキップしないよう確認することをお薦めします。

次の手順のファイル・システム・パス、開始リリースおよび言語はサンプルとしてあげられています。

注意:

Oracle Access Managerの複数のWebコンポーネントのクローンに対応している単一のWebサーバー・インスタンスがある場合には、Webサーバーを再起動する前に、対応しているすべてのWebコンポーネントのクローンをアップグレードする必要があります。

クローニングされた各WebPassインスタンスをアップグレードする手順

各WebPassクローンの準備: ここで説明されているアクティビティをすべて実行します（「クローニングされたアイデンティティ・システム・コンポーネントのアップグレードに向けた準備」のリストと同じです。詳細は第8章に記載されています）。

注意:

対象のコンポーネントに適切なすべての準備手順を実行しないと、問題からのリカバリやアップグレードが失敗した後のロールバックができなくなる可能性があります。

ソースの作成: アップグレード用のソースを作成するためのWebPassクローンが含まれるサブディレクトリの名前を変更します。次に例を示します。

変更前: clone_np\webcomponent_01\identity
変更後: clone_np\webcomponent_01\identity_source
図clone_rename_wp611.gifの説明
宛先の作成: クローンのトップレベルのファイル・システムで、10g（10.1.4.0.1）のWebPassのライブラリとファイルを抽出し、名前を変更する前のクローンに完全に一致する宛先パスを指定します。次に例を示します。

宛先パス: clone_np\webcomponent_01\identity

宛先パスの例は、表16-10の列1を参照してください。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。
ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。
このWebPassのアップグレード用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むdestination_dirに変更します。次に例を示します。

cd clone_np\webcomponent_01\identity\oblix\tools\migration_tools\
MigrateOAM. bat
MigrateOAMスクリプトをクローン・モードで実行し、開始リリースの詳細およびこのインスタンスのパス名を指定します。次に例を示します。
```
MigrateOAM -M Clone -C WP -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\ 
identity_source" -D "C:\clone_np\webcomponent_01\identity" -I "C:\clone_np\ 
webcomponent_01\identity" -L "en-us" -W "nsapi"
```
1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。
2. このクローンが構成されているWebサーバー構成ファイルへの完全なディレクトリ・パス名を指定し、Webサーバー構成の変更をそのまま使用します。
3. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。
4. 画面のメッセージに従って完了します。
  
  宛先には、ソースに基づいてアップグレードされた情報が含まれています。
  
  図clone_1014_wp_end.gifの説明

次のようにして、WebPassクローンのアップグレードが成功したことを検証します。

必要に応じてWebサーバーの変更内容を反映します。

関連するアイデンティティ・サーバー・サービスを停止して再起動します。

注意:

Oracle Access Managerの複数のWebコンポーネントに対応している単一のWebサーバー・インスタンスがある場合には、Webサーバーを再起動する前に、対応しているすべてのWebコンポーネントをアップグレードする必要があります。詳細は、「複数のOracle Access Managerリリースに対するWebサーバーのサポート」を参照してください。

このホストのすべてのWebコンポーネントをアップグレードしたら、WebPassのWebサーバー・インスタンスを開始します。
Webサーバーが起動しない場合: 次のアクティビティを実行します。

イベント・ログおよびWebPassのログ出力ファイルを確認します。ロギングおよびログ出力ファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

Webサーバー固有の構成ファイルを確認します。インスタンスにWebサーバーとしてIISが構成されている場合は、ISAPIフィルタに緑のステータスのtransfilterがあることを確認します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか移行ログ・ファイルを確認します。
Windows: レジストリエディタ（regedit）を実行し、レジストリ・エントリが更新されていることを検証します。また、次の確認を行います。

レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にあるWebPassのエントリを確認します。
宛先パスのバージョン・ファイルが、10.1.4（npversion_component.txt）に更新されていることを確認します。次に例を示します。

destination_dir\oblix\config\np1014_wp.txt
destination_dir\identity\oblix\apps\webpass\bin\webpass.xmlのwebpass.xmlファイルを参照して、このインスタンスの詳細が含まれていることを確認します。
アップグレードが失敗した場合: 「クローニングされたアイデンティティ・システムのアップグレードの失敗からのリカバリ」に進みます。
アップグレードが成功した場合: この手順全体を繰り返し、クローニングされたWebPassインスタンスをすべてアップグレードします。

WebPassインスタンスをすべてアップグレードしたら、「アップグレード済のクローニングされたアイデンティティ・システムの検証」に進みます。

16.9.5 アップグレード済のクローニングされたアイデンティティ・システムの検証

クローンのアイデンティティ・システムをアップグレードした後は、次の項目をただちに検証してアップグレードの成功を確認することをお薦めします。

このタスクは、クローンのアップグレード後、および個別にインストールされたSDKとアイデンティティ・システムのカスタマイズのアップグレード後に実行することをお薦めします。詳細は、次も参照してください。

クローニングされたアイデンティティ・システムのアップグレードを検証する手順

アップグレード完了後、Webブラウザのキャッシュをすべて削除します。
すべてのアイデンティティ・サーバー・サービスとWebPassのWebサーバー・インスタンスが稼働していることを確認します。
メッセージ・カタログとパラメータ・カタログのカスタマイズが保持されていることを確認します。たとえば、特定のメッセージ・カタログ・ファイルにあるメッセージを変更していた場合は、そのメッセージが保持されている必要があります。次に例を示します。

destination_dir\identity\...
アイデンティティ・システムのスキーマのアップグレード後に実行したのと同じアクティビティを実行します。詳細は、「環境の正常な動作の検証」を参照してください。
次の項のタスクを実行して、アップグレードした環境を再度検証します。
- アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更
- SDKおよびアイデンティティ・システムのカスタマイズのアップグレード
「アップグレードしたアイデンティティ・システムのクローンのバックアップ」に進みます。
アイデンティティ・システムおよびアクセス・システムの混合: システムが問題なく動作していることを確認してから、「クローニングされたアクセス・システムのアップグレード」に進みます。
アクセス・システムがない場合: 第17章に進む前に、すべての検証テストおよびタスクを完了し、元のインスタンスのアップグレードを開始します。

16.9.6 アップグレードしたアイデンティティ・システムのクローンのバックアップ

正常に動作していることを確認した後に、アップグレードしたクローニング済のアイデンティティ・システムをバックアップすることをお薦めします。これにより、環境を、必要に応じてアップグレード直後の状態に簡単にリストアできます。

アップグレード後に重要な情報をバックアップする手順

アップグレードした宛先のファイル・システム・ディレクトリをバックアップします。これは、既存コンポーネントのインストール・ディレクトリのバックアップと同じです。詳細は、「既存のコンポーネント・インストール・ディレクトリのバックアップ」を参照してください。
Webサーバー: ベンダーのドキュメントの指示および「既存のWebサーバー構成ファイルのバックアップ」の詳細を参照し、アップグレードしたWebサーバー構成ファイルをバックアップします。
Windows: 「Windowsレジストリ・データのバックアップ」の説明に従って、宛先用のWindowsレジストリ・データをバックアップします。
「他の章の内容」に進みます。

16.9.7 クローニングされたアイデンティティ・システムのアップグレードの失敗からのリカバリ

クローニングされたアイデンティティ・システム・コンポーネントのアップグレードが失敗した場合、次の手順を実行し、以前のクローン・インスタンスをリストアしてコンポーネントのアップグレードを再試行できます。ソースのファイル・システム・ディレクトリはアップグレードされておらず、変更されません。

停止時間ゼロのアップグレードを続行しない場合は、「アイデンティティ・システムのクローンのアップグレード後におけるロールバック」を参照してください。

クローニングされたアイデンティティ・システムのアップグレードの失敗からリカバリする手順

クローンのソースをバックアップします。クローンのアップグレードを再開する際に、バックアップ・コピーを保存します。次に例を示します。

クローンのソースのコピー元: clone_np\ois_01\identity_source
コピー先: backup_clone_np\ois_01\identity_source
宛先（リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイル）を削除します。
Webサーバー: クローニングされたWebPassに必要な場合は、バックアップされたWebサーバー構成ファイルをリストアします。
Windows: ソース・インスタンスのバックアップされたレジストリをリストア（インポート）します。
アップグレードするインスタンスの10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを抽出し、「宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得」の説明に従って、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。
インスタンスのアップグレードを再開します。

16.9.8 アイデンティティ・システムのクローンのアップグレード後におけるロールバック

次の手順を使用すると、変更内容をすべてロールバックして元のインストールに戻すことができます。この操作を完了すると、環境にはクローンがなくなり、システム・コンソールのクローン・エントリもなくなります。

アップグレード前に外部ユーティリティを使用してスキーマをバックアップした場合以外は、スキーマのアップグレードをロールバックできません。外部ツールを使用したバックアップおよびスキーマのリカバリの詳細は、このマニュアルの対象外です。

アイデンティティ・システムのクローンのアップグレード後にロールバックする手順

クローン・サービスおよびWebサーバーを停止します。
ホスト・コンピュータから次の項目を削除します。
- クローンのファイル・システム・ディレクトリ
- リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイル
- 追加またはアップグレード・プロセスの一部として自動的に追加された任意のファイル・システム・ディレクトリ
- クローンのWebサーバー・インスタンス
- 新しい構成DNおよびポリシーDN用に追加されたLDAPディレクトリ・サーバーのブランチ
元のシステム・コンソールから、すべてのクローン・プロファイルを削除します。
アップグレード前にスキーマのバックアップ・コピーを用意しておけば、元のスキーマを回復できます。
元の設定が正常に動作していることを確認します。

16.9.9 他の章の内容

アップグレードされたアイデンティティ・システム・コンポーネントでは、UTF-8エンコーディングでデータが送受信されます。以前のコンポーネントでは、Latin-1エンコーディングでデータが送受信されます。このため、10g（10.1.4.0.1）のアイデンティティ・システムは以前のアクセス・システム・コンポーネントと連動せず、以前のアイデンティティ・システムのカスタマイズとも連動しない場合があります。予期されるシステム動作および下位互換性の詳細は、第4章を参照してください。

元のアイデンティティ・システム・コンポーネントがすべて正常にアップグレードされたら、以前のインストールの構成に基づいて必要な手順に進みます。具体的には次のとおりです。

アイデンティティ・システムのみ: 以前のインストールにアクセス・システムが含まれていない場合、「タスクの概要: 残りのアイデンティティ・システムのみのアップグレード・アクティビティ」で説明されている順番でアクティビティを実行する必要があります。
アイデンティティ・システムおよびアクセス・システムの混合: 以前のインストールに特定のサード・パーティ製品用のアクセス・システムおよびOracle Access Managerの統合コネクタが含まれている場合、SDKをアップグレードする前に統合コネクタをアップグレードする必要があります。この場合は、「タスクの概要: 残りのアイデンティティ・システムおよびアクセス・システムの混合のアクティビティ」の説明に従ってタスクを実行します。

タスクの概要: 残りのアイデンティティ・システムのみのアップグレード・アクティビティ

必要に応じて、「アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更」のタスクを実行します。
「SDKおよびアイデンティティ・システムのカスタマイズのアップグレード」のタスクを実行して完了します。
元のインスタンスをアップグレードする前に、エンタープライズに必要なだけ、テストおよび練習のアクティビティを実行します。
検証期間が終了したら、第17章に進んで元のインスタンスをアップグレードします。

注意:

以前のインストールにアクセス・システムが含まれている場合は、SDKをアップグレードする前に統合コネクタをアップグレードする必要があります。

タスクの概要: 残りのアイデンティティ・システムおよびアクセス・システムの混合のアクティビティ

クローニングされたアイデンティティ・システムのアップグレードの完了: この章の次の項に進み、説明に従ってタスクを実行します。
- アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更
- SDKおよびアイデンティティ・システムのカスタマイズのアップグレード
クローニングされたアクセス・システムのアップグレードの完了: この章の次の項に進み、説明に従ってタスクを実行します。
1. クローニングされたアクセス・システムのアップグレード
2. SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード
元のインスタンスをアップグレードする前に、エンタープライズに必要なだけ、テストおよび練習のアクティビティを実行します。
独自の検証期間が終了したら、第17章に進んで元のインスタンスをアップグレードします。

16.10 アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更

アイデンティティ・システムのクローンを7.0より前のリリースからアップグレードしたら、このタスクを実行し、元のCOREidサーバーの監査ファイルのパス名を修正する必要があります。リリース7.xからアップグレードした場合、このアクティビティはスキップできます。

700より前のリリースからアップグレードする場合は、MigrateOAMスクリプトをクローン・モードで使用する際に指定したソースのCOREidサーバーへのパスが接頭辞として付いて、監査ファイル名が変更されます。次に例を示します。

クローンのパス: clone_np\ois_01\identity
ソースのパス: clone_np\ois_01\identity_source

環境に複数のCOREidサーバーがある場合は、それぞれの監査ファイル名に、クローンのアップグレードを実行するソースのCOREidサーバーと同じファイル・システム・パスが接頭辞として付けられます。そのため、アップグレード中に元の構成が失われます。たとえば、リリース611の元のCOREidサーバー・インスタンスが2つあり、監査ファイルが次の場所に格納されているとします。

\oblix\engine\auditfile_1.lst
\oblix\engine\auditfile_2.lst

このサンプルのパス名で、監査ファイルは異なるファイル・システム・パスに格納されています。ただし、クローンをアップグレードすると、どちらの監査ファイルも、クローンのアップグレード中にソースとして指定されたCOREidサーバーのパスに格納されます。次に例を示します。

clone_np\ois_01\identity_source\oblix\engine\auditfile_1.lst
clone_np\ois_01\identity_source\oblix\engine\auditfile_2.lst

クローンのアップグレード後に監査ファイルをリカバリするには、次のタスクを実行し、特定の元のCOREidサーバー・インスタンスへの適切なパスが反映されるように監査ファイルのパスを変更する必要があります。

注意:

このタスクは、クローンのアップグレード後にのみ、元のすべてのCOREidサーバーに対して実行します。

アイデンティティ・システムのクローンのアップグレード後に元の監査ファイル名をリカバリする手順

クローンのアップグレード後に、クローンのCOREidシステム・コンソールに移動して通常どおりログインします。
```
     http://hostname:port/identity/oblix
```
ここで、hostnameはクローニングされたWebPass Webサーバーをホスティングするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/identity/oblixはCOREidシステム・コンソールに接続します。
COREidシステム・コンソールで、「システム構成」→「アイデンティティ・サーバー」をクリックします。
元のCOREidサーバーの名前を選択して、そのインスタンスの情報を表示します。
「監査ファイル名」フィールドでパス名が正しいかどうかを確認します。

パス名が正しい場合は、「取消」をクリックしてステップ3と4を繰り返し、別のインスタンスの監査ファイルのパス名を確認します。パス名が正しくない場合は、ステップ5に進みます。
ページの下部にある「変更」ボタンをクリックします。
「変更」ページの「監査ファイル名」フィールドで、パス名をこのインスタンスの正しいパスに変更し、「保存」をクリックします。次に例を示します。

変更前: \oblix\engine\auditfile_2.lst
変更後: C:\np611\ois_02\identity\oblix\engine\auditfile_2.lst
稼働している場合は、詳細を更新した元のCOREidサーバーを再起動します。
各クローンおよび元のCOREidサーバー・インスタンスに対して、この手順のすべてのステップを繰り返します。
「SDKおよびアイデンティティ・システムのカスタマイズのアップグレード」に進みます。

16.11 SDKおよびアイデンティティ・システムのカスタマイズのアップグレード

アイデンティティ・システムのカスタマイズおよび個別にインストールされたSoftware Developer Kit（SDK）をアップグレードし、アップグレードしたクローニング済のアイデンティティ・システム全体が正常に動作していることを検証することをお薦めします。

次の概要では、各タスクに関する情報が記載されている場所を説明します。

タスクの概要: 残りのアイデンティティ・システムのみのアップグレード・アクティビティ

環境に応じて進めます。
- アイデンティティ・システムのみ: 第11章の説明に従って、個別にインストールされたSDKおよび統合接続をアップグレードします。
- アイデンティティ・システムおよびアクセス・システムの混合: 第11章のタスクを実行する前に、アクセス・システムをアップグレードします。
第12章の説明に従って、アイデンティティ・システムのカスタマイズをアップグレードします。
次のように続行します。
- アイデンティティ・システムおよびアクセス・システムの混合: 「クローニングされたアクセス・システムのアップグレード」に進みます。
- アイデンティティ・システムのみ: 元の環境をアップグレードする前に、「環境の正常な動作の検証」のタスクを実行します。

16.12 クローニングされたアクセス・システムのアップグレード

この項のタスクは、アイデンティティ・システムとアクセス・システムの混合で、アップグレードするためのタスクをすべて実行し、クローニングされたアイデンティティ・システムを検証して監査ファイルの名前を変更した場合にのみ実行します。それ以外の場合はこの項をスキップし、詳細な進め方について「他の章の内容」を参照してください。

実行する必要のあるタスクは、次のタスクの概要で説明されています。個々の項には、バックグラウンドの詳細およびステップごとの手順が記載されています。

タスクの概要: クローニングされたアクセス・システムのアップグレード

クローニングされたアクセス・システム・コンポーネントのアップグレードに向けた準備
クローニングされたAccess Managerインスタンスのアップグレード
クローニングされたアクセス・サーバーのアップグレード
アップグレード済のクローニングされたアクセス・システムの検証
アップグレードしたアクセス・システムのクローンのバックアップ
SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

問題がある場合のリカバリの詳細は、「クローニングされたアクセス・システム・コンポーネントのアップグレードの失敗からのリカバリ」を参照してください。ここでアクティビティを確認したら、「他の章の内容」を参照し、元のシステムのアップグレード前に実行することを推奨されているアクティビティを確認してください。

16.12.1 クローニングされたアクセス・システム・コンポーネントのアップグレードに向けた準備

アップグレードに向けてコンポーネントを準備するために実行する手順の詳細は、第8章で説明されています。各クローンをアップグレードする前に、クローニングされたアクセス・システム・コンポーネントに対する準備タスクの多くと同じものを実行する必要があります。これらのタスクの一部は、クローニングされたアイデンティティ・システム・コンポーネントのアップグレード時に実行したタスクに似ています。

アップグレードされたアクセス・サーバーには、以前のWebGateとの下位互換があります。そのため、元のWebGateをアップグレードするまでWebGateのアップグレードを延期できます。Software Developer Kit（SDK）のアップグレードも延期できます。手動で処理する必要のあるアイテムはいつでも移行できます。下位互換性の詳細は、第4章を参照してください。

アクセス・システムのクローンに実行する必要のある準備タスクは、次の概要で説明されています。各クローンのアップグレード時に、これらのタスクの実行を指示されます。

注意:

すべての準備手順を実行しないと、問題からのリカバリやアップグレードが失敗した後のロールバックができなくなる可能性があります。

タスクの概要: クローニングされたアクセス・システム・インスタンスのアップグレードに向けた準備

以前のカスタマイズの準備
ポリシー・マネージャのデフォルトのログアウトでの準備
「ホスト・コンピュータでの準備」には、次の項が含まれます。
- パスワード・ファイルの読取り権限の変更
- 空きディスク領域の確認
リリース6.x環境での準備
マルチ言語インストールの準備

ファイル・システム・ディレクトリ、Webサーバー構成およびレジストリ詳細のバックアップ

注意:

停止時間ゼロのアップグレード・メソッドでは、クローンのファイル・システム・ディレクトリのバックアップ・コピーを作成する必要はありません。かわりに、アップグレード中にソースとして使用するファイル・システム・パスの名前を変更します。ソースは、アップグレード中に変更されないバックアップになります。

サーバーおよびサービスの停止
必要な管理権限でのログイン
最初にインストールされたAccess Managerのクローン: ステップ1～8のアクティビティに加え、第5章の「Oracle Access Managerの構成データおよびポリシー・データのバックアップ」のアクティビティも実行します。

16.12.2 クローニングされたAccess Managerインスタンスのアップグレード

Access Managerクローンのアップグレードは、WebPassクローンのアップグレードに似ています。

注意:

アクティビティを実行する前に、この項のすべての情報を確認することをお薦めします。

最新のMigrateOAMスクリプトが、クローニングされた各Access Managerインスタンスの適切な場所にあることを確認するステップを実行することから開始します。次のタスクは、「停止時間ゼロのメソッドの準備タスク」で説明されており、次のようにまとめられています。

ソースの作成: アップグレード用のソースを作成するためのクローン、およびクローンのバックアップ・コピーが含まれるサブディレクトリの名前を変更します。
宛先の作成: 10g（10.1.4.0.1）のポリシー・マネージャのライブラリとファイルを抽出し、名前を変更する前のクローンに完全に一致する宛先パスを指定します。
ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、アップグレードに必要なツールを取得します。

表16-12には、これらのタスクを説明するために、実行する処理の進捗状況を説明する列にサンプルのファイル・システム・パス名がまとめられています。表16-12の後に詳細があります。サンプルのパス名はWindowsプラットフォーム用です。環境によってパスは異なります。

表16-12 クローンのAccess Managerインスタンスのアップグレードに向けた準備アクティビティ

1 クローンのパス

2 ソースの作成

3 宛先の作成およびツールの取得

Access Managerインスタンス

clone_np
\webcomponent_01
\access

clone_np
\webcomponent_02
\access

列1の各クローンが含まれているサブディレクトリの名前を変更します。次に例を示します。

clone_np
\webcomponent_01
\access_source

clone_np
\webcomponent_02
\access_source

ソースの作成後（列2を参照）:

A. 10g（10.1.4.0.1）のポリシー・マネージャのライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとして名前を変更する前にクローンのパスを指定します。次に例を示します。

clone_np\webcomponent_01\access

注意: 10g（10.1.4.0.1）のインスタンスの宛先パスは、名前を変更する前のクローンのパスに正確に一致する必要があります（列1を参照）。

「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

B. リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、ツールを取得します。

「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」を参照してください。

C. ステップAおよびBを、各クローン・インスタンスに対して繰り返します。

表16-12で説明されているアクティビティを実行すると、最新のMigrateOAMスクリプトが宛先パスに格納されます。次に例を示します。

clone_np\webcomponent_01\access\oblix\tools\migration_tools\MigrateOAM.bat
clone_np\webcomponent_02\access\oblix\tools\migration_tools\MigrateOAM.bat

表16-13に、各Access Managerクローンのアップグレードに対してクローン・モードを実行するために、10g（10.1.4.2.0）のMigrateOAMスクリプトで指定する引数を示します。

表16-13 Access Managerクローンのアップグレード用のMigrateOAMスクリプト

クローン・モードのMigrateOAMの構文	値および操作
-M Clone	モードとしてCloneを指定します。クローン・モードはクローン・コンポーネントのアップグレードに必要です。
-C component	クローニングされたAccess ManagerをアップグレードするにはAMを指定します。注意: アクセス・サーバー・クローンをアップグレードする前に、各コンピュータ上のすべてのAccess Managerクローンをアップグレードしてください。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	このデータのアップグレード後のリリースとして1014を指定します。
-S "source directory"	名前を変更した以前のAccess Managerディレクトリへのフルパスを引用符で囲んで指定します（表16-12の列2を参照）。複数のインスタンスがある場合は、次のようにします。 -S "C:\clone_np\webcomponent_01\access_source" -S "C:\clone_np\webcomponent_02\access_source" このようになります。
-D "destination directory"	以前のインスタンスと置き換えたクローニング済の10g（10.1.4.2.0）のAccess Managerディレクトリへのフルパスを引用符で囲んで指定します（表16-12の列1および4を参照）。次に例を示します。 -D "C:\clone_np\webcomponent_01\access" -D "C:\clone_np\webcomponent_02\access" このようになります。
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\clone_np\webcomponent_01\access" -I "C:\clone_np\webcomponent_02\access" このようになります。注意: パス名およびディレクトリ・コンテンツの詳細は、表16-12を参照してください。
-L "Languages"	適切なコードを引用符で囲み、アップグレードするインストール済のすべての言語を指定します。たとえば、英語は"en-us"、フランス語は"fr-fr"、ドイツ語は"de-de"です。
-W Web server type	このクローンで使用するWebサーバーの適切なコードを引用符で囲んで指定します。"nsapi"、"apache2"、"isapi"、"apache"、"ihs"、"ohs"、"ohs2"、"domino"などです。

最初にインストールされたAccess Managerのクローン: 最初にインストールしたAccess Managerのクローンをアップグレードする際には、コンポーネント固有のデータだけでなく、LDAPディレクトリ・サーバーの新しいブランチのアクセス・ポリシー・データもアップグレードされます。このアップグレードを開始する前に、LDAPディレクトリ・サーバーの新しいブランチにあるポリシー・データをバックアップすることをお薦めします。

すべてのAccess Managerのクローン: Access Managerのクローンのアップグレード処理には、Webサーバー関連の変更が含まれます。また、パラメータ・カタログ、メッセージ・ファイルおよびコンポーネント固有の変更も含まれます。

クローンのアップグレード時には、開始リリースから最新リリースまでの各手順で、メッセージとプロンプトが表示されます。最も短時間でアップグレードする場合は自動モードを使用し、プロセスをスキップしないことをお薦めします。

Webサーバー: Oracle Access Managerの複数のWebコンポーネントに対応している単一のWebサーバー・インスタンスがある場合には、Webサーバーを再起動する前に、対応しているすべてのWebコンポーネントをアップグレードする必要があります。詳細は、「複数のOracle Access Managerリリースに対するWebサーバーのサポート」を参照してください。

Windowsレジストリ: インスタンスをアップグレードすると、Windowsレジストリ・エントリが更新されます。インスタンスのアップグレード前に、ソースのレジストリをバックアップすることをお薦めします。詳細は、「ロールバック操作中における元のWindowsレジストリ・エントリの回復」を参照してください。

次の手順のパス名、開始リリースおよび言語はサンプルとしてあげられています。詳細はユーザーによって異なります。

注意:

すべての準備手順を実行しないと、問題からのリカバリやアップグレードが失敗した後のロールバックができなくなる可能性があります。

クローニングされたAccess Managerインスタンスをアップグレードする手順

すべてのAccess Managerクローン: 「クローニングされたアクセス・システム・コンポーネントのアップグレードに向けた準備」で説明されているすべてのアクティビティを実行します。詳細は第8章に記載されており、内容は次のとおりです。

以前のカスタマイズの準備
ポリシー・マネージャのデフォルトのログアウトでの準備
「ホスト・コンピュータでの準備」には、次の項が含まれます。
- パスワード・ファイルの読取り権限の変更
- 空きディスク領域の確認
リリース6.x環境での準備
マルチ言語インストールの準備

ファイル・システム・ディレクトリ、Webサーバー構成およびレジストリ詳細のバックアップ

注意:

クローンのファイル・システム・ディレクトリのバックアップ・コピーを作成する必要はありません。かわりに、ソースとして使用するパスの名前を変更します。

サーバーおよびサービスの停止
必要な管理権限でのログイン

最初のAccess Managerのクローン: ステップ1のアクティビティに加え、「Oracle Access Managerの構成データおよびポリシー・データのバックアップ」の説明に従って、新しいブランチのポリシー・データもバックアップします。
ソースの作成: アップグレード用のソースを作成するためのAccess Managerクローンが含まれるサブディレクトリの名前を変更します。次に例を示します。

変更前: clone_np\webcomponent_01\access
変更後: clone_np\webcomponent_01\access_source
図clone_am_rename.gifの説明
宛先の作成: 10g（10.1.4.0.1）のポリシー・マネージャのライブラリとファイルを抽出し、名前を変更する前のクローンのパスに完全に一致する宛先パスを指定します。次に例を示します。

宛先パス: clone_np\webcomponent_01\access

宛先パスの例は、表16-12の列1を参照してください。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。
ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。

図clone_am_move.gifの説明
このポリシー・マネージャ・インスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むdestination_dirに変更します。次に例を示します。

clone_np\webcomponent_01\access\oblix\tools\migration_tools\MigrateOAM. bat
MigrateOAMスクリプトをクローン・モードで実行し、開始リリースおよびパス名を指定します。次に例を示します。
```
MigrateOAM -M Clone -C AM -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\ 
access_source" -D "C:\clone_np\webcomponent_01\access" -I "C:\clone_np\ 
webcomponent_01\access" -L "en-us" -W "nsapi"
```
1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。
2. 要求された場合は、アクセス・ポリシー・データの変更をそのまま使用します。
3. このクローンが構成されているWebサーバー構成ファイルへの完全なディレクトリ・パスを指定し、Webサーバー構成の変更をそのまま使用します。
4. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。
5. 画面のメッセージに従って完了します。
  
  完了すると、宛先ディレクトリには、ソースに基づいた構成の詳細とともにアップグレードしたインスタンスが含まれています。
  
  図clone_am_end.gifの説明

次のようにして、クローニングされたAccess Managerのアップグレードが成功したことを検証します。

必要に応じてWebサーバーの変更内容を反映します。
「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか移行ログ・ファイルを確認します。
Windows: レジストリエディタ（regedit）を実行し、レジストリ・エントリが更新されていることを検証します。また、次の確認を行います。

レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にあるAccess Managerのエントリを確認します。
関連するアイデンティティ・サーバー・サービスを停止して再起動します。

このホストのすべてのWebコンポーネントをアップグレードしたら、クローニングされたWebPassおよびAccess ManagerのWebサーバー・インスタンスを開始します。

注意:

クローン・コンポーネントに対応しているWebサーバー・インスタンスは、対応しているすべてのコンポーネントがアップグレードされるまで停止しておく必要があります。詳細は、「複数のOracle Access Managerリリースに対するWebサーバーのサポート」を参照してください。

Webサーバーが起動しない場合: 次のアクティビティを実行します。

イベント・ログおよびAccess Managerのログ出力ファイルを確認します。ロギングおよびログ出力ファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

Webサーバー固有の構成ファイルを確認します。インスタンスにWebサーバーとしてIISが構成されている場合は、ISAPIフィルタに緑のステータスのtransfilterがあることを確認します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アップグレードが失敗した場合: 「クローニングされたアクセス・システム・コンポーネントのアップグレードの失敗からのリカバリ」に進みます。
アップグレードが成功した場合: この手順全体を繰り返してこのホストのクローニングされたAccess Managerインスタンスをすべてアップグレードし、「クローニングされたアクセス・サーバーのアップグレード」に進みます。

すべてのホスト・コンピュータ上のクローニングされたすべてのAccess Managerインスタンスをアップグレードします。

16.12.3 クローニングされたアクセス・サーバーのアップグレード

このタスクは、アイデンティティ・システムおよびアクセス・システムの混合で、以前のAccess Managerクローンがすべてアップグレードされている場合にのみ実行します。

注意:

アクティビティを実行する前に、この項のすべての情報を確認することをお薦めします。ディレクトリの名前を変更して移動するよう指示されるため、インスタンスのディレクトリおよび名前を追跡することが重要です。

クローンのアクセス・サーバーのアップグレードは、クローニングされたCOREidサーバーのアップグレードに似ています。最新のMigrateOAMスクリプトが、クローニングされた各アクセス・サーバー・インスタンスの適切な場所にあることを確認するステップを実行することから開始します。「停止時間ゼロのメソッドの準備タスク」に説明されているように、これにはソースと宛先の作成、および10g（10.1.4.2.0）のツールの取得が含まれます。

表16-14には、各アクセス・サーバーのクローンに対して実行を指示されるアクティビティを説明するために、実行する処理の進捗状況を説明する列にサンプルのファイル・システム・パス名がまとめられています。表16-14の後に詳細があります。サンプルのパス名はWindowsプラットフォーム用です。環境によってパスは異なります。

表16-14 クローンのアクセス・サーバー・インスタンスのアップグレードに向けた準備アクティビティ

1 クローンのパス

2 ソースの作成

3 宛先の作成およびツールの取得

アクセス・サーバー・インスタンス

clone_np\aaa_01\
access

clone_np\aaa_02\
access

各クローン・インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。

clone_np\aaa_01
access_source

clone_np\aaa_02
access_source

ソースの作成後（列2を参照）:

A. 10g（10.1.4.0.1）のアクセス・サーバーのライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとしてクローンのパスを指定します。次に例を示します。

clone_np\aaa_01\access

注意: 10g（10.1.4.0.1）のインスタンスのパスは、名前を変更する前のクローンのパスに正確に一致する必要があります（例は列1を参照）。

「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

B. リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、ツールを取得します。

「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」を参照してください。

C. ステップAおよびBを、各クローン・インスタンスに対して繰り返します。

表16-14で説明されているアクティビティを実行すると、最新のMigrateOAMスクリプトがdestination_dirに格納されます。次に例を示します。

clone_np\aaa_01\access\oblix\tools\migration_tools\MigrateOAM.bat
clone_np\aaa_02\access\oblix\tools\migration_tools\MigrateOAM.bat

表16-15に、アクセス・サーバー・インスタンスに対してクローン・モードのアップグレードを実行するために、10g（10.1.4.2.0）のMigrateOAMスクリプトで指定する引数を示します。

表16-15 アクセス・サーバー・クローンのアップグレード用のMigrateOAMスクリプト

クローン・モードのMigrateOAMの構文	値および操作
-M Clone	モードとしてCloneを指定します。クローン・モードはクローン・コンポーネントのアップグレードに必要です。
-C component	クローニングされたアクセス・サーバーをアップグレードするにはAAAを指定します。注意: アクセス・サーバー・クローンをアップグレードする前に、各コンピュータ上のすべてのAccess Managerクローンをアップグレードしてください。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	このデータのアップグレード後のリリースとして1014を指定します。
-S "source directory"	名前を変更した以前のAccess Managerディレクトリへのフルパスを引用符で囲んで指定します（表16-14の列2を参照）。複数のインスタンスがある場合は、次のようにします。 -S "C:\clone_np\aaa_01\access_source" -S "C:\clone_np\aaa_02\access_source" このようになります。
-D "destination directory"	以前のインスタンスと置き換えたクローニング済の10g（10.1.4.2.0）のAccess Managerディレクトリへのフルパスを引用符で囲んで指定します（表16-14の列1および4を参照）。次に例を示します。 -D "C:\clone_np\aaa_01\access" -D "C:\clone_np\aaa_02\access" このようになります。
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\clone_np\aaa_01\access" -I "C:\clone_np\aaa_02\access" このようになります。注意: パス名およびディレクトリ・コンテンツの詳細は、表16-14を参照してください。
-L "Languages"	適切なコードを引用符で囲み、アップグレードするインストール済のすべての言語を指定します。たとえば、英語は"en-us"、フランス語は"fr-fr"、ドイツ語は"de-de"です。

次の手順のディレクトリ・パス名、開始リリースおよび言語はサンプルとしてあげられています。自動モードを選択し、プロセスをスキップしないことをお薦めします。

注意:

次の手順のアクティビティを開始する前に、クローンのアップグレードに関するすべての情報を確認することをお薦めします。ソースの名前の変更、10g（10.1.4.0.1）のライブラリおよびファイルの抽出、および10g（10.1.4.2.0）のパッチの適用を指示されます。すべてのステップを順番に実行することが重要です。

クローニングされたアクセス・サーバー・インスタンスをアップグレードする手順

「クローニングされたアクセス・システム・コンポーネントのアップグレードに向けた準備」のタスクの概要で説明されているアクティビティをすべて実行します。

注意:

ソースの作成: アップグレード用のソースを作成するためのアクセス・サーバー・クローンが含まれるサブディレクトリの名前を変更します。次に例を示します。

変更前: clone_np\aaa_01\access
変更後: clone_np\aaa_01\access_source
図clone_np_aaa_rename.gifの説明
宛先の作成: 10g（10.1.4.0.1）のアクセス・サーバーのコンポーネント・ライブラリとファイルを抽出し、名前を変更する前のクローンに完全に一致する宛先パスを指定します。次に例を示します。

宛先パス: clone_np\aaa_01\access

宛先の例は、表16-14の列1を参照してください。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。
ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。

図clone_np_aaa_move.gifの説明
このアクセス・サーバーのアップグレード用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含む宛先に変更します。次に例を示します。

cd clone_np\aaa_01\access\oblix\tools\migration_tools\MigrateOAM.bat
10g（10.1.4.2.0）のMigrateOAMスクリプトをクローン・モードで実行し、開始リリースおよびパス名を指定します。次に例を示します。
```
MigrateOAM -M Clone -C AAA -F 610 -T 1014 -S "C:\clone_np\aaa_01\access_source" 
-D "C:\clone_np\aaa_01\access" -I "C:\clone_np\aaa_01\access" -L "en-us" 
```
1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。
2. 要求された場合は、データを変更します。
3. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。
4. 画面のメッセージに従って完了します。
  
  宛先には、ソースに基づいてアップグレードされたインスタンスが含まれています。
監査およびアクセス・レポート: 以前のインストールに監査およびアクセス・レポートが組み込まれている場合は、その他の手順を実行する前に「アイデンティティ・システムの監査およびアクセス・レポートのアップグレード」に進みます。
次のようにして、アクセス・サーバー・クローンのアップグレードが成功したことを検証します。
1. アクセス・サーバーのサービスを起動します（起動後、その名前が最初に割り当てられた名前から変わっていないことに注意してください）。たとえば、password.lstファイルにサーバー・パスワードを格納していない場合には、次のコマンドを使用します。
  
  start_access_server -P mypassword port -d -t 61
  
  コマンド・オプションによっては、非表示オプションが無効となり、パスワードがコマンドラインに表示されることになります。
2. 必要な場合は、プロンプトでパスワードを入力してください。
  
  IBM SecureWay LDAPディレクトリ・サーバーでは、次にアクセス・サーバーを起動した際に、PEMパスフレーズをリクエストするダイアログの表示までに数分かかります。
3. アクセス・サーバー・サービスが起動しない場合: イベントおよびアクセス・サーバーのログ出力ファイルを確認します。ロギングおよびログ出力ファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
4. 「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか移行ログ・ファイルを確認します。
5. aaa_server_config.xmlファイルを参照して、このアップグレードされたクローンの正しい情報が含まれていることを確認します。
6. このインスタンスのglobalparams.xmlファイルで、MigrateUserDataTo1014の値がfalseであることを確認します。次に例を示します。
  
  clone_np\aaa_01\access\oblix\apps\common\bin\globalparams.xml
```
<NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
```
7. Windows: レジストリエディタ（regedit）を実行し、次の方法のいずれかを使用してレジストリ・エントリが更新されていることを検証します。
  
  「レジストリエディタ」ウィンドウで、「マイコンピュータ」→「HKEY_LOCAL_MACHINE」→「SYSTEM」→「CurrentControlSet」→「Services」をクリックし、「ObAAAServer-<Service Name>」を探します。この中でイメージのパスを確認します。
  
  レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にある「ObAAAServer-<Service Name>」のエントリを確認します。
8. アップグレードが失敗した場合: 「クローニングされたアクセス・システム・コンポーネントのアップグレードの失敗からのリカバリ」に進みます。
9. アップグレードが成功した場合: この手順全体を繰り返し、残りのアクセス・サーバーのクローン・インスタンスをアップグレードします。
アクセス・サーバーのインスタンスをすべてアップグレードしたら、「アップグレード済のクローニングされたアクセス・システムの検証」に進みます。

16.12.4 アップグレード済のクローニングされたアクセス・システムの検証

クローニングされたすべてのコンポーネントをアップグレードした後に、アップグレード済のクローニングされたアクセス・システムを検証することをお薦めします。

クローニングされたアクセス・システムのアップグレードを検証する手順

すべてのWebブラウザ・キャッシュを削除します。
すべてのアイデンティティ・サーバー・サービスとWebPassのWebサーバー・インスタンス、およびポリシー・マネージャのWebサーバー・インスタンスとアクセス・サーバー・サービスが稼働していることを確認します。
アクセス・システムのスキーマのアップグレード後に実行したのと同じアクティビティを実行します。詳細は、「環境の正常な動作の検証」を参照してください。
第13章の説明に従って、アクセス・システムのカスタマイズのアップグレードを実行します。
アップグレードしたアクセス・システムが、アップグレードしたカスタマイズおよびプラグインと正常に連動していることを確認します。詳細は、「環境の正常な動作の検証」を参照してください。
「アップグレードしたアクセス・システムのクローンのバックアップ」に進みます。
アップグレードしたクローン環境（アップグレードしたカスタマイズを含む）が正常に動作していることを確認したら、第17章に進んで元のインスタンスのアップグレードを開始します。

元のインスタンスをすべてアップグレードおよび検証するまで、ユーザー・データの移行は開始しないことをお薦めします。

16.12.5 アップグレードしたアクセス・システムのクローンのバックアップ

正常にアップグレードされたことを検証したら、重要な情報をバックアップすることをお薦めします。これにより、アップグレード直後の環境にリストアする必要が生じたときに簡単にリストアできるようになります。

アクセス・システム・クローンのアップグレード後に重要な情報をバックアップする手順

アップグレードした宛先のファイル・システム・ディレクトリをすべてバックアップします。これは、既存コンポーネントのインストール・ディレクトリのバックアップと同じです。詳細は、「既存のコンポーネント・インストール・ディレクトリのバックアップ」を参照してください。
クローン用のWebサーバー: ベンダーのドキュメントの指示および「既存のWebサーバー構成ファイルのバックアップ」の詳細を参照し、アップグレードしたWebサーバー構成ファイルをバックアップします。
Windows: 「Windowsレジストリ・データのバックアップ」の説明に従って、アップグレードしたクローン用のWindowsレジストリ・データをバックアップします。

16.12.6 クローニングされたアクセス・システム・コンポーネントのアップグレードの失敗からのリカバリ

クローニングされたコンポーネントのアップグレードが失敗した場合、次の手順を実行して複数の変更を元に戻し、インスタンスのアップグレードを再試行できます。

ソースのファイル・システム・ディレクトリは、アップグレード前のクローニングされたインスタンスのバックアップ・コピーです。ソースにより、アップグレード中に情報が提供されます。ソースのファイル・システム・ディレクトリは変更されません。

クローニングされたシステムのトレースをすべて削除する場合は、「アクセス・システムのクローンのアップグレード後におけるロールバック」を参照してください。

アクセス・システム・クローンのアップグレードの失敗からリカバリする手順

クローンのソースをバックアップします。クローンのアップグレードを再開する際に、バックアップ・コピーを保存します。次に例を示します。

クローンのコピー元: clone_np\aaa_01\access
コピー先: backup_clone\aaa_01\access
リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを削除します。
アップグレードするインスタンス用に10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを抽出し、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。
クローン用のWebサーバー: クローニングされたWebPassに必要な場合は、バックアップされたWebサーバー構成ファイルをリストアします。
Windows: ソース・インスタンスのバックアップされたレジストリをリストア（インポート）します。
この章の説明に従ってクローンのアップグレードを再開します。

16.12.7 アクセス・システムのクローンのアップグレード後におけるロールバック

次の手順を実行すると、この時点までの変更内容をすべてロールバックして元の設定に戻すことができます。

スキーマのアップグレード前に外部ユーティリティを使用してスキーマをバックアップした場合以外は、スキーマのアップグレードをロールバックできません。外部ツールを使用したバックアップおよびスキーマのリカバリの詳細は、このマニュアルの対象外です。

クローニングされたアクセス・システムのアップグレード後にロールバックする手順

元の設定が正常に動作し、顧客にサービスを提供していることを確認します。
クローンに対応しているクローン・サービスおよびWebサーバーを停止します。
ホスト・コンピュータから次の項目を削除します。
- クローンのファイル・システム・ディレクトリ
- リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイル
- 追加またはアップグレード・プロセスの一部として自動的に追加された任意のファイル・システム・ディレクトリ
- クローンのWebサーバー・インスタンス
- 新しい構成DNおよびポリシーDN用に追加されたLDAPディレクトリ・サーバーのブランチ
元のシステム・コンソールから、すべてのクローン・プロファイルを削除します。
アップグレード前のスキーマのバックアップ・コピーがある場合は、外部ツールを使用して元のスキーマを回復できます。
元の設定が正常に動作していることを確認します。

16.12.8 他の章の内容

以前のコンポーネントでは、Latin-1エンコーディングでデータが送受信されます。アップグレードしたアクセス・サーバーではUTF-8エンコーディングが使用され、プラグイン・データにはUTF-8データが含まれます。予期されるシステム動作の詳細は、第4章を参照してください。

以前のアクセス・システム・クローンをすべて正常にアップグレードしたら、次に示すタスクの概要の説明に従って続行します。

タスクの概要: 残りのアイデンティティ・システムおよびアクセス・システムの混合のアクティビティ

クローニングされたアクセス・システムのアップグレードの完了: 次の項に進みます。
1. SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード
2. 環境の正常な動作の検証
元のインスタンスをアップグレードする前に、エンタープライズに必要なだけ、テストおよび練習のアクティビティを実行します。

16.13 SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

カスタマイズをアップグレードし、第13章の説明に従って、アップグレードしたクローンのアクセス・システムを使用してテストすることをお薦めします。次に示す概要では、実行の必要があるタスクを説明します。

注意:

統合コンポーネントまたは個別にインストールされたSDKをアップグレードする前に、アクセス・システムをアップグレードする必要があります。

タスクの概要: SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

16 スキーマ、データおよびクローン・システムのアップグレード

16.1 停止時間ゼロのアップグレードを開始する前の前提条件

16.2 停止時間ゼロのアップグレードに向けた元のインストールの準備

16.2.1 ホスト・コンピュータをOracle Access Manager 10g（10.1.4.0.1）のサポート・レベルまで上げる

16.2.2 ディレクトリ・サーバー・インスタンスおよびデータの準備

16.2.3 デプロイへの新しいハードウェアまたは以前のインスタンスの追加

16.2.4 システム・コンソールでの計画済COREidサーバー・クローンのプロファイルの追加

16.2.5 システム・コンソールでの計画済WebPassクローンのプロファイルの追加

16.2.6 WebPassクローンのプロファイルとCOREidサーバー・クローンのプロファイルの関連付け

16.2.6.1 WebPassと関連付けられた既存のCOREidサーバーの詳細の表示

16.2.6.2 COREidサーバー・クローンとWebPassクローンの関連付け

16.2.7 クローニングされたCOREidサーバーの新規ディレクトリ・サーバー・プロファイルの追加

16.2.8 Access Managerクローンのエントリの概要

16.2.9 アクセス・サーバー・クローンのプロファイルの追加

16.2.10 アクセス・システム・クローンの新規ディレクトリ・サーバー・プロファイルの作成

16.2.11 元のWebGateとアクセス・サーバー・クローンの関連付け

16.2.11.1 元のWebGateおよびクローンのアクセス・サーバーを関連付ける代替手順

16.2.12 システム・コンソールへの入力情報に関する問題からのリカバリ

16.2.13 クローンの詳細入力後における開始点へのロールバック

16.3 停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング

16.3.1 クローン作成の概要

16.3.2 ファイル・システムの設定およびクローン・インスタンスの作成

16.3.3 クローニングされたWebコンポーネントの新しいWebサーバー・インスタンスの作成

16.3.4 コンポーネントのクローニング後における変更内容のロールバック

16.4 宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得

16.4.1 宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出

16.4.2 ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用

16.5 LDAPディレクトリ・サーバーの新しいブランチへの構成データおよびポリシー・データのコピー

16.5.1 LDAPディレクトリ・サーバーへの新しいブランチの作成および移入の概要

16.5.2 新しいoblixブランチの作成および移入

16.5.3 新しいブランチへの移入に関する問題からのリカバリ

16.5.4 新しいoblixブランチへの変更内容のロールバック

16.6 クローニングされたコンポーネントおよびサービスの構成

16.6.1 クローニングされたCOREidサーバーのサービスおよび詳細の構成

16.6.2 クローニングされたCOREidサーバーと連動するためのクローニングされたWebPassインスタンスの構成

16.6.3 クローニングされたCOREidシステムで新しいブランチを使用するための設定

16.6.4 クローニングされたAccess Managerで新しいブランチを使用するための設定

16.6.4.1 クローニングされたAccess ManagerのWebサーバー構成ファイルの更新

16.6.4.2 クローニングされたAccess Managerで新しいブランチを使用するための設定

16.6.5 クローニングされたアクセス・サーバーの構成

16.6.6 環境の分離

16.6.6.1 クローン設定の分離およびWebGateの範囲の指定

16.6.6.2 元の設定の分離の概要

16.6.7 再構成されたクローンに対する変更内容のロールバック

16.7 停止時間ゼロのアップグレード中のスキーマのアップグレード

16.7.1 スキーマのアップグレードの概要

16.7.2 アイデンティティ・システムのスキーマのアップグレード

16.7.3 アクセス・システムのスキーマのアップグレード

16.8 環境の正常な動作の検証

16.8.1 アイデンティティ・システムの動作の検証

16.8.2 アクセス・システムの動作の検証

16.8.3 スキーマのアップグレード後におけるロールバック

16.9 クローニングされたアイデンティティ・システムのアップグレード

16.9.1 アクセス・サーバーのキャッシュ・フラッシュの停止

16.9.2 クローニングされたアイデンティティ・システム・コンポーネントのアップグレードに向けた準備

16.9.3 クローニングされたCOREidサーバーのアップグレード

16.9.4 クローニングされたWebPassインスタンスのアップグレード

16.9.5 アップグレード済のクローニングされたアイデンティティ・システムの検証

16.9.6 アップグレードしたアイデンティティ・システムのクローンのバックアップ

16.9.7 クローニングされたアイデンティティ・システムのアップグレードの失敗からのリカバリ

16.9.8 アイデンティティ・システムのクローンのアップグレード後におけるロールバック

16.9.9 他の章の内容

16.10 アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更

16.11 SDKおよびアイデンティティ・システムのカスタマイズのアップグレード

16.12 クローニングされたアクセス・システムのアップグレード

16.12.1 クローニングされたアクセス・システム・コンポーネントのアップグレードに向けた準備

16.12.2 クローニングされたAccess Managerインスタンスのアップグレード

16.12.3 クローニングされたアクセス・サーバーのアップグレード

16.12.4 アップグレード済のクローニングされたアクセス・システムの検証

16.12.5 アップグレードしたアクセス・システムのクローンのバックアップ

16.12.6 クローニングされたアクセス・システム・コンポーネントのアップグレードの失敗からのリカバリ

16.12.7 アクセス・システムのクローンのアップグレード後におけるロールバック

16.12.8 他の章の内容

16.13 SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

16.5.2 新しい`oblix`ブランチの作成および移入

16.5.4 新しい`oblix`ブランチへの変更内容のロールバック