| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
このマニュアル全体を通して紹介してきたガイドラインや手法に加え、この付録では、アップグレード・プロセスの間または後に使用できるトラブルシューティングの詳細を説明します。内容は次のとおりです。
各コンポーネントのアップグレード中に、問題が発生していないかどうかを通知するためのログ・ファイルが1つ以上生成されます。ログ・ファイルが生成される場合、アップグレード・プロセス中のメッセージにより、生成された各ログ・ファイルの名前と場所が表示されます。通常、アップグレード・ログ・ファイルは次の場所に生成されます。
Component_install_dir\identity|access\oblix\tools\migration_tools\toolname.log
ここで、\Component_install_dirはそのコンポーネントがインストールされた場所、identity|accessはコンポーネントが属するシステム（それぞれアイデンティティ・システムまたはアクセス・システム）、toolnameは、ログを生成するユーティリティの名前です。たとえば、生成されるログ・ファイルには次のようなものがあります。
各ログ・ファイルには、コンポーネントのアップグレード中に発生する特定のアクティビティに関する情報が含まれます。たとえば、ファイルのアップグレード、メッセージとパラメータのアップグレード、およびOracle Access Managerスキーマのアップグレードに対して、別個のログ・ファイルが生成されます。
一般的にログ・ファイルには、特定の問題のトラブルシューティングに使用できる次のような情報が含まれます。
障害の発生箇所の特定を容易にするため、それぞれのツールで実行されているステップのスナップショットが記録されます。
不正な値が渡されたことを容易に検出できるようにするため、ツールの実行中に渡された引数の詳細が記録されます。この記録は、ツールを手動で実行する必要がある場合にも役立ちます。
返されたエラーを容易に特定できるようにするため、リターン・コードの詳細が記録されます。特定のエラーについて、Oracleサポート・サービスに問い合せ、分析を依頼できます。
obmigrateparamsgツールで実行されるパラメータ・カタログおよびメッセージ・カタログのアップグレード中には、対応するログ・ファイル（obmigrateparamsg.log）にアップグレード済のファイルがすべて表示されます。この情報は、欠落したファイルを特定して、カスタマイズの失敗を検出するために役立ちます。
コンポーネント固有のログ・ファイルには、特定のコンポーネントに対して行われた変更が表示されます。これには、アップグレード中に発生した、コンポーネント固有の構成ファイルすべてやレジストリに関する変更が含まれます。この情報により、各コンポーネントのアップグレードの失敗を特定できます。
特定のログ・ファイル、その内容、および生成元となるツールの詳細は、付録C「アップグレード・プロセスおよびユーティリティ」を参照してください。
さらに、LDAP固有のエラーを記録するために次のファイルが作成されます。
アイデンティティ・サーバー・データの移行時に、error_output_fromversion_to_toversion_osd.ldifファイルがIdentityServer_install_dir\identity\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
ポリシー・マネージャ・データの移行時に、error_output_fromversion_to_toversion_psc.ldifファイルがPolicyManager_install_dir\access\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
スキーマおよびデータのアップグレード後にエラー「人オブジェクト・クラスが見つかりません。」が表示された場合、スキーマとデータのアップグレードに使用したマスターAccess Managerコンポーネントが、元のコンポーネントと同じトランスポート・セキュリティを使用していない可能性があります。
元のAccess Managerコンポーネントが、ディレクトリ・サーバーに対してSSL対応の通信を使用するようにインストールおよび構成されている場合、アクセス・システムのスキーマとデータをアップグレードするために追加するマスター・コンポーネントも、ディレクトリ・サーバーに対してSSL対応の通信を使用する必要があります。
詳細は、「インプレース・メソッドのマスターとして使用するための以前のAccess Managerの追加」を参照してください。
新しくインストールしたアクセス・サーバーが、以前のWebGateからの情報を処理しないように見える場合、下位互換性の問題があることが考えられます。
アップグレードされたアクセス・サーバーは、自動的に以前のWebGateとの下位互換性を持つようになります。ただし、新しい10g（10.1.4.0.1）のアクセス・サーバーを以前のWebGateが含まれる環境にインストールする場合は、新しくインストールしたアクセス・サーバーのglobalparams.xmlに、手動でIsBackwardCompatible" Value="trueと設定する必要があり、これによって、以前のWebGateやカスタム・アクセス・ゲートをはじめ、以前のプラグインやインタフェースとの通信も可能になります。「アクセス・サーバーの下位互換性」も参照してください。
以前の環境に監査およびアクセス・レポートが構成されていた場合、この機能を引き続き使用できるようにするには、特定の手順を実行する必要があります。実行しない場合、監査レコードに一部の言語（中国語、日本語など）の文字が正しく挿入されなくなることがあります。
グローバリゼーションの変更に対応するために必要な手順は、英語のみの環境でも必要であり、使用しているデータベースのタイプによって異なります。
|
注意: 既存のデータベース・インスタンスや表の単純なアップグレードや変更はサポートされていないため、それらの処理を行うと、既存データが永久的に切り捨てられ、失われます。 |
また、700より前のリリースからマスター・アイデンティティ・サーバー、スキーマおよびデータをアップグレードする場合、監査ファイル名はマスター・アイデンティティ・サーバーのパスに接頭辞を付けて変更されます。デプロイに複数のアイデンティティ・サーバーが含まれる場合、それぞれの監査ファイル名は、データのアップグレードが実行されるアイデンティティ・サーバーと同じアイデンティティ・サーバーのインストール・ディレクトリ・パスに接頭辞が付けられたものになります。この結果、アイデンティティ・サーバーのアップグレード中に元の構成が失われます。
次のタスクの概要では、監査およびアクセス・レポートの問題を修正するために必要な詳細を示します。
タスクの概要: 監査およびアクセス・レポートの問題の修正
使用環境に監査用のOracleデータベース・インスタンスが含まれている場合、データベース・キャラクタ・セットがAL32UTF8であることを確認できます。
「アイデンティティ・システムの監査およびアクセス・レポートのアップグレード」のすべての手順を確認および実行します。
「スキーマおよびデータのアップグレード後の監査ファイル名の変更」のすべてのステップを確認して実行します。
「アクセス・サーバーの監査およびレポートのアップグレード」のすべての手順を確認および実行します。
Latin-1以外のログインIDを使用しているユーザーは、カスタム・フォームの使用時にログインに失敗することがあります。この問題は、カスタム・ログイン・フォームに国際化されたデータがあるが、ログインのHTMLエンコーディングをUTF-8に更新していない場合に発生する可能性があります。
第4章「システム動作と下位互換性」で説明されているように、10g（10.1.4.0.1）では、フォーム・ベース認証で非ASCIIのログイン資格証明（ユーザー名/パスワード）がサポートされます。フォーム・ベース認証を10g（10.1.4.0.1）WebGateで使用するには、ログイン・フォームのキャラクタ・セット・エンコーディングをUTF-8に設定する必要があります。
|
注意: Basic認証は、非ASCIIのログイン資格証明では失敗します。非ASCIIのログイン資格証明には、フォーム・ベース認証を使用してください。Basic認証は、ASCIIのログイン資格証明に使用します。 |
フォーム・ベース認証に関する問題を修正するには、「フォーム・ベース認証のアップグレード」を参照してください。
問題: リリース6.1.1からのアップグレード後に、認可失敗のリダイレクトが意図したとおりに動作しない場合があります。
原因: リリース7.xで、未確定という認可の状態が新しく導入されました（認可の成功および失敗とは別の状態）。
解決方法: 「認可ルール」で「拒否」のルールを必ず明示的に指定し、「一般」パネルで「許可を優先」を「はい」に変更します。詳細は、「6.1.1からのアップグレード後に認可失敗のリダイレクトが正しく行われるようにするための作業」を参照してください。
問題: 以前の環境でチャレンジ・フレーズとレスポンスの属性が別のパネルにある場合、レスポンス属性が「プロファイル」ページに表示されません。
原因: 以前のリリースでは、チャレンジ・フレーズとレスポンスの属性をユーザー・マネージャ、グループ・マネージャおよび組織マネージャの「プロファイル」ページの別のパネルに配置できました。ただし、10g（10.1.4.0.1）では、チャレンジ・フレーズ属性とレスポンス属性を同じパネルに配置する必要があります。
解決方法: パネルの定義を更新して、レスポンス属性をチャレンジ属性と同じパネルに含める必要があります。詳細は、「単一パネルへのチャレンジ属性とレスポンス属性の配置」を参照してください。
アップグレード中に手動によるデータの移行（古いインスタンスから新規インスタンスへユーザー・データをエクスポートする推奨されない処理）を選択した場合、ロスト・パスワード管理のチャレンジ・レスポンスが正しく変換されないことがあります。その結果、一部のユーザーがロスト・パスワード機能を使用できなくなります。たとえば、「ロスト・パスワード管理」ページに正しいレスポンスが指定してもユーザーがパスワードをリセットできません。また、ユーザーの一部が新規レスポンスを設定できなくなる可能性もあります。これは基本的に、古いレスポンスが正しくないことから起こるエラーです。
チャレンジ・レスポンスの値は、CPResponseEncryptionKeyノードの共有シークレットで、RC6暗号化アルゴリズムを使用して暗号化されます。チャレンジ・レスポンスの暗号化キーには次の属性があります。
DN:
cn=CPResponseEncryptionKey,obcontainerId=encryptionKey,o=Oblix,<container>
Attribute: obSecretSize
Attribute: obSharedSecret
ここで、Attribute: obSharedSecretはバイナリ属性です。
|
注意: アップグレードされた環境で構成ツリーが移動したり、別のディレクトリ・サーバーが使用されていたりすると、共有シークレットが一致しない場合があります。 |
共有シークレットの扱いに注意します。共有シークレットをコピーして貼り付けることはできません。
元の構成ツリーに手動で共有シークレットを記述して、その共有シークレットを10g（10.1.4.0.1）の構成ツリーに追加します。
詳細は、「暗号化スキームおよび共有シークレット」と「以前のリリースとの互換性のチェック」を参照してください。
以前にカスタマイズしたプラグインが、アップグレード後に国際化データ（Latin-1以外のデータ）を処理している際に意図したとおり動作しない場合、プラグインの設計を変更して、UTF-8でエンコードされたデータを処理できるようにする必要があります。国際化データを送受信するには、以前のカスタム・プラグインでUTF-8エンコーディングが使用されるように設計を変更する必要があります。
また、SolarisおよびLinuxでは、オペレーティング・システムに付属するコンパイラとは関係なく、GCC v3.3.2 C++コンパイラを使用してリリース7.xより前のプラグインを再コンパイルする必要があります。
|
注意: リリース7.0のプラグイン、および実行可能ファイルとして実装されている以前のプラグインやスクリプト言語（Perlなど）を使用するプラグインは、アップグレード後の再コンパイルを必要としません。ただし、以前のプラグインで国際化されたデータを送受信するには、以前のプラグインをUTF-8エンコーディングで通信するように設計を変更する必要があります。 |
アップグレードされた環境において以前のプラグインの互換性を確保するには、次の項を参照してください。
カスタマイズされたグラフィカル・ユーザー・インタフェース（GUI）のイメージが壊れる、正しく表示されない、またはJavaScriptエラーが発生するのは、以前のカスタマイズがアップグレードされた環境に手動で組み込まれていないためです。
前述のように、カスタマイズされた.XSLスタイル・ファイル、イメージ、およびJavaScriptファイルは、アップグレードの際には移行されません。前のインストールで以前のXSLスタイルシートに大きな変更を加えた場合や、Oracle Access Managerのデフォルトのクラシック・スタイル以外のスタイルを使用する場合は、10g（10.1.4.0.1）のスタイルシート、イメージおよびJavaScriptファイルに対して変更内容を手動で反映する必要があります。
|
警告: 以前のスタイルシートを単純にコピーすると、新規のスタイルシートと連携するように設計された新機能の使用時に、スタイルシートのバグ・レポートが提示されたり、予期しない動作が発生することがあります。 |
カスタマイズされたスタイル、イメージおよび（メッセージ処理を含む）JavaScriptの移行の詳細は、第12章「アイデンティティ・システムのカスタマイズ内容のアップグレード」を参照してください。
前のインストールやアップグレードにおいてvpd.propertiesファイルが残ったままの場合、インストール・ディレクトリの指定時に問題が発生することがあります。この問題が起こる可能性があるのは、コンポーネント・ファイルが指定のインストール・ディレクトリに抽出された後で、コンポーネントのインストールが終了した場合（つまりユーザーが終了した場合）、さらにアンインストーラを実行せずにインストール・ディレクトリの削除のみを実行した場合です。この場合、一貫性のないvpd.propertiesファイルが残されます。
アップグレードを開始する前に、このファイルを削除する必要があります。
vpd.propertiesファイルを探します。次に例を示します。
Windows NTの場合: vpd.propertiesファイルはc:\WINNTにあります。
UNIXの場合: vpd.propertiesファイルはインストーラを実行しているユーザーのホーム・ディレクトリにあります。
このファイルを削除します。
アップグレード後に、Portal Insertsが意図したとおりに動作していないことがわかった場合、Portal InsertsのURLがUTF-8エンコーディングになるよう手動で更新する必要があります。また、PresentationXMLリクエストで国際化されたデータを使用するには、それらのリクエストでUTF-8エンコーディングを指定する必要があります。
Oracle Access Manager 10g（10.1.4.0.1）では、問合せ文字列のエンコーディングを検出できないため、エンコーディングがUTF-8であるとみなします。10g（10.1.4.0.1）のアイデンティティ・サーバーは、以前のPortal InsertsのLatin-1データを処理できません。10g（10.1.4.0.1）にアップグレードした後で、以前のPortal Insertsにおける問合せ文字列のエンコーディングをLatin-1からUTF-8に変更する必要があります。
使用環境でPortal Insertsとの互換性を確保するには、「以前のPortal Insertsとの互換性の確保」を参照してください。
アップグレードの後にこれらに関して問題が発生することはありません。詳細は次の項の説明を参照してください。
新しくインストールしたアイデンティティ・サーバーが、プラグインからの情報を処理しないように見える場合、下位互換性の問題があることが考えられます。
アップグレードされたアイデンティティ・サーバーは、自動的に以前のプラグインとの下位互換性を持つようになります。ただし、アップグレードされている環境に10g（10.1.4.0.1）のアイデンティティ・サーバーを新しくインストールする場合は、アイデンティティ・サーバーのoblixpppcatalog.lstのencodingフラグを手動で設定し、以前のプラグインおよびインタフェースとの通信を有効にする必要があります。「アイデンティティ・サーバーの下位互換性」も参照してください。
IdentityXMLコールで認証資格証明が必要となることがあります。WebPassを保護するWebGateがない場合は、基本の資格証明メカニズムが使用されます。このメカニズムは、ユーザー名とパスワードがSOAPリクエスト自体に埋め込まれた形式です。ただし、後からWebGateをインストールしたときは、SSOトークンによる認証を使用するようにIdentityXMLコールを変更する必要があります。
最初にOBSSOCookieを取得して、そのトークンを以降のすべてのコールに渡すように、IdentityXMLコールを変更する必要があります。この方法の例は、『Oracle Access Manager開発者ガイド』で紹介されています。デプロイされたIdentityXML関数のコード例とObSSOCookieの例で詳細を確認します。
Windows 2000 SP3でOracle Access Manager 5.2.xからのアップグレードの場合、アップグレード中にLDAP追加エラーを受け取ることがあります。このようなエラーを受け取った場合は、コンピュータがレプリケーションを承諾するように設定する必要があります。
Windows環境でLDAP追加エラーを受け取った場合の手順
Windows 2000のCDからサポート・ツールをインストールします。
dcdiagプログラムを実行し、必要に応じて/vコマンドライン・オプションを使用します。
レプリケーション・テストで失敗があるかどうかを確認します。
失敗が報告されている場合、次の手順でLDAP追加エラーのトラブルシューティングを行います。
フォレスト内のLDAP追加エラーのトラブルシューティング手順
クロックがドメイン・コントローラと同期していることを確認します。
コマンドラインで、フォレスト内のすべてのドメイン・コントローラについて次のように入力します。
net time /setsntp:machine name
同じコンピュータ名を使用して、時間誤差を最小限に抑えます。
レプリケーション用のグループ・ポリシーを次のように設定します。
ユーザーとコンピュータのツールを開きます。
ドメイン・コントローラに移動して右クリックし、「プロパティ」を選択します。
「グループ ポリシー」タブで、「既定のドメイン コントローラ ポリシー」、「コンピュータの構成」の順に選択し、「Windows の設定」をクリックします。
「セキュリティの設定」→「ローカル ポリシー」を選択してから、「ユーザー権利の割り当て」をクリックします。
右側にある「ネットワーク経由でコンピュータへアクセス」を選択します。
アクセス・リストにENTERPRISE DOMAIN CONTROLLERSを追加します。
サイトとサービスのツールを使用してレプリケートします。
「Sites」に移動して「Default-First-site-name」を選択してから、「Servers」を選択します。
サーバー名を選択します。
「NTDS 設定」を選択します。
右側の「<自動生成>」を右クリックして、「今すぐレプリケート」を選択します。
再度コマンドラインでdcdiagプログラムを入力し、レプリケーション・テストが正しく動作するようになったことを確認します。
これらの手順を実行すると、スキーマが適切に移行するようになります。
アップグレード中に、（既存のスキーマのリリース固有デルタ・ファイルを使用するのではなく）完全なスキーマのインストール・ファイルをすべてのディレクトリへアップロードして使用しようとすると、操作が失敗します。これは、スキーマがすでに存在し、また既存のスキーマのアップグレードに使用されるファイルでは既存のスキーマとその次のリリースとの差異のみが示されるためです。
たとえば、ADAMというディレクトリにインストールされている場合を考えます。リリース固有のデルタ・コンテンツ・ファイル（osd_650_to_700_schema_adam.ldifおよびpolicy_650_to_700_schema_adam.ldif）ではなく、完全な（新規インストールの）スキーマ・ファイル（ADAM_oblix_schema_add.ldifおよびADAM_user_schema_add.ldif）をアップロードしてインストールしようとすると、このプロセスは失敗します。これは、スキーマがすでに存在しているためです。
ガイドライン
スキーマおよびデータの自動アップグレードを受け入れることをお薦めします。
スキーマおよびデータを（たとえばADAMにおいて）手動で更新する必要がある場合は、ディレクトリ・スキーマのアップグレード用に用意された、リリース固有のデルタ・コンテンツ・ファイルのみを使用します。
システム・コンソールの属性構成アプレットに、mime_types関連のカスタマイズが反映されないことがあります。
アップグレード時には、同じParamNameを有する複数のエントリがmime_types（.xmlおよび.lst）ファイル内に存在する場合、これらのエントリは維持されません。
.xmlバージョンのファイルはアイデンティティ・サーバーで使用されます。.lstバージョンのファイルはWebPass Javaアプレットで使用されます。ファイルの両方のバージョンが一致する必要があります。また、ファイルの両方のバージョンが、IdentityServer_install_dirとWebPass_install_dirに存在する必要があります。
たとえば、元のmime_types.xmlファイル（IdentityServer_install_dir/identity/oblix/apps/admin/bin/mime_types.xml）には、次のNameValPair ParamNameが記述されています。
<NameValPair ParamName="application/postscript" Value="ai1"/> <NameValPair ParamName="application/postscript" Value="eps1"/> <NameValPair ParamName="application/postscript" Value="ps1"/>
この場合、新しくアップグレードされたファイルのエントリは次のようになります。
<NameValPair ParamName="application/postscript" Value="ai1"/> (CORRECT) <NameValPair ParamName="application/postscript" Value="eps"/> (INCORRECT) <NameValPair ParamName="application/postscript" Value="ps"/> (INCORRECT)
既存のユーザー・エントリについては、ユーザー・エントリとともにMIMEタイプがディレクトリ内へと格納されます。そのため、アップグレード後に、既存のユーザー・エントリやOracle Access Managerのインストールには影響はありません。
|
注意: .lstと.xmlの両方のバージョンのファイルが必要となります。不要になったMIMEタイプは、削除することも、今後の使用のために特定の属性に関連付ける新規のMIMEタイプとして追加することもできます。必要な作業は、アイデンティティ・サーバー用のmime_types.lstおよび.xmlファイルを編集して、これらをWebPass_install_dirにコピーし、以前のバージョンを上書きすることだけです。 |
MIMEタイプ・ファイルを正確かつアップグレード後の環境で使用可能なものにする手順
必要に応じてアイデンティティ・サーバーのmime_types.lstファイルを編集し、不要になったMIMEタイプを削除するか、今後の使用のために特定の属性に関連付ける新規のMIMEタイプとして追加します。
アイデンティティ・サーバーのmime_types.xmlファイルを編集し、編集済のmime_types.lstファイルと一致するようにします。
アイデンティティ・サーバーの両方のmime_typesファイル（.lstおよび.xml）をWebPass_install_dirにコピーして、以前のバージョンを上書きします。
問題:
以前のWebGateを10g（10.1.4.0.1）にアップグレードすると、「ページが見つかりません」というエラーが表示されます。
原因:
以前のアクセス・サーバーが完全に停止していない場合が考えられます。実行中のプロセスがある以前のアクセス・サーバーをアップグレードすると、以前のWebGateから10g（10.1.4.0.1）にアップグレードする際に問題が発生します。アップグレード前に問題を回避するには、「サーバーおよびサービスの停止」を参照してください。
解決方法:
関連するアクセス・サーバーを停止して実行中のプロセスを終了（たとえば、Solarisプラットフォームの場合はkill -9コマンドを使用）し、アクセス・サーバーを再起動します。
iPlanetディレクトリおよびNDSディレクトリは、索引をアップロードしなくても稼働します。ただし、検索のパフォーマンスが影響を受け、低下します。
詳細は、「ディレクトリ・サーバーの索引ファイルのアップロード」を参照してください。
アップグレード前に以前のアクセス・サーバーが簡易モードの場合、10g（10.1.4.0.1）へのアップグレード時にpassword.lstファイルがpassword.xmlに変換されません。その結果、起動時にコマンドラインのパラメータを使用してパスフレーズを渡さないかぎり、「サービス」ウィンドウでアクセス・サーバーを起動できません。また、簡易モードのWebGateをアップグレードしてWebサーバーを起動すると、次のエラーが表示される場合があります。
"Exception thrown during WebGate initialization"
Error^Oracle AccessGate API is not initialized.
最初の「アクセス・システム(Access System)」ページが表示されます。ただし、どのリンクをクリックしても「サーバー・エラー」（エラー番号なし）がブラウザに表示され、コンソールでエラーが繰り返されます。そのため、システムにアクセスできません。
アップグレードされた領域に、更新されたpassword.xmlファイルはありません。
|
注意: 10g（10.1.4.0.1）より前のリリースでは、パスワード・ファイルの名前と形式はpassword.lstです。リリース10g（10.1.4.0.1）から、その名前と形式はpassword.xmlになりました。 |
次に、同じ簡易モードのパスワードがアイデンティティ・システムで使用される場合のこの問題に対する回避策を示します。この場合、「同じ簡易モードのパスワードがアイデンティティ・システムで使用される場合の回避策」の手順に従って、アップグレードされたアイデンティティ・サーバーからアップグレードされたアクセス・サーバーおよびWebGateにpassword.xmlファイルをコピーできます。簡易モードの選択後、すぐにパスワードが求められます。
ただし、アイデンティティ・サーバーとアクセス・サーバーでパスワードが異なる場合、次の手順にスキップします。ここでも、簡易モードの選択後すぐにパスワードが求められます。
同じ簡易モードのパスワードがアイデンティティ・システムで使用される場合の回避策
同じ簡易モードのパスワードがアイデンティティ・システムで使用される場合、password.xmlファイルを次のようにコピーします。
アクセス・サーバーを起動します。
WebGateのWebサーバーを再起動します。
アクセス・システムの簡易モードのパスワードがアイデンティティ・システムの簡易モードのパスワードと異なる場合、次のツールおよび手順を使用してパスワードを変更する必要があります。
簡易モードのパスワードがアイデンティティ・システムとアクセス・サーバーで異なる場合の回避策
configureAAAserverがあるフォルダに移動します。具体的には次のとおりです。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
次の実行可能ファイルを実行します。
configureAAAServer chpasswd AccessServer_install_dir
画面に表示されるプロンプトに従います。
アクセス・サーバーを再起動します。
簡易モードのパスワードがアイデンティティ・システムとWebGateで異なる場合の回避策
次のディレクトリに移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate
WebGate_install_dirは、WebGateがインストールされているディレクトリです。
次のコマンドを実行します。
configureWebGate -i WebGate_install_dir -t WebGate -k
-kオプションを指定すると、簡易モードまたは証明書モードのトランスポート・セキュリティの場合のみパスワードが求められます。
画面上のプロンプトに従います。
WebGateのWebサーバーを再起動します。
configureAAAServerおよびconfigureWebGateツールの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
この項にあるリリース番号は説明のみを目的としており、関連する情報は、付録E「Windows 2000上でのSun Webサーバー・バージョン4からバージョン6へのアップグレード」にあります。以前のOracle Access Managerリリースからリリース6.1.1への中間アップグレードに関する詳細は、このマニュアルの対象外です。Oracle Access Manager 6.1.1より前のリリースからアップグレードを開始する場合は、その前にOracleサポート・サービスにお問い合せください（http://www.oracle.com/support/contact.html）。
リリース6.0のSun Webサーバーへのアップグレード、およびOracle Access Manager 7.0のアイデンティティ・システムへのアップグレードの後には、問題がいくつか発生する可能性があります。
アップグレード中に、obj.confに次のエントリが追加されます。
NameTrans fn="pfx2dir" from="/identity/oblix" dir="G:/70/webpass/identity/oblix" name="idoblix" …… <Object name="idoblix"> PathCheck file=".nsconfig" fn="load-config" descend="1" </Object>
ただし、バージョン4.1のWebサーバーにインストールされているOracle Access Manager 5.2のアイデンティティ・システムでは、obj.confに前述の下線の付いたエントリが含まれません。バージョン4のWebサーバーがリリース6に移行され、Oracle Access Managerがリリース7.0にアップグレードされても、obj.confにこれらのエントリは含まれません。
4.1のiPlanetインスタンスでcgiを有効にしている場合、URLの接頭辞、およびスクリプトのディレクトリ設定は移行の際にも正確に引き継がれます。このディレクトリがバージョン4.1のドキュメント・ルートの下にある場合、このディレクトリを次の方法で変更することもできます。
リリース6.0のWebサーバーの管理コンソールを使用（「Class manager」→「Programs」）
または、obj.confの適切な行を手動で編集
6.0のobj.conf内の1行を例として次に示します。
NameTrans fn="pfx2dir" from="/cgi-bin" dir="D:/NSWS/Server4/docs/cgi-bin"
name="shellcgi"
|
注意: 古いインストール領域（この場合、D:/NSWS/Server4）で移行後のobj.confを検索して、6.0のサーバーのインスタンスが古いインストール領域を参照しないようにすることをお薦めします。 |
Webサーバーのconfigディレクトリにあるjvm12.confファイルでは、移行後に次の行が見つかることがあります。このプロパティには古い（4.1の）ビットに対する参照が含まれ、これは正しく移行されていません。
jvm.classpath=D:/NSWS/Server4/plugins/samples/servlets/beans.10/SDKBeans10.jar; D:/NSWS/Server4/plugins/samples/servlets/beans/SDKBeans.jar;D:/NSWS/Server4/bin /https/jar/Bugbase.jar;D:/NSWS/Server4/bin/https/jar/Calljsac.jar
この行は次のように書き換える必要があります。
jvm.classpath=G:/iPlanet6WS/plugins/servlets/examples/legacy/beans.10/SDKBeans 10.jar
|
注意: 他のjarはリリース6.0のWebサーバー構成に含まれることはなく、意図的に除外されます。 |
古いドキュメント・ルートにあったファイルやフォルダはすべて、新しいドキュメント・ルートの同じ構造内に手動でコピーする必要があります。これは、新規のWebサーバー・インスタンスが古いインスタンスとまったく同じ動作をするようにする場合に重要です。
前述のとおり、バージョン4.1およびバージョン6.0のどちらの管理コンソールでもサーバーを操作できます。これは、6.0のバイナリを使用して動作します。管理コンソールでは、単純にWindows NTのサービスを利用してサーバーの起動と停止が行われます。
4.1のコンソール以降では、古いインスタンスを削除すると、サービスおよびバージョン4.1のファイルも削除されます。この場合、サービスが削除されているため、6.0のコンソールでもインスタンスを操作できません。これは望ましい状態ではないため、次の手順が必要になります。
サーバーを停止します（バージョン4.1またはリリース6.0のコンソール、またはNTサービスを使用）。
ログなどを保持するには、古いログ・ディレクトリを手動でバックアップします。
バージョン4.1のインスタンス・ディレクトリを手動で削除します。
バージョン4.1の管理コンソールを再起動します。
|
注意: アップグレードされたサーバーは、バージョン4.1の管理コンソールで管理できなくなります。 |
これで、このプロセスは完了です。
スキーマおよびデータのアップグレード後に、Oracle Internet Directoryに適切な索引をアップロードしないと、ユーザーがログインできなくなります。
詳細は、「ディレクトリ・サーバーの索引ファイルのアップロード」を参照してください。
NetPointWASRegistryを有効にするには、registryTesterプログラムを実行して、NetPointWASRegistryの登録とアイデンティティ・システムへの正常な接続を確認する必要があります。registryTesterの実行に必要なファイルはWAS_install_dirで入手が可能でした。ただし、現在このファイルはWebSphere用Oracle Access Managerコネクタにバンドルされていません。そのため、registryTesterはWebSphere 6.1用Oracle Access Managerコネクタで実行できません。
回避策: 外部ソース（WebSphere Application Server 6.0のインストール・ディレクトリなど）からsas.jarをコピーして、クラスパスを適宜設定します。次に例を示します。
set CLASSPATH=.:${CLASSPATH}:${INSTALL_DIR}/oblix/lib/NetPointWASRegistry.jar
:${INSTALL_DIR}/oblix/lib/jobaccess.jar
:${WAS_INSTALL_DIR}/lib/wssec.jar
:${WAS_INSTALL_DIR/lib/sas.jar
:${WAS_INSTALL_DIR}/lib/j2ee.jar
:${WAS_INSTALL_DIR}/java/jre/lib/security.jar
:${WAS_INSTALL_DIR}/java/jre/lib/xml.jar
WeblogicおよびWebSphereコネクタが簡易モードで実行されている場合、簡易モードで実行中のWeblogic用Oracle COREidリリース7.0.4コネクタを10g（10.1.4.0.1）にアップグレードしても、password.xmlファイルが移行されません。この場合、Weblogic（またはWebSphere）サーバーの起動時にユーザー名とパスワードの他にNetPointトランスポート・パスワードが求められます。
回避策: アップグレードを開始する前に、次の内容をconnector_ install_dir/NetPointSecuProvForWeblogic/oblix/tools/migration_toolsディレクトリのasdk_base_files.lstファイルに追加する必要があります。移行が正常に終了したことを示すメッセージを受け取ったら、NetPointProvidersConfig.propertiesおよびmbean.jarファイルを、アップグレードされたディレクトリからWeblogicポータル・ドメインにコピーします。
file:/oblix/config/password.lst
アップグレードを開始する前に、次の内容をconnector_ install_dir/NetPointSecuProvForWeblogic/oblix/tools/mig ration_toolsディレクトリのasdk_base_files.lstファイルに追加します。
file:/oblix/config/password.lst
Oracle COREidリリース7.0.4から10g（10.1.4.0.1）へのアップグレードを開始し、アクセス・サーバーSDKもアップグレードします。
移行が正常に終了したことを示すメッセージを受け取ったら、NetPointProvidersConfig.propertiesおよびmbean.jarファイルを、アップグレードされたディレクトリからWeblogicポータル・ドメインにコピーします。
WebLogicを再起動します。
詳細は、「統合コネクタのアップグレードの終了」を参照してください。
WebSphere Application ServerおよびPortal Server用の統合コネクタのインストール中には、次のファイルを追加するため、WebSphereクラスのディレクトリ・パスを指定するように求められます。
jobaccess.jarおよびNetPointWASRegistry.jar
一方、WebSphere Application ServerおよびPortal Server用の統合コネクタのアップグレード時には、このディレクトリの指定は求められません。かわりに、次の例に示す3つのファイルをアップグレード後に手動でディレクトリにコピーしてから、WebSphere Application ServerおよびPortal Serverを再起動する必要があります。
リリース6.5のインストールにはNetPointCMR.jarはありません。
詳細は、「サード・パーティ製品の統合コネクタのアップグレード」を参照してください。
この項では、停止時間ゼロのメソッドを使用してアップグレードを実行する場合に固有の問題について説明します。停止時間ゼロのアップグレード・メソッドを使用していない場合はこの項をスキップしてください。内容は次のとおりです。
問題: アップグレード後のクローン化されたWebコンポーネントのWindowsレジストリが更新されません。
クローン化されたCOREidサーバーをアップグレードして、サービスを正常に開始すると、Windowsレジストリはアップグレードされたクローンの詳細とともに更新されます。ただし、Microsoft IIS 5.0がWebサーバーの場合、クローン化されたWebPass（またはAccess Manager）のアップグレード後にレジストリが更新されません。この場合、コンポーネントはリリース10.1.4にアップグレードされて以前のレジストリ・キーは削除されますが、10.1.4キーには新しいエントリがありません。
原因:
10.1.4.2.0のパッチが適用されたWebコンポーネントをコピーしてクローンを作成したときに、そのコンポーネントのtransfilterが登録されなかったことが原因です。この結果、その場所がレジストリ・エディタで使用できません。
回避策: 次のステップを実行します。
アップグレードされたクローンのCOREidサーバー・サービスを停止します。
アップグレードされたWebコンポーネントとともに実行しているIIS v5のWebサーバーを停止します。
元のCOREidサーバー・ディレクトリの名前を変更します。次に例を示します。
変更前: np611\ois_01\identity
変更後: orig_np611\ois_01\identity_1014
元のWebコンポーネント・ディレクトリの名前を変更します。
変更前: np611\webcomponent_01\identity
変更後: orig_np611\webcomponent_01\identity_1014
10.1.4.0.1のアイデンティティ・サーバーおよびWebPassをインストールし、10.1.4.2.0パッチ・セットを次のように適用します。
「宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得」の手順を参考として使用します。
10.1.4.0.1のアイデンティティ・サーバーのインストール先として、元のCOREidサーバーのインストール・ディレクトリを指定します。次に例を示します。
インストール先: np611\ois_01\identity
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)の説明に従って、10g（10.1.4.2.0）パッチ・セットを10.1.4.0.1のアイデンティティ・サーバーに適用します。
10.1.4.0.1 WebPassのインストール先として、元の（現在は名前が変更されている）WebPassのインストール・ディレクトリを指定します。次に例を示します。
インストール先: np611\webcomponent_01\identity
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)の説明に従って、10g（10.1.4.2.0）パッチ・セットを10.1.4.0.1 WebPassに適用します。
第15章の説明に従って、使用環境に合せた残りの停止時間ゼロのアップグレード・タスクに進みます。
この項では、Windowsプラットフォームにインストールされている元のコンポーネント・インスタンスのアップグレード後にロールバックする場合のWindowsレジストリ・エントリの回復方法について説明します。この項は、他のプラットフォームには関係ありません。
ロールバック手順を確実かつ効率的に実行するには、インスタンスのアップグレード・アクティビティを開始する直前に、元のインスタンスごとにWindowsレジストリ・エントリをバックアップすることをお薦めします。つまり、元のファイル・システムのパス名を変更して停止時間ゼロのアップグレードのソースを作成する前に、元のWindowsレジストリ・エントリをバックアップする必要があります。実際、各アップグレード手順のステップ1で、第8章で詳細に説明されている特定の準備タスクを実行するよう指示しています。この準備タスクでは、ファイル・システム・ディレクトリ、Webサーバー構成ファイルおよびWindowsレジストリの詳細のバックアップを実行します。
ロールバックする際に、次の方法で元のレジストリ・エントリを回復できます。
推奨方法: 元のインスタンスのファイル・システムのパス名を変更してアップグレードのソースを作成する前に、元のレジストリ・エントリをバックアップします。
各インスタンスのアップグレード・アクティビティを開始する前に、（クローン・インスタンスであるか元のインスタンスであるかにかかわらず）インスタンスのレジストリの詳細をエクスポートすることをお薦めします。これにより、元のリリースにロールバックする場合に、レジストリ・エントリをインポートできます。
代替方法: ロールバック・タスク時に元のインスタンスを再インストールします。
ロールバック中にインポートするバックアップのレジストリ・エントリがない場合は、エントリを自動的に回復する方法はありません。この場合は、元のコンポーネントのインストールを新たに開始する必要があります。レジストリ・エントリを作成したら、インストール・プロセスを終了して、アップグレード前に名前を変更したソースから元の構成の詳細をコピーします。詳細は、次の手順を参照してください。
次の手順では、元のレジストリ・エントリのバックアップ・コピーがない場合の代替方法の使用について説明します。この手順では、次のようなサンプル・パス名が使用されます。
元のインスタンス（アップグレード先）: np611\ois_01\identity
ソース（名前を変更した元のインスタンス）: np611\ois_01\identity_source
元のインスタンスへのロールバックで、インポートするバックアップ・コピーがない場合にWindowsレジストリ・エントリを生成する手順
クローンの設定が機能し、元のWebGateによって顧客にサービスが提供されていることを確認します。
元のサーバーを停止します。
インスタンスのアップグレード用に作成されたソースのパスが元のパスと異なることを確認します。
ソース: np611\ois_01\identity_source
元のインスタンス（リリース10.1.4パッチ・セット1（10.1.4.2.0）が適用された10g（10.1.4.0.1）コンポーネントのライブラリおよびファイル）用に作成されたアップグレード先のファイル・システムを削除（または名前変更）します。
削除（または名前変更）されるアップグレード先: np611\ois_01\identity
元のコンポーネント・リリースの再インストールを開始して、レジストリ・エントリを次のように作成します。
名前を変更したソースのホスト・コンピュータで元のコンポーネント・インストーラを見つけて起動します。例: NetPoint6_EN_sparc-s2_COREid_Server
元のインスタンスと同じインストール・パスを指定します。例: np611\ois_01
インストールするコンポーネントのタイプに応じて、ステップ5またはステップ6に進みます。
COREidまたはアクセス・サーバーの場合:
元のインスタンスと同じトランスポート・セキュリティの詳細を指定します。
元のインスタンスと同じ構成の詳細（元のCOREidまたはアクセス・サーバーの名前、ホスト名およびポート）を指定して、レジストリ・エントリを作成します。
サービス名が存在することが通知されたら、「取消」をクリックしてインストール・プロセスを終了します。
ステップ7に進みます。
WebPass、Access ManagerまたはWebGateの場合: ライブラリとファイルが抽出されたら、インストールを取り消します。レジストリ・エントリと新しいディレクトリが作成されます。
すべてのコンポーネント: 次の点に注意して、新たにインストールされたファイル・システムを、名前変更したソースで置き換えます。
新たにインストールされたファイル・システムから、新しい\identity（または\access）フォルダとすべてのサブディレクトリを削除します。次に例を示します。
新たにインストールされたファイル・システムからの削除: \identity（または\access）
名前変更したソースから、\identity（または\access）フォルダおよびすべてのサブディレクトリをコピーします。次に例を示します。
名前変更したソースからのコピー: \identity_source
新たにインストールされたファイル・システムに、コピーしたフォルダを追加します。次に例を示します。
新しいファイル・システムへの追加: \identity_source
新たにインストールされたファイル・システムで、元の名前と一致するように、コピーしたフォルダの名前を必要に応じて変更します。次に例を示します。
新しいファイル・システムでの変更: \identity_source
変更後: \identity
アクセス・サーバーの場合: 次の点に注意して、アクセス・サーバーのバックアップ\configディレクトリをコピーして、新たにインストールされたアクセス・サーバーのファイル・システムにこのディレクトリを追加します。次に例を示します。
元のインスタンスを再構成する前に作成されたアクセス・サーバーのバックアップ\configディレクトリを見つけ、コピーします。次に例を示します。
コピー元: backup_aaa\config
新たに名前変更されたアクセス・サーバー・ファイル・システムに、コピーした\configフォルダを追加します。次に例を示します。
新しいファイル・システムへの追加: np611\access\oblix\config
WebPass、Access ManagerまたはWebGateの場合: インスタンスのアップグレード前に作成されたバックアップ・コピーを使用して、元のWebサーバー構成ファイルを回復します。次に例を示します。
元のコンポーネントの、アップグレードされたWebサーバー構成ファイルを削除（または名前変更）します。
以前のWebコンポーネントのエントリを含むWebサーバー構成ファイルのバックアップ・コピー（元のインスタンスのアップグレード前に作成されたもの）を回復します。
Webサーバー・インスタンスを再起動します。
COREidまたはアクセス・サーバーの場合: サービスを再開します。
元のコンポーネントをすべて起動したら、元の設定をテストして、その設定が完全に機能することを確認します。
