| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
This chapter introduces upgrade concepts, strategies, and processing methods. Unless explicitly stated, the information in this chapter applies equally to in-place upgrades and to zero downtime upgrades. Topics in this chapter include:
Note:
There are several important name changes that you should know about. Be sure to review "Product and Component Name Changes". This manual uses the new names, even when referring to earlier releases.For an introduction to Oracle Access Manager, a road map to related manuals, and a glossary of terms, see the Oracle Access Manager Introduction.
This section describes the difference between a full release and a patch set, differences between numbering of various releases, and incremental upgrades.
Oracle Access Manager 10g (10.1.4.0.1) is a full release that includes all component packages, libraries, and files needed for a fresh installation or a in-place upgrade. Release 10g (10.1.4.0.1) component installation programs control both installation and upgrade processing.
Oracle Access Manager Release 10.1.4 Patch Set 1 (10.1.4.2.0) is a patch set, not a full release. A patch release provides fixes to known problems. The Release 10.1.4 Patch Set 1 (10.1.4.2.0) also includes some new features and functions, including the MigrateOAM script that can be used with only the zero downtime upgrade methodology:
In-Place Upgrade Method: This method requires release 10g (10.1.4.0.1) component installers to upgrade existing components where they currently reside.
Zero Downtime Upgrade Method: This method requires the MigrateOAM script that is available only with Release 10.1.4 Patch Set 1 (10.1.4.2.0), as described in Part IV.
Your earlier installation might include patches. However, you do not need to apply patches to the earlier installation before upgrading. For details about applying the latest patch set after upgrading, see "The Latest Patch Set".
Starting with release 10g (10.1.4.0.1), Oracle Access Manager uses the Oracle product numbering scheme. A major release is identified by the first three numbers (10.1.4, for example) of a five segment product number. The last two digits of an Oracle product number represent the maintenance and patch release numbers (10.1.4.0.0), respectively:
Earlier release numbers consisted of four elements:
During an upgrade, automated processing occurs incrementally from the earliest release to the latest. Upgrade processing handles the differences between release numbering schemes seamlessly. During the upgrade, a minor release (or maintenance release or patch release) is recognized as a major release. For example, 6.5.5.3 is recognized as 6.5.
Note:
To upgrade from releases earlier than 6.1.1, contact Oracle Support at
http://www.oracle.com/support/contact.html.The following process overview outlines the automated processing that occurs during a component upgrade. This sequence occurs regardless of the methodology you are using. In this example, the starting release is 6.1.1. While your starting release might be different, the incremental upgrade from each earlier release occurs automatically during every component upgrade.
Process overview: Automatic Incremental upgrades
The first increment brings your installation from release 6.1.1 to release 6.5.
The second increment brings your installation from release 6.5 to release 7.0.
Third increment brings your installation from release 7.0 to 10g (10.1.4.0.1).
Release 10.1.4 Patch Set 1 (10.1.4.2.0) is not a full release. This means that Release 10.1.4 Patch Set 1 (10.1.4.2.0) installers cannot be used to install or upgrade components using the in-place upgrade method.
If your system environment includes Oracle Application Server components, you can upgrade these to 10g (10.1.4.0.1) by following the instructions in the Oracle Application Server Upgrade and Compatibility Guide.
The upgrade procedures for Oracle Access Manager are documented separately from the Oracle Application Server upgrade procedures because the two products are installed separately.
Regardless of the upgrade methodology you choose, it is important to make back up copies of certain information both before and after upgrading. Figure 2-1 illustrates the types of information that Oracle recommends you back up. Unless you have the Access System installed, you can ignore details for the Policy Manager, Access Server, and WebGate.
As depicted in As discussed in Chapter 1, the installation directory for each component includes the following information types:
Component-specific configuration files (and in some cases failover configuration files and the software developer kit (SDK) configurations)
A WebPass must also be installed with each Policy Manager on the same Web server instance, at the same directory level.
For more information, see:
Oracle recommends that you perform certain back up activities before upgrading to help restore an earlier environment in the unlikely event that you want to do this following an upgrade. Table 2-1 provides more information. If you are using the zero downtime upgrade method, see also Part VI.
Table 2-1 Back Up Strategies Before Upgrading
| Back Up the Following Information Types | As Described In |
|---|---|
|
Oracle Access Manager Schema The upgraded schema offers backward compatibility with the earlier schema, as far back as release 6.1.1. However, you cannot roll back a schema upgrade using any Oracle-provided tools. Some directory server vendors provide tools that you can use to back up the schema. If you backed up the earlier schema using external tools before upgrading, you should be able to reinstate the backup copy if you decide to roll back to the original release. |
Chapter 5: Backing up the Earlier Oracle Access Manager Schema |
|
Oracle Access Manager Configuration and Policy Data |
Chapter 5: Backing up Oracle Access Manager Configuration and Policy Data |
|
Oracle Access Manager User and Group Data |
|
|
Oracle Access Manager Workflow Data |
|
|
Processed Workflows |
|
|
Existing Directory Instances |
|
|
Earlier Installed Component File System Directory (and any Customization Directories) Note: With the zero downtime upgrade method, you will create a source that provides details for the upgrade and also becomes a backup copy of the instance. As a result, you do not need to explicitly back up the installation directory. However, you must still take care of customizations. For more information, see Part VI. |
Chapter 5: Backing Up the Existing Component Installation Directory |
|
Web Server Configuration Files |
Chapter 8: Backing Up the Existing Web Server Configuration File |
|
Windows Registry |
After you have completed and verified each component upgrade, Oracle recommends that you back up the upgraded information listed in Table 2-2. This will enable you to restore an upgraded environment to the newly upgraded status should this be needed. You will perform some of the same tasks after upgrading as you did before the upgrade. Only this time, the target will be the newly upgraded instance. If you are using the zero downtime upgrade method, see also Part VI.
Table 2-2 Back Up Strategies After Upgrading
| Back Up the Following Information Types After Upgrading | As Described In |
|---|---|
|
Existing Directory Instances |
|
|
Earlier Installed Component Directory (and any Customization Directories) |
Chapter 5: Backing Up the Existing Component Installation Directory |
|
Web Server Configuration Files |
Chapter 8: Backing Up the Existing Web Server Configuration File |
|
Windows Registry |
Should something unlikely occur and you find that a process did not complete successfully, you can use the strategies in Table 2-3 to recover. Unless explicitly stated, the following recovery strategies apply to both in-place upgrades and the zero downtime upgrade method. If a task applies to only one method, that method is identified.
Table 2-3 Upgrade Recovery Strategies
| Task | What to do If the Task Fails |
|---|---|
|
Backing Up Existing Oracle Access Manager Data |
Retry this task using instructions to back up data in Chapter 5 |
|
Backing Up Existing Directory Instances |
See your directory vendor documentation. |
|
In-place Method: Adding An Earlier Identity System to Use as a Master for the In-place Method (against Read/Write master directory instances, not against read-only replicas) |
Retry this task using instructions to back up data in Chapter 5 |
|
In-place Method: Adding an Earlier Access Manager to Use as a Master for the In-Place Method (against Read/Write master directory instances, not against read-only replicas) |
Retry this task using instructions to prepare for the schema and data upgrade during an in-place upgrade in Chapter 5. |
|
In-place Method: Upgrading Identity System Schema and Data In Place using the in-place upgrade method. |
Restore the directory instance you backed up before starting this upgrade (see "Backing Up Existing Directory Instances"). Locate your backup copy of the earlier master Identity Server installation directory (made before the upgrade) and make another backup copy. You will retain one to as a backup and use the other when you retry the upgrade. See "Backing Up File System Directories, Web Server Configurations, and Registry Details". Retry the upgrade of the master Identity Server using instructions in Chapter 6. Note: User data is not migrated during the upgrade, but is migrated during the first login following the upgrade. For more information about the implications of this, see "Halting On-the-fly User Data Migration at First Login Temporarily". |
|
In-place Method: Enabling Multi-Language Capability when upgrading the master Identity Server from a starting release of 6.1.1 Note: This process does not occur when your starting release is 6.5 or 7.x because those releases automatically supported multi-language capability. |
Restore the directory instance you backed up before starting this upgrade (see "Backing Up Existing Directory Instances"). Locate your backup copy of the earlier master Identity Server installation directory (made before the upgrade) and make another backup copy. You will retain one to as a backup and use the other when you retry the upgrade. See "Backing Up File System Directories, Web Server Configurations, and Registry Details". Retry the upgrade of the master Identity Server using instructions in Chapter 6. |
|
In-place Method: Upgrading Access System Schema and Data In Place |
Restore the directory instance you backed up before starting this upgrade (see "Backing Up Existing Directory Instances"). Locate your backup copy of the earlier master Access Manager installation directory (made before the upgrade) and make another backup copy. You will retain one to as a backup and use the other when you retry the upgrade. See "Backing Up File System Directories, Web Server Configurations, and Registry Details". Retry the upgrade of the master Access Manager using instructions in Chapter 7. |
|
Uploading Directory Server Index Files |
Retry this task using instructions in "Uploading Directory Server Index Files". |
|
In-place Method: Upgrading Components Identity Server, WebPass, Policy Manager (formerly known as the Access Manager component)), Access Server, or WebGate |
Locate your backup copy of the earlier component installation directory (made before the upgrade) and make another backup copy. You will retain one to as a backup and use the other when you retry the upgrade. See "Backing Up File System Directories, Web Server Configurations, and Registry Details". Retry this step and specify the earlier component installation directory when asked for the installation directory. See Part III, "Upgrading Components". |
|
Zero Downtime Method: Adding Profiles for Clones |
Retry this task using instructions in "Recovering From Issues With Information Entered in the System Console". |
|
Zero Downtime Method: Cloning Instances for a Zero Downtime Upgrade |
Remove the clone file system subdirectory and retry this task as described in "Cloning Earlier Components for a Zero Downtime Upgrade". |
|
Zero Downtime Method: Creating and Populating a New Branch in the Directory Server |
Perform steps in "Recovering from Problems With Populating the New Branch". |
|
Zero Downtime Method: Reconfiguring Clones To Use the New Branch |
Retry this task and ensure that all specifications are correct, as described in "Configuring Cloned Components and Services". |
|
Zero Downtime Method: Schema Upgrades |
If you created a back up copy of the schema using external tools, you might be able to restore the schema. |
|
Zero Downtime Method: Clone Upgrades |
Copy the source file system directory. Remove the destination file system directory. Restore the backed up Web server configuration file, and import the backed up Windows registry entry, if needed. For more information, see: For more information, see the following topics: Retry the clone system upgrade as described in following topics: |
|
Zero Downtime Method: Original Instance Upgrades |
Remove the destination file system directory. Restore the backed up Web server configuration file, and import the backed up Windows registry entry, if needed. For more information, see the following topics: Retry the original instance upgrade, as described in following topics: |
|
Upgrading Your Identity System Customizations |
Retry this task using instructions in Chapter 12 |
|
Upgrading Your Access System Customizations |
Retry this task using instructions in Chapter 13 |
Additional information on recovering from an upgrade failure can be found throughout this book. Specific troubleshooting information is located in Appendix G.
There is only one way to start zero downtime upgrade processing and that is by obtaining the 10.1.4.2.0 MigrateOAM script and using it from the command line.
For more information, see "Zero Downtime Upgrade Tools and Processes".
As mentioned earlier, you use the corresponding 10g (10.1.4.0.1) component installer to begin each component upgrade. You can launch the installer using either the graphical user interface (GUI method) or the command-line interface (Console method).
Either Method: Regardless of the method you choose, the sequence of events and prompts are nearly identical. In later chapters, minor differences are identified as they occur during a specific sequence. If you see something that does not apply to your environment or installation, you can ignore it. Also, whether you launch the upgrade using GUI or Console method, you will be asked to choose a mode (Automatic versus Confirmed), as described in "Upgrade Event Modes".
For more information, see:
Note:
These methods do not apply when using tools for the zero downtime upgrade method. For more information about the zero downtime upgrade tools, see "Zero Downtime Upgrade Tools and Processes" .This method is the default for Windows systems when you select the installation package from the file system. For example:
Oracle_Access_Manager10_1_4_0_1_win32_Identity_Server.exe
The command-line method (also known as Console method) is the default for Unix systems. For example:
./ Oracle_Access_Manager10_1_4_0_1_sparc-s2_Identity_Server
Regardless of the method you are using, in-place or zero downtime, at some point during upgrade processing you will be asked to select either Automatic mode or Confirmed mode:
-------------------------------------
Please specify the mode for migration:
'1' - Automatic (recommended)
Each step is performed automatically.
No interaction from the user is required.
'2' - Confirmed
Each step needs confirmation from the user.
Enter choice ( '1' or '2' ) :
--------------------------------------------
For more information about each of these processing modes, see:
Note:
. These modes apply whether you are performing an in-place upgrade or a zero downtime upgrade and regardless of the mode in which you might be running the installer (GUI method or the Console method).Oracle recommends that you choose the Automatic mode. This mode provides declarative messages to keep you informed as the upgrade progresses. For example:
Creating original folders ... ---------------------------------------------------- Copying general configuration files OK. ---------------------------------------------------- Updating parameter catalogs ... OK. ----------------------------------------------------
From time to time in Automatic mode, you are asked to respond to specific queries that require your acceptance before being initiated (or simply acknowledging that you are ready to continue). For example when upgrading the master Identity Server and master Access Manager, you are asked to accept an automatic schema and data upgrade as indicated in this example:
Oracle Access Manager schema migration ...
Retrieving Oracle configuration parameters ...
OK.
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'Yes" to proceed:
For more information about the sequence of automated processes and events, see Chapter 3.
Note:
In both Automatic and Confirmed mode, you are informed as the program completes each step of the upgrade process. This guide provides information using Automatic mode, both for brevity and because this is the recommended method.If you select Confirmed mode during a component upgrade, you are presented with a question before each and every event (not just those that require acceptance during Automatic mode). The types of messages you see in Confirmed mode are shown here:
Copy general configurations files?
'1' - Yes
'2' - No
Enter choice ( '1' or '2' ) : 1
OK.
In Confirmed mode, each event is performed only after you accept by entering the number 1. If you enter the number 2, the event is skipped and you are then asked to accept or decline the next event.
Confirmed mode is recommended for use in only the following situations when you need to conditionally run, skip, and re-run certain event in a component upgrade. For example:
Upgrade Strategies When Support is Changed or Deprecated: Suppose a release 6.1.1 WebPass resides on a computer with a Web server version that is not supported by 10g (10.1.4.0.1). In this case, you must upgrade the 6.1.1 WebPass incrementally, as follows.
Retain the Web server version that is supported for the release 6.1.1 WebPass.
After initiating the WebPass upgrade and selecting Console mode, you accept activities to upgrade the WebPass from the release 6.1.1 to the next Oracle Access Manager release that supports the existing Web server version (to release 6.5 for example). You decline activities to upgrade WebPass further and accept updating the Web server configuration with 6.1.1 to 6.5 information.
After the incremental WebPass upgrade, you must upgrade the Web server to a version that is supported by the next WebPass release using your vendor documentation as a guide.
After upgrading the Web server, you complete another incremental WebPass upgrade in Console mode by skipping the release 6.1.1 to 6.5 events that were already completed and continuing to the next component release that supports the existing Web server.
For more information, see "Upgrade Strategies When Support is Changed or Deprecated".
Correcting Information: Suppose you provide incorrect information during an component upgrade (or another problem arises). In this case, you can also use Confirmed mode to conditionally re-run a step. For example, suppose you entered incorrect information while upgrading the Identity Server. When the upgrade finishes, you can re-run it in Confirmed mode to skip events that completed successfully the first time (and enter correct information for unsuccessful events the second time). For instance, if you forgot to change the schema domain, you can re-run the upgrade using Confirmed mode and fix the problem.
Continue the component upgrade as far as you can despite entering incorrect information.
Restart the component upgrade and choose Confirmed mode.
Skip any events that completed successfully during the initial component upgrade.
Accept and perform any events that were not successful (and restate any incorrect information).
Confirm that the in-place upgrade was successful as described in Part III.
Perform all other tasks in sequence, as described in "In-Place Upgrade Task Overview".
When all upgrade tasks are performed, validate the complete system upgrade as described in Part V.
Table 2-4 describes the items for which support is not longer officially available.
Table 2-4 Deprecated in 10g (10.1.4.0.1)
| Component | Comments |
|---|---|
|
Support was deprecated in release 6.1. If your earlier installation includes Oblix IDLink, you are notified while upgrading the Identity Server. To continue using Oblix IDLink, you must retain the earlier release. |
|
|
Support was deprecated in release 6.0. Publisher cannot operate at the same time as release 6.1 or later. Oracle Access Manager 10g (10.1.4.0.1) provides reporting, auditing, and logging enhancements. You can create, view, and configure reports within the User, Group, and Organization Manager applications. For more information, see the Oracle Application Server Release Notes. |
|
|
Support was deprecated in release 7.0. If your earlier installation includes the CPS, following the upgrade you will have to request and install any new certificates through a third-party vendor. |
|
|
Support was deprecated in release 6.5 when NetPoint SAML Services (now Oracle COREid Federation) became the preferred method to provide access privileges across multiple associated portals and DNS domains. APS remains deprecated. |
|
|
There is no migration path from NetPoint SAML Services to any Oracle Federation product available with 10g (10.1.4.0.1). NetPoint SAML Services was replaced with Oblix SHAREid. |
|
|
Renamed to Oracle COREid Federation. This functionality is now accomplished with Oracle Identity Federation. There is no migration path. However, you can install Oracle Identity Federation after upgrading to Oracle Access Manager10g (10.1.4.0.1). |
|
|
This functionality is now accomplished with Oracle Identity Federation. There is no migration path. However, you can install Oracle Identity Federation after upgrading to Oracle Access Manager10g (10.1.4.0.1). |
|
|
Support for this feature is deprecated in 10g (10.1.4.0.1). There is no migration path. |
|
|
MIIS Provisioning |
Provisioning external applications from Oracle Access Manager by integrating with Microsoft Identity Integration Server (MIIS) is deprecated in 10g (10.1.4.0.1). This functionality is now accomplished with Oracle Identity Manager (Oracle Xellerate Identity Provisioning), and is no longer available in Oracle Access Manager. There is no migration path. |
|
Microsoft .NET Passport |
Support for this feature is deprecated in 10g (10.1.4.0.1). |
|
Support was deprecated in release 7.0.4 (also available as part of Oracle Application Server 10g Release 2 (10.1.2)). This is no longer distributed with the Access Server (including Authn_valicert authentication plug-in, authn_valicert.dll, and authn_valicert_d.dll). |
|
|
This directory is not supported in 10g (10.1.4.0.1). Although the installation screen might still display DirX as a possible option. |
|
|
Support was deprecated in release 7.0.4.2. However, the Security Provider for WebLogic SSPI is still supported. To upgrade an earlier Security Provider for WebLogic SSPI to the latest release, see"Upgrading Third-Party Integration Connectors". To integrate a new Security Provider for WebLogic SSPI, see the Oracle Access Manager Integration Guide. |
This discussion provides strategies to help you proceed with a component upgrade when support for a directory server or Web server version has changed or been deprecated.
The strategies presented here focus on a single component upgrade in a specific situation:
Note:
Before upgrading an Oracle Access Manager installation earlier than release 6.1.1, contact Oracle Support athttp://www.oracle.com/support/contact.htmlWhen 10g (10.1.4.0.1) supports a different Web server or directory server release than those in your earlier installation, you must complete the upgrade a little differently to accommodate upgrading third-party components.
Note:
If you are performing a zero downtime upgrade, see Part VI.The following overview outlines the sequence you need to complete when you must upgrade an Oracle Access Manager component in addition to upgrading a Web server (or directory server) instance to meet 10g (10.1.4.0.1) requirements. This is provided to give you an idea of how to proceed in this situation and is not meant to provide all steps needed to accomplish the task. See your vendor documentation for information about third-party components and other chapters in this guide for details about Oracle Access Manager components and validation steps.
For example, when 10g (10.1.4.0.1) supports the same Web server or directory server versions as your earlier installed Oracle Access Manager release, you simply upgrade each component once and accept changes to third-party configuration files. However, during an upgrade, third-party configuration files are not updated in their entirety. Instead, only the delta is applied (the difference between changes for the old release and changes for 10g (10.1.4.0.1). For this reason, you cannot simply install a new Web server instance and specify the path to it during an upgrade.
Note:
The strategies outlined here presume that you have completed all appropriate preparation tasks, and that you are following steps provided elsewhere in this guide. Preparation, verification, and recovery steps are not repeated here. Steps to upgrade the specific Oracle Access Manager component are not repeated here.Task overview: Upgrading Oracle Access Manager together with third-party product versions
Compare support requirements under the Certify tab at Oracle MetaLink, as follow:
Go to Oracle MetaLink at the following URL:
https://metalink.oracle.com
Log in to Oracle MetaLink as directed
Click the Certify tab.
Click View Certifications by Product
Select the Application Server option and click Submit.
Choose Oracle Identity Manager and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, "Oracle Access Manager Certification" to display the certification matrix.
Directory Server Upgrade: If this applies to your environment, perform the activities in the following list:
Use instructions in Chapter 5 to back up current directory instances and data (and to create and prepare master instances of the earlier Identity Server, WebPass, and Policy Manager against the existing directory server).
Stop all Identity Server services and follow instructions in your vendor documentation to upgrade a third-party directory server to the new level supported by 10g (10.1.4.0.1).
Perform and validate the schema and data on the upgraded directory instance upgrade using the master Identity Server and Policy Manager as described in:
Web Server Upgrades amid Oracle Access Manager Upgrades: If your environment includes an earlier Web server version than is supported by10g (10.1.4.0.1), prepare components and perform upgrade activities as prescribed in this manual with the following differences:
Oracle Access Manager Web Component Upgrades: When you upgrade Web components, accept the automatic Web server configuration file update for the currently installed Web server.
Web Server Upgrade: Use your vendor documentation to back up an older third-party Web server then upgrade it to the new level supported by 10g (10.1.4.0.1).
Manually update the Web server configuration file for 10g (10.1.4.0.1) following the Web server upgrade. For more information, see the Oracle Access Manager Installation Guide.
Note:
You cannot apply Oracle Access Manager-related Web server configuration changes to a new Web server instance.Complete other activities as described in this manual, then validate the upgrade as described in Chapter 14, "Validating the Entire System Upgrade".
In some cases, you might discover that Oracle Access Manager 10g (10.1.4.0.1) does not support an earlier Web Server or directory server release. For example, the release 6.1 Policy Manager supports Sun (formerly iPlanet) 4.x Web server. However, from Oracle Access Manager 6.5 onward this Web server release is not supported.
When 10g (10.1.4.0.1) does not support an earlier Web Server or directory release, you must complete the upgrade as outlined in:
Upgrading with Manual Web Server Configuration When Support is Deprecated
Upgrading Oracle Access Manager Incrementally When Third-Party Support is Deprecated
Note:
Before upgrading an installation earlier than release 6.1.1, contact Oracle Support athttp://www.oracle.com/support/contact.htmlWhen 10g (10.1.4.0.1) support does not include your earlier release Web Server, you can use the strategy here to upgrade to 10g (10.1.4.0.1). For example, from Oracle Access Manager 6.5 onward the Sun (formerly iPlanet) 4.x Web server is not supported. As a result, during the upgrade from Oracle Access Manager release 6.1.1 to release 6.5 the Web server configuration files are not automatically updated. Instead, you must install the Sun 6.x Web server and run EditObjConf and ManageObjConf manually to update the Web server configuration files for Oracle Access Manager release 6.5, 7.x, and 10g (10.1.4.0.1).
The following task overview is provided to give you an idea of how to proceed in this situation and is not meant to provide all steps needed to accomplish the task.
Note:
The strategies outlined here presume that you have completed appropriate preparation tasks, and that you are following steps provided elsewhere in this guide. Preparation, verification, and recovery steps are not repeated here. Steps to upgrade the specific Oracle Access Manager component are not repeated here. Release numbers in examples are provided for illustration only.Task overview: Upgrading when Web server support was deprecated
Upgrade your earlier Oracle Access Manager installation to 10g (10.1.4.0.1), including all Web components (WebPass, Policy Manager, and WebGate).
Note:
Web server configuration files are not automatically updated.Create an instance of the Web server that is supported by 10g (10.1.4.0.1) using your vendor documentation as a guide.
Run the EditObjConf tool for WebPass, Policy Manager (formerly the Access Manager component), then WebGate, as needed.
Run the ManageObjConf tool for WebPass, Policy Manager, then WebGate, as needed.
Perform the component validation step to ensure that it upgraded properly as described in Part III.
The following method describes an incremental upgrade that you can use when the latest Oracle Access Manager release is not compatible with both the currently installed Web server (or directory server) release, and the currently supported release.
In this case, the goal is to use Confirmed mode to upgrade the Oracle Access Manager component incrementally to a release that supports both the earlier Web server (or directory server) release and a later interim Web server (or directory server) release. You repeat the process to incrementally upgrade the Oracle Access Manager component and the third-party component until both are in sync with 10g (10.1.4.0.1).
As you complete this task in confirmed mode, you accept appropriate processes while skipping those that take the Oracle Access Manager component too far. Then, you migrate your earlier Web server (or directory server) to the newer supported release. This might involve a sequence of manual steps to true up the configuration files for the new instance. You might need to repeat this sequence until you have upgraded both the third-party component to a release supported by 10g (10.1.4.0.1), and the Oracle Access Manager is upgraded to 10g (10.1.4.0.1).
In the following task overview, a WebPass upgrade is interspersed with a Web server upgrade. The strategies outlined here presume that you have completed appropriate preparation tasks, and that you are following steps provided elsewhere in this guide. Preparation, verification, and recovery steps are not repeated here. Steps to upgrade the specific Oracle Access Manager component are not repeated here. See also "Console Method".
Note:
Release numbers in examples are provided for illustration only. Before upgrading an installation earlier than release 6.1.1, contact Oracle Support athttp://www.oracle.com/support/contact.htmlTask overview: Upgrading incrementally when Web server support is deprecated
On the computer hosting the earlier Oracle Access Manager Web component (WebPass, Policy Manager, or WebGate), start the upgrade using 10g (10.1.4.0.1) installers. For example:
Start Upgrading: WebPass 5.2 on Sun ONE Web Server 4.1
In Confirmed mode, accept processes that upgrade the Oracle Access Manager Web component only to the next major release that supports the current Web server. For example, in this case you upgrade only to 6.0:
From: WebPass 5.2
To: WebPass 6.0
Note:
Skip any processes that would upgrade this component to a release that does not support the current environment.Accept the automatic Web server configuration file update, and finish the component upgrade for this incremental release.
Migrate the current Web server to the latest level supported by the interim WebPass release, using your vendor documentation as a guide. For example:
From: Sun ONE Web Server 4.1 (supported by Oracle Access Manager 5.2)
To: Sun ONE Web Server 6.0 (supported by Oracle Access Manager 6.0)
Restart the WebPass upgrade, use Confirmed mode to skip processes already completed and accept upgrade processes that upgrade WebPass to a later release that supports the upgraded Web server. For example:
From: WebPass 6.0
To: WebPass 6.1.1
Accept the automatic Web server configuration file update, and finish this incremental component upgrade.
Repeat steps in this list as needed until you reach and meet 10g (10.1.4.0.1) support requirements for the third-party component and upgrade the Oracle Access Manager component to 10g (10.1.4.0.1).
Validate the WebPass upgrade as described in "Finishing and Verifying the WebPass Upgrade".
For more information, see Appendix E. If needed, see "Preparing a Directory Server When Its Release is Deprecated".
