17 元のシステムのアップグレード

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

• 停止時間ゼロのメソッドを使用して元のシステムをアップグレードする際の前提条件

• 元のシステムのアップグレード前における元のブランチに対する変更内容の取得

• アップグレードしたクローンを使用するためのドメイン・ネーム・システム（DNS）の再構成

• 元のアイデンティティ・システムのアップグレード

• SDKおよびアイデンティティ・システムのカスタマイズのアップグレード

• 元のアクセス・システムのアップグレード

• SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

• ユーザー・データの即時移行の開始

• アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成

• 一時ディレクトリ・サーバー・プロファイルの削除

• 下位互換性の回復

• 元のシステムのアップグレード後におけるクローン・システムの削除

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

17.1 停止時間ゼロのメソッドを使用して元のシステムをアップグレードする際の前提条件

第16章の説明に従って、次に示す停止時間ゼロのアップグレード・タスクを実行したことを確認します。

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

• スキーマのアップグレード

• LDAPディレクトリ・サーバーの新しいブランチにあるデータのアップグレード

• クローン・システムのアップグレード

• SDK、統合コネクタおよびカスタマイズのアップグレード

• アップグレード済のクローン・システムの検証

• アップグレードしたクローン・システムのバックアップ

• 10g（10.1.4.2.0）の機能の理解

17.2 元のシステムのアップグレード前における元のブランチに対する変更内容の取得

元のシステムのアップグレード前かつLDAPディレクトリ・サーバーにクローン用の新しいブランチを作成した後に、元のシステムに変更が加えられた場合、変更はLDAPディレクトリ・サーバー（または構成ファイル）の元のブランチに格納されます。この場合、元のインスタンスをアップグレードする前に、LDAPディレクトリ・サーバーに別の新しいブランチを作成して、元のデータの最新バージョンを格納する必要があります。

最新のブランチを作成して元のシステムの最新のデータを移入したら、最新のブランチを使用するようにクローンを再構成して、クローンを新たにアップグレードします。次の概要では、このタスクを完了する場合に実行する必要のあるタスクを説明します。次に考慮事項を示します。

• 元のシステム・コンソールにある既存のクローン・プロファイルを再利用できます。ただし、クローン・プロファイルを削除して元のシステムを独立させている場合は、新しいクローン・プロファイルを追加する必要があります。

• 各ホストに存在する既存のクローンのファイル・システムおよびソース・サブディレクトリを再利用できます。

• クローンのソースを再構成して、LDAPディレクトリ・サーバーの最新のブランチを使用します。

• ソースの詳細に基づいて作成およびアップグレードされた宛先を削除する必要があります。

• クローンをアップグレードする前に新しい宛先を作成します。

• 新しいインスタンスがある場合は、クローンを作成し、元のシステム・コンソールにプロファイルを追加する必要があります。

• 新しいカスタマイズがある場合は、それらを手動でアップグレードし、アップグレード済のクローン・システムを使用して十分にテストする必要があります。

タスクの概要: 元のインスタンスのアップグレード前における元のブランチのデータに対する変更内容の取得

1. 元のシステムをアップグレードする直前に次の内容を実行します。

   1. 元のシステムが正常に動作し、顧客にサービスを提供していることを確認します。

   2. すべてのクローン・サーバーおよびサービスを停止します。

   3. LDAPディレクトリ・サーバーで、クローン・システム用に追加された新しいブランチを削除します。

   4. 各ホスト・コンピュータのクローンのファイル・システムを保存し、各クローン・インスタンスのアップグレード前に作成した各ソースを保存します。

      
      

      注意: クローンのファイル・システムおよびソースを削除する場合には、これらを新しく作成する必要があります。

      
      

   5. ステップcで削除したブランチを使用するよう構成されているため、クローンのファイル・システム・パスで、アップグレードした各宛先を削除します。

2. LDAPディレクトリ・サーバーに新しいブランチを作成し、元の構成データおよびポリシー・データの最新バージョンを移入します。詳細は、「LDAPディレクトリ・サーバーの新しいブランチへの構成データおよびポリシー・データのコピー」を参照してください。

3. クローンのファイル・システムまたはソースがない場合: ステップ1でクローンのファイル・システムまたはソースを削除した場合は、クローンを新しく作成する必要があります。詳細は、「停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング」を参照してください。

4. 元のシステム・コンソールで、すべてのクローン・インスタンスにプロファイルがあることを確認します。

5. 元のシステム・コンソールにクローン・プロファイルがない場合: プロファイルのない各クローン・インスタンス用に、元のシステム・コンソールにプロファイルを追加します。詳細は、「停止時間ゼロのアップグレードに向けた元のインストールの準備」を参照してください。

6. 最新のブランチを使用するように各クローンを構成します。詳細は、「クローニングされたコンポーネントおよびサービスの構成」を参照してください。また、次の内容も確認してください。

   • ステップ1でクローン・ソースを保存した場合は、最新のブランチを使用するようにソースを再構成してください。

   • ステップ3で新しいクローンを作成した場合はソースがないため、かわりにクローン・インスタンスを再構成する必要があります。

7. 「クローニングされたアイデンティティ・システムのアップグレード」の説明および次の内容に従って、再構成したクローンをアップグレードします。

   1. ステップ6で、最新のブランチを使用するように既存のソースを再構成した場合は、ソースの作成ステップをスキップします。

   2. 宛先を作成するためのステップを実行し、各クローン・インスタンスのアップグレード用に10g（10.1.4.2.0）のツールを取得します。

   3. 「クローニングされたアイデンティティ・システムのアップグレード」の説明に従って、アイデンティティ・システム・インスタンスをアップグレードします。

   4. 「アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更」のタスクを実行します。

   5. 「クローニングされたアクセス・システムのアップグレード」の説明に従って、アクセス・システム・インスタンスをアップグレードします。

8. 「環境の正常な動作の検証」の説明に従って、アップグレードしたクローン・システムを検証します。

9. 「アップグレードしたクローンを使用するためのドメイン・ネーム・システム（DNS）の再構成」を参照します。

10. この章に記載されている次の項の説明に従って元のシステムをアップグレードします。

    1. 元のアイデンティティ・システムのアップグレード

    2. 元のアクセス・システムのアップグレード

    3. アップグレードした元の環境全体の検証

    4. ユーザー・データの即時移行の開始

    5. アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成

    6. 元のシステムのアップグレード後におけるクローン・システムの削除

17.3 アップグレードしたクローンを使用するためのドメイン・ネーム・システム（DNS）の再構成

アップグレードしたクローン・システムが完全に動作していることを十分に検証したら、元の設定のフェイルオーバー・システムとして機能させることができます。このタスクを実行するまでは、本番の設定がユーザー・コミュニティに対応しており、アップグレードしたクローンの設定を顧客に使用することはできません。

元のサーバーをアップグレードする際に停止しないようにするためには、元のサーバーへのリクエストを、アップグレード済のクローン・サーバーまたはその他の元のサーバーにリダイレクトする必要があります。このリダイレクトを実現する方法はいくつかあります。

• 元のCOREidサーバー、クローニングされたアイデンティティ・サーバーへのWebPassシステムURL、およびWebPassシステムURLをターゲットとするリクエストをリダイレクトするよう、DNSを構成できます。

• 元のCOREidサーバーおよびWebPassコンポーネントをターゲットとするリクエストが、クローニングされたアップグレード済のアイデンティティ・サーバーおよびWebPassコンポーネント（またはその他の元のCOREidサーバーおよびWebPassコンポーネント）にリダイレクトされるようロード・バランシングを設定できます。

ネットワーク・トラフィックをリダイレクトするようにDNSを再構成する方法は、このマニュアルの対象外です。ロード・バランシングの設定の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。

17.4 元のアイデンティティ・システムのアップグレード

元のコンポーネントのかわりにアップグレードしたクローンを使用するようネットワークを再構成したら、元のアイデンティティ・システム・コンポーネントをアップグレードできます。この項の内容は次のとおりです。

• 元のアイデンティティ・システム・インスタンスのアップグレードの概要

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

• アップグレードに向けた元のアイデンティティ・システム・コンポーネントの準備

• 単一のWebPassに関連付けられた元のCOREidサーバーのアップグレード

• アップグレードした元のCOREidサーバーの構成

• 関連付けられた元のWebPassインスタンスのアップグレード

• アップグレードしたCOREidサーバー用のアップグレードした元のWebPassの構成

• 元のアクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの追加

• プロファイルを共有するWebGateの個々のプロファイル作成の概要

• アップグレードした元のアイデンティティ・システムの設定

• アップグレードした元のアイデンティティ・システムの検証

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

• 元のアイデンティティ・システムのアップグレードの失敗からのリカバリ

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

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

17.4.1 元のアイデンティティ・システム・インスタンスのアップグレードの概要

この項は、元のコンポーネントのアップグレードとクローン・コンポーネントのアップグレードの相違点および類似点についてまとめています。詳細およびステップは、アップグレード・タスクの実行時に参照する後続の説明に記載されています。

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

元のインスタンスとクローン・インスタンスをアップグレードする際の類似点: 元のインスタンスのアップグレードは、次の点でクローンのアップグレードに似ています。

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

• 宛先の作成: 最新の10g（10.1.4.0.1）のコンポーネント・ライブラリとファイルを抽出し、元のファイル・システム・パス（名前を変更する前のソース・パス）を指定します。

• ツールの取得およびアップグレード: リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、アップグレードに必要なツールを取得します。

• メッセージ: アップグレード・プロセスでは、開始リリース（6.1.1など）と最新リリース（10g（10.1.4.0.1））の間のすべての主要なリリースに対するメッセージおよびプロンプトが表示されます。最も短時間でアップグレードする場合は、確認モードではなく自動モードを使用し、プロセスをスキップしないことをお薦めします。詳細は、「元のモード（Prod）の処理の概要」を参照してください。アップグレード中に指定する宛先はアップグレードされ、ソースの詳細に基づいて10g（10.1.4.2.0）が格納されます。

• レジストリ・エントリ: Windowsプラットフォームでアップグレードする場合、最初にインストールされたインスタンスおよびリリースのレジストリ・エントリは削除され、最新のリリース用に新しいエントリが作成されます。インスタンスをアップグレードした後は、以前のリリースのレジストリ・エントリは使用できなくなります。

• 複数のWebコンポーネントに対応するWebサーバー: Webサーバー・インスタンスでは、Oracle Access Managerのリリース・レベルが異なるコンポーネント（6.1.1と10.1.4など）をサポートできません。対応しているすべてのWebコンポーネントがアップグレードされるまで、Webサーバーを停止しておく必要があります。詳細は、「複数のOracle Access Managerリリースに対するWebサーバーのサポート」を参照してください。

元のコンポーネントとクローン・コンポーネントをアップグレードする際の相違点: すべてのCOREidサーバー・クローンは、WebPassインスタンスのアップグレード前にアップグレードされます。ただし、元のCOREidサーバーの場合は、単一のWebPassに関連付けられている元のインスタンスのみをアップグレードしてから、関連付けられたWebPassをアップグレードします。

各COREidサーバーをアップグレードしたら、LDAPディレクトリ・サーバーの新しいブランチと連動するようアップグレードしたインスタンスを再構成します。単一のWebPassに関連付けられている元のCOREidサーバー・インスタンスをすべてアップグレードした後にのみ、関連付けられたWebPassをアップグレードします。元のアイデンティティ・システム・インスタンスをアップグレードする際には、次に示す追加の条件が適用されます。

• アイデンティティ・システムのみのデプロイの場合: 次のアクティビティを順番に実行します。

  • アップグレードしたWebPassが、関連付けられた元のCOREidサーバーと連動するよう構成します。

  • 異なるWebPassに関連付けられた元のCOREidサーバーをアップグレードして再構成してから、そのWebPassをアップグレードおよび再構成します。

  • 元のCOREidサーバーおよびWebPassインスタンスをすべてアップグレードするまで、この手順を繰り返します。

  • 元のアイデンティティ・システム・コンポーネントをすべてアップグレードおよび再構成したら、アップグレードしたアイデンティティ・システムを設定します。

• アイデンティティ・システムおよびアクセス・システムの混合の場合: 最初にアップグレードしたWebPassを再構成したら、元のアクセス・サーバーのアップグレード用に一時ディレクトリ・プロファイルを追加する必要があります。詳細は、「元のアクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの追加」を参照してください。

  最初のAccess Managerをアップグレードする前に、各WebGateに独自のプロファイルがあることを確認する必要があります。詳細は、「プロファイルを共有するWebGateの個々のプロファイル作成の概要」を参照してください。

タスクの概要: 元のアイデンティティ・システム・コンポーネントのアップグレード

1. 元のCOREidサーバーとWebPassインスタンスの関連付けの詳細を特定します。これは、「WebPassと関連付けられた既存のCOREidサーバーの詳細の表示」のアクティビティの実行中に印刷してあります。

2. 元のインスタンスをそれぞれアップグレードする前に前提条件のアクティビティを実行します。詳細は、「アップグレードに向けた元のアイデンティティ・システム・コンポーネントの準備」を参照してください。

3. 「単一のWebPassに関連付けられた元のCOREidサーバーのアップグレード」の説明に従って、単一のWebPassに関連付けられている元のCOREidサーバー・インスタンスをアップグレードします。

4. 「アップグレードした元のCOREidサーバーの構成」の説明に従って、LDAPディレクトリ・サーバーの新しいブランチを使用するようにアップグレードした元の各COREidサーバーを再構成します。

5. 「関連付けられた元のWebPassインスタンスのアップグレード」の説明に従って、アップグレード済の元のCOREidサーバーに関連付けられているWebPassインスタンスをアップグレードします。

6. 「アップグレードしたCOREidサーバー用のアップグレードした元のWebPassの構成」の説明に従って、アップグレードしたWebPassインスタンスを構成します。

7. アイデンティティ・システムおよびアクセス・システムの混合の場合: 「元のアクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの追加」の説明に従って、アクセス・システム・コンポーネントのアップグレード時に、使用する一時ディレクトリ・プロファイルを追加します。

8. このタスクの概要のステップを繰り返し、次の順序でその他の元のアイデンティティ・システム・コンポーネントをアップグレードします。

   • 別のWebPassに関連付けられているCOREidサーバー・インスタンスをアップグレード

   • アップグレードした元のCOREidサーバーを新しいディレクトリ・ブランチを使用するように再構成

   • 関連付けられているWebPassインスタンスをアップグレード

   • アップグレードしたWebPassインスタンスを再構成

9. すべてのアイデンティティ・システム・コンポーネントをアップグレードしたら、「アップグレードした元のアイデンティティ・システムの検証」のステップを実行します。

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

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

アイデンティティ・システムとアクセス・システムの混合デプロイの場合は、クローンのアップグレード前に、元のコンポーネントに対してこのタスクを実行しておく必要があります。まだ元のコンポーネントに実行していない場合は、続行する前に実行する必要があります。詳細は、「アクセス・サーバーのキャッシュ・フラッシュの停止」を参照してください。

17.4.3 アップグレードに向けた元のアイデンティティ・システム・コンポーネントの準備

コンポーネントをアップグレードに向けて準備する手順の詳細は、第8章で説明されています。停止時間ゼロのメソッドを使用して元の各コンポーネントをアップグレードする前に、同じ準備タスクの大部分を実行する必要があります。次に示す概要では、元の各インスタンスのアップグレードに向けて実行するタスクを説明します。詳細は、第8章の独立した項で説明されています。

注意: 元のCOREidサーバーとWebPassの関連付けの詳細を特定してください。関連付けられたWebPassまたはその他のCOREidサーバーをアップグレードする前に、特定のWebPassと関連付けられているCOREidサーバーをアップグレードする必要があります。詳細は、「WebPassと関連付けられた既存のCOREidサーバーの詳細の表示」を参照してください。

タスクの概要: 停止時間ゼロのアップグレードに向けた元のアイデンティティ・システム・コンポーネントの準備（詳細は第8章を参照）

1. 以前のカスタマイズの準備

2. カスタム・アイデンティティ・イベント・プラグインのコピー

3. ホスト・コンピュータでの準備

   • パスワード・ファイルの読取り権限の変更

   • 空きディスク領域の確認

4. リリース6.x環境での準備

5. マルチ言語インストールの準備

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

   
   

   注意: 停止時間ゼロのアップグレード・メソッドでは、各インスタンスのファイル・システム・ディレクトリをバックアップする必要はありません。かわりに、アップグレード中にソースとして使用する元のパスの名前を変更します。

   
   

7. サーバーおよびサービスの停止

8. 必要な管理権限でのログイン

17.4.4 単一のWebPassに関連付けられた元のCOREidサーバーのアップグレード

この項では、同じWebPassに関連付けられている元のCOREidサーバー・インスタンスをアップグレードするために、実行する必要のあるすべてのアクティビティを説明します。この項の最後には、すべてのステップを説明した手順が記載されています。

注意: アクティビティを実行する前に、この項のすべての情報を確認することをお薦めします。ディレクトリの名前を変更して移動するよう指示されるため、現在の場所と使用中のディレクトリを追跡する必要があります。

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

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

1 元のパス	2 ソースの作成	3 宛先の作成およびツールの取得
COREidサーバー・インスタンス np611\ois_01\identity	元のファイル・システムで、元の各インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。 np611\ois_01\identity_source	ソースの作成後（列2を参照）: A. 10g（10.1.4.0.1）のアイデンティティ・サーバーのコンポーネント・ライブラリおよびファイルを抽出し、インストール・ディレクトリとして元のパスを指定します。次に例を示します。 np611\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を、各クローン・インスタンスに対して繰り返します。

表17-1で説明されているアクティビティを実行すると、宛先で10g（10.1.4.2.0）のMigrateOAMスクリプトを使用できるようになります。次に例を示します。

np611\ois_01\identity\oblix\tools\migration_tools\MigrateOAM.bat

ソースおよび宛先作成の詳細は、「停止時間ゼロのメソッドの準備タスク」を参照してください。

表17-2に、インスタンスの10g（10.1.4.2.0）のMigrateOAMスクリプトを使用して、元のCOREidサーバーをアップグレードする際に指定する引数を示します。

表17-2 元のCOREidサーバーをアップグレードするためのProdモードのMigrateOAMの引数

MigrateOAMの元（本番）のモードの構文	値および操作
-M Prod	元のコンポーネントをアップグレードするには、モードとしてProdを指定します。本番モードは元のコンポーネントのアップグレードに必要です。
-C OIS	元のCOREidサーバーをアップグレードするにはOISを指定します。 注意: 単一の元のWebPassに関連付けられている元の各COREidサーバーをアップグレードします。元のCOREidサーバーでは、スキーマまたはデータをアップグレードしません。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	このデータのアップグレード後のリリースとして1014を指定します。
-S "source directory"	名前を変更した元のCOREidサーバー・ディレクトリへのフルパスを引用符で囲んで指定します（表17-1の列1を参照）。次に例を示します。 -S "C:\np611\ois_01\identity_source"
-D "destination directory"	元のインスタンス・ディレクトリと置き換えた10g（10.1.4.2.0）のアイデンティティ・サーバー・ディレクトリへのフルパスを引用符で囲んで指定します（表17-1の列1および4を参照）。次に例を示します。 -D "C:\np611\ois_01\identity"
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\np611\ois_01\identity"
-L "Languages"	適切なコードを引用符で囲み、アップグレードするインストール済のすべての言語を指定します。たとえば、英語は"en-us"、フランス語は"fr-fr"、ドイツ語は"de-de"です。

スクリプトおよびProdモードの詳細は、「元のモード（Prod）の処理の概要」を参照してください。

次の手順のファイル・システム・パス名、開始リリースの値および言語はサンプルとしてあげられています。詳細はユーザーによって異なります。

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

単一のWebPassに関連付けられた元のCOREidサーバーをアップグレードする手順

1. 元のCOREidサーバーとWebPassインスタンスの間の関連付けを確認します。具体的には次のとおりです。

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

   2. 「すべてのWebパスをリスト」ページで、（クローンではなく）元のWebPassの名前をクリックします。

   3. 「Webパスの詳細」ページで、アイデンティティ・サーバーをリスト・ボタンをクリックします。

      既存のWebPassに構成されたプライマリ・サーバーおよびセカンダリ・サーバーがリストされたページが表示されます。

   4. 参照用にページを印刷するか、このWebPass用にどのCOREidサーバー・インスタンスをアップグレードする必要があるかを確認します。

   5. 各WebPassに対してこれらのステップを繰り返し、関連付けられたWebPassの元のCOREidサーバーを記録します。

2. 準備: 「アップグレードに向けた元のアイデンティティ・システム・コンポーネントの準備」の説明に従って、インスタンスにタスクを実行します。内容は次のとおりです。

   • 以前のカスタマイズの準備

   • カスタム・アイデンティティ・イベント・プラグインのコピー

   • ホスト・コンピュータでの準備

     • パスワード・ファイルの読取り権限の変更

     • 空きディスク領域の確認

   • リリース6.x環境での準備

   • マルチ言語インストールの準備

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

     
     

     注意: 停止時間ゼロのアップグレード・メソッドでは、各インスタンスのファイル・システム・ディレクトリをバックアップする必要はありません。かわりに、アップグレード中にソースとして使用する元のパスの名前を変更します。

     
     

   • サーバーおよびサービスの停止

   • 必要な管理権限でのログイン

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

   
   変更前: np611\ois_01\identity
   サンプルのパス: np611\ois_01\identity_source
   
   図original_ois_rename.gifの説明
   
   

   このインスタンスのアップグレード用に10g（10.1.4.0.1）のライブラリおよびファイルを追加できます。

   
   

   注意: 既存の10g（10.1.4.0.1）のライブラリおよびファイルをコピーしないでください。

   
   

4. 宛先の作成: 10g（10.1.4.0.1）のアイデンティティ・サーバーのライブラリとファイルを抽出し、名前を変更する前の元のパスに完全に一致する宛先パスを指定します。次に例を示します。

   
   宛先パス: np611\ois_01\identity
   

   宛先パスの例は、表17-1の列1を参照してください。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

5. ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。

   ファイル・システムを設定したら、インスタンスをアップグレードできます。

   
   図original_ois_move.gifの説明
   
   

6. アップグレードするCOREidサーバー・インスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むdestination_dirに変更します。次に例を示します。

   cd np611\ois_01\identity\oblix\tools\migration_tools

7. MigrateOAMスクリプトをProdモードで実行し、開始リリースおよびインスタンスのパス名を指定します。次に例を示します。

   MigrateOAM -M Prod -C OIS -F 610 -T 1014 -S "C:\np611\ois_01\identity_source" 
   -D "C:\np611\ois_01\identity" -I "C:\np611\ois_01\identity" -L "en-us"
   

   1. 各プロセスを確認しなくてよいように自動モードを使用します。

   2. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。

   3. 画面のメッセージに従って完了します。

      ソースは変更されません。これで宛先には、ソースと同じパラメータおよび詳細で構成された10g（10.1.4.2.0）のインスタンスが格納されます。

      
      図original_ois_end.gifの説明
      
      

8. アップグレードが成功したことを確認します。

   1. 宛先パスのglobalparams.xmlで、MigrateUserDataTo1014の値がfalseであることを確認します。次に例を示します。

      destination_dir\identity\oblix\apps\common\bin\globalparams.xml

      <NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
      

   2. destination_dir\identity\oblix\configファイル・システム・ディレクトリのois_server_config.xmlファイルに、このインスタンスの正しい情報が含まれていることを確認します。

   3. アイデンティティ・サーバー・サービスが起動することを確認するため、それを起動します（起動後、その名前が最初に割り当てられた名前から変わっていないことに注意してください）。

   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）に更新されていることを確認します。次に例を示します。

      destination_dir\identity\oblix\config\np1014_is.txt

   8. アップグレードしたクローン環境で、保護されているリソースにアクセスして、WebGateの保護が機能していることを確認します。

9. 次のように続行します。

   • アップグレードが成功した場合:

     • 「アップグレードした元のCOREidサーバーの構成」のアクティビティを実行します。

     • 同じWebPassに関連付けられているその他の元のCOREidサーバー・インスタンスに対して、この手順のすべてのステップを繰り返します。

     • 同じWebPassに関連付けられている元のCOREidサーバーをすべてアップグレードおよび構成したら、「関連付けられた元のWebPassインスタンスのアップグレード」に進みます。

   • アップグレードが失敗した場合: 「アイデンティティ・システムのアップグレードの失敗からのリカバリ」に進みます。

17.4.5 アップグレードした元のCOREidサーバーの構成

元の各COREidサーバーをアップグレードした後には、インスタンスを再構成する必要があります。これは、クローン・インスタンスを再構成する際に実行した手順とほぼ同じです。

注意: 10g（10.1.4.0.1）から、COREidサーバーという名前がアイデンティティ・サーバーに変更されました。

アップグレード済の元のCOREidサーバー・インスタンスの再構成に使用するツールは、元のインスタンスのアップグレード時に指定した宛先ディレクトリに格納されています。oisという略語はOracle Identity Serverを表します。

Windowsシステム: 元のインスタンスをアップグレードした際に、レジストリ・エントリも更新されています。そのため、config_ois.exeを実行して、Windowsレジストリにアップグレード済のCOREidサーバー・サービスのエントリを追加する必要はありません。

すべてのシステム: アップグレード中に指定したファイル・システムの宛先からsetup_ois（Windows）またはstart_setup_ois（Windows以外）を実行して、ホスト名、ポートおよびアップグレードしたインスタンスのその他の詳細を構成します。次に例を示します。

Windows: np611\ois_01\identity\oblix\tools/setup/setup_ois

UNIX: /home/np611/ois_01/identity/oblix/tools/setup/start_setup_ois

この例のUNIXは、LinuxやSolarisなどのサポートされているUNIXベースのプラットフォームを意味します。このツールを実行する際には、-iオプションのみを使用し、-i "destination_dir"のようにして、インスタンスのアップグレード時に使用した宛先のファイル・システム・ディレクトリを指定します。

コマンドおよびパラメータは1行で入力します。アップグレードした元のインスタンスの次のような詳細を指定するよう要求されます。

• 元のCOREidの一意の識別子

• 元のCOREidサーバーのホスト名

• 元のCOREidサーバーがリスニングするポート

• 元のCOREidサーバーのセキュリティ・モード

• これが最初にインストールされたCOREidサーバーであるかどうか: そうである場合はYes、そうでない場合はNoと回答

元のシステム・コンソールに入力されている元のインスタンスの情報を指定してください。この環境に最初にインストールされたCOREidサーバーをアップグレードする際、これがインストールの最初のCOREidサーバーであるかどうかについて指定を求められた場合は、Yesと答えます。それ以外のCOREidサーバーの場合は、Noと答えます。

注意: 元のシステム・コンソールに入力されている元のインスタンスの情報を指定してください。この環境に最初にインストールされたCOREidサーバーをアップグレードする際、これがインストールの最初のCOREidサーバーであるかどうかについて指定を求められた場合は、Yesと答えます。それ以外のCOREidサーバーの場合は、Noと答えます。

コマンドが終了したら、アップグレードした元のCOREidサーバーは、指定した情報に基づいて再構成されています。destination_dir\identity\oblix\configファイル・システム・ディレクトリのois_server_config.xmlファイルで、変更内容を確認できます。このファイルには、構成中に指定した詳細が含まれています。これらのツールの詳細は、Oblix NetPointまたはOracle COREidの管理ガイドを参照してください。

設定ファイルの削除: 再構成を開始する前に、次のファイルを削除するよう指示されます。

• setup.*

• configInfo.*

• \ldapサブディレクトリ（存在する場合）

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

次の手順の情報は例としてあげられています。詳細はユーザーによって異なります。

アップグレードした元のCOREidサーバーを再構成する手順

1. インスタンスに指定されていたdestination_dir\identity\oblix\configファイル・システム・ディレクトリ（np611\ois_01\identityなど）から、次のファイルを削除します。

   • setup.*

   • configInfo.*

   • \ldapサブディレクトリ

2. アップグレードしたこのインスタンスのCOREidサーバーの設定ツールが含まれるファイル・システムdestination_dirに変更します。次に例を示します。

   Windows: np611\ois_01\identity\oblix\tools/setup/setup_ois

   UNIX: /home/np611/ois_01/identity/oblix/tools/setup/start_setup_ois

   この例のUNIXは、LinuxやSolarisなどのサポートされているUNIXベースのプラットフォームを意味します。

3. 元のインスタンスに対して、次のパラメータおよび指定内容を使用してコマンドを実行します。次に例を示します。

   Windows:

      setup_ois.exe -i "C:\np611\ois_01\identity"
   

   UNIX:

      ./start_setup_ois -i "/home/np611/ois_01/identity"
   

4. 画面のプロンプトに従い、アップグレードした元のCOREidサーバーおよびCOREidサーバー・サービスの詳細を答えます。

   1. 元のCOREidの一意の識別子: 元のCOREidサービスの名前を入力します。

   2. COREidサーバーのホスト名: アップグレードした元のCOREidサーバーが存在するDNSホスト名を入力します。

   3. COREidサーバーのポート: アップグレードした元のCOREidサーバーがリスニングするポートを入力します。

   4. セキュリティ・モード[open\simple\cert]: アップグレードした元のCOREidサーバー・インスタンスに対して、システム・コンソールで指定されているモードを入力します。

   5. COREidサーバーとディレクトリ・サーバー間にSSLを設定するかどうか[y/n]: 元の接続に合せて適切に答えます。

   6. 最初のCOREidサーバー: 最初にインストールされたCOREidサーバー・インスタンスである場合はYes、そうでない場合はNoと答えます。

5. destination_dir\identity\oblix\configファイル・システム・ディレクトリのois_server_config.xmlファイルを参照し、操作中に指定した詳細が含まれていることを確認します。

6. 次のように続行します。

   • 成功: ステップ5で説明したファイルに指定した情報が含まれている場合、操作は成功です。ステップ7に進みます。

   • 失敗: ステップ5で説明したファイルに情報が表示されない場合、操作は失敗です。この場合は、「元のアイデンティティ・システムのアップグレードの失敗からのリカバリ」を参照してください。

7. アップグレードした元のCOREidサーバー・サービスを再開し、次のように続行します。

   • 同じWebPassに複数のCOREidサーバーが関連付けられている場合: 「単一のWebPassに関連付けられた元のCOREidサーバーのアップグレード」の説明に従って、このステップを繰り返し、このWebPassに関連付けられている次の元のCOREidサーバーをアップグレードします。

   • 同じWebPassに関連付けられているCOREidサーバーがこれ以上ない場合: 「関連付けられた元のWebPassインスタンスのアップグレード」に進みます。

17.4.6 関連付けられた元のWebPassインスタンスのアップグレード

特定のWebPassに関連付けられている元のCOREidサーバーをアップグレードしたら、関連付けられた元のWebPassをアップグレードできます。元のWebPassインスタンスのアップグレード時に実行するアクティビティは、WebPassクローンをアップグレードするために実行したアクティビティに非常に似ています。

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

クローニングされた各WebPassインスタンスで、10g（10.1.4.2.0）のMigrateOAMスクリプトが適切な場所にあることを確認するステップを実行することから開始します。表17-3には、実行を指示されるアクティビティを説明するために、実行する処理の進捗状況を説明する列にサンプルのディレクトリ・パス名がまとめられています。サンプルのパス名はWindowsプラットフォーム用です。環境によってパスは異なります。

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

1 元のパス	2 ソースの作成	3 宛先の作成およびツールの取得
WebPassインスタンス np611\webcomponent_01\identity	元のファイル・システムで、元の各インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。 np611\webcomponent_01\identity_source	元のインスタンスのアップグレード用ソースの作成後: A. 10g（10.1.4.0.1）のWebPassのライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとして名前を変更する前の元のパスを指定します。次に例を示します。 np611\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を、各クローン・インスタンスに対して繰り返します。

表17-3で説明されているアクティビティを実行すると、作成した宛先に10g（10.1.4.2.0）のMigrateOAMスクリプトが格納されます。次に例を示します。

np611\webcomponent_01\identity\oblix\tools\migration_tools\MigrateOAM.bat

表17-3のソースおよび宛先をさらに作成する場合は、「停止時間ゼロのメソッドの準備タスク」を参照してください。

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

表17-4 元のWebPassのアップグレード用のMigrateOAMスクリプト

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

元のWebPassインスタンスをアップグレードしてもスキーマおよびデータに影響はありませんが、Webサーバー構成はアップグレードされます。元のWebPassのアップグレード中に、開始リリースから最後までの各手順で、メッセージとプロンプトが表示されます。最も短時間でアップグレードする場合は、確認モードではなく自動モードを使用することをお薦めします。また、プロセスはすべて実行することをお薦めします。

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

次の手順のファイル・システム・ディレクトリのパス名、開始リリースおよび言語は、実行する必要があるアクティビティを説明するためにサンプルとしてあげられています。

注意: すべての準備タスクを実行しないと、アップグレードの問題からのロールバックやリカバリができなくなる可能性があります。

元のWebPassインスタンスをアップグレードする手順

1. 準備: 「アップグレードに向けた元のアイデンティティ・システム・コンポーネントの準備」を参照してください。内容は次のとおりです。

   • カスタム・アイデンティティ・イベント・プラグインのコピー

   • 以前のカスタマイズの準備

   • ホスト・コンピュータでの準備

     • パスワード・ファイルの読取り権限の変更

     • 空きディスク領域の確認

   • リリース6.x環境での準備

   • マルチ言語インストールの準備

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

     
     

     注意: 停止時間ゼロのアップグレード・メソッドでは、各インスタンスのファイル・システム・ディレクトリをバックアップする必要はありません。

     
     

   • サーバーおよびサービスの停止

   • 必要な管理権限でのログイン

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

   
   変更前: np611\webcomponent_01\identity
   変更後: np611\webcomponent_01\identity_source
   図original_np611_wp_ren.gifの説明
   
   

3. 宛先の作成: 10g（10.1.4.0.1）のWebPassのライブラリおよびファイルを抽出し、宛先として（名前を変更する前の）元のパスを指定します。次に例を示します。

   
   サンプルのパス: np611\webcomponent_01\identity
   

   宛先の例は、表17-3の列1を参照してください。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

   
   図original_np611_move.gifの説明
   
   

4. ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。

   この手順のステップに従って元のファイル・システムを設定したら、元のWebPassをアップグレードできます。

5. アップグレードするインスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むファイル・システムの宛先に変更します。次に例を示します。

   destination_dir\webcomponent_01\identity\oblix\tools\migration_tools

6. 10g（10.1.4.2.0）のMigrateOAMスクリプトをProdモードで実行し、開始リリース、パス名、言語およびWebサーバー・タイプを指定します。次に例を示します。

   MigrateOAM -M Prod -C WP -F 610 -T 1014 -S "C:\np611\webcomponent_01\identity_
   source" -D "C:\np611\webcomponent_01\identity" -I "C:\np611\webcomponent_ 
   01\identity" -L "en-us" -W "nsapi"
   

   1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。

   2. この元のインスタンスが構成されているWebサーバー構成ファイルへの完全なディレクトリ・パス名を指定し、Webサーバー構成の変更を受け入れます。

   3. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。

   4. 画面のメッセージに従って完了します。

      宛先は、ソースの構成の詳細を使用してアップグレードされています。

      
      図original_wp_end.gifの説明
      
      

7. 次のようにして、アップグレードが成功したことを確認します。

   1. 必要な場合には、Webサーバーの変更を適用し、Webサーバー固有の構成ファイルを確認します。インスタンスにWebサーバーとしてIISが構成されている場合は、ISAPIフィルタに緑のステータスのtransfilterがあることを確認します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

      
      

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

      
      

   2. Windows: レジストリ エディタ（regedit）を実行し、レジストリ・エントリが更新されていることを検証します。また、次の確認を行います。

      レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にあるWebPassのエントリを確認します。

   3. 「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか移行ログ・ファイルを確認します。

8. 次のように続行します。

   1. WebPassのアップグレードが成功した場合: 「アップグレードしたCOREidサーバー用のアップグレードした元のWebPassの構成」に進みます。

   2. アップグレードが失敗した場合: 「アイデンティティ・システムのアップグレードの失敗からのリカバリ」に進みます。

9. 元のWebPassインスタンスをすべてアップグレードおよび構成したら、「アップグレードした元のアイデンティティ・システムの設定」に進みます。

17.4.7 アップグレードしたCOREidサーバー用のアップグレードした元のWebPassの構成

WebPassインスタンスをアップグレードした後に、次の手順を実行します。この場合は、WebPass設定ツールを使用して、アップグレードした元のCOREidサーバーと通信するようにインスタンスを再構成します。

注意: 元のWebPassインスタンスをアップグレードすると、Webサーバー構成も更新されます。それ以上Webサーバー構成を更新する必要はありません。

WebPass設定ツールは、すべてのプラットフォームでアップグレードした各宛先に格納されています。Windowsプラットフォームではツールはsetup_webpass.exeという名前で、Windows以外のシステムではstart_setup_wepbassという名前です。ツールは、ファイル・システムのアップグレードしたWebPassの宛先に配置されています。次に例を示します。

np611\webcomponent_01\identity\oblix\tools\setup\setup_WebPass

表17-5に、ツールのオプションを示します。このツールを実行した場合、指定できるのは-iオプションのみで、その他すべての情報は自動的にリクエストされます。WebPassインスタンスが複数ある場合は、元の各インスタンスに対してこの操作を繰り返す必要があります。

表17-5 元のインスタンス用のsetup_webpass（およびstart_setup_webpass）のオプション

コマンド・オプション	操作
-i "Upgrade_Destination_dir"	アップグレードされた元のWebPassが格納されているファイル・システム・ディレクトリ（アップグレード中に指定された宛先）を指定します。C:\np611\webcomponent_01\identityなどです。
-q -n WebPass _name	元のWebPassインスタンスの一意の名前を指定します。
-h associated_COREidServer_Hostname	関連付けられた元のCOREidサーバーが存在するコンピュータ名を指定します。
-p associated_COREidServer_port_#	関連付けられた元のCOREidサーバーが存在するコンピュータのポート番号を指定します。
-s mode	関連付けられた元のCOREidサーバーおよび元のWebPassのトランスポート・セキュリティ・モードを、open、simpleまたはcertのいずれかで指定します。
-P simple|cert mode password	簡易または証明書トランスポート・セキュリティ・モードのパスワードを指定します。
-c request|install	証明書のリクエストまたはインストールを指定します。

コマンドを実行すると、メッセージで状況を把握できます。操作中に要求された環境の情報を指定してください。

次の手順では、実行が必要な一連のステップを説明します。ファイル・システムのパス名は例としてあげられています。詳細はユーザーによって異なります。

アップグレードしたCOREidサーバーと連動するようアップグレードした元のWebPassを変更する手順

1. 元のWebPassのアップグレード用に指定されたファイル・システムの宛先に変更して、setup_WebPass（またはstart_setup_webpass）ユーティリティを探します。次に例を示します。

   
   Windows: np611\webcomponent_01\identity\oblix\tools\setup\setup_webpass
   UNIX: /home/np611/webcomponent_01/identity/oblix/tools/setup/start_setup_
   webpass
   

2. アップグレードした元のWebPassの指定内容を使用してユーティリティを実行します。次に例を示します。

   setup_webpass -i "C:\np611\webcomponent_01\identity"
   

3. 画面のプロンプトに従い、アップグレードした元のWebPassおよび関連付けられたアップグレード済の元のCOREidサーバーの詳細を答えます。

   1. WebPassの一意の識別子: システム・コンソールに表示される元のWebPassの名前を入力します。

   2. COREidサーバーのホスト名: 関連付けられた元のCOREidサーバーが存在するDNSホスト名を入力します。

   3. COREidサーバーのポート: システム・コンソールに指定されているように、関連付けられた元のCOREidサーバーがリスニングするポートを入力します。

   4. セキュリティ・モード[open\simple\cert]: システム・コンソールに指定されているモードを入力します。

4. 失敗: 「元のアイデンティティ・システムのアップグレード後におけるロールバック」に進みます。

5. 成功: 次のように続行します。

   • アイデンティティ・システムのみ:

     • COREidサーバーが異なるWebPassに関連付けられている場合: 「単一のWebPassに関連付けられた元のCOREidサーバーのアップグレード」のステップを実行してから、関連付けられているWebPassをアップグレードします。

     • これ以上アップグレードするWebPassインスタンスがない場合: 「アップグレードした元のアイデンティティ・システムの設定」のステップを実行します。

   • アイデンティティ・システムおよびアクセス・システムの混合:

     • 最初にアップグレードしたWebPassの場合: 「元のアクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの追加」のステップを実行します。

     • COREidサーバーが異なるWebPassに関連付けられている場合: 「単一のWebPassに関連付けられた元のCOREidサーバーのアップグレード」の説明に従って、次のCOREidサーバーのセットをアップグレードしてから、関連付けられているWebPassをアップグレードします。

     • これ以上アップグレードするWebPassインスタンスがない場合: 「アップグレードした元のアイデンティティ・システムの設定」のステップを実行します。

17.4.8 元のアクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの追加

アイデンティティ・システムとアクセス・システムの混合の場合は、最初の元のWebPassインスタンスをアップグレードおよび再構成した後にこのタスクを実行する必要があります。このタスクは、使用可能でアップグレード済のクローンのアイデンティティ・システムを使用して実行します。

元のアクセス・サーバーのポリシー・データに対する書込み権限を付与するLDAPディレクトリ・プロファイルがない場合、このタスクはマスター・アクセス管理者が実行します。このタスクは、最初の元のWebPassインスタンスをアップグレードした後で、元のアクセス・システム・コンポーネントをアップグレードする前に実行します。一時プロファイルによって、ディレクトリ・サーバーの新しいブランチに格納されているポリシー・データへの元のアクセス・サーバーの書込み権限が付与されます。一時ディレクトリ・プロファイルは、アップグレードしたクローンのアイデンティティ・システム・コンソールを使用して作成します。

WebGateのアップグレード中には、アクセス・サーバーにより、WebGatestatic.lstファイルに格納されている構成情報が収集され、アップグレードのために作成された一時ディレクトリ・プロファイルを使用してLDAPディレクトリ・サーバーが更新されます。アクセス・サーバーは、LDAPディレクトリ・サーバーに情報を書き込むと、WebGateにステータス情報を返します。WebGateStatic.lstファイル内の不明なパラメータはすべてLDAPディレクトリ・サーバーに移動されます。

以前のリリースでは、WebGateの構成パラメータはWebGatestatic.lstファイルに格納されていました。ただし、Oracle Access Manager 10g（10.1.4.0.1）から、『Oracle Access Managerアクセス管理ガイド』の説明に従って、システム・コンソールのIPValidationおよびIPValidationExceptionsなどのWebGateパラメータを構成する必要があります。WebGateStatis.lstファイルが削除されるため、アップグレード中に以前のWebGateの構成パラメータを正常に移行する必要があります。

注意: このプロファイルを作成する前に追加のWebPassインスタンスまたはアクセス・システムのいずれかのコンポーネントをアップグレードすると、アップグレードが失敗することがあります。

一時ディレクトリ・プロファイルのガイドライン

一時ディレクトリ・プロファイルを作成するには、次のようにします。

• プロファイルにmigration_wgstatic_profileという名前を割り当てます。これ以外の名前は使用しないでください。

• ポリシー・データが格納されているディレクトリ用にmigration_wgstatic_profileを作成します。具体的には次のとおりです。

  • ユーザー・データ、構成データおよびポリシー・データがすべて単一のLDAPディレクトリ・サーバーに格納されている場合は、そのLDAPディレクトリ・サーバー用にこの新しいプロファイルを作成します。

  • ポリシー・データが構成データと同じLDAPディレクトリ・サーバーに格納されている場合は、そのLDAPディレクトリ・サーバー用にこの新しいプロファイルを作成します。

• migration_wgstatic_profileに対してすべての操作を行う権限を割り当てます。

• クローンのAccessManager_dir/access/oblix/config/configInfo.xmlに格納されている（新しいブランチ用の）<ldapOblixBase>と同じネームスペースを使用します。たとえば、obapp=PSC,o=Oblix, <New_Config_DN>です。

• ご使用のLDAPディレクトリ・サーバーでLDAP参照がサポートされている場合、この一時LDAPディレクトリ・サーバー・プロファイルでLDAP参照を有効にします。参照を使用すると、クライアント・リクエストを別のサーバーにリダイレクトし、リクエストされた情報を別の場所で検索できます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

• ポリシー・データのLDAPディレクトリ・サーバーがSSL対応の場合は、LDAPディレクトリ・サーバーに接続するために、アクセス・サーバーからCA証明書を要求されます。CA証明書は、元のAccessServer_install_dir/access/oblix/config/cert8.dbまたはcert7.dbの証明書ストアに手動で（certutilツールを使用して）追加する必要があります。ただし、アクセス・サーバーで使用される既存のポリシー・データ・ディレクトリがすでにSSLモードであり同じCA証明書を使用する場合は、このステップは必要ありません。

• 複数のWebGateでアクセス・システム・コンソールの単一のアクセス・ゲート・プロファイルを共有している場合は、元のAccess Managerインスタンスをアップグレードする前に、「プロファイルを共有するWebGateの個々のプロファイル作成」のタスクも実行する必要があります。

重要: 次の手順は、追加のWebPassインスタンスおよびアクセス・システム・コンポーネントをアップグレードする前に完了する必要があります。LDAPディレクトリ・サーバー・プロファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

アクセス・サーバー用の一時LDAPディレクトリ・サーバー・プロファイルを作成する手順

1. クローン環境で、クローンのアイデンティティ・システム・コンソール（以前のCOREidシステム・コンソール）に移動します。次に例を示します。

        http://hostname:port/identity/oblix/
   

2. クローンのアイデンティティ・システム・コンソールで、「システム構成」タブをクリックします。

3. 「ディレクトリ・プロファイル」をクリックして「プロファイルの構成」ページを表示します。

4. 「LDAPディレクトリ・サーバー・プロファイルの構成」セクションに移動して「追加」をクリックし、「ディレクトリ・サーバー・プロファイルの作成」ページを表示します。

5. この一時プロファイルに関する情報として、「名前」フィールドには次の名前を、「ネームスペース」フィールドには使用環境のネームスペースを入力します。

   名前: migration_wgstatic_profile

   ネームスペース: obapp=PSC,o=Oblix, <New_Config_DN>

   この例で、ネームスペースはクローンのAccessManager_dir/oblix/configファイル・システム・パスに格納されているconfigInfo.xmlの定義どおり、obapp=PSC, <ldapOblixBase>です。

6. 「すべての操作」ボタンを選択して、すべての操作を実行する権限をこのプロファイルに付与します。

7. 「使用」フィールドで、「アクセス・サーバー」オプションを選択します。

   次に、ポリシー・データが格納されているLDAPディレクトリ・サーバーを指定するためのデータベース・インスタンス・プロファイルを作成する必要があります。このように行う必要があるのは、ポリシー・データが独立したLDAPディレクトリ・サーバーに格納されている場合です。ユーザー・データ、構成データおよびポリシー・データがすべて1つのLDAPディレクトリ・サーバーにある場合は、そのLDAPディレクトリ・サーバー用に新しいデータベース・インスタンス・プロファイルを作成する必要があります。

8. 「ディレクトリ・サーバー・プロファイルの作成」ページの「データベース・インスタンス」セクションで、「追加」をクリックします。

   「データベース・インスタンスの作成」ページが表示されます。

9. 次の情報を入力して、ポリシー・データのLDAPディレクトリ・サーバーに対しデータベース・インスタンス・プロファイルを構成します。

   
   名前:
   マシン:
   ポート:
   ルートDN:
   ルートDNのパスワード:
   

   詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

10. LDAP参照がディレクトリでサポートされていて環境に必要な場合は、「フラグ」フィールドでLDAP参照チェック・ボックスを選択します。

    LDAP参照の構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

11. データベース・インスタンス・プロファイルと、関連付けられたLDAPディレクトリ・サーバー・プロファイルを保存します。

12. ポリシーのLDAPディレクトリ・サーバーがSSLモードで動作している場合は、LDAPディレクトリ・サーバーに接続するために、アクセス・サーバーからCA証明書を要求されます。

    ポリシーのLDAPディレクトリ・サーバーでアクセス・サーバーと同じCA証明書を使用している場合は、追加の構成は不要です。同じでない場合には、次に示す元のファイル・システム・パスにある証明書ストアにCA証明書（cert8.dbまたはcert7.db）を追加する必要があります。

    AccessServer_install_dir\oblix\config\cert8.dbまたはcert7.db

    AccessServer_install_dirは、元のアクセス・サーバーがインストールされているファイル・システム・パスです。新しい証明書ストアの追加の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

13. 次のように続行します。

    • 複数のWebGateでアクセス・ゲート・プロファイルを共有している場合: 「プロファイルを共有するWebGateの個々のプロファイル作成の概要」に進みます。

    • アップグレードするWebPassインスタンスが他にもある場合: 「単一のWebPassに関連付けられた元のCOREidサーバーのアップグレード」に進みます。

    • これ以上アップグレードするWebPassインスタンスがない場合: 「アップグレードした元のアイデンティティ・システムの設定」に進みます。

    • 失敗した場合: 一時ディレクトリ・プロファイルを削除して、新しく作成します。

17.4.9 プロファイルを共有するWebGateの個々のプロファイル作成の概要

元のAccess Managerをアップグレードする前に、アクセス・ゲート・プロファイルを共有する各WebGateのクローンのシステム・コンソールに個々のプロファイルを追加する必要があります。WebPassのアップグレード時にこのことについて通知されますが、元のAccess Managerをアップグレードする準備ができるまでこのタスクを実行する必要はありません。

詳細は、「プロファイルを共有するWebGateの個々のプロファイル作成」を参照してください。

17.4.10 アップグレードした元のアイデンティティ・システムの設定

アップグレードした元のCOREidサーバーおよびWebPassインスタンスをすべて構成したら、新しい構成DNを使用するようにアップグレードしたアイデンティティ・システムを設定する必要があります。このタスクは、アイデンティティ・サーバーおよびWebPassの個々の関連付けに対して実行する必要があります。

Webサーバー要件: Oracle Access Manager Webコンポーネント（WebPass、Access ManagerおよびWebGate）は、Webサーバーを再起動する前に、同じリリース（10g（10.1.4.2.0））にしておく必要があります。つまり、すべてのOracle Access Manager Webコンポーネントをアップグレードするまで、アイデンティティ・システムまたはAccess Managerを設定できません。条件は表17-6を参照してください。

表17-6 アップグレードした元のシステムの設定条件

システム	Webサーバーを再起動するための準備
アイデンティティ・システムのみ:	最後のWebPassをアップグレード済。
アイデンティティ・システムおよびアクセス・システムの混合:
WebPassおよびAccess Managerで同じWebサーバー・インスタンスを使用している場合	対応している元のAccess Managerコンポーネントをアップグレードするまでアイデンティティ・システムの設定を延期
Access ManagerおよびWebGateが同じディレクトリに存在している場合	Access Managerを再構成する前にWebGateをアップグレード
1つのWebサーバー・インスタンスで複数のOracle Access Manager Webコンポーネントに対応している場合	Webサーバー・インスタンスを再起動する前に対応しているすべてのWebコンポーネントをアップグレード
ホスト・コンピュータのすべてのWebコンポーネント（WebGateを含む）がアップグレードされている場合	次のアクティビティを実行 アップグレードした元のアイデンティティ・システムの設定 アップグレードした元のAccess Managerの設定

詳細は、「複数のOracle Access Managerリリースに対するWebサーバーのサポート」を参照してください。

分割されたディレクトリ・サーバー構成の余分なディレクトリ・プロファイル: この場合、設定操作中に余分なディレクトリ・プロファイルが追加されている可能性があります。余分なプロファイルを削除するよう指示されます。詳細は、「クローニングされたCOREidシステムで新しいブランチを使用するための設定」を参照してください。

次の手順は、環境の準備ができた場合にのみ実行します。この手順のファイル・システムのパス名は例としてあげられています。詳細はユーザーによって異なります。アイデンティティ・システムの設定の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

新しいブランチを使用するようにアップグレードした元のアイデンティティ・システムを設定する手順

1. 次の条件に基づいて環境の準備ができていることを確認します。

2. 元のWebPass Webサーバーが稼働していることを確認し、通常どおり、アップグレードした元のアイデンティティ・システム・コンソールに移動します。

        http://hostname:port/identity/oblix/
   

   このサンプルURLで、hostnameはアップグレードした元のWebPass Webサーバーをホスティングするコンピュータで、portはWebPass Webサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/identity/oblixはアイデンティティ・システム・コンソールに接続します。

3. 「アイデンティティ・システム・コンソール」リンクをクリックします。

   「システム・コンソール」設定ページが表示されます。

4. 「セットアップ」ボタンをクリックします。

5. 画面およびこの項の指示に従い、アイデンティティ・システムを設定します（詳細は、『Oracle Access Managerインストレーション・ガイド』も参照）。

   1. 新しいディレクトリ・ブランチのLDAPディレクトリ・サーバーの詳細を確認します。

   2. 使用する構成バインドDNおよびユーザー・データの検索ベースを入力します。

      構成DN: o=Newbranch,o=company,c=us

      検索ベース: 元の検索ベースを指定

   3. この設定を終了し、その他すべての設定の詳細をそのままにします。

   4. 設定中に指示されたら、新しいアイデンティティ・サーバー・サービスを再開します。

6. アイデンティティ・システム・コンソールに移動し、アップグレードした元のアイデンティティ・サーバーのディレクトリ・サーバー・プロファイルに新しい構成DNが使用されていることを検証します。具体的には次のとおりです。

   1. 通常どおり、アイデンティティ・システム・コンソールに移動します。

           http://hostname:port/identity/oblix/
      

   2. アイデンティティ・システム・コンソールで、「システム構成」タブをクリックします。

   3. 左側の列で「ディレクトリ・プロファイル」をクリックし、「プロファイルの構成」ページを表示します。

   4. 元のアイデンティティ・サーバーの既存のディレクトリ・プロファイルの名前をクリックして、指定内容を表示します。

   5. 新しい構成DNがプロファイルに表示されることを確認します。

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

7. setup.xmlファイル（\identity\oblix\configディレクトリ）を参照して、新しい構成DNがリストされていることを確認します。

   • setup.xml*

   • configInfo.xml*

   • configInfo.lst*

   • \ldapサブディレクトリ（存在する場合）

8. Webサーバーおよびアップグレードしたアイデンティティ・サーバー・サービスを再起動します。

9. 次のように続行します。

   • 構成が成功した場合（アイデンティティ・システムおよびアクセス・システムの混合）: 「元のアクセス・システムのアップグレード」に進みます。

   • 構成が成功した場合（アイデンティティ・システムのみ）: 「アップグレードした元の環境全体の検証」に進みます。

   • 構成が失敗した場合: ステップ7で説明したファイルを削除して、この手順の説明に従ってブラウザベースの設定を再実行します。それ以外の場合は、「元のアイデンティティ・システムのアップグレード後におけるロールバック」のアクティビティを実行します。

17.4.11 アップグレードした元のアイデンティティ・システムの検証

元のアイデンティティ・システムのアップグレード全体が成功したことを確認するために、次の項目を検証することをお薦めします。

注意: 対応しているすべてのWebコンポーネントがアップグレードされるまで、Webサーバー・インスタンスを停止しておく必要があります。

アップグレードした元のアイデンティティ・システムを検証する手順

1. アップグレード完了後、Webブラウザのキャッシュをすべて削除します。

2. アップグレードした元のアイデンティティ・サーバー・サービスとWebPassのWebサーバー・インスタンスがすべて稼働していることを確認します。

3. メッセージ・カタログとパラメータ・カタログのカスタマイズが保持されていることを確認します。たとえば、特定のメッセージ・カタログ・ファイルにあるメッセージを変更していた場合は、そのメッセージが保持されている必要があります。

4. 「アイデンティティ・システムの動作の検証」の説明に従って、アップグレードしたアイデンティティ・システムに対してすべての検証アクティビティを実行します。

   
   

   注意: これらは、アップグレードしたアイデンティティ・システムのスキーマの動作を検証した際に実行したアクティビティと同じです。

   
   

5. 「アップグレードした元のアイデンティティ・システムのバックアップ」に進みます。

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

正常に動作していることを検証してから、次のバックアップ・タスクを実行することをお薦めします。これにより、必要に応じて環境をアップグレードし、検証直後の状態に簡単にリストアできます。これらのタスクは、第8章で詳細に説明されています。

元のアイデンティティ・システム・コンポーネントのアップグレード後に重要な情報をバックアップする手順

1. アップグレードした宛先のファイル・システム・ディレクトリをバックアップします。これは、既存コンポーネントのインストール・ディレクトリのバックアップと同じです。詳細は、「既存のコンポーネント・インストール・ディレクトリのバックアップ」を参照してください。

2. Webサーバー: ベンダーのドキュメントの指示および「既存のWebサーバー構成ファイルのバックアップ」の詳細を参照し、アップグレードしたWebサーバー構成ファイルをバックアップします。

3. Windows: 「Windowsレジストリ・データのバックアップ」の説明に従って、Windowsレジストリ・データをバックアップします。

4. 「他の章の内容」に進みます。

17.4.13 元のアイデンティティ・システムのアップグレードの失敗からのリカバリ

元のアイデンティティ・システム・コンポーネントのアップグレードが失敗した場合は、次の手順を実行してアップグレードを再開できます。

ソース・ディレクトリはアップグレード中に変更されないため、再利用できます。

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

1. ソース・ファイル・システム・ディレクトリを新たにバックアップします。1つはバックアップ・コピーとして使用するために保存し、もう1つはアップグレードを再開するために使用します。

2. 再試行するインスタンスで、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のライブラリおよびファイルを削除します。

3. 再試行するインスタンスに、10g（10.1.4.0.1）のライブラリおよびファイルをインストールして、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。

4. Webサーバー: 必要な場合には、バックアップしたWebサーバー構成ファイルをリストアします。

5. Windows: バックアップしたこのコンポーネントのレジストリ・データをリストアします。

6. 以前の元のコンポーネントのインストール・ディレクトリ（および必要な場合はWebサーバー構成）のバックアップ・コピーを使用して、該当する項の説明に従ってアップグレードを再開します。

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

このタスクはオプションです。次の手順を使用すると、変更内容をすべてロールバックして元のインストールに戻すことができます。この操作が終了した後は、元の設定とリリースのみになります。

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

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

1. クローンの設定が正常に動作し、顧客にサービスを提供していることを確認します。

2. アップグレードした元のサービスまたはWebサーバーを停止します。

3. 元のアップグレードに追加された10g（10.1.4.2.0）の宛先のファイル・システム・ディレクトリを削除します。

4. 自動的にまたはユーザーが追加したその他のファイル・システム・ディレクトリを削除します。

5. ソースの名前を変更し、元のインスタンスのファイル・システム・パスをリストアします。

6. Windows: Windowsプラットフォームの元の各インスタンスに、このコンポーネントのWindowsレジストリ・エントリのバックアップ・コピーをインポートします。

   
   

   注意: Windowsレジストリ・エントリのバックアップ・コピーがない場合は、新しいレジストリ・エントリを生成するための特別な手順を実行する必要があります。詳細は、「ロールバック操作中における元のWindowsレジストリ・エントリの回復」を参照してください。

   
   

7. Webサーバー構成: 元のWebサーバー構成ファイルのバックアップ・コピーをリストアします。

8. 元のサービスまたはWebサーバーを再起動します。

9. アップグレードした元の各アイデンティティ・システムに対してすべてのステップを繰り返します。

10. 元のシステム・コンソールで、クローン用のエントリを削除します。

11. アップグレード前の元のスキーマのバックアップ・コピーがある場合は、外部ツールを使用してコピーを回復できます。

12. 元の設定が正常に動作していることを確認し、元の設定で顧客にサービスを提供できるようにDNSを構成します。詳細は、「アップグレードしたクローンを使用するためのドメイン・ネーム・システム（DNS）の再構成」を参照してください。

13. すべてのクローンのファイル・システム・ディレクトリ、クローン用に作成されたWebサーバー・インスタンス、およびLDAPディレクトリ・サーバーに作成された新しいブランチが含まれるアップグレードしたクローン設定をロールバックします。クローン・コンポーネントの元のシステム・コンソールに追加されたエントリも削除します。詳細は、次を参照してください。

    • 第16章の「新しいoblixブランチへの変更内容のロールバック」

    • 第16章の「アイデンティティ・システムのクローンのアップグレード後におけるロールバック」

17.4.15 他の章の内容

アップグレードした元のアイデンティティ・システム・コンポーネントでは、UTF-8エンコーディングで情報が送受信されます。以前のコンポーネントでは、Latin-1エンコーディングでデータが送受信されます。このため、10g（10.1.4.0.1）アイデンティティ・システムは以前のアクセス・システム・コンポーネントと連動しません。予期されるシステム動作の詳細は、第4章を参照してください。

次のように続行します。

• アイデンティティ・システムのみ: 「タスクの概要: 残りの元のアイデンティティ・システムのアップグレード・アクティビティ」の説明に従って、アップグレードを完了します。

• アイデンティティ・システムおよびアクセス・システムの混合: SDKをアップグレードする前に、統合コネクタをアップグレードする必要があります。この場合は、「タスクの概要: 残りの元のアイデンティティ・システムおよびアクセス・システムの混合のアクティビティ」の説明に従ってタスクを実行します。

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

1. 「SDKおよびアイデンティティ・システムのカスタマイズのアップグレード」に進みます。

2. 「アップグレードした元の環境全体の検証」に進みます。

3. エンタープライズに必要なだけテストを実行し、次の項に進みます。

   • ユーザー・データの即時移行の開始

   • アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成

   • 一時ディレクトリ・サーバー・プロファイルの削除

   • 下位互換性の回復

   • 元のシステムのアップグレード後におけるクローン・システムの削除

注意: アイデンティティ・システムとアクセス・システムの混合の場合、この章やその他の章の情報を参照して、次の手順でアクティビティを実行する必要があります。

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

1. 元のアイデンティティ・システムのアップグレードを完了: 「SDKおよびアイデンティティ・システムのカスタマイズのアップグレード」のタスクを実行します。

2. 元のアクセス・システムのアップグレードを実行: 指示に従ってタスクを実行します。

   1. 元のアクセス・システムのアップグレード

   2. SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

   3. アップグレードした元の環境全体の検証

3. 停止時間ゼロのアップグレードの完了: 独自の検証期間が終了したら、次の項に進みます。

   • ユーザー・データの即時移行の開始

   • アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成

   • 一時ディレクトリ・サーバー・プロファイルの削除

   • 下位互換性の回復

   • 元のシステムのアップグレード後におけるクローン・システムの削除

17.5 SDKおよびアイデンティティ・システムのカスタマイズのアップグレード

アイデンティティ・システムのカスタマイズおよび個別にインストールされたSoftware Developer Kit（SDK）をアップグレードし、アップグレードした元のアイデンティティ・システム全体が正常に動作していることを検証することをお薦めします。

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

1. 環境に応じて進めます。

   • アイデンティティ・システムのみ: 第11章の説明に従って、個別にインストールされたSDKおよび統合接続をアップグレードします。

   • アイデンティティ・システムおよびアクセス・システムの混合: 第11章のタスクを実行する前に、アクセス・システムをアップグレードします。

2. 第12章の説明に従って、元のアイデンティティ・システムのカスタマイズをアップグレードします。内容は次のとおりです。

   • アイデンティティ・システムの監査およびアクセス・レポートのアップグレード

   • 単一パネルへのチャレンジ属性とレスポンス属性の配置

   • アイデンティティ・システムのフェイルオーバーおよびロード・バランシングの確認

   • カスタム・アイデンティティ・イベント・プラグインの移行

   • 以前のPortal Insertsとの互換性の確保

   • カスタム・アイテムとそのアップグレードの概要

   • リリース6.5および7.xからのカスタマイズの組込み

   • 6.5より前のリリースからのカスタマイズの組込み

   • アイデンティティ・システムのカスタマイズのアップグレードの検証

3. 次のように続行します。

   • アイデンティティ・システムおよびアクセス・システムの混合: 「元のアクセス・システムのアップグレード」に進みます。

   • アイデンティティ・システムのみ: 表17-7のタスクを実行します。

     表17-7 アイデンティティ・システムのみのデプロイのアップグレードの完了

     	元のアイデンティティ・システムのアップグレードの完了
     	アップグレードした元の環境全体の検証
     	ユーザー・データの即時移行の開始
     	アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成
     	一時ディレクトリ・サーバー・プロファイルの削除
     	下位互換性の回復
     	元のシステムのアップグレード後におけるクローン・システムの削除

     
     

17.6 元のアクセス・システムのアップグレード

元のアイデンティティ・システムをアップグレードしたら、停止時間ゼロのメソッドを使用して元のアクセス・システムをアップグレードできます。

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

この項の内容は次のとおりです。

• 元のアクセス・システム・インスタンスのアップグレードの概要

• アップグレードに向けた元のアクセス・システム・コンポーネントの準備

• プロファイルを共有するWebGateの個々のプロファイルの作成

• 元のAccess Managerインスタンスのアップグレード

• アップグレードした元のAccess Managerの設定

• 元のアクセス・サーバーで新しいブランチを使用するための構成

• 元のアクセス・サーバー・インスタンスのアップグレード

• 元のWebGateのアップグレード

• アップグレードした元のアクセス・システムの検証

• アップグレードした元のアクセス・システムのバックアップ

• 元のアクセス・システムのアップグレードの失敗からのリカバリ

• 元のアクセス・システムのアップグレード後におけるロールバック

• 他の章の内容

17.6.1 元のアクセス・システム・インスタンスのアップグレードの概要

この項は、元のアクセス・システム・コンポーネントのアップグレードとクローン・コンポーネントのアップグレードの相違点および類似点についてまとめています。詳細および手順はこの項で後から説明します。

元のインスタンスとクローン・インスタンスをアップグレードする際の類似点: 元のインスタンスのアップグレードは、次の点でクローンのアップグレードに似ています。

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

• 宛先の作成: 最新の10g（10.1.4.0.1）のコンポーネント・ライブラリとファイルを、名前を変更する前の元のパスに抽出します。

• ツールの取得およびアップグレード: リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、アップグレードに必要なツールを取得します。

• メッセージ: メッセージおよびプロンプトで状況を把握できます。自動モードを使用し、プロセスをスキップしないでください。詳細は、「元のモード（Prod）の処理の概要」を参照してください。宛先はソースの詳細に基づいてアップグレードされます。

• レジストリ・エントリ: アップグレード後、以前のリリースのレジストリ・エントリは使用できなくなります。

• 複数のWebコンポーネントに対応するWebサーバー: 「複数のOracle Access Managerリリースに対するWebサーバーのサポート」の説明に従って、Webサーバーを停止しておく必要があります。

元のインスタンスとクローン・インスタンスをアップグレードする際の相違点: 各Access Managerインスタンスをアップグレードしたら、アップグレードしたスキーマおよびLDAPディレクトリ・サーバーの新しいブランチのデータと連動するよう再構成します。次の項目を確認してください。

• 元のAccess Managerのすべてのコンポーネントは、アクセス・サーバー・インスタンスをアップグレードする前にアップグレードおよび再構成する必要があります。

• 元のアクセス・サーバーを再起動する前で、アップグレードした元のAccess Managerを再構成した後に、アップグレードした元のAccess Managerからアクセス・システム・コンソールにログインし、Access_Manager_user_setup_profileおよびAccess_Server_setup_user_profileという名前で作成されたプロファイルを削除します。

すべてのAccess Managerコンポーネントをアップグレードしたら、元のアクセス・サーバーのアップグレード・タスクを開始できます。この場合は、新しいブランチの構成データをバックアップしてから、元のアクセス・サーバーを再構成します。元のアクセス・サーバーを再構成したら、アップグレードを開始します。

次に示すタスクの概要では、実行する一連の手順を説明します。ホスト上のアクセス・サーバーをアップグレードする前に、そのホストのすべてのAccess Managerをアップグレードする必要があります。ホスト上のWebGateをアップグレードする前に、同じホスト上のすべてのアクセス・サーバーをアップグレードする必要があります。

タスクの概要: 元のアクセス・システム・コンポーネントのアップグレード

1. 元のアクセス・サーバーとWebGateインスタンスの関連付けの詳細を、アクセス・システム・コンソールを使用して確認します。詳細は、NetPointまたはOracle COREidの管理ガイドを参照してください。

2. 準備: 指示されたら、「アップグレードに向けた元のアクセス・システム・コンポーネントの準備」を参照します。

3. Access Manager: 次の項を参照し、指示に従ってタスクを実行します。

   1. 元のAccess Managerインスタンスのアップグレード

   2. アップグレードした元のAccess Managerの設定

4. アクセス・サーバー: 元のアクセス・サーバーに対するタスクは、クローンに対するタスクとは逆の順序で実行する必要があります。

   1. 元のアクセス・サーバーで新しいブランチを使用するための構成

   2. 元のアクセス・サーバー・インスタンスのアップグレード

5. WebGate: 「元のWebGateのアップグレード」のタスクを実行します。

6. 検証およびバックアップ: 次のタスクを実行します。

   1. アップグレードした元のアクセス・システムの検証

   2. アップグレードした元のアクセス・システムのバックアップ

7. 次の項を参照して、SDK、統合コネクタおよびアクセス・システムをカスタマイズします。

   • SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

   • アップグレードした元の環境全体の検証

問題がある場合のリカバリの詳細は、「元のアクセス・システムのアップグレードの失敗からのリカバリ」を参照してください。

17.6.2 アップグレードに向けた元のアクセス・システム・コンポーネントの準備

各コンポーネントをアップグレードに向けて準備する手順の詳細は、第8章で説明されています。停止時間ゼロのメソッドを使用して元の各アクセス・システム・コンポーネントをアップグレードする前に、同じ準備タスクの大部分を実行する必要があります。次に示す概要では、元の各インスタンスのアップグレードに向けて実行するタスクを説明します。詳細は、第8章の独立した項で説明されています。

タスクの概要: 元のアクセス・システム・コンポーネントのアップグレードに向けた準備に含まれる項

1. プロファイルを共有するWebGateの個々のプロファイルの作成

2. ポリシー・マネージャのデフォルトのログアウトでの準備

3. ホスト・コンピュータでの準備

   • パスワード・ファイルの読取り権限の変更

   • 空きディスク領域の確認

4. リリース6.x環境での準備

5. マルチ言語インストールの準備

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

   
   

   注意: ファイル・システム・ディレクトリをバックアップする必要はありません。かわりに、ソースとして使用する元のパスの名前を変更します。ソースは、アップグレード中に変更されないバックアップになります。

   
   

7. サーバーおよびサービスの停止

8. 必要な管理権限でのログイン

17.6.3 プロファイルを共有するWebGateの個々のプロファイルの作成

元のAccess Managerインスタンスをアップグレードする前に、アクセス・ゲート・プロファイルを共有する各WebGateのクローンのシステム・コンソールに個々のプロファイルを追加する必要があります。各WebGateが独自の個別プロファイルによって定義されている場合は、このタスクをスキップできます。

各WebGateにアクセス・システム・コンソールで定義された個々のプロファイルがある場合、WebGateStatic.lstファイルのコンテンツは属性obcompoundataの下のLDAPディレクトリ・サーバーに移行されます。データが移行されると、WebGatestatic.lstファイルはWebGate_install_dirファイル・システム・パスから自動的に削除されます。ただし、同じプロファイルを共有しているWebGateが複数ある場合は、そのプロファイルを使用する2番目のWebGateのアップグレード時に次のエラーが発生します。

"The WebGate Profile is being shared by many WebGate Instances. WebgateStatic.lst
has already been migrated. However the contents do not match between the
WebgateStatic.lst of this WebGate Instance and the migrated one. Please create a
new WebGate Entry for this WebGate Instance. ...."

他のWebGateとプロファイルを共有するWebGateをアップグレードする前に、次の操作を実行する必要があります。

• 現在プロファイルを共有している元の各WebGateに個別および一意のアクセス・ゲート・プロファイルを追加します。

• 新しいプロファイルに、既存のWebGateStatic.lstファイルの詳細に基づいた指定内容が含まれていることを確認します。

• バックアップしてから、WebGateStatic.lstファイルを元のWebGate_install_dirから削除します。

次に、リリース6.1.1のWebGateStatic.lstファイルを示します。このファイルの詳細は、Oblix NetPointまたはOracle COREidの管理ガイドを参照してください。このファイルのすべてのパラメータは、リリース10.1.4パッチ・セット1（10.1.4.2.0）のアクセス・システム・コンソールのアクセス・ゲートのプロファイル・ページで確認できます。

BEGIN:vCompoundList
DenyOnNotProtected:false
CachePragmaHeader:no-cache
CacheControlHeader:no-cache
IPValidation:false
# Set UseIISBuiltinAuthentication to true
# if you are using MSPassport or Integrated
# Windows Authentication on this machine.
# Otherwise leave it set to false
# Only used for IIS
UseIISBuiltinAuthentication:false
#IPValidationExceptions:
#BEGIN:vList
#nn.nn.nn.nn
#nn.nn.nn.nn
#END:vList
WaitForFailover:-1 ( Access Server Timeout Threshold in the AccessGate Profile)
END:vCompoundList

WaitForFailoverパラメータとその代替のAccess Server Timeout Threshold in the AccessGate Profileの両方により、WebGateとそのWebGateが通信するアクセス・サーバー間のTCP/IPタイムアウトが制御されます。デフォルト値は-1で、ネットワークのデフォルトのTCP/IPタイムアウト値が使用されていることを意味します。

次の手順では、新しいプロファイルを追加して、プロファイルを共有するWebGateを準備する方法を説明します。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

元の各WebGate用に個別のプロファイルを作成する手順

1. 個別のプロファイルが必要なWebGateのWebGateStatic.lstファイルを特定し、そのファイルのバックアップ・コピーを作成して詳細を印刷します。次に例を示します。

   
   WebGate_install_dir\access\oblix\apps\webgate\WebGateStatic.lst
   

2. 通常どおり、クローンのアクセス・システム・コンソールに移動します。

   http://hostname:port/access/oblix/
   

3. 「アクセス・システム・コンソール」リンク→「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「新規アクセス・ゲートの追加」をクリックします。

4. 「新規アクセス・ゲートの追加」ページで、特定のWebGateの一意の詳細を追加します。

   • アクセス・ゲート名: WebGateインスタンスの名前。空白、コロン（:）、番号記号（#）または英語以外のキーボード文字は使用できません。

   • 説明: 後からこのWebGateを識別する際に役立つオプションのサマリー。

   • ホスト名: このWebGateをホスティングしているサーバーの名前またはIPアドレス。

   • ポート: このWebGateによって保護されているWebサーバー・ポート。

   • アクセス・ゲートのパスワード: アクセス・サーバーに対してこのWebGateを識別するための英数字。

     
     

     注意: このパスワードは、WebGateのインストール時に指定したパスワードと同一である必要があります。

     
     

   • アクセス・ゲートのパスワードを再入力: パスワードを再入力します。

5. インスタンスのWebGateStatic.lstファイルの情報に基づいて残りのフィールドを入力し、プロファイルを保存します。

6. 「アクセス・ゲートの詳細」ページで、次のようにして、新しいプロファイルを元のアクセス・サーバーに関連付けます。

   1. 「アクセス・ゲートの詳細」ページで、ページの下部にある「アクセス・サーバーをリスト」（または「クラスタをリスト」）ボタンをクリックします。

   2. 「追加」ボタンをクリックして、「新規アクセス・サーバーの追加」ページに進みます。

   3. 「サーバーの選択」リストからアクセス・サーバーを選択して優先順位を指定し、このWebGateが接続するアクセス・サーバー（接続）の数を定義します。次に例を示します。

      
      サーバーの選択: 以前のプロファイルと同じ
      優先順位の選択: 以前のプロファイルと同じ
      接続数: 以前のプロファイルと同じ

   4. 「追加」ボタンをクリックして関連付けを完了します。

   5. リンクをクリックしてサマリーを表示し、今後の使用に備えてこのページを印刷します。

7. WebGateをアップグレードする前に、WebGateのインストール・ディレクトリからWebGateStatic.lstファイルを削除します。

8. プロファイルを共有している各WebGateに対してこの手順を繰り返します。

9. その他すべての停止時間ゼロのアップグレード・タスクを順番に完了します。

17.6.4 元のAccess Managerインスタンスのアップグレード

元のAccess Managerインスタンスのアップグレード時に実行するアクティビティは、Access Managerクローンのアップグレード時に実行したアクティビティに似ています。

注意: アクティビティを実行する前に、この項のすべての情報を確認することをお薦めします。ファイル・システム・ディレクトリの名前の変更および作成を指示されます。

インスタンスのアップグレード用にソース、宛先およびツールが定義されていることを確認することから開始します。表17-8には、これらのアクティビティを説明するために、実行する処理の進捗状況を説明する列にサンプルのファイル・システム・パスがまとめられています。表の後に詳細があります。サンプルのパス名はWindowsプラットフォーム用です。環境によってパスは異なります。

表17-8 元のAccess Managerインスタンスのアップグレードに向けた準備アクティビティ

1 元のパス	2 ソースの作成	3 宛先の作成およびツールの取得
Access Managerインスタンス np611\webcomponent_01\access np611\webcomponent_02\access	元のファイル・システムで、元の各インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。 np611\webcomponent_01 \access_source np611\webcomponent_02\access_source	ソースの作成後（列2を参照）: A. 10g（10.1.4.0.1）のポリシー・マネージャのライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとして元のパスを指定します。次に例を示します。 np611\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を、各クローン・インスタンスに対して繰り返します。

表17-8で説明されているアクティビティを実行すると、destination_dirに10g（10.1.4.2.0）のMigrateOAMスクリプトが格納されます。次に例を示します。

np611\webcomponent_01\access\oblix\tools\migration_tools\MigrateOAM.bat
np611\webcomponent_02\identity\oblix\tools\migration_tools\MigrateOAM.bat

ソースおよび宛先作成の詳細は、「停止時間ゼロのメソッドの準備タスク」を参照してください。

表17-9に、個々のAccess Managerの元のインスタンスをアップグレードするために、10g（10.1.4.2.0）のMigrateOAMスクリプトで指定する引数を示します。

表17-9 元のAccess Managerインスタンスのアップグレード用のMigrateOAMスクリプト

元のモードのMigrateOAMの構文	値および操作
-M Prod	モードとしてProdを指定します。元のコンポーネントのアップグレードに必要です。
-C AM	元の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ディレクトリへのフルパスを引用符で囲んで指定します（表17-8の列2を参照）。複数のインスタンスがある場合は、次のようにします。 -S "C:\np611\webcomponent_01\access_source" -S "C:\np611\webcomponent_02\access_source" このようになります。
-D "destination directory"	以前のAccess Managerディレクトリと置き換えた10g（10.1.4.2.0）のポリシー・マネージャ・ディレクトリへのフルパスを引用符で囲んで指定します（表17-8の列1および4を参照）。次に例を示します。 -D "C:\np611\webcomponent_01\access" -D "C:\np611\webcomponent_02\access" このようになります。
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\np611\webcomponent_01\access" -I "C:\np611\webcomponent_02\access" このようになります。 注意: パス名およびディレクトリ・コンテンツの詳細は、表17-8を参照してください。
-L "Languages"	適切なコードを引用符で囲み、アップグレードするインストール済のすべての言語を指定します。たとえば、英語は"en-us"、フランス語は"fr-fr"、ドイツ語は"de-de"です。
-W "Web server type"	この元のWebPassで使用するWebサーバーの適切なコードを引用符で囲んで指定します。"nsapi"、"apache2"、"isapi"、"apache"、"ihs"、"ohs"、"ohs2"、"domino"などです。

元のAccess Managerをアップグレードしてもスキーマまたはデータに影響はありませんが、Webサーバー構成はアップグレードされます。このアップグレードでMigrateOAMを使用する方法の詳細は、「元のモード（Prod）の処理の概要」を参照してください。

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

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

注意: すべての準備手順を実行しないと、問題からのリカバリやアップグレードが失敗した後のロールバックができなくなる可能性があります。

元のAccess Managerをアップグレードする手順

1. 準備: 「アップグレードに向けた元のアクセス・システム・コンポーネントの準備」のタスクを実行します。内容は次のとおりです。

   • 以前のカスタマイズの準備

   • ポリシー・マネージャのデフォルトのログアウトでの準備

   • プロファイルを共有するWebGateの個々のプロファイルの作成

   • ホスト・コンピュータでの準備

     • パスワード・ファイルの読取り権限の変更

     • 空きディスク領域の確認

   • リリース6.x環境での準備

   • マルチ言語インストールの準備

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

     
     

     注意: このアップグレード・メソッドでは、ファイル・システム・ディレクトリをバックアップする必要はありません。

     
     

   • サーバーおよびサービスの停止

   • 必要な管理権限でのログイン

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

   
   変更前: np611\webcomponent_01\access
   変更後: \np611\webcomponent_01\access_source
   図orig_pm_rename.gifの説明
   
   

3. 宛先の作成: 10g（10.1.4.0.1）のポリシー・マネージャのライブラリとファイルを抽出し、名前を変更する前の元のAccess Managerに完全に一致する宛先パスを指定します。次に例を示します。

   
   宛先パス: np611\webcomponent_01\access
   

   または、宛先パスの例は、表17-8の列1を参照してください。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

4. ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。

   ファイル・システムを適切に設定したら、元のインスタンスをアップグレードできます。

5. アップグレードするインスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むdestination_dirに変更します。次に例を示します。

   np611\webcomponent_01\access

6. MigrateOAMスクリプトをProdモードで実行し、開始リリースおよびインスタンスのパス名を指定します。次に例を示します。

   MigrateOAM -M Prod -C AM -F 610 -T 1014 -S "C:\np611\webcomponent_01\access_
   source" -D "C:\np611\webcomponent_01\access" -I "C:\np611\webcomponent_01\ 
   access" L "en-us" -W "nsapi"
   

   1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。

   2. この元のインスタンスが構成されているWebサーバー構成ファイルへの完全なディレクトリ・パス名を指定し、Webサーバー構成の変更を受け入れます。

   3. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。

   4. 画面のメッセージに従って完了します。

      ソースは変更されません。これで宛先には、ソースと同じパラメータおよび詳細で構成された10g（10.1.4.2.0）のインスタンスが格納されます。

      
      図orig_pm_end.gifの説明
      
      

7. 次のようにして、元のAccess Managerのアップグレードが成功したことを検証します。

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

      
      

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

      
      

   2. Windows: レジストリ エディタ（regedit）を実行し、レジストリ・エントリが更新されていることを検証します。また、次の確認を行います。

      レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にあるAccess Managerのエントリを確認します。

   3. 宛先パスのバージョン・ファイルが、10.1.4（npversion_component.txt）に更新されていることを確認します。次に例を示します。

      destination_dir\oblix\config\np1014_am.txt

8. 次のように続行します。

   1. アップグレードが失敗した場合: 「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか、このインスタンスの移行ログ・ファイルを確認します。

   2. アップグレードが成功した場合: このホストのすべてのWebコンポーネントをアップグレードした場合は、「アップグレードした元のAccess Managerの設定」に進みます。それ以外の場合は、「元のアクセス・サーバー・インスタンスのアップグレード」にスキップします。

9. 元のAccess Managerインスタンスをすべてアップグレードおよび設定します。

17.6.5 アップグレードした元のAccess Managerの設定

各Access Managerインスタンスをアップグレードしたら、アップグレードしたスキーマおよびLDAPディレクトリ・サーバーの新しいブランチのデータと連動するよう再構成します。表17-10の条件を確認してください。

表17-10 停止時間ゼロのアップグレードのAccess Managerの設定条件

条件	アクション
Access ManagerおよびWebGateが同じディレクトリに存在している場合	WebGateをアップグレードするまでこのAccess Managerの再構成を延期
単一のWebサーバー・インスタンスが他のWebコンポーネントにも対応している場合	Webサーバー・インスタンスを再起動する前に対応しているすべてのWebコンポーネントをアップグレード
このWebサーバー・インスタンスのすべてのWebコンポーネントがアップグレードされている場合	次のアクティビティを実行 アップグレードした元のアイデンティティ・システムの設定（必要な場合） アップグレードした元のAccess Managerの設定 元のアクセス・サーバー・サービスを再起動する前で、アップグレードした元のAccess Managerを再構成した後に、アップグレードした元のAccess Managerからアクセス・システム・コンソールにログインし、Access_Manager_user_setup_profileおよびAccess_Server_setup_user_profileという名前で作成されたプロファイルを削除

アップグレード後に元のAccess Managerを設定するには、次の手順を実行します。この手順では、実行が必要な一連のステップを説明します。ファイル・システムのパス名は例としてあげられています。詳細はユーザーによって異なります。アイデンティティ・システムの設定の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

17.6.5.1 元のAccess Managerで新しいブランチを使用するための設定

この手順の実行中に、LDAPディレクトリ・サーバーのタイプ、ユーザー・データおよび検索ベースの場所、および人オブジェクト・クラスなど、元のインストールの詳細の一部を指定する必要があります。この情報は、元のCOREidシステムの設定時に定義されています。人オブジェクト・クラスおよびその他の詳細は、Access Managerクローンの設定時に取得してあります。元のAccess Managerにアクセスできない場合は、元のCOREidサーバーのソース・ディレクトリにあるsetup.xmlファイルから取得できます。たとえば、この例のソースはnp611\ois_01\identity_source\oblix\config\setup.xmlです。

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

次の手順では、実行が必要な一連のステップを説明します。ファイル・システムのパス名は例としてあげられています。詳細はユーザーによって異なります。

元のAccess Managerで新しいブランチを使用するよう再構成する手順

1. setup.xmlファイルから元のソースCOREidサーバーの詳細を取得します。たとえば、np611\webcomponent_01\identity_source\oblix\config\setup.xmlです。

2. np611\webcomponent_01\access\oblix\configなど、インスタンスに指定されたアップグレードの宛先から次のファイルを削除します。

   • setup.*

   • configInfo.*

   • \ldapサブディレクトリ

3. 元のAccess Manager Webサーバーが稼働していることを確認し、通常どおり、元のアクセス・システム・コンソールに移動します。

   http://hostname:port/access/oblix/
   

   このサンプルURLで、hostnameはアップグレードした元のWebPassをホスティングするコンピュータで、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/access/oblixは元のアクセス・システム・コンソールに接続します。

4. 「アクセス・システム・コンソール」リンクをクリックし、「セットアップ」ページを表示して「セットアップ」ボタンをクリックします。

5. 次のようにして、Access Managerが新しい構成DNおよびポリシー・ベースを使用するように設定します（詳細は、『Oracle Access Managerインストレーション・ガイド』も参照）。

   1. ディレクトリ・サーバーのタイプ、およびユーザー・データと構成データの場所と詳細を含むLDAPディレクトリ・サーバーの詳細を入力して確認します。

   2. ユーザー・データ（元の検索ベース）の情報、およびディレクトリ・サーバーの新しいブランチの構成データ（構成DN）やポリシー・データ（ポリシー・ベース）の情報を入力します。次に例を示します。

      検索ベース: 元の検索ベースを入力。

      構成DN: o=Newbranch,o=company,c=us

      ポリシー・ベース: o=NewPolicyBase,o=Policy_base,o=company,c=us

   3. Access Managerの残りの設定ページに入力し、その他すべての設定の詳細はそのままにします。

   4. 元のCOREidシステムの設定中に選択した人オブジェクト・クラスを入力します。

      
      

      注意: この情報は、np611\ois_01\identity\oblix\config\setup.xmlなど、元のCOREidサーバーのsetup.xmlファイルにあります。

      
      

   5. 指示されたら、Webサーバーおよびアイデンティティ・サーバー・サービスを再開します。

   6. Webサーバーを再起動したら、「次へ」をクリックし、デフォルトの「ポリシー・ドメイン・ルート」をそのまま使用して続行します（または、元のインストールのルートを指定します）。

   7. 続行しますが、NetPointのURLを保護するための認証スキームまたはポリシーは構成しないでください。

   8. 設定が完了したら「完了」をクリックします。

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

   1. 通常どおり、アクセス・システム・コンソールに移動します。

      http://hostname:port/access/oblix/
      

   2. 「アクセス・システム・コンソール」→「システム構成」→「サーバー設定」をクリックします。

   3. 左側の列で「サーバー設定」をクリックし、「ディレクトリ・サーバー」リンクをクリックします。

   4. 「ディレクトリ・サーバー構成」ページで、構成ベース（構成DNとも呼ばれる）およびポリシー・ベースに新しいブランチが反映されていることを確認します。

   5. Access_Manager_user_setup_profileおよびAccess_Server_setup_user_profileという名前で追加された余分なディレクトリ・プロファイルを確認して削除します。

7. 次のように続行します。

   • 成功: ステップ8に進みます。

   • 失敗: 手順を再度実行してAccess Managerを新しく設定し、すべての情報を正しく指定します。

8. アップグレードおよび更新した次のAccess Managerの構成ファイルに、新しい構成DNが表示されていることを確認します。たとえば、np611\webcomponent\access_01\oblix\configの次のファイルです。

   • setup.*

   • setup_am*

   • configInfo

9. 次のように続行します。

   • 成功: ステップ8で説明したファイルに新しい構成DNおよびポリシー・ベースが表示された場合、操作は成功です。ステップ10に進みます。

   • 失敗: ステップ8で説明したファイルに新しい構成DNおよびポリシー・ベースが表示されない場合、操作は失敗です。この場合は、「元のアクセス・システムのアップグレード後におけるロールバック」を参照してください。

10. 次の手順を繰り返し、元の各Access Managerをアップグレードおよび設定します。

    • アップグレードに向けた元のアクセス・システム・コンポーネントの準備

    • 元のAccess Managerインスタンスのアップグレード

    • アップグレードした元のAccess Managerの設定（対象の環境のWebサーバー条件に適切な場合）

11. 元のAccess Managerインスタンスをすべてアップグレードしたら、「元のアクセス・サーバーで新しいブランチを使用するための構成」に進みます。

17.6.6 元のアクセス・サーバーで新しいブランチを使用するための構成

このタスクは、アイデンティティ・システムおよびアクセス・システムの混合がデプロイされている場合にのみ実行します。それ以外の場合は、「アップグレードした元の環境全体の検証」に進みます。ホスト・コンピュータ上の元のAccess Managerインスタンスがすべてアップグレードされていることを確認します。

元の各アクセス・サーバーを再構成する前に、LDAPディレクトリ・サーバーの元のブランチをバックアップし、処理済のワークフローをアーカイブする必要があります。必要な元のブランチのデータには、構成データとポリシー・データ、ユーザー・データとグループ・データおよびワークフロー・データが含まれています。また、元のブランチのディレクトリ・サーバー構成の詳細が含まれる、元のインスタンスの\configファイル・システム・サブディレクトリをバックアップする必要があります。これは、ロールバックすることを選択した場合に、正常なロールバック操作に必要です。

バックアップ・アクティビティを実行したら、新しいブランチを使用するようにインスタンスを再構成できます。ただし、アクセス・サーバー・サービスを開始できるのは、インスタンスのアップグレード後のみです。インスタンスの再構成後には、アクセス・サーバー・サービスを再開しないでください。

configureAAAserver.exeツール（Windows）またはstart_configureAAAServer（UNIXベースのシステム）を使用してこのタスクを実行します。ツールは、元の各アクセス・サーバー・ディレクトリに配置されています。次に例を示します。

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

UNIX: /home/np611/aaa_01/access/oblix/tools/configureAAAServer\start_
configureAAAServer

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

この例のUNIXは、LinuxやSolarisなどのサポートされているUNIXベースのプラットフォームを意味します。ツールを実行すると、元のアクセス・サーバーの詳細を指定するよう要求されます。次の手順のファイル・システム・パス名はサンプルとしてあげられています。詳細はユーザーによって異なります。

注意: インスタンスに対してすべての準備タスクを実行しないと、問題がある場合のリカバリや元のインスタンスへのロールバックができなくなる可能性があります。

元のアクセス・サーバーで新しいブランチを使用するよう再構成する手順

1. 元のブランチの準備: 元のインストールが使用するブランチをバックアップします。第5章を参照し、次のタスクを実行します。

   • 以前のOracle Access Managerスキーマのバックアップ

   • Oracle Access Managerの構成データおよびポリシー・データのバックアップ

   • ユーザー・データおよびグループ・データのバックアップ

   • ワークフロー・データのバックアップ

   • 処理済ワークフロー・インスタンスのアーカイブ

2. ファイル・システムの準備: 再構成するインスタンスの\configディレクトリをバックアップします。\configは、元のAccessServer_install_dirファイル・システム・パスに配置されています。次に例を示します。

   np611\aaa_01\access\oblix\config

3. 元のAccessServer_install_dirにある、プラットフォーム用のツールを探して実行します。次に例を示します。

   
   Windows: np611\aaa_01\access\oblix\tools\configureAAAServer\
   configureAAAserver.exe
   

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

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

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

4. 画面のプロンプトに従って、指示された場合には元のインスタンスの詳細を指定します。具体的には次のとおりです。

   • 元のインスタンスのトランスポート・セキュリティ・モード

   • ユーザー・データ・ディレクトリが実行されているセキュリティ・モード

   • ユーザー・データ・ディレクトリが存在するホスト・コンピュータ

   • ユーザー・データ・ディレクトリがリスニングするポート番号

   • ユーザー・データ・ディレクトリのバインドDN

   • ユーザー・データ・ディレクトリのパスワード

   • ユーザー・データのディレクトリ・タイプ

   • 新しいoblix（構成）データの格納場所

   • 新しい構成DN

   • 新しいポリシー・ベース

   • 元のインスタンスのアクセス・サーバーID

   configureAAAツールおよびLDAPディレクトリ・サーバー構成の詳細は、NetPointまたはOracle COREidの管理ガイドを参照してください。

5. 元のインスタンスのアクセス・サーバー・サービスの名前を入力します。ただし、フェイルオーバー情報の指定や更新はしないでください。また、インスタンスがアップグレードされるまでアクセス・サーバー・サービスを開始しないでください。

   • 成功: ステップ6に進みます。

   • 失敗: 「元のアクセス・システムのアップグレードの失敗からのリカバリ」に進みます。

6. 再構成中に入力した新しい情報が、元のAccessServer_install_dirにある\configファイル・システム・サブディレクトリのaaa_server_config.xmlファイルに含まれていることを確認します。次に例を示します。

   np611\aaa_01\access\oblix\config\aaa_server_config.xml

7. このインスタンスのglobalparams.xmlファイルで、MigrateUserDataTo1014の値がfalseであることを確認します。次に例を示します。

   np611\aaa_01\access\oblix\apps\common\bin\globalparams.xml

   <NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
   

8. 次のように続行します。

   • 成功: ステップ6で説明したファイルに新しいポリシー・ベースが表示されている場合、操作は成功です。ステップ9に進みます。

     
     

     注意: ホスト・コンピュータのWebサーバー・インスタンスは、ホスト・コンピュータのすべてのWebコンポーネント（WebPass、Access ManagerおよびWebGate）をアップグレードするまで停止しておく必要があります。

     
     

   • 失敗: ステップ6で説明したファイルに新しいポリシー・ベースが表示されない場合、操作は失敗です。この場合は、「元のアクセス・システムのアップグレードの失敗からのリカバリ」を参照してください。

9. Access Managerの設定後: 次のようにして、元のアクセス・サーバー・インスタンスのディレクトリ・サーバー・プロファイルに新しい構成DNおよびポリシー・ベースが含まれていることを確認します。

   1. 通常どおり、元のアクセス・システム・コンソールに移動します。

      http://hostname:port/access/oblix/
      

   2. 「アクセス・システム・コンソール」→「システム構成」→「サーバー設定」をクリックします。

   3. 「ディレクトリ・サーバー」リンクをクリックして、「ディレクトリ・サーバー構成」ページを表示します。

   4. 新しい構成DNおよびポリシー・ベースが正しいことを確認して、「取消」をクリックします。

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

10. 次のように続行します。

    • 成功: このインスタンスをアップグレードする場合は、「元のアクセス・サーバー・インスタンスのアップグレード」に進みます。

    • 失敗: 「元のアクセス・システムのアップグレードの失敗からのリカバリ」に進み、再度開始します。

11. 「元のWebGateのアップグレード」に進む前に、元の各アクセス・サーバー・インスタンスに対して、この手順および「元のアクセス・サーバー・インスタンスのアップグレード」のステップをすべて繰り返します。

17.6.7 元のアクセス・サーバー・インスタンスのアップグレード

この項では、再構成した後に、元のアクセス・サーバー・インスタンスをアップグレードするために実行する必要のあるすべてのアクティビティを説明します。この項の最後には、すべてのアクティビティを説明したステップごとの手順が記載されています。

注意: 開始する前に、この項のすべての情報を確認することをお薦めします。

元のアクセス・サーバーのアップグレード中に、パラメータ・カタログおよびコンポーネント固有の構成ファイルもアップグレードされます。表17-11には、実行する処理の進捗状況を説明する列にサンプルのディレクトリ・パス名が示されています。表の後に詳細があります。サンプルのファイル・システム・パス名はWindowsプラットフォーム用です。インストールのパスはユーザーによって異なります。

表17-11 元のアクセス・サーバー・インスタンスのアップグレードに向けた準備アクティビティ

1 元のパス	2 ソースの作成	3 宛先の作成およびツールの取得
アクセス・サーバー・インスタンス np611\aaa_01\access np611\aaa_02\access	元のファイル・システムで、元の各インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。 np611\aaa_01\access_source np611\aaa_02\access_source	ソースの作成後（列2を参照）: A. 10g（10.1.4.0.1）のアクセス・サーバーのライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとして元のパスを指定します。次に例を示します。 np611\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を、各クローン・インスタンスに対して繰り返します。

表17-11で説明されているアクティビティを実行すると、元のアクセス・サーバー・インスタンスの宛先パスで10g（10.1.4.2.0）のMigrateOAMスクリプトを使用できるようになります。次に例を示します。

np611\aaa_01\access\oblix\tools\migration_tools\MigrateOAM.bat
np611\aaa_02\access\oblix\tools\migration_tools\MigrateOAM.bat

表17-12に、元のアクセス・サーバーのアップグレードを実行するために10g（10.1.4.2.0）のMigrateOAMスクリプトで指定する引数を示します。

表17-12 元のアクセス・サーバーをアップグレードするための本番モードのMigrateOAMの引数

MigrateOAMの元（本番）のモードの構文	値および操作
-M Prod	元のコンポーネントをアップグレードするには、モードとしてProdを指定します。本番モードは元のコンポーネントのアップグレードに必要です。
-C AAA	元のアクセス・サーバーをアップグレードするにはAAAを指定します。 注意: 元のWebGateをアップグレードする前に元の各アクセス・サーバーをアップグレードします。
-F nnn	以前のリリースを示す数値を指定します。例: 610（6.1または6.1.1の場合）、650（6.5.xの場合）または700（7.xの場合）
-T 1014	このデータのアップグレード後のリリースとして1014を指定します。
-S "source directory"	名前を変更した元のアクセス・サーバー・ディレクトリへのフルパスを引用符で囲んで指定します（表17-11の列1を参照）。次に例を示します。 -S "C:\np611\aaa_01\access_source" -S "C:\np611\aaa_02\access_source" このようになります。
-D "destination directory"	元のインスタンス・ディレクトリと置き換えた10g（10.1.4.2.0）のアクセス・サーバー・ディレクトリへのフルパスを引用符で囲んで指定します（表17-11の列1および4を参照）。次に例を示します。 -D "C:\np611\aaa_01\access" -D "C:\np611\aaa_02\access" このようになります。
-I "installation directory"	インストール・ディレクトリは、宛先ディレクトリと同一である必要があります。次に例を示します。 -I "C:\np611\aaa_01\access" -I "C:\np611\aaa_02\access" このようになります。
-L "Languages"	適切なコードを引用符で囲み、アップグレードするインストール済のすべての言語を指定します。たとえば、英語は"en-us"、フランス語は"fr-fr"、ドイツ語は"de-de"です。

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

注意: すべての準備手順を実行しないと、問題からのリカバリやアップグレードが失敗した後のロールバックができなくなる可能性があります。

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

1. 準備: 「アップグレードに向けた元のアクセス・システム・コンポーネントの準備」のタスクを実行します。内容は次のとおりです。

   • 以前のカスタマイズの準備

   • ポリシー・マネージャのデフォルトのログアウトでの準備

   • プロファイルを共有するWebGateの個々のプロファイルの作成

   • ホスト・コンピュータでの準備

     • パスワード・ファイルの読取り権限の変更

     • 空きディスク領域の確認

   • リリース6.x環境での準備

   • マルチ言語インストールの準備

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

     
     

     注意: このアップグレード・メソッドでは、ファイル・システム・ディレクトリをバックアップする必要はありません。

     
     

   • サーバーおよびサービスの停止

   • 必要な管理権限でのログイン

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

   
   変更前: np611\aaa_01\access
   変更後: np611\aaa_01\access_source
   図orig_aaa_rename.gifの説明
   
   

3. 宛先の作成: 10g（10.1.4.0.1）のアクセス・サーバーのライブラリとファイルを抽出し、名前を変更する前の元のインスタンスに完全に一致する宛先パスを指定します。次に例を示します。

   
   宛先パス: np611\aaa_01\access
   

   宛先パスは、ステップ2で名前を変更する前のソースに正確に一致する必要があります。宛先の例は、表17-11を参照してください。抽出の詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

4. ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）のインスタンスに適用します。

   ファイル・システムを適切に設定したら、元のインスタンスをアップグレードできます。

   
   図orig_aaa_extract.gifの説明
   
   

5. アップグレードするインスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むdestination_dirに変更します。次に例を示します。

   np611\aaa_01\access

6. MigrateOAMスクリプトをProdモードで実行し、開始リリースおよびインスタンスのパス名を指定します。次に例を示します。

   MigrateOAM -M Prod -C AAA -F 610 -T 1014 -S "C:\np611\aaa_01\access_source" -D
   "C:\np611\aaa_01\access" -I "C:\np611\aaa_01\access" -L "en-us"
   

   1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。

   2. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。

   3. 画面のメッセージに従って完了します。

      ソースは変更されません。これで宛先には、ソースと同じパラメータおよび詳細で構成された10g（10.1.4.2.0）のインスタンスが格納されます。

      
      図orig_aaa_end.gifの説明
      
      

7. 次のようにして、アップグレードが成功したことを確認します。

   1. アクセス・サーバー・サービスを起動します。アクセス・サーバー・サービスが起動されない場合は、次のようにします。

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

      「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか移行ログ・ファイルを確認します。

   2. Windows: レジストリ エディタ（regedit）を実行し、次の方法のいずれかを使用してレジストリ・エントリが更新されていることを検証します。

      「レジストリ エディタ」ウィンドウで、「マイ コンピュータ」→「HKEY_LOCAL_MACHINE」→「SYSTEM」→「CurrentControlSet」→「Services」をクリックし、「ObAAAServer-<Service Name>」を探します。この中でイメージのパスを確認します。

      レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にある「ObAAAServer-<Service Name>」のエントリを確認します。

   3. 宛先パスのバージョン・ファイルが、10.1.4に更新されていることを確認します。次に例を示します。

      destination_dir\access\oblix\config\np1014_aaa.txt

      
      

      注意: Webサーバーは、ホスト・コンピュータのすべてのWebコンポーネントをアップグレードするまで停止しておく必要があります。

      
      

   4. アップグレードが失敗した場合: 「元のアクセス・システムのアップグレードの失敗からのリカバリ」に進みます。

   5. アップグレードが成功した場合: ステップ8に進みます。

8. 「元のWebGateのアップグレード」に進む前に、このホストに存在するその他すべての元のアクセス・サーバー・インスタンスに対して、この手順のすべてのステップを繰り返します。

9. すべてのアクセス・サーバー・インスタンスをアップグレードします。

17.6.8 元のWebGateのアップグレード

単一のホスト上のアクセス・サーバー・インスタンスをアップグレードした後には、システムの再構成を完了して再起動できるように、WebGateをアップグレードすることをお薦めします。Webサーバーは、ホスト・コンピュータのすべてのWebコンポーネントをアップグレードするまで停止しておく必要があります。

複数のWebGateで以前のインストールの単一のプロファイルを共有している場合は、WebGateをアップグレードする前に、まだ実行していない場合には、各WebGateに個別にプロファイルを作成するよう指示されます。

各WebGateのアップグレードでは、そのWebGate用に構成されているアクセス・サーバーが少なくとも1つは実行されている必要があります。これは、WebGateStatic.lstファイルからシステム・コンソールのWebGateプロファイルへの情報の移行を可能にするために必要です。

元のWebGateをアップグレードするには、次の項を参照してください。

• 元のWebGateのアップグレード

• アップグレードしたWebGateの再構成

17.6.8.1 元のWebGateのアップグレード

WebGateのアップグレード中、元のWebGateStatic.lstファイルから情報を移行する際にプロファイルの情報が使用されます。「元のアクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの追加」の説明に従ってプロファイルを作成していない場合は、これがアップグレードの最初のステップになります。

注意: アクティビティを実行する前に、この項のすべての情報を確認することをお薦めします。ディレクトリの名前を変更して移動するよう指示されるため、インスタンスのディレクトリおよび名前を追跡することが重要です。

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

表17-13 元のWebGateインスタンスのアップグレードに向けた準備アクティビティ

1 元のパス	2 ソースの作成	3 宛先の作成およびツールの取得
WebGateインスタンス np611\webgate_01\ access	元のファイル・システムで、元の各インスタンスが含まれているサブディレクトリの名前を変更します。次に例を示します。 np611\webgate_01\ access_source	ソースの作成後（列2を参照）: A. 10g（10.1.4.0.1）のWebGateのライブラリおよびファイルを抽出し、インストール（宛先）ディレクトリとして元のパスを指定します。次に例を示します。 np611\webgate_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を、各WebGateインスタンスに対して繰り返します。

表17-13で説明されているアクティビティを実行すると、作成した宛先に10g（10.1.4.2.0）のMigrateOAMスクリプトが格納されます。次に例を示します。

np611\webgate_01\access\oblix\tools\migration_tools\MigrateOAM.bat

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

表17-14 元のWebGateインスタンスのアップグレード用のMigrateOAMスクリプト

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

元のWebGateインスタンスのアップグレードには、Webサーバー構成のアップグレードだけでなく、メッセージおよびパラメータ・ファイルのアップグレードも含まれます。

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

各WebGateのアップグレードでは、そのWebGate用に構成されているアクセス・サーバーが少なくとも1つは実行されている必要があります。これは、WebGateStatic.lstファイルからシステム・コンソールのWebGateプロファイルへの情報の移行を可能にするために必要です。

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

注意: すべての準備手順を実行しないと、問題からのリカバリやアップグレードが失敗した後のロールバックができなくなる可能性があります。

元のWebGateをアップグレードする手順

1. 準備: 「アップグレードに向けた元のアクセス・システム・コンポーネントの準備」のタスクを実行します。内容は次のとおりです。

   • 以前のカスタマイズの準備

   • ポリシー・マネージャのデフォルトのログアウトでの準備

   • プロファイルを共有するWebGateの個々のプロファイルの作成

   • ホスト・コンピュータでの準備

     • パスワード・ファイルの読取り権限の変更

     • 空きディスク領域の確認

   • リリース6.x環境での準備

   • マルチ言語インストールの準備

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

     
     

     注意: このアップグレード・メソッドでは、ファイル・システム・ディレクトリをバックアップする必要はありません。

     
     

   • サーバーおよびサービスの停止

   • 必要な管理権限でのログイン

2. 「元のアクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの追加」の説明に従って、アクセス・システム用の一時LDAPディレクトリ・プロファイルがあることを確認します。

3. アクセス・システム・コンソールで、各WebGateに一意で個別のプロファイルが定義されていることを確認します。詳細は、「プロファイルを共有するWebGateの個々のプロファイル作成の概要」を参照してください。

4. 元のWebGate Webサーバーを停止して、このWebGateと連動するよう構成されているアクセス・サーバーが少なくとも1つは実行されていることを確認します。

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

   
   変更前: np611\webgate_01\access
   変更後: np611\webgate_01\access_source
   図orig_wg_rename.gifの説明
   
   

6. 宛先の作成: 10g（10.1.4.0.1）のWebGateのライブラリとファイルを抽出し、名前を変更する前の元のWebGateに完全に一致する宛先パスを指定します。次に例を示します。

   
   宛先パス: np611\webgate_01\access
   

   宛先の例は、表17-13を参照してください。抽出の詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。

7. ツールの取得: 「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」の説明に従って、10g（10.1.4.2.0）のパッチを10g（10.1.4.0.1）の宛先に適用します。

   ファイル・システムを適切に設定したら、元のインスタンスをアップグレードできます。

   
   図orig_wg_extract.gifの説明
   
   

8. アップグレードするインスタンス用の10g（10.1.4.2.0）のMigrateOAMスクリプトを含むdestination_dirに変更します。次に例を示します。

   cd np611\webgate_01\access

9. MigrateOAMスクリプトをProdモードで実行し、開始リリースおよびインスタンスのパス名を指定します。次に例を示します。

   MigrateOAM -M Prod -C WG -F 610 -T 1014 -S "C:\np611\webgate_01\access_
   source" -D "C:\np611\webgate_01\access" -I "C:\np611\webgate_01\access" 
   -L "en-us" -W "nsapi"
   

   1. 各プロセスを確認しなくてよいように、各手順に自動モードを使用します。

   2. この元のインスタンスが構成されているWebサーバー構成ファイルへの完全なディレクトリ・パス名を指定し、Webサーバー構成の変更を受け入れます。

   3. リクエストに応じてすべてのプロセスを実行します。プロセスはスキップしないでください。

   4. 画面のメッセージに従って完了します。

      これで、宛先ディレクトリは、元のソース構成に基づいてアップグレードされています。

      
      図orig_wg_end.gifの説明
      
      

10. 次のようにして、元のWebGateのアップグレードが成功したことを検証します。

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

       
       

       注意: Webサーバーは、ホスト・コンピュータのすべてのWebコンポーネントをアップグレードするまで停止しておく必要があります。

       
       

    2. Windows: レジストリ エディタ（regedit）を実行し、レジストリ・エントリが更新されていることを検証します。また、次の確認を行います。

       レジストリ・エントリ「HKEY_LOCAL_MACHINE」→「SOFTWARE」→「Oblix」→「Oblix Netpoint」を表示します。それぞれのインストール・バージョンを確認し、その下位にあるWebGateのエントリを確認します。

    3. 宛先パスのバージョン・ファイルが、10.1.4（npversion_component.txt）に更新されていることを確認します。次に例を示します。

       destination_dir\webgate\access\oblix\config\np1014_wg.txt

11. 次のように続行します。

    1. アップグレードが失敗した場合: 「ログ・ファイルへのアクセス」の説明に従って、アップグレード中に報告されたエラーがないか、このインスタンスのイベント・ログおよび移行ログ・ファイルを確認します。

    2. アップグレードが成功した場合: 「アップグレードしたWebGateの再構成」の説明に従って、アップグレードしたWebGateを再構成します。

12. 元のWebGateをすべてアップグレードおよび構成したら、アクセス・システムを検証します。

17.6.8.2 アップグレードしたWebGateの再構成

WebGateインスタンスをアップグレードしたら、アップグレードしたアクセス・サーバーと通信するようにアップグレードしたWebGateを再構成する必要があります。

configureWebGate（Windows）およびstart_configureWebGate（UNIX）設定ツールを使用して、関連付けられたアップグレード済のアクセス・サーバーとWebGateの通信を可能にします。WebGate設定ツールは、すべてのプラットフォームで各WebGateのファイル・システム・パスに格納されています。この例では、宛先のファイル・システム・パスは次のとおりです。

np611\webgate_01\access\oblix\tools\configureWebGate

表17-15に、configureWebGateおよびstart_configureWebGateのオプションを示します。WebGateインスタンスが複数ある場合は、各インスタンスに対してこの操作を繰り返す必要があります。

表17-15 configureWebGateおよびstart_configureWebGateのコマンド・オプション

コマンド・オプション	操作
-i "destination_dir"	このインスタンスのアップグレードに使用される宛先ディレクトリへの完全なディレクトリ・パスを引用符で囲んで指定します。次に例を示します。 Windows: "C:\np611\webgate_01\access" UNIX: "/home/np611/webgate_01/access"
-t WebGate	これがWebGateに対する操作であることを指定します。

コマンドを実行すると、メッセージで進行状況が通知され、アップグレードしたWebGateの情報の指定を求められる場合があります。対象環境の情報を指定してください。

次の手順では、実行が必要な一連のステップを説明します。詳細はユーザーによって異なります。

アップグレードしたアクセス・サーバーと通信するようにWebGateを変更する手順

1. アップグレード中に指定したWebGateの宛先ディレクトリに移動し、configureWebGate（またはstart_configureWebGate）ユーティリティを探します。次に例を示します。

   
   Windows: C:\np611\webgate_01\access\oblix\tools\configureWebGate
   UNIX: /home/np611/webgate_01/access/oblix/tools/configureWebGate
   

2. ツール・ディレクトリから、次のオプション（表17-15も参照）、および元の環境の指定内容を使用してconfigureWebGateを実行します。次に例を示します。

   configureWebGate -i "C:\np611\webgate_01\access" -t WebGate
   

   コマンドは、改行せずに1行で入力する必要があります。

3. 画面のメッセージに従って進みます。

   • 元のインスタンスのトランスポート・セキュリティ・モード

   • WebGate ID

   • WebGateのパスワード（簡易または証明書モードの場合）

   • アクセス・サーバーID

   • アクセス・サーバー・ホスト

   • アクセス・サーバーがリスニングするポート番号

4. 次のように続行します。

   • 成功: 「Web Gateは正常にインストールされました。」というメッセージが表示されます。「アップグレードした元のアクセス・システムのバックアップ」の説明に従って、この情報をバックアップした後にステップ5に進みます。

   • 失敗: 「元のアクセス・システムのアップグレードの失敗からのリカバリ」に進みます。

5. WebGateがアップグレードしたAccess Managerと同じディレクトリにある場合は、「アップグレードした元のAccess Managerの設定」に進みます。それ以外の場合は、別のWebGateをアップグレードおよび再構成します。

6. 以前のWebGateをそれぞれアップグレードおよび再構成します。

7. すべてのWebGateインスタンスを再構成したら、「アップグレードした元のアクセス・システムの検証」に進みます。

17.6.9 アップグレードした元のアクセス・システムの検証

元のアクセス・システムのアップグレード全体が成功したことを確認するために、次の項目を検証することをお薦めします。

アップグレードした元のアクセス・システムを検証する手順

1. アップグレード完了後、Webブラウザのキャッシュをすべて削除します。

2. アップグレードした元のアクセス・サーバー・サービス、Access ManagerおよびWebGateのWebサーバー・インスタンスがすべて稼働していることを確認します。

3. メッセージ・カタログとパラメータ・カタログのカスタマイズが保持されていることを確認します。たとえば、特定のメッセージ・カタログ・ファイルにあるメッセージを変更していた場合は、そのメッセージが保持されている必要があります。

4. 「アップグレードした元のアクセス・システムの検証」の説明に従って、アップグレードしたアクセス・システムに対してすべての検証タスクを実行します。

5. 「アップグレードした元のアクセス・システムのバックアップ」に進みます。

17.6.10 アップグレードした元のアクセス・システムのバックアップ

正常に動作していることを検証してから、バックアップ・アクティビティを実行することをお薦めします。これにより、環境を、必要に応じてアップグレード直後の状態に簡単にリストアできます。

元のアクセス・システム・コンポーネントのアップグレード後に重要な情報をバックアップする手順

1. アップグレードした宛先のファイル・システム・ディレクトリをバックアップします。これは、既存コンポーネントのインストール・ディレクトリのバックアップと同じです。詳細は、「既存のコンポーネント・インストール・ディレクトリのバックアップ」を参照してください。

2. Webサーバー: ベンダーのドキュメントの指示および「既存のWebサーバー構成ファイルのバックアップ」の詳細を参照し、アップグレードしたWebサーバー構成ファイルをバックアップします。

3. Windows: 「Windowsレジストリ・データのバックアップ」の説明に従って、Windowsレジストリ・データをバックアップします。

4. 「他の章の内容」および「SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード」に進みます。

17.6.11 元のアクセス・システムのアップグレードの失敗からのリカバリ

元のアクセス・システム・コンポーネントのアップグレードが失敗した場合は、次の手順を実行して環境をリストアし、再試行することができます。

元のアクセス・システム・コンポーネントのアップグレードの失敗からリカバリする手順

1. ソース・ファイル・システム・ディレクトリを新たにバックアップします。1つはバックアップ・コピーとして使用するために保存し、もう1つはアップグレードを再開するために使用します。

2. 再試行するインスタンスで、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用した10g（10.1.4.0.1）のライブラリおよびファイルを削除します。

3. 再試行するインスタンスに、10g（10.1.4.0.1）のライブラリおよびファイルをインストールして、リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用します。

4. Webサーバー: 必要な場合には、バックアップしたWebサーバー構成ファイルをリストアします。

5. Windows: バックアップしたこのコンポーネントのレジストリ・データをリストアします。

6. 以前の元のコンポーネントのインストール・ディレクトリ（および必要な場合はWebサーバー構成）のバックアップ・コピーを使用して、該当する項の説明に従ってアップグレードを再開します。

17.6.12 元のアクセス・システムのアップグレード後におけるロールバック

この手順を実行するとすべての変更が元に戻り、アップグレード前の元のインストールの状態になります。

WebGateが1つのみの場合、ロールバック中は停止します。

元のアクセス・システムのアップグレード後にロールバックする手順

1. クローンの設定が正常に動作し、顧客にサービスを提供していることを確認します。

2. アップグレードした元のサービスまたはWebサーバーを停止します。

3. 追加およびパッチが適用された宛先のファイル・システム・ディレクトリを削除します。

4. ソースの名前を変更し、元のインスタンスのファイル・システム・パスをリストアします。

5. Windows: 元のインスタンスおよびリリースのWindowsレジストリ・エントリのバックアップ・コピーをインポートします。

6. Webサーバー構成: 元のWebサーバー構成ファイルのバックアップ・コピーをリストアします。

7. アクセス・サーバーの\configサブディレクトリのバックアップ・コピーをリストアし、元の構成に戻します。

8. 元のサービスまたはWebサーバーを再起動します。

9. アップグレードした元の各アイデンティティ・システムに対してすべてのステップを繰り返します。

10. 元のシステム・コンソールで、クローン用のエントリを削除します。

11. アップグレード前の元のスキーマのバックアップ・コピーがある場合は、外部ツールを使用してコピーを回復できます。

12. 元の設定が正常に動作していることを確認し、元の設定で顧客にサービスを提供できるようにDNSを構成します。詳細は、「アップグレードしたクローンを使用するためのドメイン・ネーム・システム（DNS）の再構成」を参照してください。

13. すべてのクローンのファイル・システム・ディレクトリ、クローン用に作成されたWebサーバー・インスタンス、およびLDAPディレクトリ・サーバーに作成された新しいブランチが含まれるアップグレードしたクローン設定をロールバックします。クローン・コンポーネントの元のシステム・コンソールに追加されたエントリも削除します。詳細は、第16章を参照してください。

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

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

    • アクセス・システムのクローンのアップグレード後におけるロールバック

17.6.13 他の章の内容

アイデンティティ・システムとアクセス・システムの混合の場合は、次の手順でアクティビティを実行してアップグレードを完了します。

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

1. SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

2. アップグレードした元の環境全体の検証

3. ユーザー・データの即時移行の開始

4. アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成

5. 一時ディレクトリ・サーバー・プロファイルの削除

6. 下位互換性の回復

7. 元のシステムのアップグレード後におけるクローン・システムの削除

17.7 SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

カスタマイズをアップグレードし、アップグレードしたクローンのアクセス・システムを使用してテストすることをお薦めします。次に示す概要では、実行の必要があるタスクを説明します。

注意: 統合コンポーネントまたは個別にインストールされたSDKをアップグレードする前に、アクセス・システムをアップグレードする必要があります。

タスクの概要: SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード

1. 第11章

   • サード・パーティ製品の統合コネクタのアップグレード

   • 個別にインストールされたSoftware Developer Kitのアップグレード

2. 第13章

   • アクセス・サーバーの監査およびレポートのアップグレード

   • アクセス・システムのフェイルオーバーおよびロード・バランシングの確認

   • フォーム・ベース認証のアップグレード

   • カスタム認証および認可プラグインの再コンパイルおよび設計変更

   • リリース6.1.1の認可ルールとアクセス・ポリシーの関連付け

   • 6.1.1からのアップグレード後に認可失敗のリダイレクトが正しく行われるようにするための作業

   • カスタムCコードのObAMMasterAuditRule_getEscapeCharacterの更新

   • アクセス・システムのカスタマイズのアップグレードの検証: 次に「アップグレードした元の環境全体の検証」も参照。

3. この章: アップグレードした元の環境全体の検証。

17.8 アップグレードした元の環境全体の検証

アップグレードした元の環境全体を検証する前に、クローン環境でテストしたアップグレード済のカスタマイズを統合しておいてください。

詳細、およびアイデンティティ・システムおよびアクセス・システムを含むアップグレードした元の環境全体を検証する際の推奨事項は、第14章を参照してください。これは、「環境の正常な動作の検証」で実行した検証と同じです。

アップグレードが成功したら、「ユーザー・データの即時移行の開始」の説明に従って、ユーザー・データの自動移行を再開できます。

17.9 ユーザー・データの即時移行の開始

アップグレードした元の環境が正常に動作していること、および以前のリリースにロールバックしないことを確認したら、この手順を実行してユーザー・データの即時移行を開始します。

注意: このアクティビティを実行した後に以前のリリースへロールバックすると、移行したユーザー・データを元に戻すことはできません。

次の手順で、アップグレードおよび検証した環境（クローンまたは元の環境）でglobalparams.xml.upgradeファイルを特定し、MigrateUserDataTo1014パラメータの値をfalseからtrueに変更します。

停止時間ゼロのアップグレード後にユーザー・データの即時移行を開始する手順

1. アップグレードおよび検証した環境の宛先パスで、globalparams.xmlファイルを探します。次に例を示します。

   np611\ois_01\identity\oblix\apps\common\bin\globalparams.xml

2. ユーザー・データの移行を開始できるように、MigrateUserDataTo1014パラメータの値をfalseからtrueに変更します。次に例を示します。

   <NameValPair ParamName="MigrateUserDataTo1014" Value="True" />
   

3. アイデンティティ・サーバー・サービスを再起動します。

4. アップグレードした元のシステムが正常に動作していることを確認したら、「アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成」に進みます。

17.10 アップグレードした元のデプロイを使用するためのドメイン・ネーム・システムの再構成

アップグレードした元のシステムが完全に動作していることを十分に検証したら、クローン環境ではなく元の環境を使用するようにDNSを再構成できます。

ネットワーク・トラフィックをリダイレクトするようにDNSを再構成する方法は、このマニュアルの対象外です。

このタスクが終了したら、「一時ディレクトリ・サーバー・プロファイルの削除」に進みます。

17.11 一時ディレクトリ・サーバー・プロファイルの削除

元のWebPassを1つアップグレードした後、ディレクトリ・サーバーに格納されたポリシー・データへの書込み権限をアクセス・サーバーに与えるため、管理者は一時ディレクトリ・プロファイルを作成します。この一時ディレクトリ・プロファイルは、アクセス・サーバーがWebGatestatic.lstファイルに含まれる構成情報を収集し、WebGateのアップグレード時にディレクトリ・サーバーを更新する際に必要でした。

以前のWebGateをすべてアップグレードし、アップグレードしたWebGateが正常に動作することを確認した後は、この一時ディレクトリ・サーバー・プロファイルを削除できます。

注意: 使用環境内の以前のWebGateがすべてアップグレードされ、動作検証が完了するまではこのタスクを実行しないでください。

詳細は、「一時ディレクトリ・サーバー・プロファイルの削除」を参照してください。このタスクが完了したら、「下位互換性の回復」に進みます。

17.12 下位互換性の回復

アイデンティティ・サーバーおよびアクセス・サーバーのアップグレードの際は、以前のカスタム・プラグイン（およびWebGate、アクセス・ゲート）との下位互換性が有効になっていました。

以前のプラグイン、WebGateおよびアクセス・ゲートをすべてアップグレードし、システム全体のアップグレードが正常に完了したことを確認した後、下位互換性を回復することをお薦めします。

下位互換性を手動で回復するために実行する必要がある手順は、下位互換性を手動で有効化した手順に似ています。詳細は、第14章の次の各項を参照してください。

• アイデンティティ・サーバーの下位互換性の回復

• アクセス・サーバーの下位互換性の回復

このタスクが完了したら、「元のシステムのアップグレード後におけるクローン・システムの削除」に進みます。

17.13 元のシステムのアップグレード後におけるクローン・システムの削除

元の環境をアップグレードおよび検証し、アップグレードした元のシステムを使用するようにDNSを再構成したら、必要な場合にはクローン・システムを削除できます。

タスクの概要: クローン環境を削除する手順

1. 元の設定が正常に動作し、顧客にサービスを提供していることを確認します。

2. クローン・サービスおよびWebサーバーを停止します。

3. クローンのファイル・システム・ディレクトリをすべて削除します。

4. 元のシステム・コンソールで、クローン用のエントリを削除します。