When your installation includes only the Identity System, you can skip the upgrade of Access System integration connectors and upgrade the independently installed SDK. However, when your earlier installation includes the Access System and Oracle Access Manager integration connectors for certain third-party products, you must upgrade integration connectors before upgrading the SDK.
Note: The SDK upgrade that is invoked automatically as the last step when upgrading the Identity Server and Oracle Access Manager Security Connector for WebSphere SSPI has no impact on independently installed SDKs for custom AccessGates. |
Unless explicitly stated, the information in this chapter applies equally to both upgrade methods (in-place component upgrades and zero downtime upgrades). Topics in this chapter include
Note: You must upgrade the Access System before upgrading integration components or an independently installed SDK. If you are using the zero downtime method, see also Part VI. |
When your environment includes the following integrations, you must complete procedures here to ensure compatibility with 10.1.4 and:
Security Provider for WebLogic SSPI
Oracle Access Manager Connector for WebSphere
The task here is similar to other upgrades. The example provided in this chapter illustrates how to upgrade the Oracle Access Manager Security Provider for WebLogic SSPI. However, the procedures are similar for other integration connectors.
For the latest information about configuring release 10g (10.1.4.0.1) integrations, see the Oracle Access Manager Integration Guide.
Task overview: Upgrading third-party Integrations includes
Completing Integration Upgrade Prerequisites.
The sample upgrade here starts from a Oracle Access Manager 6.1.1 installation. Your starting release might differ.
Failure to complete prerequisites in Table 11-1 can adversely affect your upgrade.
Table 11-1 Integration Upgrade Prerequisites
Integration Upgrade Prerequisites |
---|
Schema and Data upgrade is successful as described in Part II. |
Component upgrades are successful as described in Part III. |
Perform all required steps to prepare components as discussed in Chapter 8, and:
|
WebSphere: When upgrading the Oracle Access Manager Connector for WebSphere:
|
Weblogic: Ensure that the NetPointProvidersConfig.properties file in your current connector installation directory is synchronized with the one in your Weblogic server's domain directory. |
Stop the corresponding Application/Portal Server. For example if you are upgrading Security Provider for WebLogic SSPI then you must stop the corresponding WebLogic Application server. |
This is similar to upgrading other components. Should an error occur, the name of the log file that contains information about the error is identified. Skip any details that do not apply to your installation.
The sample upgrade in this procedure starts from an installation that is integrated with the Oracle Security Provider for WebLogic SSPI. Your environment might vary.
To launch the integration connector upgrade
Ensure that you have completed prerequisites for this instance as described in "Integration Upgrade Prerequisites".
Stop the corresponding Application/Portal Server. For example if you are upgrading Security Provider for WebLogic SSPI then you must stop the corresponding WebLogic Application server.
Log in as a user with administrator privileges.
Locate and launch the 10g (10.1.4.0.1) installer in your preferred method:
Dismiss the Welcome screen by clicking Next, then respond to the question about administrator privileges based upon your platform.
Choose the directory where you installed the earlier integration component, then click continue as directed.
Accept the upgrade by clicking Yes, then click Next.
Complete any language questions, as described earlier, then click Next.
When the status screen indicates that this phase is complete, click Next.
Proceed to "Upgrading Security Provider for WebLogic SSPI" next.
This procedure is the similar to other component upgrades. However, it does include several steps that are unique to the Security Provider for WebLogic SSPI.
To upgrade the Security Provider for WebLogic SSPI
Choose an upgrade mode: Automatic or Confirmed.
Follow the prompts onscreen.
The GUI exits, and a command-line window appears with messages that keep you informed.
------------------------------------- Starting migration (6.1.1 -> 6.5.0) ---------------------------------------------------- Updating component-specific configuration files ... OK. ---------------------------------------------------- Starting migration (6.5.0 -> 7.0.0) ---------------------------------------------------- Updating component-specific configuration files ... OK. ---------------------------------------------------- Starting migration (7.0.0 -> 10.1.4) ---------------------------------------------------- Updating component-specific configuration files ... OK. ---------------------------------------------------- Migration has completed successfully! Press <ENTER> to continue :
Upgrade the software developer kit (SDK); otherwise, current SDK configuration settings are not preserved and you must reconfigure the SDK later using the configureAccessGate tool, as described in the Oracle Access Manager Access Administration Guide.
If you are upgrading the Security Provider for WebLogic SSPI, complete the following steps.
Note: If you are upgrading the integration component for WebSphere Application Server and Portal Server, you must copy the NetPointCMR.jar file to the Portal_install_dir and the NetPointWASRegistry.jar file and jobaccess.jar to the WAS_install_dir then restart the servers. See the Oracle Access Manager Integration Guide for details. |
To finish the Security Connector upgrade
Copy the appropriate mbean jar file from following location. For example:
From: SecurityProvider_install_dir/oblix/lib/mbeantypes
To: WebLogic_Home/server/lib/mbeantypes
Copy the files here from your SecurityProvider_install_dir to your WebLogic domain folder.
NetPointProvidersConfig.properties
NetPointResourceMap.conf (only for the Application Server domain)
Start the Application/Portal/Web server to confirm that this upgrade was successful.
Server Does Not Start: Confirm that you have performed all tasks and specified all information accurately. Look for troubleshooting tips in Appendix G.
View migration log files to see if they contain any errors. See "Accessing Log Files".
Upgrade Successful: Perform activities in "Backing Up Upgraded Integration Connector or SDK Data" for this instance, then continue upgrading earlier Policy Managers.
Upgrade Not Successful: Proceed to "Recovering From an Integration Connector or SDK Upgrade Failure".
After upgrading all integration connectors, proceed with "Upgrading Independently Installed Software Developer Kits" next.
The SDK (formerly known as the Access Server SDK) is now named the Access Manager SDK in 10.1.4. The SDK upgrade that is invoked automatically as the last step when upgrading components bundled with the SDK (the Identity Server and Oracle Access Manager Security Connector for WebSphere SSPI, for example), has no impact on independently installed SDKs for custom AccessGates.
On Windows, if you plan to continue using the SDK provided for the .NET Framework 1.1, you must upgrade any independently installed SDK as described here. After applying the 10g (10.1.4.3) patch, you can also install the .NET 2 SDK for custom AccessGates as described in the Oracle Access Manager Developer Guide. You can both .NET 1 and .NET 2 SDKs and AccessGates.
Note: If you use the 10g (10.1.4.3).NET 2 SDK, you might want to recompile earlier custom AccessGates, as described in "Recompiling Custom AccessGates for .NET 2 Support". |
Task overview: Upgrading the Software Developer Kit includes
Completing all SDK Upgrade Prerequisites
Starting the SDK Upgrade, Specifying a Target Directory and Languages
Before you begin upgrading the Software Developer Kit, check the tasks in Table 11-2 to ensure you have performed these. Failure to complete prerequisites can adversely affect your upgrade.
Table 11-2 SDK Upgrade Prerequisites
SDK Upgrade Prerequisites |
---|
Complete activities in Part II. |
Complete activities in Part III, as needed for your environment. |
Integration Components: Upgrade integration components, as described in "Upgrading Third-Party Integration Connectors", if appropriate for your environment. |
Perform all required steps in Chapter 8 for this instance and host, and:
|
The sample upgrade here starts from a release 6.1.1 installation. Your starting release and environment might vary. Should an error occur, the name of the log file that contains information about the error is identified.
This procedure presumes you are performing an in-place upgrade using 10g (10.1.4.0.1) packages. However, you might be performing a zero downtime upgrade, as described in Part VI, "Upgrading Using the Zero Downtime Upgrade Method".
You can skip any details that do not apply to your installation.
Confirm that all activities in "SDK Upgrade Prerequisites" have been completed.
Turn off the server or service then log in as a user with administrator privileges.
Locate and launch the program in your preferred method:
The Welcome screen appears.
Dismiss the Welcome screen, then respond to the administrator question based upon your platform.
Choose the directory where you installed the earlier SDK, then click Next
Accept the upgrade by clicking Yes, then click Next.
Ensure that a check mark appears beside English and any other languages you have installed, then click Next.
Confirm the languages listed by clicking Next.
Record the time-stamped directory name, then continue.
Record the amount of disk space required, then start the file extraction into the target directory.
UNIX—Run the command indicated, then press Enter to continue.
Proceed to "Upgrading the SDK Configuration and Verifying the Upgrade" next.
This procedure requires little input from you.
To upgrade the SDK configuration
Specify either Automatic or Confirmed, then continue.
Status messages about the upgrade start scrolling by:
------------------------------------- Starting migration ( 6.1.1 -> 6.5.0 )... ------------------------------------- Copying general configuration files... OK. ------------------------------------- Updating message catalogs... OK. ------------------------------------- Updating parameter catalogs... OK. ------------------------------------- Updating component-specific configuration files... OK. --------------------------------------
The sequence will repeat until 10g (10.1.4.0.1) is reached, then you will see the message:
------------------------------------- Migration has completed successfully! Press <ENTER> to continue :
Finish the upgrade as directed, then restart the server service.
Server or Service Does Not Start: Confirm that you have performed all tasks and specified all information accurately. Look for troubleshooting tips in Appendix G.
View migration log files to see if they contain any errors. See "Accessing Log Files".
Upgrade Successful: Perform activities in "Backing Up Upgraded Integration Connector or SDK Data".
Upgrade Not Successful: Proceed to "Recovering From an Integration Connector or SDK Upgrade Failure".
Repeat for each independently installed SDK in your environment, then see "Looking Ahead".
As mentioned earlier, Oracle recommends that you finish each component upgrade by backing up the latest component directory after verifying that it is working properly. This will enable you to easily restore your environment to the newly upgraded state should that be a requirement.
To back up critical information after the integration connector or SDK upgrade
Back up the upgraded integration connector or SDK directory and store it in a new location.
Web Server: Back up the upgraded Web server configuration file, if needed, using your vendor documentation as a guide.
Back up Windows registry data if required.
If the component was not successful, you can perform the following steps to rollback this upgrade, then try again.
To recover from an unsuccessful integration connector or SDK upgrade
Restore the earlier directory that you backed up before this upgrade (to recover the earlier environment), then back it up again. You will retain one of the earlier directories as a backup copy and use one to restart the upgrade.
Windows: Restore the backed up registry for the component (to recover the earlier environment).
Web Server: Restore the earlier backed up Web server configuration file, if required for this component (to recover the earlier environment).
Using a backup copy of your earlier environment, restart the upgrade as described in this chapter.
Upgraded Identity and Access System components send and receive information sent in UTF-8 encoding. Earlier components send and receive data in Latin-1 encoding. To continue the upgrade, proceed as appropriate for your earlier installation. For example:
Identity System Only: When your earlier installation does not include the Access System, you complete activities in the sequence listed here using information in:
Joint Identity and Access System: In this case, you must complete activities in the following sequence using information in:
For more information about expected system behaviors, see Chapter 4.