| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章のアクティビティは、以前のアクセス・システム・コンポーネントのアップグレードを担当する管理者を対象としています。使用環境にアクセス・システムのコンポーネントが含まれていない場合は、この章をスキップしてください。停止時間ゼロのメソッドを使用している場合は、第VI部を参照してください。内容は次のとおりです。
|
注意: 統合コンポーネントまたは個別にインストールされたSDKをアップグレードする前に、アクセス・システムをアップグレードする必要があります。 |
Oracle Access Managerのアクセス・ポリシーを使用するには、事前にアクセス・システム・コンポーネントのアップグレードが必要です。次の手順の後に、この章のタスクを実行してください。
第II部の説明に従って、スキーマおよびデータをアップグレードした後
第9章の説明に従って、残りのアイデンティティ・システム・コンポーネントをアップグレードした後
第8章の説明に従って各アクセス・システム・コンポーネントを準備（個々のインスタンスをアップグレードする直前に実行可能）した後
残りのアクセス・システム・コンポーネントをインプレース・アップグレードするには、対応する10g（10.1.4.0.1）コンポーネント・インストーラを使用し、既存のコンポーネントと同じターゲット・ディレクトリを指定します。
アップグレード元リリースが6.5または7.xで、それに複数の言語がインストールされている場合は、既存のマルチ言語機能を保持するためにこれらの言語をアップグレードする必要があります。
図10-1は、アクセス・システムのインプレース・アップグレード・タスクの概要を示しています。
タスクの概要: アクセス・システム・コンポーネントのインプレース・アップグレード
データベースの監査: 以前のインストールにデータベースの監査が構成されている場合は、10g（10.1.4.0.1）で正確な監査を行うために、アップグレードされたアクセス・サーバー・サービスを再起動する前に、いくつかのタスクを手動で行う必要があります。「アクセス・サーバーの監査およびレポートのアップグレード」を参照してください。
WebGateのインプレース・アップグレード: このアクティビティは今回一緒に行わなくてもかまいません。アップグレードされたアクセス・サーバーと以前のWebGateとの間には、自動的な下位互換性があるためです。
コンポーネントのアップグレードが成功した場合: 「アップグレードされたアクセス・システム・コンポーネント・ディレクトリのバックアップ」に進みます。このタスクは、コンポーネントのアップグレードが成功するたびに実行する必要があります。これにより、必要に応じてこのアップグレードに簡単にロールバックできるようになります。
コンポーネントのアップグレードが失敗した場合: 「アクセス・システムのインプレース・アップグレードの失敗からのリカバリ」に進みます。
この章では、以前のAccess Managerコンポーネントという名前にかわってポリシー・マネージャという名前を使用します。マスター・ポリシー・マネージャのアップグレードは、アクセス・システムのスキーマおよびデータのアップグレードと一緒に行われていました。
ここでは、図10-2に示すように、残りのポリシー・マネージャ・インスタンスのアップグレード時に応答するよう求められるイベントと意思決定ポイントの2つの項目に分けて説明します。更新されるスキーマおよびデータは自動的に検出されます。このため、対応するメッセージやイベントは表示されません。
|
注意: 以前のポリシー・マネージャ・インスタンスが、以前のWebGateと同じコンピュータ上の同じディレクトリにインストールされている場合、ポリシー・マネージャをアップグレードし、続いて、WebGateと通信するすべてのアクセス・サーバーをアップグレードし、最後にWebGateをアップグレードしてからWebサーバーを再起動する必要があります。 |
タスクの概要: 残りのポリシー・マネージャのインプレース・アップグレード
残りのポリシー・マネージャのアップグレードを開始する前、すなわち以前の環境の各インスタンスをアップグレードする前に、表10-1のタスクをチェックし、これらのタスクが完了していることを確認してください。前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
表10-1 ポリシー・マネージャのインプレース・アップグレードの前提条件
| ポリシー・マネージャのアップグレードの前提条件 |
|---|
|
第I部の各章の内容をよく理解している。 |
|
第II部の説明に従って、スキーマおよびデータのインプレース・アップグレードを完了している。 |
|
第9章の説明に従って、残りのアイデンティティ・システム・コンポーネントをインプレース・アップグレードしている。 |
|
第8章の説明に従って、ポリシー・マネージャ・インスタンスを準備している。
|
この手順では、アップグレード・プロセスを開始し、以前のポリシー・マネージャ・コンポーネントと同じターゲット・ディレクトリを指定して、アップグレードする言語を指定します。
このステップでも同様に、記載されているメッセージ、入力する応答、および一連のイベントの例は、GUIメソッドと自動モード（推奨）を使用した場合のものです。次の手順で説明されているアップグレード例は、リリース6.1.1からアップグレードする場合です。アップグレード元リリースや環境は同じでなくてもかまいません。
|
注意: 実行するインストールに該当しない詳細はスキップしてください。たとえば、UNIX環境の場合には、Windows環境の詳細はスキップしてください。 |
ポリシー・マネージャのアップグレードを開始し、ターゲット・ディレクトリと言語を指定する手順
このインスタンスで「ポリシー・マネージャのインプレース・アップグレードの前提条件」に記載されているすべての前提条件が満たされていることを確認します。
ポリシー・マネージャのWebサーバー・インスタンスを停止した後、適切な管理者権限のあるユーザーとしてログインし、Oracle Access Managerファイルを更新します。
選択したメソッドを使用して、インストール・プログラムを特定し、起動します。
WindowsのGUIメソッド:
Oracle_Access_Manager10_1_4_0_1_Win32_NSAPI_PolicyManager.exe
Solarisのコンソール・メソッド:
./Oracle_Access_Manager10_1_4_0_1_sparc-s2_NSAPI_PolicyManager
「ようこそ」画面が表示されます。
指示に従って「ようこそ」画面を閉じます。次に、プラットフォーム固有の管理者確認画面に応答します。
以前のリリースをインストールしたディレクトリを選択し、指示に従って続行します。
「はい」をクリックしてアップグレードに同意し、「次へ」をクリックします。
「英語」やインストールしたその他の言語の横にチェックマークが付いていることを確認し、「次へ」をクリックします。
「次へ」をクリックし、リストされている言語を確定します。
タイムスタンプの付いたディレクトリ名を記録し、「次へ」をクリックして続行します。
必要なディスク領域量を記録し、「次へ」をクリックして、ターゲット・ディレクトリへのファイルの抽出を開始します。
アップグレード・プロセスのモード（自動モードまたは確認モード）を指定するよう求められます。
コンソール・メソッドを使用している場合は、インストール・スクリプトが終了してトランスクリプトが表示されます。トランスクリプト内のコマンドを実行し、続いてステップ9に進みます。（UNIXの場合は、コマンドがファイル（start_migration）に出力され、このファイルを実行するよう指示するメッセージが出力されます。）
数字を選択し、表示されるメッセージを確認します。次に例を示します。
1
Creating orig folders ... ---------------------------------------------------- Copying general configuration files OK. ---------------------------------------------------- Updating parameter catalogs ... OK. ----------------------------------------------------
この手順では、コンポーネント固有のアップグレードを実行します。ポリシー・マネージャのアップグレード作業には、Webサーバー構成の更新、ポリシー・マネージャ構成パラメータのアップグレードが含まれます。
次の手順では、各メッセージについて、どのような内容かわかるようにするため最小限の情報のみを記載します。これらは環境によって異なります。
Webサーバーおよびポリシー・マネージャをアップグレードする手順
メッセージを確認し、環境についての質問に適切に応答します。
------------------------------------- Updating web server configuration files... Connecting to server ...Done. OK. ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting migration ( 6.5.0 -> 7.0.0 )... ------------------------------------- Please type 'yes' to proceed:
リリース7.0から10g（10.1.4.0.1）へのアップグレードの場合は、必要に応じて、コンポーネント固有の構成に進みます。
Enter
Updating component-specific configuration files.
メッセージにより、アップグレードが正常に終了したことを確認してください。
Directory permissions copied ... C:\NetPoint\WebComponent\access_20060223_190102\oblix)
C:\NetPoint\WebComponent\access\oblix)
---------------------------------------------------
Migration has completed successfully!
Press <ENTER> to continue.
このフェーズが完了したら、指示に従って作業を進め、「ポリシー・マネージャのアップグレードの終了確認」に進みます。
この手順に従ってアップグレードの終了の確認を行います。
必要に応じて、Webサーバー構成ファイルの変更内容を反映します。
|
重要: 以前のポリシー・マネージャ・コンポーネントが、以前のWebGateと同じコンピュータ上の同じディレクトリにインストールされている場合、ポリシー・マネージャをアップグレードし、続いて、WebGateと通信するすべてのアクセス・サーバーをアップグレードし、最後にWebGateをアップグレードしてからWebサーバーを再起動する必要があります。 |
Webサーバーを起動し、このアップグレードが成功したことを確認します。
ポリシー・マネージャのWebサーバーが起動しない場合: 付録Gのトラブルシューティングのヒントを参照してください。
ポリシー・マネージャ移行ログ・ファイルを表示して、エラーが含まれているかどうかを確認します。「ログ・ファイルへのアクセス」を参照してください。
アップグレードが成功した場合: このインスタンスに対して「アップグレードされたアクセス・システム・コンポーネント・ディレクトリのバックアップ」のアクティビティを実行し、残りのポリシー・マネージャのアップグレードを続けます。
アップグレードが失敗した場合: 「アクセス・システムのインプレース・アップグレードの失敗からのリカバリ」に進みます。
すべてのポリシー・マネージャのアップグレードとバックアップが完了したら、「アクセス・サーバーのインプレース・アップグレード」に進みます。
ここでは、図10-3に示すように、アクセス・サーバー・インスタンスのアップグレード時に発生するイベントと意思決定ポイントの2つの項目に分けて説明します。アクセス・サーバーのアップグレードでは、Webサーバーは関係しません。
タスクの概要: アクセス・サーバーのインプレース・アップグレード
アクセス・サーバーのアップグレードを開始する前に、表10-2のタスクをチェックし、これらが実行されていることを確認します。前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
表10-2 アクセス・サーバーのインプレース・アップグレードの前提条件
| アクセス・サーバーのアップグレードの前提条件 |
|---|
|
第I部の各章の内容をよく理解している。 |
|
第II部の説明に従って、スキーマおよびデータのインプレース・アップグレードを実行している。 |
|
第9章の説明に従って、残りのアイデンティティ・システム・コンポーネントをインプレース・アップグレードしている。 |
|
「残りのポリシー・マネージャのインプレース・アップグレード」の説明に従って、すべてのポリシー・マネージャをインプレース・アップグレードしている。 |
|
第8章の説明に従って、インスタンスの準備アクティビティを実行している。
|
ここで説明するサンプルのアップグレードは、既存のOracle Access Manager 6.1.1インストールから開始します。ここでも同様に、以前のコンポーネントと同じターゲット・ディレクトリを指定し、アップグレードする言語を指定します。
アクセス・サーバーのアップグレードを開始し、ターゲット・ディレクトリと言語を指定する手順
「アクセス・サーバーのインプレース・アップグレードの前提条件」に記載されているすべての前提条件が満たされていることを確認します。
Oracle Access Managerファイルを更新できる管理者権限のあるユーザーとしてログインします。
アクセス・サーバー・サービスを停止します。
選択したメソッドでプログラムを特定し起動します。
WindowsのGUIメソッド:
Oracle_Access_Manager10_1_4_0_1_Win32_AccessServer.exe
Solarisのコンソール・メソッド:
./Oracle_Access_Manager10_1_4_0_1_sparc-s2_AccessServer
「ようこそ」画面が表示されます。
「ようこそ」画面を閉じます。次に、使用しているプラットフォームに基づいて次の質問に回答します。
以前のリリースをインストールしたディレクトリを選択し、「次へ」をクリックします。
「はい」をクリックしてアップグレードに同意し、「次へ」をクリックします。
リストからデフォルトの管理者言語およびアップグレードするその他の言語を選択します。
「英語」やその他のアップグレード対象の言語の横に必ずチェックマークを付け、「次へ」をクリックします。
言語を確認し、「次へ」をクリックします。
タイムスタンプの付いたディレクトリ名を記録し、指示に従って続行するようクリックします。
ターゲット・ディレクトリへのファイルの抽出を開始します。
この手順には、メッセージ・カタログおよびパラメータ・カタログのアップグレード、アクセス・サーバーのディレクトリ・プロファイルの作成、コンポーネント構成のアップグレードが含まれます。
ここで説明するサンプルは、Oracle Access Manager 6.1.1からアップグレードを開始します。他のリリースからアップグレードを開始する場合は、次の手順で示す数字が異なります。
自動モードを使用する場合は1（確認モードを使用する場合は2）を入力し、メッセージが表示されたら応答します。次に例を示します。
1
メッセージの表示が開始されます。
Creating orig folders... ------------------------------------- Copying general configuration files... OK. ------------------------------------- Updating parameter catalogs... OK. ------------------------------------- Starting migration ( 6.1.1 -> 6.5.0 )... DBProfiles created. ------------------------------------- Updating component-specific configuration files... OK. Please note the name of the Oracle Access Manager Access Server service : NetPoint AAA Server (aaa-viking) OK. ------------------------------------- Starting migration ( 6.5.0 -> 7.0.0 )... ------------------------------------- Updating component-specific configuration files... OK. Please note the name of the Oracle Access Manager Access Server service : NetPoint AAA Server (aaa-viking) OK. ------------------------------------- Starting migration ( 7.0.0 -> 10.1.4 )... ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Migration has completed successfully! Press <ENTER> to continue: -------------------------------------
アクセス・サーバー・サービスの名前を記録し、[Enter]を押します。
[Enter]を押します。
これにより、一連の作業が終了し、通例のREADME情報が表示されます。
次の手順に従って、各インスタンスのアップグレードの終了の確認を行います。
|
注意: 以前の環境にデータベースの監査が構成されている場合は、アクセス・サーバー・サービスを再起動する前に、「アクセス・サーバーの監査およびレポートのアップグレード」の該当アクティビティを必ず実行してください。 |
監査およびアクセス・レポート: 以前のインストールに監査およびアクセス・レポートが組み込まれている場合は、ステップ2を実行する前に「アクセス・サーバーの監査およびレポートのアップグレード」に進みます。
アクセス・サーバー・サービスを起動します。たとえば、password.lstファイルにサーバー・パスワードを格納していない場合には、次のコマンドを使用します。
start_access_server -P mypassword port -d -t 61
コマンド・オプションによっては、非表示オプションが無効となり、パスワードがコマンドラインに表示されることになります。
必要な場合は、プロンプトでパスワードを入力してください。
IBM SecureWayディレクトリ・サーバーでは、次にアクセス・サーバーを起動した場合、PEMパスフレーズを要求するダイアログの表示までに数分かかる場合があります。
アクセス・サーバー・サービスが起動しない場合: 付録Gのトラブルシューティングのヒントを参照してください。
アクセス・サーバー移行ログ・ファイルを表示して、エラーが含まれているかどうかを確認します。「ログ・ファイルへのアクセス」を参照してください。
アップグレードが失敗した場合: 「アクセス・システムのインプレース・アップグレードの失敗からのリカバリ」に進みます。
アップグレードが成功した場合: このインスタンスに対して「アップグレードされたアクセス・システム・コンポーネント・ディレクトリのバックアップ」のアクティビティを実行します。その後、この手順を繰り返して、使用環境のすべてのアクセス・サーバーをアップグレードします。
すべてのアクセス・サーバーをアップグレードしたら、次の手順に進んでください。
次に、「WebGateのインプレース・アップグレード」に進みます。
この他に進める作業については、「他の章の内容」を参照してください。
すべてのWebGateをアップグレードすることをお薦めします。なお、これは今回一緒に行わなくてもかまいません。これは前述のように、アップグレードされたアクセス・サーバーでは、下位互換性が自動的に確保されているため、以前のWebGateと通信できるためです。詳細は、「アクセス・システムの動作変更」を参照してください。
それでもWebGateのインプレース・アップグレードを行う場合は、開始する前に次の重要な変更点を把握しておいてください。WebGateをアップグレードする際、WebGateStatic.lst構成ファイルが削除されます。このファイル内の構成パラメータは、ディレクトリ・サーバーへと移行され、アクセス・システム・コンソールのアクセス・ゲート構成機能で使用できます。
WebGateのアップグレード中に、アップグレード・ツールはアクセス・サーバーと通信し、構成情報をWebGatestatic.lstファイルからディレクトリ・サーバーに送信して書き込みます。この書込みができるよう、一時ディレクトリ・プロファイルがマスター・ポリシー・マネージャのアップグレードの後に作成されています。
WebGate構成パラメータが正しく移行されない場合は、アクセス・システム・コンソールでアクセス・ゲート構成機能を使用してパラメータ値を追加および変更できません。WebGateのアップグレード後は、WebGatestatic.lstファイルは使用できなくなります。WebGateの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。WebGateの変更点の詳細は、「WebGate」を参照してください。
WebGateのアップグレードに必要な手順は、次の項目および図10-4に示します。スキーマおよびデータの更新はありません。
タスクの概要: WebGateのインプレース・アップグレード
WebGateのアップグレードを開始する前に、表10-3のタスクをチェックし、これらが実行されていることを確認します。
前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
表10-3 WebGateのインプレース・アップグレードの前提条件
| WebGateのアップグレードの前提条件 |
|---|
|
第I部の各章の内容をよく理解している。 |
|
第II部の説明に従って、スキーマおよびデータのインプレース・アップグレードを実行している。 |
|
第9章の説明に従って、残りのアイデンティティ・システム・コンポーネントをインプレース・アップグレードしている。 |
|
「残りのポリシー・マネージャのインプレース・アップグレード」の説明に従って、残りのポリシー・マネージャをインプレース・アップグレードしている。 |
|
「アクセス・サーバーのインプレース・アップグレード」の説明に従って、すべてのアクセス・サーバーが正常にアップグレードされていることを確認する。 |
|
このインスタンスについて第8章のアクティビティが完了している。
|
これは、実行済の他のアップグレードと同様のプロセスです。アップグレードを開始し、以前のWebGateと同じターゲット・ディレクトリを指定して、アップグレードする言語を指定します。ここで説明するサンプルは、リリース6.1.1からアップグレードする場合です。環境は同じでなくてもかまいません。
WebGateのアップグレードを開始し、ターゲット・ディレクトリと言語を指定する手順
「WebGateのインプレース・アップグレードの前提条件」に記載されているすべての前提条件が満たされていることを確認します。
WebGate Webサーバー・インスタンスを停止した後、適切な管理者権限のあるユーザーとしてログインし、Oracle Access Managerファイルを更新します。
選択したメソッドでプログラムを特定し起動します。
WindowsのGUIメソッド:
Oracle_Access_Manager10_1_4_0_1_Win32_NSAPI_WebGate.exe
Solarisのコンソール・メソッド:
./Oracle_Access_Manager10_1_4_0_1_sparc-s2_NSAPI_WebGate
「ようこそ」画面が表示されます。
指示に従って「ようこそ」画面を閉じます。次に、プラットフォーム固有の管理者確認画面に応答します。
以前のWebGateをインストールしたディレクトリを選択し、指示に従って続行します。
アップグレードに同意し、次に進みます。
「英語」やインストールしたその他の言語の横にチェックマークが付いていることを確認し、次に進みます。
アップグレードされる言語を確認し、次に進みます。
タイムスタンプの付いたディレクトリ名を記録し、次に進みます。
必要なディスク領域量を記録して、「次へ」をクリックします。
アップグレード用に選択したメソッドに従ってアクティビティを行い、必要に応じて応答し続行します。
|
注意: Windowsでは、ディレクトリに対するセキュリティ上の権限を取得するために入力した情報は、obmigratenp.logに記録されます。 |
この手順では、WebGate構成ファイルとWebサーバー構成のアップグレードが実行されます。この自動化されたプロセスでは、ユーザーが入力する必要はほとんどありません。
WebGate構成ファイルとWebサーバー構成ファイルをアップグレードする手順
自動モードを使用する場合は1（確認モードを使用する場合は2）を入力し、メッセージが表示されたら応答します。次に例を示します。
1
プロセスの進行に従い、メッセージがスクロールされます。
Creating orig folders... ------------------------------------- Copying general configuration files... OK. ------------------------------------- Updating parameter catalogs... OK. ------------------------------------- Starting migration ( 6.1.1 -> 6.5.0 )... ----------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting migration ( 6.5.0 -> 7.0.0 )... ------------------------------------- Updating web server configuration files... OK. ----------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting migration ( 7.0.0 -> 10.1.4 )... ------------------------------------- Updating web server configuration files... OK. ----------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting the WebgateStatic.lst Migration ... Completed the WebgateStatic.lst Migration successfully. OK. Directory permissions copied... C:\NetPoint\access\webcomponent-iis\access_20040426_164541\oblix ) -> ( C:\NetPoint\access\webcomponent-iis\access\oblix ) ------------------------------------- Migration has completed successfully! Press <ENTER> to continue: -------------------------------------
指示に従って処理を進め、「WebGateのアップグレードの終了確認」に進みます。
WebGateアップグレードの終了の確認作業には、他のコンポーネントのアップグレードとの違いがいくつかあります。たとえば、WebGateのアクセス管理サービスを必ず停止する必要があります。
必要に応じて、Webサーバー構成ファイルの変更内容を反映します。
このWebGateのアクセス管理サービスの停止: アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・ゲート構成」→「WebGate」のリンクをクリックします。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
WebGate Webサーバーを起動します。
WebGateのWebサーバーが起動しない場合: 付録Gのトラブルシューティングのヒントを参照してください。
WebGate移行ログ・ファイルを表示して、エラーが含まれているかどうかを確認します。「ログ・ファイルへのアクセス」を参照してください。
WebGateが意図したとおりに動作すること、および10g（10.1.4.0.1）環境が動作することを確認します。詳細は、第4章を参照してください。
アップグレードが成功した場合: このインスタンスに対して「アップグレードされたアクセス・システム・コンポーネント・ディレクトリのバックアップ」のアクティビティを実行し、以前のWebGateのアップグレードを続けます。
アップグレードが失敗した場合: 「アクセス・システムのインプレース・アップグレードの失敗からのリカバリ」に進みます。
各WebGateのアップグレードを続けるか、「他の章の内容」に進みます。
前述のように、10g（10.1.4.0.1）コンポーネント・ディレクトリが正常に動作していることを確認した後にこのディレクトリをバックアップして、各コンポーネントのアップグレードを終了することをお薦めします。これにより、アップグレード直後の環境にリストアする必要が生じたときに簡単にリストアできるようになります。
10g（10.1.4.0.1）コンポーネント・ディレクトリをバックアップし、新しい場所に格納します。
Webサーバー: 必要に応じて、ベンダーのドキュメントを参照し、アップグレードされたWebサーバーの構成ファイルをバックアップします。
Windows: 必要に応じて、「Windowsレジストリ・データのバックアップ」の説明に従ってWindowsレジストリ・データをバックアップします。
「他の章の内容」に進みます。
コンポーネントのアップグレードが失敗した場合、次の手順を実行してこのアップグレードをロールバックし、アップグレードしなおすことができます。
アクセス・システム・コンポーネントのインプレース・アップグレードの失敗からリカバリする手順
アップグレードの前にバックアップした以前のコンポーネントのインストール・ディレクトリをリストア（以前の環境をリカバリ）してから、このディレクトリを再度バックアップします。以前のディレクトリの一方をバックアップ・コピーとして保存し、他方のディレクトリを使用してアップグレードを再開します。
Webサーバー: 該当するコンポーネント（ポリシー・マネージャまたはWebGate）で必要な場合は、バックアップ済のWebサーバー構成ファイルをリストアします。
Windows: このインスタンスで必要な場合は、コンポーネントのバックアップ済レジストリをリストアします。
以前のコンポーネントのインストール・ディレクトリ（および必要な場合はWebサーバー構成）のバックアップ・コピーを使用して、この章の説明に従ってコンポーネントのアップグレードを再開します。
アップグレードされたアクセス・システム・コンポーネントでは、UTF-8エンコーディングでデータが送受信されます。以前のコンポーネントでは、Latin-1エンコーディングでデータが送受信されます。以前のアクセス・システム・コンポーネントがすべて正常にアップグレードされたら、次の章に進み、説明に従ってタスクを実行します。
予期されるシステム動作の詳細は、第4章を参照してください。
