1. Oracle Identity Managerのアップグレード
  2. アップグレード前の要件

2 アップグレード前の要件

Oracle Identity Manager 12c (12.2.1.3.0)へのアップグレードを開始する前に、バックアップ、現在の環境のクローニング、システムが動作保証された要件を満たしていることの確認など、アップグレード前のタスクを実行する必要があります。

  • Oracle Fusion Middlewareアップグレード前のチェックリスト
    アップグレードの成功と限定的な停止時間を実現するために、アップグレードの開始前に、このチェックリストのタスクを実行してください。
  • 完全なバックアップの作成
    アップグレードを開始する前に、Oracleホーム、Middlewareホーム、およびOracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なすべてのファイルをバックアップします。
  • 個別のBusiness Intelligence Publisherインストールの作成
    Oracle Identity Manager 11gには、Oracle Identity Managementレポートの生成に使用される組込みOracle BI Publisher実装が含まれています。Oracle Identity and Access Management 12c (12.2.1.3.0)では、専用のOracle Business Intelligence (BI) Publisherインストールを使用することをお薦めします。
  • Oracle HTTP Serverのアップグレード
    Oracle Identity and Access Managementのデプロイメントが、Oracle Identity Governanceに送信されるリクエストが経由するOracle HTTP Serverの背後に存在する場合は、Oracle HTTP Serverのアップグレードを検討してください。
  • テストのための環境のクローニング
    実際の環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを必ず確認してから、環境をアップグレードします。
  • 動作保証およびシステム要件の確認
    ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。
  • 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新
    アップグレードされる環境で強化された暗号化(Advanced Encryption Standard (AES 256など))を使用する予定の場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。
  • 未使用データのパージ
    アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。
  • Upgrade Assistantを実行するための非SYSDBAユーザーの作成
    Upgrade Assistantを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。
  • アップグレードに対応可能な既存のスキーマの特定
    このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。
  • Oracle Identity Managerのデータベース・パラメータの更新
    Oracle Identity Managerを12c (12.2.1.3.0)にアップグレードする前に、いくつかのデータベース・パラメータを検証および更新する必要があります。
  • Oracle Identity Managerのコネクタの更新
    既存のコネクタがOracle Identity Manager 12c (12.2.1.3.0)でサポートされていない場合は、更新します。
  • ノード・マネージャの停止
    アップグレード・プロセスを開始する前に、すべてのローカルおよびリモートのノード・マネージャを停止していることを確認してください。
  • Oracle Identity Managerのアップグレード前レポートの生成および分析
    Oracle Identity Managerのアップグレード・プロセスを開始する前にアップグレード前レポート・ユーティリティを実行し、すべての問題にレポートで提示されている解決策を使用して対処します。

Oracle Fusion Middlewareアップグレード前のチェックリスト

アップグレードの成功と限定的な停止時間を実現するために、アップグレードの開始前に、このチェックリストのタスクを実行してください。

アップグレードはサーバーの停止中に実行されます。このチェックリストでは、重要で、多くの場合時間のかかるアップグレード前タスクのうち、停止時間を限度内にとどめるためにアップグレード前に実行できるタスクを特定します。アップグレード・プロセスを開始する前の準備を十分に行うほど、オフラインの時間を減らすことができます。

ノート:

実行するアップグレード前の手順は、既存のシステムの構成、アップグレードするコンポーネントおよびアップグレードと構成プロセスの最後に作成する環境によって異なります。構成またはユースケースに該当するタスクのみを実行してください。

Oracle Identity ManagerとOracle Access Managerが異なるドメインにあることを確認します。同じドメインにある場合は、複数のドメインに分ける必要があります。詳細は、「Oracle Identity Managementアプリケーションの複数のドメインへの分離」を参照してください。

表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク

タスク 説明

必須

既存の環境の完全なバックアップを作成します。

Oracleホーム、Middlewareホーム、およびアップグレード対象のスキーマが含まれるデータベースを含め、システムに重要なすべてのファイルをバックアップします。アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再度開始する必要があります。

「完全なバックアップの作成」を参照してください。

省略可能

使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。

システム・ファイルの完全なバックアップを作成する他に、本番環境のクローンも作成することをお薦めします。この環境は、アップグレードをテストするために使用されます。

「テストのための環境のクローニング」を参照してください。

必須

サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。

注意: サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。

ハードウェアとソフトウェア(オペレーティング・システムも含む)の構成が最新の動作保証および要件でサポートされていることを確認します。また、12c製品のディストリビューションをインストールする前に、サポート対象バージョンのJDKを使用していることを確認してください。

動作保証要件は頻繁に更新されるため、この情報は、アップグレードの開始直前に確認することをお薦めします。

ノート:
  • アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。
  • コンポーネントは、Oracleコンポーネントであるか依存コンポーネントであるかにかかわらず、1つずつアップグレードします。たとえば、OUD、OIM、OAM、オペレーティング・システム、データベースおよびハードウェアをすべて同時にアップグレードしないでください。

動作保証とシステム要件の確認に関する項を参照してください。

32ビット・オペレーティング・システムの場合にのみ必須

アップグレードする前に、64ビット・オペレーティング・システムに移行します。

これは、現在サポート対象外の32ビット・オペレーティング・システムを実行している場合にのみ必要になります。

「32ビットから64ビット・オペレーティング・システムへの移行」を参照してください。

省略可能

強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。

強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

「強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新」を参照してください。

省略可能

アップグレードの前に、古いデータまたは使用しないデータを削除します。

パフォーマンスを最適化するために、アップグレードした環境では使用されないデータとオブジェクトはパージすることをお薦めします。

「未使用データのパージ」を参照してください。

省略可能

Upgrade Assistantを実行するための非SYSDBAユーザーを作成します。

Upgrade Assistantを実行するための、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理者の権限を持たずにUpgrade Assistantを実行できます。

「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

省略可能

使用可能なスキーマのリストを確認します。

スキーマ・バージョン・レジストリを問い合せて、スキーマ情報を表示します。

「アップグレードで使用可能な既存のスキーマの識別」を参照してください。

必須

データベース・パラメータを更新します。

「Oracle Identity Managerのデータベース・パラメータの更新」を参照してください。

必須

Oracle Identity Managerのコネクタの更新

「Oracle Identity Managerのコネクタの更新」を参照してください。

省略可能

アップグレード・プロセスを開始する前に、すべてのローカルおよびリモートのノード・マネージャを停止します。

「ノード・マネージャの停止」を参照してください。

必須

アップグレード前レポート・ユーティリティを実行します。

「Oracle Identity Managerのアップグレード前レポートの生成および分析」を参照してください

親トピック: アップグレード前の要件

完全なバックアップの作成

アップグレードを開始する前に、Oracleホーム、Middlewareホーム、およびOracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なすべてのファイルをバックアップします。

バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表を含める必要があります。これにより、アップグレードが失敗したときに、コンテンツをアップグレード前の状態にリストアできるようになります。

ノート:

Upgrade Assistantの「前提条件」画面では、アップグレードを実際に進める前に、バックアップが実行されていることについての確認を求められます。ただし、Upgrade Assistantは、バックアップが作成されていることを確認しません。
参照:
  • スキーマ・バージョン・レジストリ表のバックアップ
    システム・バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表またはFMWREGISTRY.SCHEMA_VERSION_REGISTRY$表を含める必要があります。
  • カスタマイズされたドメイン設定および環境設定のメンテナンス
    アップグレード前の環境において、ドメインで生成されたスクリプト、サーバー起動スクリプトまたは構成ファイルを変更した場合は、これらの変更内容がインストール、ドメイン・アップグレードおよび再構成の操作中に上書きされることに注意する必要があります。カスタマイズしたファイルは共有ライブラリの場所に保存し、アップグレード後にもそれらを継続して使用できるようにします。

親トピック: アップグレード前の要件

スキーマ・バージョン・レジストリ表のバックアップ

システム・バックアップには、SYSTEM.SCHEMA_VERSION_REGISTRY$表またはFMWREGISTRY.SCHEMA_VERSION_REGISTRY$表を含める必要があります。

SYSTEM.SCHEMA_VERSION_REGISTRY$表には、各Fusion Middlewareスキーマの行があります。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。Upgrade Assistantを実行する前に、既存のデータベース・スキーマおよびスキーマ・バージョン・レジストリを必ずバックアップします。

ノート:

Upgrade Assistantを使用してスキーマをアップグレードする前に、完全なデータベースのバックアップを実行する必要があります。アップグレード中に、バックアップが実行されていることを確認する必要があります。

親トピック: 完全なバックアップの作成

カスタマイズされたドメイン設定および環境設定のメンテナンス

アップグレード前の環境で、ドメインで生成されたスクリプト、サーバー起動スクリプトまたは構成ファイルを変更した場合、これらの変更内容がインストール、ドメイン・アップグレードおよび再構成の操作中に上書きされることに注意する必要があります。カスタマイズしたファイルは共有ライブラリの場所に保存し、アップグレード後にもそれらを継続して使用できるようにします。

どのドメインのインストールにも、動的に生成されたドメインおよびサーバーの起動スクリプト(setDomainEnvなど)が含まれています。これらのファイルは、インストールとアップグレードのプロセスで新しいバージョンに置き換えられます。カスタムのドメインレベルの環境設定を維持する場合は、スクリプトを直接変更するのではなく、アップグレード前に、カスタムのドメイン情報を保存しておく個別のファイルを作成することをお薦めします。

たとえば、ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のコマンドライン・オプションを指定する、または追加の環境変数を指定するなどの構成が可能です。 packおよびunpackコマンドを使用する際、このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存されてリモート・サーバーに継承されます。

次の例は、setUserOverridesファイルでの起動のカスタマイズを示しています。
# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command-line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

サーバーの起動中にsetUserOverridesファイルが存在する場合、このファイルが起動シーケンスに含まれ、このファイルにオーバーライドがあれば、有効になります。setUserOverridesファイルは、DOMAIN_HOME/binディレクトリに格納する必要があります。

ノート:

アップグレード前に、setUserOverridesスクリプトを作成できない場合は、Oracle WebLogic Serverのアップグレードの起動スクリプトへのカスタマイズの再適用の説明に従って、設定を再適用する必要があります。

親トピック: 完全なバックアップの作成

個別のBusiness Intelligence Publisherインストールの作成

Oracle Identity Manager 11gには、Oracle Identity Managementレポートの生成に使用される組込みOracle BI Publisher実装が含まれています。Oracle Identity and Access Management 12c (12.2.1.3.0)では、専用のOracle Business Intelligence (BI) Publisherインストールを使用することをお薦めします。

Oracle Identity and Access Management 12c (12.2.1.3.0)にアップグレードすると、組込みBI Publisherが削除されます。レポートをスタンドアロンのOracle BI Publisherに移行する必要があります。

詳細は、次のガイドを参照してください:

親トピック: アップグレード前の要件

Oracle HTTP Serverのアップグレード

Oracle Identity and Access Managementのデプロイメントが、Oracle Identity Governanceに送信されるリクエストが経由するOracle HTTP Serverの背後に存在する場合は、Oracle HTTP Serverのアップグレードを検討してください。

手順については、『Oracle HTTP Serverのアップグレード』を参照してください。

親トピック: アップグレード前の要件

テストのための環境のクローニング

実際の環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを必ず確認してから、環境をアップグレードします。

テストのための環境のクローニングをお薦めしますが、必須ではありません。

アップグレードは元に戻せません。ほとんどの場合、エラーが発生したときには、アップグレードを中止してバックアップから環境全体をリストアし、アップグレード・プロセスを最初からやり直す必要があります。

ノート:

すべてのコンポーネントおよびオペレーティング・システムのクローニング手順について、このドキュメントでは説明していません。クローニング手順は、コンポーネントおよびオペレーティング・システムに固有のものです。概略としては、アップグレード前のバージョンのコンポーネント・ドメインをテスト・マシンにインストールし、リポジトリ作成ユーティリティ(RCU)を使用して必要なスキーマを作成し、アップグレードを実行します。
クローン環境でアップグレードを実行すると、次のようなメリットもあります:

  • アップグレードに関する問題を明らかにし、修正します。

  • エンドツーエンドのアップグレードを完了させる練習をします。

  • アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。

  • アップグレードの完了までに必要な時間を理解します。

  • データベース・リソースの使用(一時表領域、プログラム・グローバル領域(PGA)など)について理解します。

ノート:

クローン環境でアップグレード前の準備状況チェックを実行して、データに関する潜在的なアップグレードの問題を識別できますが、アップグレードを確実に成功させるには、クローン環境で完全なテスト・アップグレードを実行する必要があります。

クローン・アップグレードを実行する手順は、「Oracle Identity Managerのアウトオブプレース・クローン・アップグレードの実行」を参照してください。

親トピック: アップグレード前の要件

動作保証およびシステム要件の確認

ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。

ノート:

動作保証、システム要件および相互運用性情報を確認する場合、特に32ビットまたは64ビットのシステム要件を確認するようにしてください。32ビットまたは64ビットの環境専用として設計されているソフトウェアを明示的にダウンロードすることが重要です。

親トピック: アップグレード前の要件

環境が動作保証要件を満たしていることの確認

Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品を、サポートされているハードウェアおよびソフトウェア構成上にインストールすることを確認してください。

新しい動作保証要件が確認されると、それらはすぐに適切な動作保証に関するドキュメントに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、オラクルの技術リソースで提供されています。12c (12.2.1.3.0)の動作保証マトリックスを参照してください。

親トピック: 動作保証およびシステム要件の確認

システム要件と仕様の確認

ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

Oracle Fusion Middlewareのシステム要件と仕様のドキュメントを使用して、動作保証要件を満たしていることを確認してください。たとえば、12c (12.2.1.3.0)の動作保証マトリックスに、目的の製品が64ビットOracle Linux 7にインストールすることで動作保証されると示されている場合は、Oracle Linux 7システムが最低限必要な仕様(ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチ、その他のオペレーティング・システム固有のアイテムなど)を満たしていることを確認します。このドキュメントは必要に応じて更新され、オラクルの技術リソースのドキュメント・ライブラリの外部に置かれます。

ノート:

アップグレード準備の一環としてOracle Fusion Middlewareリリース12cソフトウェアをインストールする際は、アップグレード前の既存のOracle Fusion Middlewareソフトウェアのインストールおよび構成に使用したものと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これにより適切な所有者とグループが新しいOracle Fusion Middleware 12cのファイルとディレクトリに確実に適用されます。

32ビット環境を実行している場合は、追加のステップのセットを実行する必要があります。

親トピック: 動作保証およびシステム要件の確認

32ビットから64ビット・オペレーティング・システムへの移行

32ビットのオペレーティング・システムを使用している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。

次のタスクでは、ホストは、32ビット・ソース・マシンを指し、ターゲットは、新しい64ビット・ターゲット・マシンを指します。

ノート:

これらのステップは、データベースが別のホスト上にあり、移動されないことを前提としています。
オペレーティング・システムのアップグレードには、通常、次の内容が含まれます。

注意:

これらのステップは、オペレーティング・システム・アップグレード・プロセスの例として説明されているため、特定のオペレーティング・システムを更新する場合に実行する必要がある手順がすべて含まれている場合と含まれていない場合があります。詳細は、使用しているオペレーティング・システムのアップグレード・ドキュメントを参照してください。

親トピック: システム要件と仕様の確認

アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する

アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。

すべてのプロセスを停止する

アップグレードの前に、すべてのプロセスを停止する必要があります。ホスト上で管理対象サーバー、管理サーバーおよびノード・マネージャが起動されている場合は、これらも含めて停止する必要があります。

ノート:

アップグレード中にデータベースが稼働していることを確認します。

ステップ1: 管理対象サーバーを停止する

管理対象サーバーの起動方法に応じて、次のいずれかの方法に従ってWebLogic管理対象サーバーを停止します:

方法1: Weblogicコンソールを使用してWebLogic Server管理対象サーバーを停止するには:
  • weblogic管理者としてWeblogicコンソールにログインします。
  • 「サーバー」 > 「制御」タブに移動します。
  • 必要な管理対象サーバーを選択します。
  • 「停止」をクリックします。
方法2: ノード・マネージャを使用してWebLogic Server管理対象サーバーを停止するには、次のコマンドを実行します:
wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
            'AdminServerHostName','5556','domain_name',
            'DOMAIN_HOME')

wls:/offline>nmKill('ManagedServerName')

ステップ2: 管理サーバーを停止する

管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

  • (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。

ステップ3: ノード・マネージャを停止する

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。『WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。

32ビット・ホスト・マシンからすべてのファイルをバックアップする

11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。

ノート:

同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあります。

『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

アップグレード時に、次のコンテンツにアクセスする必要があります。

  • 11g_DOMAIN_HOME

  • 11g_ORACLE_HOME/wlserver/common/にある11g/nodemanagerディレクトリ

『Oracle Fusion Middleware管理者ガイド』の環境のバックアップに関する項で説明されている一部のバックアップおよびリカバリ手順は、製品に固有です。完全バックアップを作成するまでアップグレードを続行しないでください。

11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する

ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。

IPアドレスおよびホスト名を変更するプロセスは、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムの管理ドキュメントを参照してください。

11gのバックアップを32ビット・ホストから64ビット・ホストにリストアする

11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

『Oracle Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

12c製品ディストリビューションをターゲット・マシンにインストールする

アップグレードには、アウトオブプレース・アプローチをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。

手順については、「Oracle Identity Managerのアウトオブプレース・アップグレードの実行」を参照してください。

標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする

ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

インプレース・アップグレードについては、「Oracle Identity Managerのインプレース・アップグレード」を参照してください。

アウトオブプレース・アップグレードについては、「Oracle Identity Managerのアウトオブプレース・アップグレードの実行」を参照してください。

追加のコンポーネントをアップグレードする場合は、コンポーネントに固有のアップグレード・ガイドを参照してください。

ノート:

ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。「32ビット・ホスト・マシンからすべてのファイルをバックアップする」の一部として32ビット・ソース・マシンからバックアップされた11gノード・マネージャ・ファイルを使用します。

Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認

Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。

アップグレードを開始する前にFusion Middlewareデータベース要件を確認し、Oracle Fusion Middlewareをホストしているデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認します。12c (12.2.1.3.0)の動作保証マトリックスを参照してください。

ノート:

サポート対象外になったデータベース・バージョンを使用している場合は、アップグレードの開始前に、サポート対象バージョンにアップグレードする必要があります。『Oracle Fusion Middlewareのアップグレードのプランニング』の12cのためのOracle Databasesのアップグレードと準備に関する項を参照してください。

親トピック: 動作保証およびシステム要件の確認

このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認

このマニュアルの発行時における12c (12.2.1.3.0)に対して動作保証されたJDKは1.8.0_131でした。

オラクルの技術リソースでOracle Fusion Middlewareのサポート対象システム構成に関する情報を参照して、現在使用しているJDKがサポートされていることを確認します。

サポート対象外のJDKを使用している場合やJDKをインストールしていない場合は、次に示すWebサイトから必須のJava SE JDKをダウンロードする必要があります。
http://www.oracle.com/technetwork/java/javase/downloads/index.html

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。このため、JDKは/home/oracle/products/jdkディレクトリにインストールすることをお薦めします。

親トピック: 動作保証およびシステム要件の確認

強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新

アップグレードされた環境で、Advanced Encryption Standard (AES 256),など強化された暗号化を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

Javaプラットフォームでは、暗号化、公開キーインフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。これらのAPIによって、開発者はアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。

Fusion Middleware 12c (12.2.1.3.0)で使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。「Java暗号化アーキテクチャOracleプロバイダのドキュメント」を参照してください。

ノート:

アップグレードの開始前に、これらのポリシー・ファイルをJDKに適用せずに強化された暗号化を使用しようとすると、アップグレードに失敗することがあり、その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。

親トピック: アップグレード前の要件

未使用データのパージ

アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。

一部のコンポーネントには自動化されたパージ・スクリプトがあります。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。Upgrade Assistantを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。

詳細は、「アーカイブおよびパージ・ユーティリティを使用したデータ増加の制御」を参照してください。

ノート:

データ量が多い大規模システムでは、アーカイブ/パージに時間がかかる場合があります。パフォーマンスを向上させるために、アーカイブ/パージ・スクリプトを並行して実行しないことを強くお薦めします。

親トピック: アップグレード前の要件

Upgrade Assistantを実行するための非SYSDBAユーザーの作成

Upgrade Assistantを実行するために、FMWという非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。

SYSDBAはデータベースの作成、起動、停止、バックアップまたはリカバリなどの高度な管理操作を実行するために必要な管理権限です。SYSDBAシステム権限は、完全な権限を持つデータベース管理者が使用します。SYSDBA権限で接続すると、通常はユーザー名に関連付けられているスキーマではなく、デフォルトのスキーマで接続が確立されます。SYSDBAの場合、このスキーマはSYSです。デフォルト・スキーマへのアクセスは非常に強力な権限となる場合があります。たとえば、ユーザーSYSとして接続する場合、データ・ディクショナリの表における権限は無制限となります。このため、SYSDBA以外のユーザーを作成してスキーマをアップグレードすることをお薦めします。Upgrade Assistantを起動する前に、次に示した権限をユーザーFMWに付与する必要があります。

ノート:

SYSDBAではないユーザーFMWは、Upgrade Assistantを実行するためにのみ作成されます。このステップが完了したら、このFMWユーザーを削除してください。Upgrade Assistantを実行するために必要な権限は、リリースごとに異なる可能性があります。
デフォルトでは、v$xatrans$表は存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。さらに、 v$xatrans$表のgrant select権限は、Oracle Identity Governanceでのみ必要です。構成にOracle Identity Governanceが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。 
   grant select on v$xatrans$ to FMW with grant option;
次の例では、<password>はFMWユーザーに対して設定されたパスワードです。権限を付与する際は、必ず実際のパスワードを指定してください。
create user FMW identified by <password>;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

Oracle Identity Manager (OIM)スキーマをアップグレードする場合、FMWユーザーに次の追加権限が付与されていることを確認してください。

grant execute on SYS.DBMS_FLASHBACK to fmw with grant option;
grant execute on sys.DBMS_SHARED_POOL to fmw with grant option;
grant execute on SYS.DBMS_XMLGEN to FMW with grant option;
grant execute on SYS.DBMS_DB_VERSION to FMW with grant option;
grant execute on SYS.DBMS_SCHEDULER to FMW with grant option;
grant execute on SYS.DBMS_SQL to FMW with grant option;
grant execute on SYS.DBMS_UTILITY to FMW with grant option;
grant ctxapp to FMW with admin option;
grant execute on SYS.DBMS_FLASHBACK TO FMW with grant option;
grant create MATERIALIZED VIEW to FMW with admin option;
grant all on SCHEMA_VERSION_REGISTRY TO FMW with grant option;
grant create SYNONYM to FMW with admin option;
grant execute on CTXSYS.CTX_ADM to FMW with grant option;
grant execute on CTXSYS.CTX_CLS TO FMW with grant option;
grant execute on CTXSYS.CTX_DDL TO FMW with grant option;
grant execute on CTXSYS.CTX_DOC TO FMW with grant option;
grant execute on CTXSYS.CTX_OUTPUT TO FMW with grant option;
grant execute on CTXSYS.CTX_QUERY TO FMW with grant option;
grant execute on CTXSYS.CTX_REPORT TO FMW with grant option;
grant execute on CTXSYS.CTX_THES TO FMW with grant option;
grant execute on CTXSYS.CTX_ULEXER TO FMW with grant option;
grant create JOB to FMW with admin option;

親トピック: アップグレード前の要件

アップグレードに対応可能な既存のスキーマの特定

このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。

Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個別に選択することもできます。この判断には、次に示すステップを実行して、アップグレードに対応可能なすべてのスキーマのリストを表示することが役立ちます。

  1. Oracleデータベースを使用している場合は、Oracle DBA権限が付与されたアカウントを使用してデータベースに接続し、SQL*Plusから次を実行します。

    SET LINE 120
SET PAGESIZE 20
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY VERSION, MRC_NAME, COMP_ID;

  2. 生成されたレポートを調査します。

    アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンがschema_version_registry表に維持されます。

  3. 既存のスキーマに使用されているスキーマ接頭辞名を確認します。RCUを使用して新しい12cスキーマを作成する場合は、同じ接頭辞を使用します。

ノート:

  • 11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードを実行する前に新しいOPSSスキーマを必ず作成してください。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。

  • Oracle Fusion Middlewareリリース12c (12.2.1.3.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.3.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

親トピック: アップグレード前の要件

Oracle Identity Managerのデータベース・パラメータの更新

Oracle Identity Managerを12c (12.2.1.3.0)にアップグレードする前に、いくつかのデータベース・パラメータを検証および更新する必要があります。

次のステップを実行します。
  1. Oracle DBA権限を持つアカウントを使用してデータベースに接続し、この手順でSQL*Plusからコマンドを実行します。
  2. データベース・パラメータmax_string_sizeの値を確認するには、次のコマンドを実行します。
    SQL> SELECT value FROM v$parameter WHERE name='max_string_size';
  3. 戻り値に応じて、次のようにしてください。
    • STANDARD: この手順の残りのステップをスキップして次の手順に進み、アップグレードを続行します。
    • EXTENDED: ステップ4に進みます。
  4. OIMデータベース・ユーザーとしてログインし、次のコマンドを実行して、サイズが4000文字を超える列を検索します。
    SQL> SELECT table_name, column_name, data_length FROM user_tab_columns WHERE data_length>4000;
  5. 行がリストされている場合は、対応する列データを4000文字に減らすか、行を削除します。

    ノート:

    必要に応じて、新しい表にリストされた行のバックアップを作成します。
  6. ステップ4で検出されたすべての列サイズをから4000文字にリセットします。

    OIMデータベース・ユーザーとして、次のコマンドを実行します。

    SQL> ALTER TABLE <table_name> MODIFY <column_name> VARCHAR2(4000);
  7. 長さが変更されて4000文字を超えた列で、既存の索引を削除します。
  8. OIMデータベース・ユーザーとして次のコマンドを実行して、サイズが4000を超える列がないことを確認します。
    SQL> SELECT table_name, column_name, data_length FROM user_tab_columns WHERE data_length>4000;
  9. 必要に応じて、指定された列の表および索引の統計情報を収集します。

詳細は、Oracle Identity Governanceのパフォーマンスの監視に関する項を参照してください。

親トピック: アップグレード前の要件

Oracle Identity Managerのコネクタの更新

既存のコネクタがOracle Identity Manager 12c (12.2.1.3.0)でサポートされていない場合は、更新します。

次のステップを実行します。
  1. Oracle Identity Managerコネクタの動作保証に移動します。
  2. 動作保証情報表を使用して、既存のコネクタが12c (12.2.1.3.0)でサポートされているかどうかを確認します。
  3. 既存のコネクタは12c (12.2.1.3.0)でサポートされていますか。
    • はい: この手順をスキップして、次のアップグレード手順に進みます。
    • いいえ: 必要なコネクタを更新します。Oracle Identity Governance 12cコネクタを参照してください。

親トピック: アップグレード前の要件

ノード・マネージャの停止

アップグレード・プロセスを開始する前に、すべてのローカルおよびリモートのノード・マネージャを停止していることを確認してください。

アップグレードの完了後にWebLogic管理サーバーを起動するまで、ノード・マネージャは停止したままにする必要があります。WebLogic管理サーバーが稼働しているときに、ノード・マネージャを起動し、続いて管理対象サーバーを起動します。

親トピック: アップグレード前の要件

Oracle Identity Managerのアップグレード前レポートの生成および分析

Oracle Identity Managerのアップグレード・プロセスを開始する前に、アップグレード前レポート・ユーティリティを実行し、すべての問題にレポートで提示されている解決策を使用して対処します。

アップグレード前レポート・ユーティリティは、既存のOracle Identity Manager環境を分析し、アップグレードを開始する前に完了する必要がある必須前提条件に関する情報を提供します。

ノート:

アップグレード前レポートで報告された問題が修正されていない状態ではアップグレードが失敗する可能性があるため、すべての問題を解決してからアップグレードを進めることが重要です。

アップグレード前レポート・ユーティリティを実行する前に、データベースおよび11.1.2.3.0 Oracle Identity Managerサーバーが稼働していることを確認してください。

  • アップグレード前レポート・ユーティリティの入手
    Oracle Technology Network (OTN)からOracle Identity Manager用のアップグレード前レポート・ユーティリティをダウンロードします。
  • アップグレード前レポートの生成
    Oracle Identity Managerのアップグレード・プロセスを開始する前に、アップグレード前レポートを生成し、レポートに示された問題を解決します。
  • アップグレード前レポートの分析
    Oracle Identity Managerのアップグレード前レポートを生成した後、各レポートを確認して、レポートに記載されているすべてのタスクを実行します。レポートに記載されている必須タスクを実行しないと、アップグレードが失敗する可能性があります。

親トピック: アップグレード前の要件

アップグレード前レポート・ユーティリティの入手

Oracle Technology Network (OTN)からOracle Identity Manager用のアップグレード前ユーティリティをダウンロードします。

ユーティリティは、My Oracle Supportの次の場所でPreUpgradeReport.zipというzipファイルで提供されており、ReadMe.docが付属しています。

My Oracle SupportのドキュメントID 2308933.1

ReadMe.docには、アップグレード前レポートを生成および分析する方法に関する情報が含まれています。

親トピック: Oracle Identity Managerのアップグレード前レポートの生成および分析

アップグレード前レポートの生成

Oracle Identity Managerのアップグレード・プロセスを開始する前に、アップグレード前レポートを生成し、レポートに示された問題を解決します。

Oracle Identity Managerのアップグレード前レポートを生成するには、管理サーバーのホスト・マシンで次のステップを実行します:

  1. 任意の場所にディレクトリを作成し、その新規ディレクトリにPreUpgradeReport.zipの内容を抽出します。
  2. アップグレード前レポートの生成先ディレクトリを作成します。たとえば、OIM_preupgrade_reportsという名前のディレクトリを作成します。
  3. PreUpgradeReport.zipの内容を抽出したディレクトリに移動し、テキスト・エディタでpreupgrade_report_input.propertiesファイルを開きます。表2-2に示されたパラメータに適切な値を指定して、プロパティ・ファイルを更新します

    表2-2 preupgrade_report_input.propertiesファイルで指定するパラメータ

    パラメータ 説明
    oim.mwhome 既存のインストールのMiddlewareホームへの絶対パスを指定します。

    たとえば: /Oracle/Middleware
    oim.oimhome 既存のOIMホームへの絶対パスを指定します。

    たとえば: /Oracle/Middleware/Oracle_IDM1
    oim.javahome Javaホームへの絶対パスを指定します。JAVA 8を指していることを確認してください。
    oim.wlshome WebLogic Serverホームへの絶対パスを指定します。

    たとえば: /Oracle/Middleware/wlserver_10.3
    oim.domain Oracle Identity Managerドメイン・ホームの絶対パスを指定します。

    たとえば: /Oracle/Middleware/user_projects/domains/IAMGovernanceDomain
    oim.oimhost Oracle Identity Managerのホスト名を指定します。

    たとえば: oim.example.com
    oim.oimport Oracle Identity Managerサーバーのポートを指定します。

    たとえば: 14000
    oim.username Oracle Identity Managerの管理ユーザー名を指定します。

    たとえば: xelsysadm
    oim.targetVersion Oracle Identity Managerのターゲット・バージョン(つまり、12.2.1.3.0)を指定します。
    oim.jdbcurl Oracle Identity ManagerのJDBC URLを次のいずれかの形式で指定します。

    host:port/service_name

    または

    host:port:sid
    oim.oimschemaowner OIMスキーマの所有者の名前を指定します。
    oim.mdsjdbcurl MDS JDBC URLを次のいずれかの形式で指定します。

    host:port/service_name

    または

    host:port:sid
    oim.mdsschemaowner MDSスキーマの所有者を指定します。
    oim.databaseadminname DBA権限を持つユーザーを指定します。たとえば、FMWまたはsysをsysdbaとして指定します。
    oim.outputreportfolder レポートを生成するディレクトリ(OIM_preupgrade_reports)への絶対パスを指定します。このディレクトリに読取りおよび書込み権限があることを確認してください。
  4. PreUpgradeReport.zipの内容を抽出した場所から、次のコマンドを実行します。
    • UNIXの場合:

      sh generatePreUpgradeReport.sh

    • Windowsの場合:

      generatePreUpgradeReport.bat

  5. 次のプロンプトが表示されたら、詳細を指定します。
    • OIMスキーマ・パスワード: Oracle Identity Manager (OIM)スキーマのパスワードを入力します。
    • MDSスキーマ・パスワード: Metadata Services (MDS)スキーマのパスワードを入力します。
    • DBAパスワード: データベース管理者のパスワードを入力します。
    • OIM管理パスワード: Oracle Identity Manager管理者のパスワードを入力します。
  6. レポートは、preupgrade_report_input.propertiesファイルのパラメータoim.outputreportfolderに指定した場所に、HTMLページとして生成されます。ログは、同じ場所のlogsフォルダにあるpreUpgradeReport<time>.logというログ・ファイルに格納されています。

親トピック: Oracle Identity Managerのアップグレード前レポートの生成および分析

アップグレード前レポートの分析

Oracle Identity Managerのアップグレード前レポートを生成した後、各レポートを確認して、それらに記載されているすべてのタスクを実行します。レポートに記載されている必須タスクを実行しないと、アップグレードが失敗する可能性があります。

表2-3 Oracle Identity Managerに対して生成されたアップグレード前レポート

レポート名 説明とアクション・アイテム

OIMシステム・プロパティのステータス — XL.AllowedBackURLs

このレポートには、Oracle Identity Managerでの戻りURLの設定に関連するシステム・プロパティのステータスが記載されます。

12cにおけるSCIM-JWTへの変更

このレポートには、12c (12.2.1.3.0)中に公開された新しいSCIM URLがリストされます。

古いものではなく、新しいURLを使用する必要があります。

ユーザー定義の属性に関する潜在的なアップグレードの問題

このレポートには、アップグレード中にOracle Identity Manager 11.1.2.3.0で定義されたユーザー定義フィールド(UDF)に関する潜在的な問題がリストされます。

必須データベース・コンポーネントのステータス

このレポートには、アップグレードに必要な必須データベース・コンポーネントのインストール・ステータスがリストされます。

OIM認証JARに関する必須の削除のステータス

このレポートには、アップグレード前に削除する必要がある2、3の必須JARのステータスがリストされます。

ソース環境の完全MDSエクスポート

このレポートには、アップグレード前に行われたMDSバックアップに関する詳細がリストされます。

ソース環境におけるカスタマイズ済通知テンプレート

このレポートには、カスタマイズされた即時利用可能(OOTB)通知テンプレートがリストされます。これらのカスタマイズは、アップグレード中にOOTB値で上書きされます。

OIM-OMSS統合アップグレード前レポート

このレポートでは、12c (12.2.1.3.0)におけるOracle Identity ManagerとのOracle Mobile Security Services (OMSS)に関する非推奨の情報が示されます。

ドメイン構成のステータス

このレポートには、ステージ・モードのアプリケーションが存在する場合、それらがリストされます。

必須DB権限のステータス

このレポートには、アップグレードに必要な必須のデータベース権限で不足しているものがリストされます。

アクセス・ポリシーと関連付けられているデータのステータス

12cでは、アクセス・ポリシーはリソース・オブジェクトではなくアプリケーション・インスタンスに関連付けられます。同じように処理するため、このレポートにはOracle Identity Manager 11.1.2.3.0で一貫性のないデータがある場合、それらがリストされます。

ソース環境の認可ポリシーのバックアップ

このレポートには、アップグレード前に行われたOracle Identity Manager認可ポリシーのバックアップに関する詳細がリストされます。

ソース環境におけるOIMデータ・パージ・タスクという名前のスケジュール・タスクに対するスケジュール・ジョブに関する情報

このレポートには、アップグレード後に使用可能となる、いずれか1つのスケジュール・タスクに関する重要な情報が記載されます。

ソース環境における廃止されたテンプレートの存在ステータス

このレポートには、アップグレード前にソース・ドメインに存在していた古いテンプレートがリストされます。

ソース環境における廃止されたアプリケーションの存在ステータス

このレポートには、アップグレード前にソース・ドメインに存在していた古いアプリケーションがリストされます。

ソース環境におけるsoaOIMLookupDBデータ・ソースのステータス

このレポートには、アップグレード前のソース・ドメイン内の非トランザクションsoaOIMLookupDBデータ・ソースがリストされます。

ソース環境におけるKSSのOIMデフォルト・キーストアのステータス

このレポートには、OIMデフォルト・キーストアがアップグレード前にソース・ドメインのKSSに存在していた場合、それがリストされます。

親トピック: Oracle Identity Managerのアップグレード前レポートの生成および分析