| 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 provides important information to help you prepare your earlier environment before you begin upgrading remaining Identity and Access System components. Refer to your own planning documents and use the summaries in Appendix F to track your progress.
Unless explicitly stated, you perform these activities regardless of the upgrade method you are using. For details about zero downtime upgrades, see Part IV. You also perform these tasks when you are upgrading while switching from a Solaris platform to Linux as described in Appendix B. Topics in this chapter include:
Note:
New product and component names are used in this chapter even when referring to the earlier product and components. For example, Oracle Access Manager is used instead of Oblix NetPoint or Oracle COREid. For more information, see "What's New in Oracle Access Manager?".There are several actions you need to take to confirm compatibility between your earlier installation and 10g (10.1.4.0.1). As mentioned in Chapter 2, support for some items has been deprecated. In some cases, you might need to decide how to proceed given the support changes.
To confirm compatibility with 10g (10.1.4.0.1)
Review "Support Deprecated"
Review 10g (10.1.4.0.1) platform support, as described here:
Navigate to MetaLink at https://metalink.oracle.com.
Log in to 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.
When directory server or Web server versions or platform support has changed, see "Upgrade Strategies When Support is Changed or Deprecated", for information about how to proceed.
All standard plug-ins are copied during the upgrade, as are custom authorization and authentication plug-ins. However, custom Identity Event plug-ins created using the Identity Event Plug-in API are not copied during the upgrade.
Oracle recommends that you complete the following procedure to prepare custom Identity Event plug-ins for possible redesign before the upgrade, in a small isolated environment or (zero downtime clone environment).
To copy Identity Event Plug-ins before the upgrade
Before the upgrade, create a directory for your old Identity Event plug-ins in the top level of your Identity Event API directory.
Copy custom Identity Event plug-ins in to the new directory.
Proceed to "Preparing Earlier Customizations" next.
Oracle recommends that you start manually processing customizations in your existing environment well in advance of upgrading components. This should occur in a test or development environment to minimize service disruptions. After completing the upgrade and testing your customizations, you can deploy them in the upgraded environment as discussed in "Customization Upgrade Planning".
Note:
If you are using the zero downtime upgrade method, Oracle recommends that you perform customization upgrades early and test these thoroughly within the upgraded clone environment. For more information, see also "Customization Upgrades Using the Zero Downtime Upgrade Method".For many customizations, you can start work before upgrading components, regardless of the upgrade method you are using. However, a few customization upgrades can be accomplished only after upgrading components.
Identity System: The overview here lists Identity System customization work that must be performed and where to find details within Chapter 12.
Task overview: Upgrading earlier Identity System customizations includes
Joint Identity and Access System: In addition to the Identity System work that is outlined in the previous task overview, you must also upgrade earlier Access System customizations. The next overview outlines Access System customization upgrades that you need to perform manually. For details, see Chapter 13.
Task overview: Upgrading earlier Access System customizations includes
Recompiling and Redesigning Custom Authentication and Authorization Plug-Ins
Associating Release 6.1.1 Authorization Rules with Access Policies
Assuring Proper Authorization Failure Re-directs After Upgrading from 6.1.1
Updating the ObAMMasterAuditRule_getEscapeCharacter in Custom C Code
For more information, see "About Upgrading and Backward Compatibility".
Before the upgrade, the default logout should be unprotected in the Policy Manager. Otherwise, after the upgrade, users will be challenged when they click the Logout link.
To prepare the default logout for an upgrade
Confirm that the default logout is not protected in the Policy Manager.
If you use oblogout.cgi for WebGate logouts, be sure that it is installed on the target server.
Preparing computers hosting the earlier installation includes the following procedures:
For additional information, see "Backing Up File System Directories, Web Server Configurations, and Registry Details".
If you are running the Identity System using Simple or Cert mode, your password.xml file in the IdentityServer_install_dir\identity\oblix\config directory is not readable. The same issue applies to the Access System password.lst file in install_dir\access\oblix\config.
To prepare password files for the upgrade
For Identity System upgrades, assign read permissions to password.xml for the duration of the upgrade process. See also, "Logging in with Appropriate Administrative Rights".
Reset password.xml to the desired permissions after the upgrade is complete.
For Access System upgrades, repeat the steps in this list on the password.lst file.
You need enough disk space on the computer hosting the earlier component for both the earlier Oracle Access Manager release and the new release.
To confirm you have enough disk space
Check the Oracle Access Manager Installation Guide for the disk space required for the new component.
On the computer hosting the component to be upgraded, check the amount of disk space required for the earlier installation that will be retained in a renamed time-stamped source directory.
To ensure success when upgrading certain Oracle Access Manager 6.x installations (excepting 6.5.1), you must add specific bundles in to your original Component_install_dir in addition to the standard 10g (10.1.4.0.1) installation packages. Discussions here identify additional files needed when you are starting the upgrade from specific releases only:
WARNING:
Use only the files that are relevant to your specific installation. See also "Preparing Multi-Language Installations".
During the upgrade to 10g (10.1.4.0.1), the installer for each component creates a directory named "orig" and compares the environment to ensure appropriate files are upgraded. The original Oracle Access Manager 6.5.0 release did not provide an upgrade capability and, therefore, did not create a file named "orig".
As a result, before you upgrade from Oracle Access Manager 6.5.0.x, you must extract and add the following packages to your original Component_install_dir.
| Extract 65-orig Packages to the Original Component_install_dir |
|---|
| Netpoint_65_orig_en_COREid_Server_msg.zip |
| Netpoint_65_orig_COREid_Server_param.zip |
| Netpoint_65_orig_en_Access_Manager_msg.zip |
| Netpoint_65_orig_Access_Manager_param.zip |
| Netpoint_65_orig_en_WebPass_msg.zip |
| Netpoint_65_orig_WebPass_param.zip |
| Netpoint_65_orig_en_Access_Server_msg.zip |
| Netpoint_65_orig_Access_Server_param.zip |
| Netpoint_65_orig_en_WebGate_msg.zip |
| Netpoint_65_orig_WebGate_param.zip |
| Netpoint_65_orig_en_AccessServerSdk_msg.zip |
To obtain the 65_orig packages
Obtain the 65_orig packages listed in the preceding list from Oracle MetaLink, as follows:
In your browser, enter the following URL:
Log in to MetaLink, as usual.
From the Quick Find list, select Patch Number.
Enter 5724938 in the field beside Quick Find Patch Number, then click the Go button.
The results of your search are displayed with the description: UNABLE TO LOCATE MIGRATION BUNDLE FOR 6.5-10.1.4 UPGRADE.
Note:
The Platform is automatically specified as Microsoft Windows 2000 because the bundles contain only text files that can be used on any platform; there are no binary files.Click the Download button and follow instructions on the screen, then proceed with step 2.
Extract (untar) the files to the original installation directory for each component.
This creates a new directory named "orig" for each component. For example: Component_install_dir/identity/oblix/orig (or Component_install_dir/access/oblix/orig).
Finish preparing your environment as described in this chapter and:
If your installation includes a release 6.5.2.x patch set, see "Adding Packages for Release 6.5.2.x Patch"
If your installation includes multiple languages, see "Preparing Multi-Language Installations"
During the upgrade, the 10g (10.1.4.0.1) component installerrs create a directory named "orig" and compare the environment to ensure appropriate files are upgraded. If you originally installed release 6.5.0.x, then patched it to 6.5.2.x, you must extract and add the following packages to your original Component_install_dir before the upgrade.
| Extract 652_orig Packages to the Original Component_install_dir |
|---|
| Netpoint_652_orig_en_COREid_Server_msg.zip |
| Netpoint_652_orig_COREid_Server_param.zip |
| Netpoint_652_orig_en_WebPass_msg.zip |
| Netpoint_652_orig_WebPass_param.zip |
| Netpoint_652_orig_en_Access_Manager_msg.zip |
| Netpoint_652_orig_Access_Manager_param.zip |
| Netpoint_652_orig_en_Access_Server_msg.zip |
| Netpoint_652_orig_Access_Server_param.zip |
| Netpoint_652_orig_en_WebGate_msg.zip |
| Netpoint_652_orig_WebGate_param.zip |
| Netpoint_652_orig_AccessServerSdk_param.zip |
| Netpoint_652_orig_en_AccessServerSdk_msg.zip |
Note:
You complete the next procedure only if the 6.5.2 patch was applied to a 6.5.0 installation. If your 6.5.2 installation was installed without a patch, ignore this procedure.Obtain the 652 packages in the preceding list from Oracle MetaLink, as follows:
In your browser, enter the following URL:
Log in to MetaLink, as usual.
From the Quick Find list, select Patch Number.
Enter 5724938 in the field beside Quick Find Patch Number, then click the Go button.
The results of your search are displayed with the description: UNABLE TO LOCATE MIGRATION BUNDLE FOR 6.5-10.1.4 UPGRADE.
Note:
The Platform is automatically specified as Microsoft Windows 2000 because the bundles contain only text files that can be used on any platform; there are no binary files.Click the Download button and follow instructions on the screen, then proceed to step 2.
Extract (untar) these to the original installation directory for each component.
This creates a new directory named "orig" for each component. For example: Component_install_dir/identity/oblix/orig (or Component_install_dir/access/oblix/orig).
If your installation includes multiple languages, see "Preparing Multi-Language Installations".
Finish preparing your environment as described in this chapter and start the upgrade.
If you upgrade a multi-language installation without including the corresponding 10g (10.1.4.0.1) Language Packs, you will lose the multi-language functionality. When you include 10g (10.1.4.0.1) Language Packs to the same directory as the 10g (10.1.4.0.1) installer, you can preserve your multi-language capability. After upgrading, you can add new languages as described in the Oracle Access Manager Installation Guide.
To add multi-language functionality after upgrading:
In-place Method: You can install 10g (10.1.4.0.1) Language Packs independently, after upgrading in place to 10g (10.1.4.0.1).
Zero Downtime Method: You can install 10g (10.1.4.0.1) Language Packs independently, after creating the 10g (10.1.4.0.1) destination and before applying in place to Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Note:
There is no independent Language Pack for English (en-us) because this is the default language. There are no 10g (10.1.4.2.0) Language Packs.To preserve existing multi-language functionality
Locate and add any 10g (10.1.4.0.1) Language Packs that correspond to your earlier installed languages to the same directory as the 10g (10.1.4.0.1) component installer.
Upgrade your earlier installation as described in this manual for the method you have chosen.
Oracle recommends that you complete activities in the topics here before upgrading to help ensure that you can roll back to the original installation should any problem arise:
Before starting each component (or customization) upgrade, Oracle recommends that you back up the installation directory for the earlier instance and store this backup in a different location. This will enable you to retrieve the original directory later should you need to restore the environment and rerun the upgrade.
Note:
When you use the zero downtime upgrade method, you will create a source. The source becomes a backup directory that remains intact during the upgrade. For zero downtime upgrades, you do not need to create a backup copy of the installation directory. For more information about this method, see Part VI.In-place Method: As described earlier, a time-stamped directory of original files is created when you upgrade each component using the in-place upgrade. This system-generated directory contains earlier original files that are sometimes accessed to compare content or extract customized information. The time-stamped directory is stored in the same location as the upgraded 10g (10.1.4.0.1) directory. For example:
C:\611\identity_server\identity
C:\611\identity_server\identity_20060714_1701
To back up the existing installed directory
On the computer hosting the component you will upgrade, locate the current installation directory. For example:
C:\611\identity_server\identity
Copy the directory and store the copy in a new location. For example:
D:\611_backup\identity_server\identity
Before starting any Web server component upgrade (WebPass, Policy Manager, WebGate), Oracle recommends that you back up the existing Web server configuration file and store this backup in a different location.
The files to be backed up will vary, depending upon the Web server type. For example:
Netscape or Sun One Web Server: back up the obj.conf and magnus.conf files
All Apache-based Web Servers (including Apache v1 and v2 Web Servers, IBM HTTP Server (IHS) powered by Apache, and Oracle HTTP Server (OHS)): back up httpd.conf
Internet Information Services (IIS) Web Servers): use the Microsoft Configuration Backup/Restore feature as described in the following procedure.
Domino Web Servers: Oracle recommends that you capture screen shots of each page of the Web server configuration using the Web server's graphical user interface (GUI). If needed, you can refer to the screens to reconfigure the Domino Web server if you need to restore or roll back to the earlier configuration. Domino does not maintain any configuration file that can be backed up.
To back up the existing Web Server configuration file
On the computer hosting the Web component you will upgrade, locate the existing Web server configuration file. For example:
C:/IHS_install_dir/conf/httpd.conf
Copy the Web server configuration file and store the copy in a new location. For example:
D:/IHS_install_dir/conf/httpd.conf
IIS 5: Perform the following steps.
Right click the computer name in the Internet Information Services (IIS) Manager MMC snap-in.
Click Backup/Restore Configuration.
Click the Create Backup button.
IIS 6: Perform the following steps.
Right click the computer name in the Internet Information Services (IIS) Manager MMC snap-in.
Click All Tasks, click Backup/Restore Configuration.
Click the Create Backup button.
Domino Web servers: Reconfigure the Web server using the GUI and screen shots of the previous configuration.
Before starting each component upgrade on a Microsoft Windows system, Oracle recommends that you back up any registry data that includes Oracle Access Manager (formerly NetPoint or COREid) data.
To back up Windows Registry data
Run the regedit command
Chose the key "My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Oblix\Oblix NetPoint"
Click "Registry" in the menu then select "Export registry file…" in the drop-down. menu.
Specify the export file name in the "Export Registry File" dialog.
Save the exported registry file to a known location.
Again, this will enable you to roll back to the previous installed environment and restart the upgrade, should a failure occur. Refer to your Windows documentation for details.
Before you start to upgrade to10g (10.1.4.0.1), you must stop the earlier server or service on the computer hosting the component to be upgraded.
For example, if you use WebPass, you need to stop the Web server on which the WebPass is installed. For an Identity Server, you need to stop the Identity Server service. For Identity Servers, you can use the following command to ensure that all Identity Server processes have been stopped on Solaris computers:
ps -ef | grep IdentityServer_install_dir
For Access Servers, ensure that all Access Server processes are completely shutdown before upgrading to the 10g (10.1.4.0.1) Access Server. To ensure that all Access Server processes have been stopped on Solaris computers, use the command shown next:
ps -ef | grep AccessServer_install_dir
Any still-running Access Server processes can be terminated using the kill -9 command.
IIS users: Stop the IIS Admin Service.
To stop servers or services before the upgrade
Locate the computer hosting the component you will upgrade.
Stop the Web server (WebPass, Policy Manager, and WebGate) or the service (Identity Server and Access Server).
If you are upgrading any integration components, stop the corresponding Application or Portal Server. For example if you are upgrading Security Provider for WebLogic SSP, you must stop the corresponding WebLogic Application Server.
Whether you upgrade or install an Oracle Access Manager component, you must log in as a user with administrative rights. On Solaris, you need to run the upgrade as the user who installed the previous release of Oracle Access Manager, or as a user with higher privileges.
Whenever a schema and data upgrade is involved in the upgrade process, you need to login as a user who has permission to change the schema and data in the directory server. In other words, the bind DN you use must have permission to update the directory.
Ensure that you have a userid and password that provides the rights you need to perform the upgrade as well as any schema and data changes that occur during the upgrade.
On the computer hosting the component to upgrade, log in as a user with administrative rights.
