Skip Headers
Oracle® Access Manager Upgrade Guide
10g (10.1.4.3)

Part Number E12495-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

8 Preparing Components for the Upgrade

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?".

8.1 Checking Compatibility with Previous Releases

There are several actions that you must take to confirm compatibility between your earlier installation and 10.1.4. 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 10.1.4

  1. Review "Support Deprecated"

  2. Review 10.1.4 platform support, as described here:

    1. Go to Oracle Technology Network:

      http://www.oracle.com/technology/software/products/ias/files/idm_certification_101401.html
      
    2. Locate and click the link for Oracle Access Manager Certification.

      System Requirements and Supported Platforms for Oracle Access Manager 10gR3 (xls)

  3. 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.

8.2 Copying Custom Identity Event Plug-ins

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

  1. Before the upgrade, create a directory for your old Identity Event plug-ins in the top level of your Identity Event API directory.

  2. Copy custom Identity Event plug-ins in to the new directory.

  3. Proceed to "Preparing Earlier Customizations" next.

8.3 Preparing Earlier Customizations

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

  1. Upgrading Auditing and Access Reporting for the Identity System

  2. Combining Challenge and Response Attributes on a Panel

  3. Confirming Identity System Failover and Load Balancing

  4. Migrating Custom Identity Event Plug-Ins

  5. Ensuring Compatibility with Earlier Portal Inserts

  6. Incorporating Customizations from Release 6.5 and 7.x

  7. Incorporating Customizations from Releases Earlier than 6.5

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 must perform manually. For details, see Chapter 13.

Task overview: Upgrading earlier Access System customizations includes

  1. Upgrading Auditing and Reporting for the Access Server

  2. Upgrading Forms-based Authentication

  3. Recompiling and Redesigning Custom Authentication and Authorization Plug-Ins

  4. Associating Release 6.1.1 Authorization Rules with Access Policies

  5. Assuring Proper Authorization Failure Re-directs After Upgrading from 6.1.1

  6. Updating the ObAMMasterAuditRule_getEscapeCharacter in Custom C Code

For more information, see "About Upgrading and Backward Compatibility".

8.4 Preparing the Default Logout in the Policy Manager

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

  1. Confirm that the default logout is not protected in the Policy Manager.

  2. If you use oblogout.cgi for WebGate logouts, be sure that it is installed on the target server.

8.5 Preparing Host Computers

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".

8.5.1 Changing Read Permissions on Password Files

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

  1. 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".

  2. Reset password.xml to the desired permissions after the upgrade is complete.

  3. For Access System upgrades, repeat the steps in this list on the password.lst file.

8.5.2 Confirming Free Disk Space

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

  1. Check the Oracle Access Manager Installation Guide for the disk space required for the new component.

  2. 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.

8.6 Preparing Release 6.x Environments

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".

8.6.1 Adding Packages for Release 6.5.0.x

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

  1. Obtain the 65_orig packages listed in the preceding list from My Oracle Support (formerly MetaLink), as follows:

    1. In your browser, enter the following URL:

      http://metalink.oracle.com

    2. Log in, as usual.

    3. From the Quick Find list, select Patch Number.

    4. 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 you can use on any platform; there are no binary files.
    5. Click the Download button and follow instructions on the screen, then proceed with step 2.

  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).

  3. Finish preparing your environment as described in this chapter and:

8.6.2 Adding Packages for Release 6.5.2.x Patch

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.

To obtain the 6.5.2 packages

  1. Obtain the 652 packages in the preceding list from My Oracle Support (formerly MetaLink), as follows:

    1. In your browser, enter the following URL:

      http://metalink.oracle.com

    2. Log in, as usual.

    3. From the Quick Find list, select Patch Number.

    4. 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 you can use on any platform; there are no binary files.
    5. Click the Download button and follow instructions on the screen, then proceed to step 2.

  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).

  3. If your installation includes multiple languages, see "Preparing Multi-Language Installations".

  4. Finish preparing your environment as described in this chapter and start the upgrade.

8.7 Preparing Multi-Language Installations

The Language Pack release that you require will depend upon the Oracle Access Manager release that you plan to use after upgrading or patching. For example, if you plan to upgrade or patch to Oracle Access Manager:

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.

Retaining Multi-Language Functionality During the Upgrade: If you upgrade a multi-language installation without including the corresponding 10g (10.1.4.0.1) Language Packs, you will lose current multi-language functionality. However, you can preserve multi-language functionality by including 10g (10.1.4.0.1) Language Packs in the same directory as the 10g (10.1.4.0.1) installer before the upgrade. After upgrading, you can add new Language Packs, as described in the following procedure.

You can use the following procedure with either the in-place upgrade method or the zero downtime upgrade method.

To preserve existing multi-language functionality during an upgrade

  1. Add to the same directory as the 10g (10.1.4.0.1) component installer any 10g (10.1.4.0.1) Language Packs that correspond to earlier installed languages.

  2. Upgrade your earlier installation using either method described in this book.

  3. After upgrading and before applying the latest patch sets, see "Preparing Upgraded Environments for 10g (10.1.4.3) Language Packs".

8.8 Backing Up File System Directories, Web Server Configurations, and Registry Details

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:

8.8.1 Backing Up the Existing Component Installation Directory

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 decide 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

  1. On the computer hosting the component you will upgrade, locate the current installation directory. For example:

    C:\611\identity_server\identity

  2. Copy the directory and store the copy in a new location. For example:

    D:\611_backup\identity_server\identity

8.8.2 Backing Up the Existing Web Server Configuration File

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: 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 choose 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

  1. 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

  2. Copy the Web server configuration file and store the copy in a new location. For example:

    D:/IHS_install_dir/conf/httpd.conf

  3. IIS 5: Perform the following steps.

    1. Right click the computer name in the Internet Information Services (IIS) Manager MMC snap-in.

    2. Click Backup/Restore Configuration.

    3. Click the Create Backup button.

  4. IIS 6: Perform the following steps.

    1. Right click the computer name in the Internet Information Services (IIS) Manager MMC snap-in.

    2. Click All Tasks, click Backup/Restore Configuration.

    3. Click the Create Backup button.

  5. Domino Web servers: Reconfigure the Web server using the GUI and screen shots of the previous configuration.

8.8.3 Backing Up Windows Registry Data

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

  1. Run the regedit command

  2. Chose the key "My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Oblix\Oblix NetPoint"

  3. Click "Registry" in the menu then select "Export registry file…" in the drop-down. menu.

  4. Specify the export file name in the "Export Registry File" dialog.

  5. 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.

8.9 Stopping Servers and Services

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 must stop the Web server on which the WebPass is installed. For an Identity Server, you must 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

  1. Locate the computer hosting the component you will upgrade.

  2. Stop the Web server (WebPass, Policy Manager, and WebGate) or the service (Identity Server and Access Server).

  3. 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.

8.10 Logging in with Appropriate Administrative Rights

Whether you upgrade or install an Oracle Access Manager component, you must log in as a user with administrative rights. On Solaris, you must 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 must 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.

To login before the upgrade

  1. Ensure that you have a userid and password that provides the rights required to perform the upgrade as well as any schema and data changes that occur during the upgrade.

  2. On the computer hosting the component to upgrade, log in as a user with administrative rights.