17 Upgrading the Original System

This chapter describes how to upgrade your original system using the zero downtime upgrade method. Oracle recommends that you review all information about the zero downtime upgrade method to ensure that this approach is the right one for your enterprise. This chapter includes the following topics:

• Prerequisites For Original Upgrades with the Zero Downtime Method

• Retrieving Changes in the Original Branch Before Upgrading Originals

• Reconfiguring Domain Name Systems (DNS) to Use Upgraded Clones

• Upgrading Your Original Identity System

• Upgrading SDKs and Identity System Customizations

• Upgrading Your Original Access System

• Upgrading SDKs, Integration Connectors, and Access System Customizations

• Starting On-the-fly User Data Migration

• Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment

• Deleting the Temporary Directory Server Profile

• Reverting Backward Compatibility

• Removing the Cloned System After Upgrading Originals

Note: If you are using the in-place upgrade method, skip this chapter.

17.1 Prerequisites For Original Upgrades with the Zero Downtime Method

Confirm that you and your team have performed the following zero downtime upgrade tasks, as described in Chapter 16:

• Creating and populating a new branch in the LDAP directory server

• Upgrading the Schema

• Upgrading data in the new branch of the LDAP directory server

• Upgrading the clone system

• Upgrading SDKs, integration connectors, and customizations

• Validating the upgraded clone system

• Backing up the upgraded clone system

• Familiarizing yourself with 10g (10.1.4.2.0) features and functions

17.2 Retrieving Changes in the Original Branch Before Upgrading Originals

If changes are made to the original system after you create the new branch in the LDAP directory server for the clones and before you upgrade the original, the changes are stored in the original branch in the LDAP directory server (or in configuration files). In this case, before you upgrade original instances you might want to create another new branch in the LDAP directory server to contain the very latest version of the original data.

After creating the newest branch and populating it with the latest data from the original system, you will reconfigure the clones to use the newest branch and then upgrade the clones anew. The following overview outlines the tasks that you must perform if you choose to complete this task. Here are a few considerations:.

• You can reuse the existing clone profiles in the original System Console. However, if you isolated the original system by removing clone profiles, you must add new clone profiles.

• You can reuse the existing clone file system and source subdirectories on each host.

• You will reconfigure the clone source to use the newest branch in the LDAP directory server.

• You must delete the destination that was created and upgraded based on details from the source.

• You will create a new destination before upgrading the clone.

• If you have new instances, you will want to create clones and add profiles to the original System Console.

• If you have new customizations, you will need to upgrade these manually and test them thoroughly with the upgraded cloned system.

Task overview: Retrieving changes to data in the original branch before upgrading original instances

1. Immediately before upgrading the original system:

   1. Ensure the original system is running properly and serving customers.

   2. Shut down all clone servers and services.

   3. In the LDAP directory Server, remove the new branches that were added for the clone system.

   4. Retain the clone file system on each host computer, and retain each source that was created before upgrading each clone instance.

      
      

      Note: If you remove the clone file system and source, you will need to create these anew.

      
      

   5. In the clone file system path, remove each upgraded destination because these are configured to use the branch that you deleted in Step c.

2. In the LDAP directory server, create a newer branch and populate it with the latest version of original configuration and policy data. For details, see "Copying Configuration and Policy Data to a New Branch in the LDAP Directory Server".

3. No Clone File System or No Source: If you removed a clone file system or source in Step 1, you need to create the clone anew. For details, see "Cloning Earlier Components for a Zero Downtime Upgrade".

4. In the original System Console, ensure that all clone instances have a profile.

5. Absent Clone Profiles in the Original System Console: Add a profile to the original System Console for each clone instance that does not have a profile. For details, see "Preparing the Original Installation for a Zero Downtime Upgrade".

6. Configure each clone to use the newest branch. For more information, see "Configuring Cloned Components and Services", and consider the following:

   • If you retained the cloned source in Step 1, you will reconfigure the source to use the newest branch.

   • If you created new clones in Step 3, you will not yet have a source and instead must reconfigure the clone instance

7. Upgrade the reconfigured clones using instructions in "Upgrading the Cloned Identity System" and the following:

   1. Skip the Source Creation step if you reconfigured an existing source to use the newest branch in Step 6.

   2. Perform steps to create a destination and obtain 10g (10.1.4.2.0) tools for each clone instance upgrade.

   3. Upgrade Identity System instances as described in "Upgrading the Cloned Identity System" .

   4. Perform tasks in "Renaming Audit Files After Upgrading Identity System Clones".

   5. Upgrade Access System instances as described in "Upgrading the Cloned Access System".

8. Validate the upgraded clone system as described in "Validating Successful Operations in Your Environment".

9. Go to "Reconfiguring Domain Name Systems (DNS) to Use Upgraded Clones".

10. Upgrade the originals as described in the following topics, which are located in this chapter:

    1. Upgrading Your Original Identity System

    2. Upgrading Your Original Access System

    3. Validating the Entire Upgraded Original Environment

    4. Starting On-the-fly User Data Migration

    5. Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment

    6. Removing the Cloned System After Upgrading Originals

17.3 Reconfiguring Domain Name Systems (DNS) to Use Upgraded Clones

When you are completely satisfied that the upgraded cloned system is fully operational, it can function as a failover system for your original setup. Until you perform this task, the production setup is serving your user community and the upgraded clone setup is not available to customers.

To avoid any downtime when upgrading original servers, the requests to the original servers must be redirected either to the cloned servers that have been upgraded or to other original servers. There are several ways to achieve this redirection:

• You can configure the DNS to redirect requests that target original COREid Server and WebPass system URLs to cloned Identity Server and WebPass system URLs.

• You can set up load balancing to ensure that requests that target original COREid Server and WebPass components are redirected to cloned and upgraded Identity Server and WebPass components (or other original COREid Server and WebPass components).

Reconfiguring DNS to redirect network traffic is outside the scope of this manual. For more information about setting up load balancing, see theOracle Access Manager Deployment Guide.

17.4 Upgrading Your Original Identity System

After reconfiguring your network to use upgraded clones in place of original components, you are ready to upgrade your original Identity System components. Topics in this section include:

• About Upgrading Original Identity System Instances

• Turning Off the Access Server Cache Flush

• Preparing Original Identity System Components for the Upgrade

• Upgrading Original COREid Servers that are Associated with a Single WebPass

• Configuring Upgraded Original COREid Servers

• Upgrading An Original Associated WebPass Instance

• Configuring the Upgraded Original WebPass for Upgraded COREid Servers

• Adding a Temporary Directory Profile for Original Access System Upgrades

• About Creating Individual Profiles for WebGates that Share a Profile

• Setting Up the Upgraded Original Identity System

• Validating the Upgraded Original Identity System

• Backing Up the Upgraded Original Identity System

• Recovering From an Original Identity System Upgrade Failure

• Rolling Back After Upgrading the Original Identity System

Caution: Oracle recommends that you review all information in this section before performing any activities.

17.4.1 About Upgrading Original Identity System Instances

The differences and similarities between upgrading original components and upgrading cloned components are summarized in this topic. Explicit details and steps are provided in later discussions that you will see when you perform the upgrade tasks.

Caution: Oracle recommends that you review all information in this section before performing any activities.

Similarities When Upgrading Originals versus Clones: Upgrading original instances is similar to upgrading clones in the following ways:

• Source Creation: You rename the subdirectory that contains the original instance to create a source for the upgrade. For example:

  Original Instance: np/ois_01/identity

  Source Name: np/ois_01/identity_source

• Destination Creation: You extract fresh 10g (10.1.4.0.1) component libraries and files and specify the original file system path (the path that the source had before you renamed it). For example:

  Original Instance: np/ois_01/identity

  10.1.4 Destination Name: np/ois_01/identity

• Obtaining Tools and Upgrading: You apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the 10g (10.1.4.0.1) instance to obtain the tools needed for the upgrade.

• Messages: The upgrade process provides messages and prompts for every major release between your starting release (6.1.1 for example) and the latest release (10g (10.1.4.0.1)). Oracle recommends that you use Automatic rather than Confirmed mode for the quickest upgrade and that you do not skip any processes. For more information, see "About Original Mode (Prod) Processing". The destination that you specify during the upgrade will be upgraded and include 10g (10.1.4.2.0) based on the source details.

• Registry Entries: When you upgrade on a Windows platform, the registry entry for the originally installed instance and release is deleted and a new entry is created for the latest release. After upgrading an instance, the registry entry for the earlier release is no longer available.

• Web Servers that Service Multiple Web Components: A Web server instance cannot support components that are at different Oracle Access Manager release levels (6.1.1 versus 10.14, for example). The Web server must remain off until all serviced Web components are upgraded. For more information, see "Web Server Support for Multiple Oracle Access Manager Releases".

Differences When Upgrading Originals versus Clones: All COREid Server clones were upgraded before upgrading any WebPass instances. However, with original COREid Servers, you upgrade only the original instances that are associated with a single WebPass and then you upgrade the associated WebPass.

After each COREid Server upgrade, you reconfigure the upgraded instance to operate with the new branch in the LDAP directory server. Only after upgrading all original COREid Server instances that are associated with a single WebPass will you upgrade the associated WebPass. The following additional conditions will apply when upgrading original Identity System instances:

• Identity System Only Deployment: You perform the following activities, in order:

  • Configure the upgraded WebPass to operate with associated original COREid Servers.

  • Upgrade and then reconfigure original COREid Servers that are associated with a different WebPass, and then upgrade and reconfigure that WebPass.

  • Repeat this sequence until all original COREid Servers and WebPass instances are upgraded.

  • After Upgrading and Reconfiguring All Original Identity System Components: Set up the upgraded Identity System.

• Joint Identity and Access System: After reconfiguring the first upgraded WebPass, you must add a temporary directory profile for the original Access Server upgrade. For more information, see "Adding a Temporary Directory Profile for Original Access System Upgrades".

  Before upgrading the first Access Manager, you must ensure that each WebGate has its own profile. For details, see "About Creating Individual Profiles for WebGates that Share a Profile".

Task overview: Upgrading original Identity System components

1. Locate the association details for original COREid Servers and WebPass instances, which might have been printed when performing activities in "Viewing Details for Existing COREid Servers Associated with a WebPass".

2. Perform any prerequisite activities before upgrading each original instance. For more information, see "Preparing Original Identity System Components for the Upgrade".

3. Upgrade original COREid Server instances that are associated with a single WebPass, as described in "Upgrading Original COREid Servers that are Associated with a Single WebPass".

4. Reconfigure each upgraded original COREid Server to use the new branch in the LDAP directory server, as described in "Configuring Upgraded Original COREid Servers".

5. Upgrade the WebPass instance that is associated with upgraded original COREid Servers, as described in "Upgrading An Original Associated WebPass Instance".

6. Configure the upgraded WebPass instance, as described in"Configuring the Upgraded Original WebPass for Upgraded COREid Servers".

7. Joint Identity and Access System: Add a temporary directory profile for use when upgrading Access System components, as described in "Adding a Temporary Directory Profile for Original Access System Upgrades".

8. Repeat steps in this task overview to upgrade other original Identity System components in the following order:

   • Upgrade a COREid Server instance that is associated with a different WebPass

   • Reconfigure the upgraded original COREid Server to use the new directory branch

   • Upgrade the associated WebPass instance

   • Reconfigure the upgraded WebPass instance

9. When all Identity System components are upgraded, perform steps in "Validating the Upgraded Original Identity System".

For information about recovering if there is a problem, see "Recovering From an Original Identity System Upgrade Failure". For a look at what follows original Identity System upgrade tasks, see Looking Ahead.

17.4.2 Turning Off the Access Server Cache Flush

If you have a joint Identity and Access System deployment, this task should have been performed for original components before you upgraded the clones. If it was not performed for original components earlier, it must be performed before you continue. For details, see "Turning Off the Access Server Cache Flush".

17.4.3 Preparing Original Identity System Components for the Upgrade

The procedures to prepare components for an upgrade are described in detail in Chapter 8. You must perform most of the same preparation tasks before upgrading each original component using the zero downtime method. The following overview outlines the tasks that you will perform for each original instance upgrade. Details are provided in independent topics in Chapter 8.

Note: Be sure to locate details about original COREid Server and WebPass associations. You must upgrade COREid Servers associated with a particular WebPass before upgrading the associated WebPass or other COREid Servers. For more information, see "Viewing Details for Existing COREid Servers Associated with a WebPass".

Task overview: Preparing original Identity System components for a zero downtime upgrade includes these tasks (described in Chapter 8)

1. Preparing Earlier Customizations

2. Copying Custom Identity Event Plug-ins

3. Preparing Host Computers

   • Changing Read Permissions on Password Files

   • Confirming Free Disk Space

4. Preparing Release 6.x Environments

5. Preparing Multi-Language Installations

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

   
   

   Note: With the zero downtime upgrade method, you do not need to back up the file system directory for each instance. Instead, you will rename the original path to use as a source during the upgrade.

   
   

7. Stopping Servers and Services

8. Logging in with Appropriate Administrative Rights

17.4.4 Upgrading Original COREid Servers that are Associated with a Single WebPass

This topic describes all activities that must be performed to upgrade original COREid Server instances that are associated with the same WebPass. At the end of this topic you will find a procedure that provides you with all the steps.

Caution: Oracle recommends that you review all information in this topic before proceeding with the activities. You will be instructed to rename and move directories and it is imperative that you track where you are and what directories you are using.

To help illustrate the activities that you will be instructed to perform, Table 17-1 provides sample file system path names in columns that illustrate the progression of actions that you will take before upgrading each instance. Additional information follows the table. The sample path names are for Windows platforms. The paths in your environment might be different.

Table 17-1 Activities to Prepare for an Original COREid Server Instance Upgrade

1 Original Path	2 Source Creation	3 Destination Creation and Obtaining Tools
COREid Server Instance np611\ois_01\identity	In the original file system, rename the subdirectory containing each original instance. For example: np611\ois_01\identity_source	After creating the source (see column 2): A. Extract 10g (10.1.4.0.1) Identity Server component libraries and files and specify the original path as the installation directory. For example: np611\ois_01\identity Note: The destination path of the 10g (10.1.4.0.1) instance must exactly match the path that the original had before it was renamed (see column 1). See "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files". B. Apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the 10g (10.1.4.0.1) instance to obtain the tools. See "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)". C. Repeat steps A and B for each clone instance.

After performing the activities outlined in Table 17-1, the 10g (10.1.4.2.0) MigrateOAM script will be available in the destination. For example:

np611\ois_01\identity\oblix\tools\migration_tools\MigrateOAM.bat

For more information about source and destination creation, see "Preparation Tasks for the Zero Downtime Method".

Table 17-2 lists the arguments that you specify to upgrade original COREid Servers using the 10g (10.1.4.2.0) MigrateOAM script for the instance.

Table 17-2 MigrateOAM Prod Arguments for Original COREid Server Upgrades

MigrateOAM Original (Production) Mode Syntax	Values and Operations
-M Prod	Specify Prod as the mode to upgrade original components. The production mode is required to upgrade original components.
-C OIS	Specify OIS to upgrade an original COREid Server. Note: Upgrade each COREid Server original that is associated with a single original WebPass. There are no schema or data upgrades with original COREid Servers.
-F nnn	Specify the number that identifies your earlier release. For example: 610 (for 6.1 or 6.1.1), 650 (for 6.5.x), or 700 (for 7.x)
-T 1014	Specify1014 as the release to which this data will be upgraded.
-S "source directory"	Specify the full path (in quotation marks) to the renamed original COREid Server directory (see column 1 of Table 17-1). For example: -S "C:\np611\ois_01\identity_source"
-D "destination directory"	Specify the full path (in quotation marks) to the 10g (10.1.4.2.0) Identity Server directory that replaced the original instance directory (see columns 1 and 4 of Table 17-1). For example: -D "C:\np611\ois_01\identity"
-I "installation directory"	The installation directory should be the same as the destination directory. For example: -I "C:\np611\ois_01\identity"
-L "Languages"	Specify all installed languages to be upgraded by the appropriate code, in quotations. For example, English, "en-us"; French, "fr-fr"; German, "de-de".

For more information about the script and Prod mode, see "About Original Mode (Prod) Processing".

In the following procedure any file system path names, starting release value, and languages are provided as samples only. Your details might be different.

Caution: If you do not perform all preparation activities that are appropriate for this component, it might limit your ability to recover or roll back from an upgrade issue.

To upgrade original COREid Servers associated with a single WebPass

1. Determine the associations between your original COREid Server and WebPass instances. For example:

   1. From the COREid System Console, click the System Admin tab, the System Configuration tab, and then click Configure WebPass in the left navigation pane.

   2. In the List all WebPasses page, click the name of an original WebPass (not a clone).

   3. From the Details for WebPass page, click the List Identity Servers button.

      A page appears that lists the primary and secondary servers configured for the existing WebPass.

   4. Print the page to use as a reference or simply determine which COREid Server instances must be upgraded for this WebPass.

   5. Repeat these steps for each WebPass and document the original COREid Servers for the associated WebPass.

2. Preparation: Perform tasks for the instance, as described in "Preparing Original Identity System Components for the Upgrade", which includes:

   • Preparing Earlier Customizations

   • Copying Custom Identity Event Plug-ins

   • Preparing Host Computers

     • Changing Read Permissions on Password Files

     • Confirming Free Disk Space

   • Preparing Release 6.x Environments

   • Preparing Multi-Language Installations

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

     
     

     Note: With the zero downtime upgrade method, you do not need to back up the file system directory for each instance. Instead, you will rename the original path to use as a source during the upgrade.

     
     

   • Stopping Servers and Services

   • Logging in with Appropriate Administrative Rights

3. Source Creation: Rename the subdirectory that contains the original COREid Server instance to create a source for the upgrade. For example:

   
   Rename: np611\ois_01\identity
   As Sample Path: np611\ois_01\identity_source
   
   Description of the illustration original_ois_rename.gif
   
   

   You are ready to add 10g (10.1.4.0.1) libraries and files for this instance upgrade.

   
   

   Caution: Do not copy existing 10g (10.1.4.0.1) libraries and files.

   
   

4. Destination Creation: Extract 10g (10.1.4.0.1) Identity Server libraries and files and specify a destination path that exactly matches the original path before it was renamed. For example:

   
   Destination Path: np611\ois_01\identity
   

   For a destination path example, see column 1 of Table 17-1. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".

5. Obtaining the Tools: Apply the 10g (10.1.4.2.0) patch to the 10g (10.1.4.0.1) instance, as described in "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".

   When your file system is set up, you are ready to upgrade the instance.

   
   Description of the illustration original_ois_move.gif
   
   

6. Change to the destination_dir that contains the 10g (10.1.4.2.0) MigrateOAM script for the COREid Server instance that you will upgrade. For example:

   cd np611\ois_01\identity\oblix\tools\migration_tools

7. Run the MigrateOAM script in Prod mode and specify your starting release and path names for the instance. For example:

   MigrateOAM -M Prod -C OIS -F 610 -T 1014 -S "C:\np611\ois_01\identity_source"  
   -D "C:\np611\ois_01\identity" -I "C:\np611\ois_01\identity" -L "en-us"
   

   1. Use Automatic mode so that you do not need to confirm each process.

   2. Continue as requested through all processes; do not skip any processes.

   3. Finish according to on-screen messages.

      The source remains intact. The destination now includes a 10g (10.1.4.2.0) instance configured with the same parameters and details as the source.

      
      Description of the illustration original_ois_end.gif
      
      

8. Verify that the upgrade was successful:

   1. Check that the value of the MigrateUserDataTo1014 is false in the globalparams.xml in the destination path. For example:

      destination_dir\identity\oblix\apps\common\bin\globalparams.xml

      <NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
      

   2. Verify that the ois_server_config.xml file has the correct information for this instance, in the destination_dir\identity\oblix\config file system directory.

   3. Start the Identity Server service to confirm that it will start (notice that the name has not changed from the one originally assigned).

   4. Identity Server Service Does Not Start: Check your event and Identity Server log output files. For more information about logging and log output files, see the Oracle Access Manager Identity and Common Administration Guide.

   5. Check the migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".

   6. Windows: Verify that the registry entry is updated by running the Registry editor (regedit) using one of the following methods:

      In the Registry Editor Window, click My Computer, HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Services, and then look for ObOISServer-<Service Name>. Within this, check the Image path.

      View the registry entry HKEY_LOCAL_MACHINE, SOFTWARE,Oblix,Oblix Netpoint. Check for the respective installed version and, under that, check the entry for ObOISServer-<Service Name>.

   7. Verify that the version file in the destination path is updated for 10.1.4 (npversion_component.txt). For example:

      destination_dir\identity\oblix\config\np1014_is.txt

   8. In your upgraded cloned environment, verify that WebGate protection is still working by accessing a protected resource.

9. Proceed as follows:

   • Upgrade Successful:

     • Perform activities in "Configuring Upgraded Original COREid Servers".

     • Repeat all steps in this procedure for other original COREid Server instances that are associated with the same WebPass.

     • When all original COREid Servers that are associated with the same WebPass are upgraded and configured, proceed to "Upgrading An Original Associated WebPass Instance".

   • Upgrade Not Successful: Proceed to "Recovering From an Original Identity System Upgrade Failure" .

17.4.5 Configuring Upgraded Original COREid Servers

After each original COREid Server is upgraded, you must reconfigure the instance. This is the much like the procedure that you performed to reconfigure clone instances.

Note: Starting with 10g (10.1.4.0.1), the name "COREid Server" was changed to "Identity Server".

The tools that you use to reconfigure your original upgraded COREid Server instances are stored in the destination directory that you specified when upgrading the original instance. The abbreviation "ois" refers to the Oracle Identity Server.

Windows Systems: The registry entry was updated when you upgraded the original instance. As a result, you do not need to run config_ois.exe to add the upgraded COREid Server service entry to the Windows registry.

All Systems: You run setup_ois (Windows) or start_setup_ois (non-Windows) from the file system destination that you specified during the upgrade to configure the host name, port, and other details for the upgraded instance. For example:

Windows: np611\ois_01\identity\oblix\tools/setup/setup_ois

UNIX: /home/np611/ois_01/identity/oblix/tools/setup/start_setup_ois

In the example, UNIX refers to supported UNIX-based platforms such as Linux and Solaris. When you run this tool, you will use only the -i option and specify the destination file system directory that was used when upgrading the instance: -i "destination_dir".

You enter the command and parameters on a single line. You will be prompted to provide details for the original upgraded instance, including:

• The unique original COREid Identifier

• The original COREid Server Hostname

• The port on which the original COREid Server listens.

• The security mode for the original COREid Server.

• Whether this is the first installed COREid Server: Answer Yes if it is; otherwise, answer No.

Be sure to specify information for the original instance that is entered in the original System Console. When you upgrade the first COREid Server that was installed in this environment, Answer Yes when asked if this is the first COREid Server in the installation. For other COREid Servers, answer No.

Note: Be sure to specify information for the original instance that is entered in the original System Console. When you upgrade the first COREid Server that was installed in this environment, Answer Yes when asked if this is the first COREid Server in the installation. For other COREid Servers, answer No.

When the command finishes, the original upgraded COREid Server is reconfigured based on the information that you supplied. You can verify the changes in the ois_server_config.xml file in the destination_dir\identity\oblix\config file system directory. This file should include the details that you supplied during the configuration. For more information about these tools, see your Oblix NetPoint or Oracle COREid Administration Guide.

Removing Setup Files: You will be instructed to remove the following files before starting the reconfiguration:

• setup.*

• configInfo.*

• \ldap subdirectory (if there is one)

New versions of these files will be generated during reconfiguration and setup. At the conclusion of the browser-based setup procedure that you will perform, these files will contain the new configuration DN. Removing these files when instructed will help ensure that the Identity Server service will start up after setup.

The information in the following procedure is an example only. Your details will be different.

To reconfigure original upgraded COREid Servers

1. Delete the following files from the destination_dir\identity\oblix\config file system directory that was specified for the instance (for example, np611\ois_01\identity):

   • setup.*

   • configInfo.*

   • \ldap subdirectory

2. Change to the file system destination_dir containing the COREid Server setup tool for this upgraded instance. For example:

   Windows: np611\ois_01\identity\oblix\tools/setup/setup_ois

   UNIX: /home/np611/ois_01/identity/oblix/tools/setup/start_setup_ois

   In the example, UNIX refers to supported UNIX-based platforms such as Linux and Solaris.

3. Run the command using the following parameters and specifications for your original instance. For example:

   Windows:

      setup_ois.exe -i "C:\np611\ois_01\identity"  
   

   UNIX:

      ./start_setup_ois -i "/home/np611/ois_01/identity"  
   

4. Follow the on-screen prompts and respond with details for your original upgraded COREid Server and COREid Server service.

   1. Unique original COREid Identifier: Enter the name of the original COREid Service.

   2. COREid Server Hostname: Enter the DNS host name where the original upgraded COREid Server resides.

   3. COREid Server Port: Enter the port on which the original upgraded COREid Server listens.

   4. Security Mode [open\simple\cert]: Enter the mode that is specified in the System Console for the original upgraded COREid Server instance.

   5. Do you want to setup SSL between the COREid Server and the Directory Server [y/n]: Respond appropriately for your original connection.

   6. First COREid Server: Answer Yes if it is the first installed COREid Server instance; otherwise, answer No.

5. Check the ois_server_config.xml file in destination_dir\identity\oblix\config file system directory to ensure that it includes the details that you supplied during the operation.

6. Proceed as follows:

   • Successful: If the file mentioned in Step 5 contains the information you specified, the operation was successful. Proceed to Step 7.

   • Not Successful: If the information does not appear in the files mentioned in Step 5, the operation failed. In this case, see "Recovering From an Original Identity System Upgrade Failure".

7. Restart the original upgraded COREid Server service, and proceed as follows:

   • More COREid Servers Associated with the Same WebPass: Repeat steps to upgrade the next original COREid Server that is associated with this WebPass, as described in "Upgrading Original COREid Servers that are Associated with a Single WebPass".

   • No More COREid Servers Associated with the Same WebPass: Proceed to "Upgrading An Original Associated WebPass Instance".

17.4.6 Upgrading An Original Associated WebPass Instance

After upgrading original COREid Servers that are associated with a specific WebPass, you are ready to upgrade the original associated WebPass. The activities that you perform when upgrading original WebPass instances, are very similar to the activities that you performed to upgrade WebPass clones.

Caution: Oracle recommends that you review all information in this topic before proceeding with NY activities.

You start by performing steps to ensure that for each cloned WebPass instance you have the 10g (10.1.4.2.0) MigrateOAM script in an appropriate location. To help illustrate the activities that you will be instructed to perform, Table 17-3 organizes sample directory path names in columns that describe the progression of actions that you will take. The sample path names are for Windows platforms. The paths in your environment might be different.

Table 17-3 Activities to Prepare for an Original WebPass Instance Upgrade

1 Original Path	2 Source Creation	3 Destination Creation and Obtaining Tools
WebPass Instances np611\webcomponent_01\identity	In the original file system, rename the subdirectory containing each original instance. For example: np611\webcomponent_01\identity_source	After creating a source for the original instance upgrade: A. Extract 10g (10.1.4.0.1) WebPass libraries and files and specify the original path before it was renamed as the installation (destination) directory. For example: np611\webcomponent_01\identity Note: The path of the 10g (10.1.4.0.1) instance must exactly match the path of the original instance before it was renamed (see column 1). See "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files". B. Apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the 10g (10.1.4.0.1) instance to obtain the tools. See "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)". C. Repeat steps A and B for each clone instance.

After performing activities outlined in Table 17-3, the 10g (10.1.4.2.0) MigrateOAM script will be stored in the destination that you created. For example:

np611\webcomponent_01\identity\oblix\tools\migration_tools\MigrateOAM.bat
and so on.

For more source and destination creation in Table 17-3, see "Preparation Tasks for the Zero Downtime Method".

Table 17-4 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to execute the original upgrade for each individual WebPass.

Table 17-4 MigrateOAM Script for Original WebPass Upgrades

MigrateOAM Original Mode Syntax	Values and Operations
-M Prod	Specify Prod as the mode, which is required to upgrade original components.
-C WP	Specify WP to upgrade an original WebPass component. Note: Upgrade each WebPass original after upgrading all COREid Servers that are associated with that WebPass. Upgrade all original WebPass instances before upgrading any Access System originals.
-F nnn	Specify the number that identifies your earlier release. For example: 610 (for 6.1 or 6.1.1), 650 (for 6.5.x), or 700 (for 7.x)
-T 1014	Specify1014 as the release to which this data will be upgraded.
-S "source directory"	Specify the full path (in quotation marks) to the renamed earlier WebPass directory (see column 2 of Table 17-3). For example, when you have multiple instances: -S "C:\np611\webcomponent_01\identity_source" -S "C:\np611\webcomponent_02\identity_source" and so on
-D "destination directory"	Specify the full path (in quotation marks) to the original 10g (10.1.4.2.0) WebPass directory that replaced the earlier instance directory (see columns 1 and 4 of Table 17-3). For example: -D "C:\np611\webcomponent_01\identity" -D "C:\np611\webcomponent_02\identity" and so on
-I "installation directory"	The installation directory should be the same as the destination directory. For example: -I "C:\np611\webcomponent_01\identity" -I "C:\np611\webcomponent_02\identity" and so on. Note: Refer to Table 17-3 for details about path names and directory content.
-L "Languages"	Specify all installed languages to be upgraded by the appropriate code, in quotations. For example, English, "en-us"; French, "fr-fr"; German, "de-de".
-W "Web server type"	Specify the appropriate code for the Web Server used by this original, in quotations. For example, "nsapi", "apache2", "isapi", apache", "ihs", "ohs", "ohs2", "domino".

Upgrading an original WebPass instance does not impact the schema and data but does include a Web server configuration upgrade. During the upgrade of the original WebPass, you will see messages and prompts for each sequence from your starting release to the conclusion. Oracle recommends that you use Automatic rather than Confirmed mode for the quickest upgrade. Oracle also recommends that you do not skip any processes.

Note: When you have a single Web server instance serving more than one Oracle Access Manager Web component, the Web server must remain stopped until all serviced Web components on the host computer are upgraded.

In the following procedure, sample file system directory path names, starting release, and languages are provided to help illustrate activities that you must perform.

Caution: If you do not perform all preparation tasks, you might not be able to roll back or recover from an upgrade issue.

To upgrade an original WebPass instance

1. Preparation: See "Preparing Original Identity System Components for the Upgrade", which includes:

   • Copying Custom Identity Event Plug-ins

   • Preparing Earlier Customizations

   • Preparing Host Computers

     • Changing Read Permissions on Password Files

     • Confirming Free Disk Space

   • Preparing Release 6.x Environments

   • Preparing Multi-Language Installations

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

     
     

     Note: With the zero downtime upgrade method, you do not need to back up the file system directory for each instance.

     
     

   • Stopping Servers and Services

   • Logging in with Appropriate Administrative Rights

2. Source Creation: Rename the subdirectory that contains the original WebPass to create a source for the upgrade. For example:

   
   Rename: np611\webcomponent_01\identity
   As: np611\webcomponent_01\identity_source
   Description of the illustration original_np611_wp_ren.gif
   
   

3. Destination Creation: Extract 10g (10.1.4.0.1) WebPass libraries and files and specify the original path (before it was renamed) as the destination. For example:

   
   Sample Path: np611\webcomponent_01\identity
   

   For a destination example, see column 1 of Table 17-3. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".

   
   Description of the illustration original_np611_move.gif
   
   

4. Obtaining the Tools: Apply the 10g (10.1.4.2.0) patch to the 10g (10.1.4.0.1) instance, as described "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".

   When your original file system is set up according to the steps in this procedure, you are ready to upgrade the original WebPass.

5. Change to the file system destination that contains the 10g (10.1.4.2.0) MigrateOAM script for the instance to be upgraded. For example:

   destination_dir\webcomponent_01\identity\oblix\tools\migration_tools

6. Run the 10g (10.1.4.2.0) MigrateOAM script in Prod mode and specify your starting release, path names, language, and Web server type. For example:

   MigrateOAM -M Prod -C WP -F 610 -T 1014 -S "C:\np611\webcomponent_01\identity_ 
   source" -D "C:\np611\webcomponent_01\identity" -I "C:\np611\webcomponent_ 
   01\identity" -L "en-us" -W "nsapi"
   

   1. Use Automatic mode for each sequence so that you do not need to confirm each process.

   2. Accept Web server configuration changes by specifying the full directory path name to the Web server configuration file for which this original is configured.

   3. Continue as requested through all processes; do not skip any processes.

   4. Finish according to on-screen messages.

      The destination has been upgraded using configuration details from the source.

      
      Description of the illustration original_wp_end.gif
      
      

7. Verify that the upgrade was successful, as follows:

   1. Apply Web server changes, if needed, and check the Web server-specific configuration file. If you have IIS configured as the Web server for this instance, ensure that the transfilter with its green status in ISAPI filters. For more information, see the Oracle Access Manager Installation Guide.

      
      

      Note: When you have a single Web server instance serving more than one Oracle Access Manager Web component, the Web server must remain shut down until all serviced Web components on the host computer are upgraded.

      
      

   2. Windows: Verify that the registry entry is updated by running the Registry editor (regedit) and:

      View the registry entry HKEY_LOCAL_MACHINE, SOFTWARE,Oblix,Oblix Netpoint. Check for the respective installed version and, under that, check the entry for WebPass.

   3. Check migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".

8. Proceed as follows:

   1. WebPass Upgrade Successful: Proceed with "Configuring the Upgraded Original WebPass for Upgraded COREid Servers".

   2. Upgrade Not Successful: Proceed to "Recovering From an Original Identity System Upgrade Failure".

9. After upgrading and configuring all original WebPass instances, proceed to "Setting Up the Upgraded Original Identity System".

17.4.7 Configuring the Upgraded Original WebPass for Upgraded COREid Servers

You use the following procedure after upgrading the WebPass instance. In this case, you use the WebPass setup tool to reconfigure the instance to communicate with the original upgraded COREid Server.

Note: When upgrading an original WebPass instance, the Web server configuration is also updated. No further Web server configuration update is needed.

The WebPass setup tool is included in each upgraded destination on all platforms. On windows platforms the tool is named setup_webpass.exe and on non-Windows systems it is named start_setup_wepbass. The tool is located in the upgraded WebPass destination in the file system. For example:

np611\webcomponent_01\identity\oblix\tools\setup\setup_WebPass

Options for the tool are shown in Table 17-5. When running this tool, you can specify only the -i option and all other information will be requested automatically. If you have multiple WebPass instances, you must repeat this operation with each original instance.

Table 17-5 Options for setup_webpass (and start_setup_webpass) for an Original Instance

Command Options	Operation
-i "Upgrade_Destination_dir"	Specifies the file system directory where your upgraded original WebPass is stored (the destination that was specified during the upgrade). For example: "C:\np611\webcomponent_01\identity".
-q -n WebPass _name	Specifies the unique name of this original WebPass instance.
-h associated_COREidServer_Hostname	Specifies the computer name where the associated original COREid Server resides.
-p associated_COREidServer_port_#	Specifies the port number of the computer where the associated original COREid Server resides.
-s mode	Specifies the transport security mode for the associated original COREid Server and original WebPass : open or simple or cert.
-P simple|cert mode password	Specifies the password for either the Simple or Cert transport security mode.
-c request|install	Specifies a certificate request or installation .

As the command is performed, messages keep you informed. Be sure to supply any information for your environment that is requested during the operation.

The following procedure provides the sequence of steps that you need to perform. File System path names are presented as an example. Your details will vary.

To modify an upgraded original WebPass to operate with the upgraded COREid Server

1. Change to the file system destination that was specified for this original WebPass upgrade and locate the setup_WebPass (or start_setup_webpass) utility. For example:

   
   Windows: np611\webcomponent_01\identity\oblix\tools\setup\setup_webpass
   UNIX: /home/np611/webcomponent_01/identity/oblix/tools/setup/start_setup_
   webpass
   

2. Run the utility using the specifications for this upgraded original WebPass. For example:

   setup_webpass -i "C:\np611\webcomponent_01\identity" 
   

3. Follow the on-screen prompts and respond with details for this original upgraded WebPass and the associated original upgraded COREid Server.

   1. Unique WebPass Identifier: Enter the name of the original WebPass that appears in the System Console.

   2. COREid Server Hostname: Enter the DNS host name where the associated original COREid Server resides.

   3. COREid Server Port: Enter the port on which the original associated COREid Server listens, as specified in the System Console.

   4. Security Mode [open\simple\cert]: Enter the mode that is specified in the System Console.

4. Not Successful: Proceed to "Rolling Back After Upgrading the Original Identity System".

5. Successful: Proceed as follows:

   • Identity System Only:

     • COREid Servers Associated with a Different WebPass: Perform steps in "Upgrading Original COREid Servers that are Associated with a Single WebPass", and then upgrade the associated WebPass.

     • No More WebPass Instances to Upgrade: Perform steps in "Setting Up the Upgraded Original Identity System".

   • Joint Identity and Access System:

     • First Upgraded WebPass: Perform steps in "Adding a Temporary Directory Profile for Original Access System Upgrades".

     • COREid Servers Associated with a Different WebPass: Upgrade the next set of COREid Servers as described in "Upgrading Original COREid Servers that are Associated with a Single WebPass", and then upgrade the associated WebPass.

     • No More WebPass Instances to Upgrade: Perform steps in "Setting Up the Upgraded Original Identity System".

17.4.8 Adding a Temporary Directory Profile for Original Access System Upgrades

If you have a joint Identity and Access System, you must perform this task after upgrading and reconfiguring the first original WebPass instance. You perform this task using the operational upgraded clone Identity System.

This task is performed by a Master Access Administrator if there is no LDAP directory profile that grants write permission to policy data for the original Access Server. This task is performed after upgrading the first original WebPass instance, and before upgrading any original Access System component. The temporary profile grants the original Access Server write access to the policy data stored in the new branch of the directory server. You create the temporary directory profile using the upgraded clone Identity System Console.

During WebGate upgrades, the Access Server gathers configuration information stored in the WebGatestatic.lst file and updates the LDAP directory server using the temporary directory profile created for this purpose. After writing information to the LDAP directory server, the Access Server returns status information to the WebGate. Any unknown parameters in the WebGateStatic.lst file are moved to the LDAP directory server.

In earlier releases, WebGate configuration parameters were stored in the WebGatestatic.lst file. However, starting with Oracle Access Manager 10g (10.1.4.0.1), you must configure WebGates parameters such as IPValidation and IPValidationExceptions from the System Console, as described in the Oracle Access Manager Access Administration Guide. Proper migration of earlier WebGate configuration parameters during an upgrade is required because the WebGateStatis.lst file is deleted.

Note: Upgrading any additional WebPass instances or any Access System components before creating this profile could result in a failed upgrade.

Guidelines for the Temporary Directory Profile

When creating this temporary directory profile you must:

• Assign a profile name of migration_wgstatic_profile; do not use another name.

• Create the migration_wgstatic_profile for the directory where the policy data is stored. For example:

  • If your user, configuration, and policy data are stored together on a single LDAP directory server, create this new profile for that LDAP directory server.

  • If your policy data is stored in the same LDAP directory server as configuration data, create this new profile for that LDAP directory server.

• Assign permissions for all operations to the migration_wgstatic_profile.

• Use the same namespace as the <ldapOblixBase> (for the new branch) that is stored in the clone AccessManager_dir/access/oblix/config/configInfo.xml. For example, obapp=PSC,o=Oblix, <New_Config_DN>.

• If your LDAP directory server supports LDAP referrals, enable LDAP referrals in this temporary LDAP directory server profile. A referral directs a client request to another server to find requested information in another location. For more information, see the Oracle Access Manager Identity and Common Administration Guide.

• If the policy data LDAP directory server is SSL-enabled, the CA certificate is needed by the Access Server to connect to the LDAP directory server. The CA certificate must be manually added (using the certutil tool) to the certificate store in the original AccessServer_install_dir/access/oblix/config/cert8.db or cert7.db. However, if the existing policy data directory used by the Access Server is already in SSL mode and uses the same CA certificate, this step is not needed.

• If multiple WebGates share a single AccessGate profile in the Access System Console, you must also perform tasks in "Creating Individual Profiles for WebGates that Share a Profile" before you upgrade any original Access Manager instance.

Important: The following procedure must be completed before upgrading any additional WebPass instances and any Access System components. For more information about LDAP directory server profiles, see the Oracle Access Manager Identity and Common Administration Guide.

To create the temporary LDAP directory server profile for the Access Server

1. Navigate to the clone Identity System Console (formerly known as the COREid System Console) in your cloned environment. For example:

        http://hostname:port/identity/oblix/
   

2. From the cloned Identity System Console, click the System Configuration tab.

3. Click Directory Profiles to display the Configure Profiles page.

4. Locate the Configure LDAP Directory Server Profiles section and click Add to display the Create Directory Server Profile page.

5. Fill in the information for this temporary profile: In the Name field enter the following name, and in the Name Space field enter the namespace for your environment:

   Name: migration_wgstatic_profile

   Name Space: obapp=PSC,o=Oblix, <New_Config_DN>

   In the example, the Name Space is obapp=PSC, <ldapOblixBase>, as defined in the configInfo.xml that is stored in your clone AccessManager_dir/oblix/config file system path.

6. Select the All Operations button to give this profile permission to perform all operations.

7. In the Used By field, select the Access Servers option.

   Next you must create a database instance profile where you identify the LDAP directory server where your policy data is stored. If your policy data is stored on a separate LDAP directory server, the new database instance profile should be created for that LDAP directory server. If user, configuration, and policy data are all on one LDAP directory server, the new database instance profile should be created for that LDAP directory server

8. In the Database Instances section of the Create Directory Server Profile page, click Add.

   The Create Database Instance page appears.

9. Fill in the following information to configure a database instance profile for your policy data LDAP directory server:

   
   Name:
   Machine:
   Port:
   Root DN:
   Root DN Password:
   

   For more information, see the Oracle Access Manager Identity and Common Administration Guide for details.

10. In the Flags field, if your directory supports LDAP referrals click the LDAP referrals check box if appropriate for your environment.

    See the Oracle Access Manager Identity and Common Administration Guide for details on configuring LDAP referrals.

11. Save the database instance profile and the associated LDAP directory server profile.

12. If the policy LDAP directory server operates in SSL mode, the Access Server requires a CA certificate to connect to it.

    If the policy LDAP directory server uses the same CA certificate as the Access Server, no additional configuration is required. Otherwise, you must add the CA certificate (cert8.db or cert7.db) to the certificate store in the following original file system path:

    AccessServer_install_dir\oblix\config\cert8.db or cert7.db

    Where AccessServer_install_dir is the file system path where the original Access Server is installed. For more information on adding a new certificate store, see the Oracle Access Manager Installation Guide.

13. Proceed as follows:

    • Multiple WebGates Share An AccessGate Profile: Go to "About Creating Individual Profiles for WebGates that Share a Profile".

    • Another WebPass Instance to Upgrade: Go to "Upgrading Original COREid Servers that are Associated with a Single WebPass".

    • No Other WebPass Instances to Upgrade: Go to "Setting Up the Upgraded Original Identity System".

    • Not Successful: Delete this temporary directory profile and create a new one.

17.4.9 About Creating Individual Profiles for WebGates that Share a Profile

Before you upgrade an Access Manager original, you need to add an individual profile in the clone System Console for each WebGate that shares an AccessGate profile. You are notified about this when you upgrade WebPass, however, you do not need to perform this task until you are ready to upgrade the Access Manager original.

For more information, see "Creating Individual Profiles for WebGates that Share a Profile".

17.4.10 Setting Up the Upgraded Original Identity System

After configuring all upgraded original COREid Servers and WebPass instances, you must set up the upgraded Identity System to use the new configuration DN. You must perform this task for each individual Identity Server and WebPass association.

Web Server Requirements: All Oracle Access Manager Web components (WebPass, Access Manager, and WebGates), must be the same release (10g (10.1.4.2.0)) before you restart the Web server. As a result, you cannot set up the Identity System or Access Manager until all Oracle Access Manager Web components have been upgraded. See Table 17-6 for conditions

Table 17-6 Conditions for Upgraded Original System Setup

System	Readiness to Restart Web Server
Identity System Only:	Last WebPass has been upgraded.
Joint Identity and Access System:
WebPass and Access Manager use the same Web server instance	Delay Identity System setup until after original serviced Access Manager components are upgraded
Access Manager and WebGates in the same directory	Upgrade WebGate before reconfiguring Access Manager
One Web server instance serves multiple Oracle Access Manager Web components	Upgrade all serviced Web components before restarting the Web server instance
All Web components on the host computer are upgraded, including WebGates	Perform activities in: "Setting Up the Upgraded Original Identity System" "Setting Up the Upgraded Original Access Manager"

For more information, see "Web Server Support for Multiple Oracle Access Manager Releases".

Extra Directory Profiles in a Split Directory Server Configuration: In this situation, you might find extra directory profiles are added during the setup operation. You will be instructed to remove the extra profiles. For more information, see "Setting Up the Cloned COREid System to Use the New Branch".

You use the following procedure only when your environment is ready. In this procedure, file system path names are presented as an example. Your details will be different. For more information about setting up the Identity System, see the Oracle Access Manager Installation Guide.

To set up the upgraded original Identity System to use the new branch

1. Confirm that your environment is ready based on the following conditions.

2. Ensure that the original WebPass Web server is running and go to the upgraded original Identity System Console, as usual.

        http://hostname:port/identity/oblix/
   

   In the sample URL, hostname refers to computer that hosts the Web server for the original WebPass that you have upgraded; port refers to the HTTP port number of the WebPass Web server instance; /identity/oblix connects to the Identity System Console.

3. Click the Identity System Console link.

   The System Console setup page appears.

4. Click the Setup button.

5. Follow on-screen instructions and those here to set up the Identity System (see also your Oracle Access Manager Installation Guide for more information):

   1. Confirm LDAP directory server details for the new directory branch.

   2. Enter the configuration bind DN and user data searchbase to be used.

      Configuration DN—o=Newbranch,o=company,c=us

      Searchbase—Supply the original searchbase

   3. Finish this setup and leave all other setup details as they are.

   4. Restart the new Identity Server service when instructed to do so during setup.

6. Go to the Identity System Console and verify that the Directory Server profile for upgraded original Identity Servers use the new configuration DN. For example:

   1. Go to the Identity System Console, as usual.

           http://hostname:port/identity/oblix/
      

   2. From the Identity System Console click the System Configuration tab.

   3. Click Directory Profiles in the left column to display the Configure Profiles page.

   4. Click the name of an existing directory profile for an original Identity Server to display its specifications.

   5. Confirm that the new configuration DN appears in the profile.

   6. Extra Directory Profiles in a Split Directory Configuration: Check for and remove any extra directory profiles that might have been added when upgraded Identity Servers were reconfigured. For more information, refer to the discussion about extra profiles in "Setting Up the Cloned COREid System to Use the New Branch" and see Oracle Access Manager Identity and Common Administration Guide.

7. Check the setup.xml file to ensure that the new configuration DN is listed (\identity\oblix\config directory):

   • setup.xml*

   • configInfo.xml*

   • configInfo.lst*

   • \ldap subdirectory (if there is one)

8. Restart the Web server and the upgraded Identity Server service.

9. Proceed as follows:

   • Configuration Successful, Joint Identity and Access System: Proceed to "Upgrading Your Original Access System".

   • Configuration Successful, Identity System Only: Proceed to "Validating the Entire Upgraded Original Environment".

   • Configuration Not Successful: Remove the files named in Step 7 and re-run browser-based setup as described in this procedure. Otherwise, perform activities in "Rolling Back After Upgrading the Original Identity System".

17.4.11 Validating the Upgraded Original Identity System

Oracle recommends that you quickly validate the following items to ensure that the overall upgrade of your original Identity System was successful. If you experience an issue, refer to the troubleshooting tips in Appendix G.

Note: The Web server instance should remain shut down until all serviced Web components have been upgraded.

To validate your upgraded original Identity System

1. Delete all Web browser caches once the upgrade is complete.

2. Make sure all upgraded original Identity Server services and WebPass Web server instances are running.

3. Check that your message and parameter catalog customizations have been preserved. For example, if you have changed any message in a particular message catalog file, then it needs to be retained.

4. Perform all validation activities for the upgraded Identity System, as described in "Validating Identity System Operations".

   
   

   Note: These are the same activities that you performed when validating operations with the upgraded Identity System schema.

   
   

5. Proceed to "Backing Up the Upgraded Original Identity System".

17.4.12 Backing Up the Upgraded Original Identity System

Oracle recommends that you validate successful operations and then perform the following back up tasks. This will enable you to easily restore your environment to the newly upgraded and validated state should that be needed. These tasks are described in detail in Chapter 8.

To back up critical information after upgrading original Identity System components

1. Back up the upgraded destination file system directory. This is similar to backing up an existing component installation directory. For details, see "Backing Up the Existing Component Installation Directory".

2. Web Server: Back up the upgraded Web server configuration file using instructions from your vendor and details in"Backing Up the Existing Web Server Configuration File" .

3. Windows: Back up Windows Registry data as described in "Backing Up Windows Registry Data".

4. Proceed to"Looking Ahead" .

17.4.13 Recovering From an Original Identity System Upgrade Failure

If an original Identity System component upgrade was not successful, you can perform the following steps to restart this upgrade.

The source directory was not touched during the upgrade and can be reused.

To recover from an unsuccessful original Identity System upgrade

1. Back up the source file system directory anew. You will retain one to use as a backup copy and use one to restart the upgrade.

2. For the instance to be retried, remove the 10g (10.1.4.0.1) libraries and files to which you applied Release 10.1.4 Patch Set 1 (10.1.4.2.0).

3. For the instance to be retried, install 10g (10.1.4.0.1) libraries and files and apply Release 10.1.4 Patch Set 1 (10.1.4.2.0)

4. Web Server: Restore the backed up Web server configuration file, if required.

5. Windows: Restore the backed up Registry data for the component.

6. Using a backup copy of your earlier original component installation directory (and Web server configuration, if needed), restart the upgrade as described in the appropriate topic.

17.4.14 Rolling Back After Upgrading the Original Identity System

This task is optional. You can use the following procedure to roll back all changes and return to your original installation. When you finish this operation, you will only your original setup and release.

You cannot roll back the schema upgrade unless you used an external utility to back up the schema before it was upgraded. Details about using external tools to back up and reinstate the schema is outside the scope of this manual. No automated tools are provided to roll back the schema upgrade.

To roll back after upgrading Identity System originals

1. Confirm that your clone setup is operating properly and serving customers.

2. Shut down the upgraded original service or Web server.

3. Remove any 10g (10.1.4.2.0) destination file system directories that were added for the original upgrade.

4. Remove any other file system directories that were added automatically or that you added.

5. Restore the original instance file system path by renaming the source.

6. Windows: For each original instance on a Windows platform, import the back up copy of the Windows registry entry for this component.

   
   

   Note: If there is no back up copy of the Windows registry entry, you must perform specific steps to generate a new registry entry. For more information, see "Reinstating Original Windows Registry Entries During a Rollback Operation".

   
   

7. Web Server Configuration: Restore the backup copy of original Web server configuration files.

8. Restart the original service or Web server.

9. Repeat all steps for each upgraded original.

10. In the original System Console, remove entries for the clones

11. If you have a back up copy of the original schema before upgrading, you might be able to reinstate the copy using external tools.

12. Confirm that the original setup is operating properly, and then configure the DNS to enable the original setup to serve customers. For more information, see "Reconfiguring Domain Name Systems (DNS) to Use Upgraded Clones".

13. Roll back the upgraded clone setup, which includes all clone file system directories, any Web server instances created for clones, the new branch that was created in the LDAP directory server. Also remove entries added to the original System Console for clone components. For more information, see:

    • Rolling Back Changes Made for the New oblix Branch in Chapter 16

    • Rolling Back After Upgrading Identity System Clones in Chapter 16

17.4.15 Looking Ahead

Upgraded original Identity System components send and receive information in UTF-8 encoding. Earlier components send and receive data in Latin-1 encoding. As a result, the 10g (10.1.4.0.1) Identity System does not work with earlier Access System components. For more information about expected system behaviors, see Chapter 4.

Proceed as follows:

• Identity System Only: Finish the upgrade as described in "Task overview: Remaining original Identity System upgrade activities".

• Joint Identity and Access System: You must upgrade integration connectors before upgrading the SDK. In this case, perform tasks as described in "Task overview: Remaining original joint Identity and Access System activities".

Task overview: Remaining original Identity System upgrade activities

1. Proceed to "Upgrading SDKs and Identity System Customizations" .

2. Go to "Validating the Entire Upgraded Original Environment".

3. Perform as many tests as your enterprise dictates, and then proceed to following topics:

   • Starting On-the-fly User Data Migration

   • Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment

   • Deleting the Temporary Directory Server Profile

   • Reverting Backward Compatibility

   • Removing the Cloned System After Upgrading Originals

Note: When you have a joint Identity and Access System, you must perform activities in the following sequence using information in this chapter and others.

Task overview: Remaining original joint Identity and Access System activities

1. Finishing Original Identity System Upgrades: Perform tasks in "Upgrading SDKs and Identity System Customizations".

2. Perform Original Access System Upgrades: Perform tasks as directed in:

   1. Upgrading Your Original Access System

   2. Upgrading SDKs, Integration Connectors, and Access System Customizations

   3. Validating the Entire Upgraded Original Environment

3. Finish the Zero Downtime Upgrade: After your own validation period ends, proceed to:

   • Starting On-the-fly User Data Migration

   • Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment

   • Deleting the Temporary Directory Server Profile

   • Reverting Backward Compatibility

   • Removing the Cloned System After Upgrading Originals

17.5 Upgrading SDKs and Identity System Customizations

Oracle recommends that you upgrade your Identity System customizations and any independently installed software developer kits (SDKs) and then validate that the entire upgraded original Identity System is operating properly.

Task overview: Remaining original Identity System upgrade activities

1. Proceed as needed for your environment:

   • Identity System Only: Upgrade integration connectors as described in Chapter 11.

   • Joint Identity and Access System: Upgrade the Access System, integrations, and independently installed SDKs before performing tasks in Chapter 11.

2. Upgrade original Identity System customizations as described in Chapter 12, which includes:

   • Upgrading Auditing and Access Reporting for the Identity System

   • Combining Challenge and Response Attributes on a Panel

   • Confirming Identity System Failover and Load Balancing

   • Migrating Custom Identity Event Plug-Ins

   • Ensuring Compatibility with Earlier Portal Inserts

   • About Custom Items and Upgrades

   • Incorporating Customizations from Release 6.5 and 7.x

   • Incorporating Customizations from Releases Earlier than 6.5

   • Validating Identity System Customization Upgrades

3. Proceed as follows:

   • Joint Identity and Access System: Go to "Upgrading Your Original Access System".

   • Identity System Only: Proceed to tasks in Table 17-7:

     Table 17-7 Finishing the Upgrade for Identity System Only Deployment

     	Finishing the Original Identity System Upgrade
     	Validating the Entire Upgraded Original Environment
     	Starting On-the-fly User Data Migration
     	Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment
     	Deleting the Temporary Directory Server Profile
     	Reverting Backward Compatibility
     	Removing the Cloned System After Upgrading Originals

     
     

17.6 Upgrading Your Original Access System

After upgrading your original Identity System, you are ready to upgrade your original Access System using the zero downtime method.

Caution: Oracle recommends that you review all information in this section before performing any activities.

Topics in this section include:

• About Upgrading Original Access System Instances

• Preparing Original Access System Components for the Upgrade

• Creating Individual Profiles for WebGates that Share a Profile

• Upgrading An Original Access Manager Instance

• Setting Up the Upgraded Original Access Manager

• Configuring Original Access Servers to Use the New Branch

• Upgrading Original Access Server Instances

• Upgrading Original WebGates

• Validating the Upgraded Original Access System

• Backing Up the Upgraded Original Access System

• Recovering From an Original Access System Upgrade Failure

• Rolling Back After Upgrading the Original Access System

• Looking Ahead

17.6.1 About Upgrading Original Access System Instances

The differences and similarities between upgrading original Access System components and upgrading cloned components are summarized here. Explicit details and steps are provided in later topics in this section.

Similarities When Upgrading Originals versus Clones: Upgrading original instances is similar to upgrading clones in the following ways:

• Source Creation: You do need a source; however, in this case you must rename the subdirectory containing the original instance. For example:

  Original Instance: np/aaa_01/access

  Source Name: np/aaa_01/access_source

• Destination Creation: In this case, you extract fresh 10g (10.1.4.0.1) component libraries and files into the same path that the original had before you renamed it. For example:

  Original Instance: np/aaa_01/access

  1014 Destination: np/aaa_01/access

• Obtaining Tools and Upgrading: You apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the 10g (10.1.4.0.1) instance to obtain the tools needed for the upgrade.

• Messages: Messages and prompts keep you informed. Use Automatic mode and do not skip any processes. For more information, see "About Original Mode (Prod) Processing". The destination is upgraded based on source details.

• Registry Entries: After upgrading, the registry entry for the earlier release is no longer available.

• Web Servers that Service Multiple Web Components: The Web server must remain shut down, as described in "Web Server Support for Multiple Oracle Access Manager Releases".

Differences When Upgrading Originals versus Clones: After upgrading each Access Manager instance, you reconfigure it to operate with the upgraded schema and data in the new branch of the LDAP directory server. Take the following items into account:

• All original Access Manager components must be upgraded and reconfigured before you upgrade any Access Server instances.

• Before restarting any original Access Server after reconfiguring an upgraded original Access Manager, log in to the Access System Console from any upgraded original Access Manager and delete the profiles that were created and named Access_Manager_user_setup_profile and Access_Server_setup_user_profile.

After upgrading all Access Manager components, you can start the task of upgrading original Access Servers. In this case, you first back up configuration data in the new branch and then reconfigure the original Access Server. After reconfiguring the original Access Server, you start the upgrade.

The following task overview outlines the sequence of procedures that you perform. You must upgrade all Access Managers on a host before upgrading Access Servers on the host. You must upgrade all Access Servers on a host before upgrading WebGates on the same host.

Task overview: Upgrading original Access System components

1. Locate the association details for original Access Servers and WebGate instances using the Access System Console. For more information, see your NetPoint or Oracle COREid Administration Guide.

2. Preparation: See "Preparing Original Access System Components for the Upgrade", when directed to do so.

3. Access Manager: See the following topics and perform tasks when directed:

   1. Upgrading An Original Access Manager Instance

   2. Setting Up the Upgraded Original Access Manager

4. Access Servers: Tasks with original Access Servers must be performed in reverse order compared with tasks for clones:

   1. Configuring Original Access Servers to Use the New Branch.

   2. Upgrading Original Access Server Instances

5. WebGates: Perform tasks in "Upgrading Original WebGates".

6. Validation and Backup: Perform the following tasks:

   1. Validating the Upgraded Original Access System

   2. Backing Up the Upgraded Original Access System

7. SDKs, Integration Connectors, and Access System Customizations:

   • Upgrading SDKs, Integration Connectors, and Access System Customizations

   • Validating the Entire Upgraded Original Environment

For information about recovering if there is a problem, see "Recovering From an Original Access System Upgrade Failure".

17.6.2 Preparing Original Access System Components for the Upgrade

The procedures to prepare each component for an upgrade are described in detail in Chapter 8. You must perform most of the same preparation tasks before upgrading each original Access System component using the zero downtime method. The following overview outlines the tasks that you will perform for each original instance upgrade. Details are provided in independent topics in Chapter 8.

Task overview: Preparing original Access System components for the upgrade includes the following topics

1. Creating Individual Profiles for WebGates that Share a Profile

2. Preparing the Default Logout in the Policy Manager

3. Preparing Host Computers

   • Changing Read Permissions on Password Files

   • Confirming Free Disk Space

4. Preparing Release 6.x Environments

5. Preparing Multi-Language Installations

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

   
   

   Note: WYou do not need to back up the file system directory. Instead, you will rename the original path to use as a source. The source becomes a backup that remains intact during the upgrade.

   
   

7. Stopping Servers and Services

8. Logging in with Appropriate Administrative Rights

17.6.3 Creating Individual Profiles for WebGates that Share a Profile

Before you upgrade an original Access Manager instance, you need to add an individual profile in the clone System Console for each WebGate that shares an AccessGate profile. If each WebGate is defined by its own individual profile, you can skip this task.

When each WebGate has an individual profile defined in the Access System Console, the content of the WebGateStatic.lst file is migrated to the LDAP directory server under the attribute obcompoundata. After the data is migrated, the WebGatestatic.lst file is removed from the WebGate_install_dir file system path automatically. When you have more than one WebGate sharing the same profile, however, the following error when upgrading the second WebGate that uses the profile:

"The WebGate Profile is being shared by many WebGate Instances. WebgateStatic.lst 
has already been migrated. However the contents do not match between the 
WebgateStatic.lst of this WebGate Instance and the migrated one. Please create a 
new WebGate Entry for this WebGate Instance. ...."

Before upgrading any WebGate that shares a profile with another WebGate, you need to:

• Add a separate and unique AccessGate profile for each original WebGate that currently shares a profile.

• Ensure that the new profile contains specifications based on details in the existing WebGateStatic.lst file

• Back up, and then delete the WebGateStatic.lst file from the original WebGate_install_dir

A release 6.1.1. WebGateStatic.lst file is shown next. For more information about the details in this file, see your Oblix NetPoint or Oracle COREid Administration Guide. All parameters in this file are now provided on the AccessGate profile page in the Release 10.1.4 Patch Set 1 (10.1.4.2.0) Access System Console.

BEGIN:vCompoundList 
DenyOnNotProtected:false 
CachePragmaHeader:no-cache 
CacheControlHeader:no-cache 
IPValidation:false 
# Set UseIISBuiltinAuthentication to true 
# if you are using MSPassport or Integrated 
# Windows Authentication on this machine. 
# Otherwise leave it set to false 
# Only used for IIS 
UseIISBuiltinAuthentication:false 
#IPValidationExceptions: 
#BEGIN:vList 
#nn.nn.nn.nn 
#nn.nn.nn.nn 
#END:vList  
WaitForFailover:-1 ( Access Server Timeout Threshold in the AccessGate Profile)
END:vCompoundList 

Both the WaitForFailover parameter and the replacement Access Server Timeout Threshold in the AccessGate Profile control the TCP/IP timeout between the WebGate and the Access Servers with which the WebGate communicates. The default value is -1, which means that the network default TCP/IP timeout value is used.

The following procedure outlines how to add a new profile to prepare WebGates that share a profile. For more information, see Oracle Access Manager Access Administration Guide.

To create an individual profile for each original WebGate

1. Locate the WebGateStatic.lst file for the WebGate that needs an individual profile, make a back up copy of the file, and then print the details. For example:

   
   WebGate_install_dir\access\oblix\apps\webgate\WebGateStatic.lst
   

2. Go to the clone Access System Console, as usual.

   http://hostname:port/access/oblix/
   

3. Click the Access System Console link, click Access System Configuration, and then click Add New AccessGate in the left navigation pane.

4. On the Add New AccessGate page, add unique details for this specific WebGate:

   • AccessGate Name: The name of this WebGate instance, which cannot contain spaces, a colon ":", the pound sign "#", or non-English keyboard characters.

   • Description: Optional summary that will help you identify this WebGate later on.

   • Hostname: The name or IP address of the server hosting this WebGate.

   • Port: The Web server port protected by this WebGate

   • AccessGate Password: An alphanumeric string to identity this WebGate to an Access Server.

     
     

     Note: This password must be the same one that was specified when you installed the WebGate.

     
     

   • Re-type AccessGate Password: Re-type the password.

5. Fill in remaining fields based on information in the WebGateStatic.lst file for the instance, and then save the profile.

6. Associate this new profile with an original Access Server, on the Details for AccessGate page as follows:

   1. On the Details for AccessGate page, click the List Access Servers (or List Clusters) button at the bottom of the page.

   2. Click the Add button to advance to the Add a new Access Server page.

   3. Select an Access Server from the Select Server list, specify a priority, and define the number of Access Servers (connections) to which this WebGate can connect. For example:

      
      Select server—Same as earlier profile
      Select priority—Same as earlier profile
      Number of connections—Same as earlier profile

   4. Click the Add button to complete the association.

   5. Click the link to display a summary and print this page for use later

7. Delete the WebGateStatic.lst file from WebGate installation directory before you upgrade the WebGate.

8. Repeat this procedure for each WebGate that is sharing a profile.

9. Complete all other zero downtime upgrade tasks in order.

17.6.4 Upgrading An Original Access Manager Instance

The activities that you perform when upgrading original Access Manager instances, are similar to the activities that you performed to upgrade Access Manager clones.

Caution: Oracle recommends that you review all information in this topic before proceeding with the activities. You will be instructed to rename and create file system directories.

You start by ensuring that you have the source, destination, and tools defined for the instance upgrade. To help illustrate these activities, Table 17-8 organizes sample file system paths in columns that describe the progression of actions that you will perform. Additional information follows the table. The sample path names are for Windows platforms. The paths in your environment might differ.

Table 17-8 Activities to Prepare for an Original Access Manager Instance Upgrade

1 Original Path	2 Source Creation	3 Destination Creation and Obtaining Tools
Access Manager Instances np611\webcomponent_01\access np611\webcomponent_02\access	In the original file system, rename the subdirectory containing each original instance. For example: np611\webcomponent_01 \access_source np611\webcomponent_02\access_source	After creating the source (see column 2): A. Extract 10g (10.1.4.0.1) Policy Manager libraries and files and specify the original path as the installation (destination) directory. For example: np611\webcomponent_01\access Note: The destination path of the 10g (10.1.4.0.1) instance must exactly match the original path before it was renamed (see column 1). See "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files". B. Apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the 10g (10.1.4.0.1) instance to obtain the tools. See "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)". C. Repeat steps A and B for each clone instance.

After performing the activities outlined in Table 17-8, the 10g (10.1.4.2.0) MigrateOAM script will be stored in the destination_dir. For example:

np611\webcomponent_01\access\oblix\tools\migration_tools\MigrateOAM.bat
np611\webcomponent_02\identity\oblix\tools\migration_tools\MigrateOAM.bat
and so on.

For more information about source and destination creation, see "Preparation Tasks for the Zero Downtime Method".

Table 17-9 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to execute the original instance upgrade for each individual Access Manager.

Table 17-9 MigrateOAM Script for Original Access Manager Instance Upgrades

MigrateOAM Original Mode Syntax	Values and Operations
-M Prod	Specify Prod as the mode, which is required to upgrade original components.
-C AM	Specify AM to upgrade an original Access Manager component. Note: Upgrade each original Access Manager after upgrading all Identity System components and before upgrading any original Access Servers.
-F nnn	Specify the number that identifies your earlier release. For example: 610 (for 6.1 or 6.1.1), 650 (for 6.5.x), or 700 (for 7.x)
-T 1014	Specify1014 as the release to which this data will be upgraded.
-S "source directory"	Specify the full path (in quotation marks) to the renamed original Access Manager directory (see column 2 of Table 17-8). For example, when you have multiple instances: -S "C:\np611\webcomponent_01\access_source" -S "C:\np611\webcomponent_02\access_source" and so on
-D "destination directory"	Specify the full path (in quotation marks) to the 10g (10.1.4.2.0) Policy Manager directory that replaced the earlier Access Manager directory (see columns 1 and 4 of Table 17-8). For example: -D "C:\np611\webcomponent_01\access" -D "C:\np611\webcomponent_02\access" and so on
-I "installation directory"	The installation directory should be the same as the destination directory. For example: -I "C:\np611\webcomponent_01\access" -I "C:\np611\webcomponent_02\access" and so on Note: Refer to Table 17-8 for details about path names and directory content.
-L "Languages"	Specify all installed languages to be upgraded by the appropriate code, in quotations. For example, English, "en-us"; French, "fr-fr"; German, "de-de".
-W "Web server type"	Specify the appropriate code for the Web Server used by this original, in quotations. For example, "nsapi", "apache2", "isapi", apache", "ihs", "ohs", "ohs2", "domino".

Upgrading an original Access Manager does not impact the schema or data but does include a Web server configuration upgrade. For more information about using the MigrateOAM for this upgrade, see "About Original Mode (Prod) Processing"

Note: When you have a single Web server instance serving more than one Oracle Access Manager Web component, the Web server must remain stopped until all serviced Web components on the host computer are upgraded.

In the following procedure, directory path names, the starting release, and languages are provided as samples only.

Caution: If you do not perform all preparation steps, you might not be able to recover from a problem or to roll back after a failed upgrade.

To upgrade the original Access Manager

1. Preparation: Perform tasks in "Preparing Original Access System Components for the Upgrade", which includes:

   • Preparing Earlier Customizations

   • Preparing the Default Logout in the Policy Manager

   • Creating Individual Profiles for WebGates that Share a Profile

   • Preparing Host Computers

     • Changing Read Permissions on Password Files

     • Confirming Free Disk Space

   • Preparing Release 6.x Environments

   • Preparing Multi-Language Installations

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

     
     

     Note: With this upgrade method, you do not need to back up the file system directory.

     
     

   • Stopping Servers and Services

   • Logging in with Appropriate Administrative Rights

2. Source Creation: Rename the subdirectory that contains the original Access Manager to create a source for the upgrade. For example:

   
   Rename: np611\webcomponent_01\access
   As: \np611\webcomponent_01\access_source
   Description of the illustration orig_pm_rename.gif
   
   

3. Destination Creation: Extract 10g (10.1.4.0.1) Policy Manager libraries and files and specify a destination path that exactly matches the original before you renamed it. For example:

   
   Destination Path: np611\webcomponent_01\access
   

   or a destination path example, see column 1 of Table 17-8. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".

4. Obtaining the Tools: Apply the 10g (10.1.4.2.0) patch to the 10g (10.1.4.0.1) instance, as described "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".

   When your file system is set up appropriately, you are ready to upgrade the original instance.

5. Change to the destination_dir that includes the 10g (10.1.4.2.0) MigrateOAM script for the instance that you will upgrade. For example:

   np611\webcomponent_01\access

6. Run the MigrateOAM script in Prod mode and specify your starting release and path names for the instance. For example:

   MigrateOAM -M Prod -C AM -F 610 -T 1014 -S "C:\np611\webcomponent_01\access_ 
   source" -D "C:\np611\webcomponent_01\access" -I "C:\np611\webcomponent_01\ 
   access" L "en-us" -W "nsapi"
   

   1. Use Automatic mode for each sequence so that you do not need to confirm each process.

   2. Accept Web server configuration changes by specifying the full directory path name to the Web server configuration file for which this original is configured.

   3. Continue as requested through all processes; do not skip any processes.

   4. Finish according to on-screen messages.

      The source remains intact. The destination now includes a 10g (10.1.4.2.0) instance configured with the same parameters and details as the source.

      
      Description of the illustration orig_pm_end.gif
      
      

7. Verify that upgrading the original Access Manager was successful as follows:

   1. Apply Web server changes, if needed.

      
      

      Note: When you have a single Web server instance serving more than one Oracle Access Manager Web component, the Web server must remain stopped until all serviced Web components on the host computer are upgraded.

      
      

   2. Windows: Verify that the registry entry is updated by running the Registry editor (regedit) and:

      View the registry entry HKEY_LOCAL_MACHINE, SOFTWARE,Oblix,Oblix Netpoint. Check for the respective installed version and, under that, check the entry for Access Manager.

   3. Verify that the version file in the destination path is updated for 10.1.4 (npversion_component.txt). For example:

      destination_dir\oblix\config\np1014_am.txt

8. Proceed as follows:

   1. Upgrade Not Successful: Check the migration log file for this instance for any errors reported during the upgrade, as described in "Accessing Log Files".

   2. Upgrade Successful: Proceed to "Setting Up the Upgraded Original Access Manager" if all Web components on this host are upgraded. Otherwise, skip to "Upgrading Original Access Server Instances".

9. Upgrade and set up all original Access Manager instances.

17.6.5 Setting Up the Upgraded Original Access Manager

After upgrading each Access Manager instance, you reconfigure it to operate with the upgraded schema and data in the new branch of the LDAP directory server. Be sure to take the conditions in Table 17-10 into account:

Table 17-10 Access Manager Setup  Conditions for Zero Downtime Upgrades

Condition	Action
Access Manager and WebGates are in the same directory	Postpone reconfiguring this Access Manager until the WebGate is upgraded
One Web server instance is servicing other Web components	Upgrade all serviced Web components before restarting the Web server instance
All Web components for this Web server instance are upgraded	Perform activities in: "Setting Up the Upgraded Original Identity System", if needed "Setting Up the Upgraded Original Access Manager" Before restarting any original Access Server service after reconfiguring an upgraded original Access Manager, log in to the Access System Console from any upgraded original Access Manager and delete the profiles that were created and named Access_Manager_user_setup_profile and Access_Server_setup_user_profile

You use the following procedure to set up the original Access Manager after upgrading. This procedure provides the sequence of steps that you need to perform. File System path names are presented as an example. Your details will be different. For more information about setting up the Identity System, see the Oracle Access Manager Installation Guide.

17.6.5.1 Setting Up the Original Access Manager to Use the New Branch

During this procedure, you will need to provide some details from the original installation, including the LDAP directory server type, the location of user data and the searchbase, and the Person Object Class. This information was defined when the original COREid System was set up. The Person Object Class and other details were obtained when setting up the Access Manager clone. If you do not have access to the original, you can obtain it from the setup.xml file in the original COREid Server source directory. For example, the source in this example would be np611\ois_01\identity_source\oblix\config\setup.xml, for example).

You will also need to supply new information, including the new branch in the LDAP directory server where configuration and policy data are stored.

The following procedure provides the sequence of steps that you need to perform. File System path names are presented as an example. Your details will vary.

To reconfigure the original Access Manager to use the new branch

1. Obtain details about the original source COREid Server from the setup.xml file. For example: np611\webcomponent_01\identity_source\oblix\config\setup.xml.

2. Delete the following files from the upgrade destination that was specified for the instance: for example, np611\webcomponent_01\access\oblix\config:

   • setup.*

   • configInfo.*

   • \ldap subdirectory

3. Ensure that the original Access Manager Web server is running and go to the original Access System Console, as usual.

   http://hostname:port/access/oblix/
   

   In the sample URL, hostname refers to computer that hosts the original upgraded WebPass; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the original Access System Console.

4. Click the Access System Console link to display the Setup page, and then click the Setup button.

5. Set up the Access Manager to use the new configuration DN and policy base, as follows (see also your Oracle Access Manager Installation Guide for more information).

   1. Enter and confirm LDAP directory server details, including the directory server type and the location and details for user data and configuration data.

   2. Enter the information for user data (original search base), and for configuration data (configuration DN) and policy data (Policy Base) in the new branch of the directory server. For example:

      Search Base—Enter the original searchbase.

      Configuration DN— o=Newbranch,o=company,c=us

      Policy Base——o=NewPolicyBase,o=Policy_base,o=company,c=us

   3. Proceed through remaining Access Manager setup pages and leave all other setup details as they are.

   4. Enter the Person Object Class, which was selected during the original earlier COREid System set up.

      
      

      Note: This information is located in the setup.xml file of the original COREid Server: np611\ois_01\identity\oblix\config\setup.xml, for example.

      
      

   5. Restart the Web server and Identity Server service when instructed to do so.

   6. After the Web server restarts, click Next and continue by accepting the default Policy Domain Root (or specifying the root for your original installation).

   7. Continue, but do not configure authentication schemes or policies to protect NetPoint URLs.

   8. Click done when setup is complete.

6. Verify that the Directory Server profile has the new configuration DN and policy base, as follows:

   1. Go to the Access System Console, as usual.

      http://hostname:port/access/oblix/
      

   2. Click Access System Console, click System Configuration, then click Server Settings.

   3. Click Server Settings in the left column and then click the Directory Server link.

   4. On the Directory Server Configuration page, confirm that the Configuration Base (also known as the configuration DN) and Policy Base reflect the new branch.

   5. Check for and delete any extra directory profiles that might have been added and named Access_Manager_user_setup_profile and Access_Server_setup_user_profile.

7. Proceed as follows:

   • Successful: Proceed with Step 8.

   • Not Successful: Set up the Access Manager anew by performing procedure again and be sure to specify all information correctly.

8. In the following upgraded and updated Access Manager configuration files, confirm that the new configuration DN appears. For example, in np611\webcomponent\access_01\oblix\config:

   • setup.*

   • setup_am*

   • configInfo

9. Proceed as follows:

   • Successful: If the new configuration DN and policy base appear in the files mentioned in step 8, the operation was successful. Proceed to Step 10.

   • Not Successful: If the new configuration DN and policy base do not appear in the files mentioned in step 8, the operation failed. In this case, see "Rolling Back After Upgrading the Original Access System".

10. Repeat the following procedures to upgrade and set up each original Access Manager.

    • Preparing Original Access System Components for the Upgrade

    • Upgrading An Original Access Manager Instance

    • Setting Up the Upgraded Original Access Manager, as appropriate for the Web server conditions in your environment

11. When all original Access Manager instances are upgraded, proceed to "Configuring Original Access Servers to Use the New Branch".

17.6.6 Configuring Original Access Servers to Use the New Branch

You perform this task only if you have a joint Identity and Access System deployed. Otherwise, skip to "Validating the Entire Upgraded Original Environment". Ensure that all original Access Manager instances on the computer host have been upgraded.

Before you reconfigure each original Access Server, you must back up the original branch in the LDAP directory server, and then archive processed workflows. The original branch data that you need includes configuration and policy data, user and group data, workflow data. In addition, you need to back up the original instance \config file system subdirectory, which contains directory server configuration details for the original branch. This is needed for a successful roll back operation if you choose to roll back.

After performing the backup activities, you are ready to reconfigure the instance touse the new branch. However, the Access Server Service should be started only after you upgrade the instance. Do not restart the Access Server Service after reconfiguring the instance.

You will use the configureAAAserver.exe tool (Windows) or start_configureAAAServer (UNIX-based systems) for this task. The tool is located in each original Access Server directory. For example:

Windows: np611\aaa_01\access\oblix\tools\configureAAAServer\
configureAAAServer.exe

UNIX: /home/np611/aaa_01/access/oblix/tools/configureAAAServer\start_
configureAAAServer

Extra directory profiles might be created for original Access Servers during the reconfiguration. You will be instructed to remove any extra directory profiles when you verify the reconfigured Access System.

In the example, UNIX refers to supported UNIX-based platforms such as Linux and Solaris. When running the tool, you will be asked to provide details for the original Access Server. File system path names in the following procedure are samples only. Your details will be different.

Caution: If you do not perform all preparation tasks for the instance, you might not be able to recover if there is a problem or to roll back to the original instance.

To reconfigure an original Access Server to use the new branch

1. Preparing the Original Branch: Back up the branch that is used by the original installation. See Chapter 5 and perform the following tasks:

   • Backing up the Earlier Oracle Access Manager Schema

   • Backing up Oracle Access Manager Configuration and Policy Data

   • Backing Up User and Group Data

   • Backing Up Workflow Data

   • Archiving Processed Workflow Instances

2. Preparing the File System: Back up the \config directory for the instance to be reconfigured; \config is located in the original AccessServer_install_dir file system path. For example:

   np611\aaa_01\access\oblix\config

3. Locate and run the tool for your platform in the original AccessServer_install_dir. For example:

   
   Windows: np611\aaa_01\access\oblix\tools\configureAAAServer\
   configureAAAserver.exe
   

   configureAAAServer.exe install "C:\np611\aaa_01\access" 
   

   
   UNIX: /home/np611/aaa_01/access/oblix/tools/configureAAAServer/
   start_configureAAAServer
   

   ./start_configureAAAServer install "/home/np611/aaa_01/access"
   

4. Follow the on-screen prompts and provide details for your original instance when prompted. For example:

   • The transport security mode for the original instance

   • The security mode in which the user data directory is running

   • The host computer on which the user data directory resides

   • The port number on which the user data directory listens

   • The bind DN of the user data directory

   • The password of the user data directory

   • The directory type for user data

   • The location where new oblix (configuration) data is stored

   • The new configuration DN

   • The new policy base

   • The original instance Access Server ID

   See the NetPoint or Oracle COREid Administration Guide for information on the configureAAA tool and LDAP directory server configurations.

5. Write the name of the original instance Access Server service, but do not specify or update failover information; do not start the Access Server service until the instance has been upgraded.

   • Successful: Proceed to Step 6.

   • Not Successful: Proceed to"Recovering From an Original Access System Upgrade Failure".

6. Confirm that the new information that you entered during reconfiguration is included in the aaa_server_config.xml file in the \config file system subdirectory in the original AccessServer_install_dir. For example:

   np611\aaa_01\access\oblix\config\aaa_server_config.xml

7. Confirm that the value of the MigrateUserDataTo1014 is false in the globalparams.xml file for this instance. For example:

   np611\aaa_01\access\oblix\apps\common\bin\globalparams.xml

   <NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
   

8. Proceed as follows:

   • Successful: If the new policy base appears in the file mentioned in Step 6, the operation was successful. Proceed to Step 9.

     
     

     Note: The Web Server instance on the host computer must remain stopped until all Web components (WebPass, Access Manager, and WebGate) on the host computer have been upgraded.

     
     

   • Not Successful: If the new policy base does not appear in the files mentioned in step 6, the operation failed. In this case, see "Recovering From an Original Access System Upgrade Failure".

9. After Access Manager Set Up: Verify that the Directory Server profile for the original Access Server instance has the new configuration DN and policy base, as follows:

   1. Go to the original Access System Console, as usual.

      http://hostname:port/access/oblix/
      

   2. Click Access System Console, click System Configuration, then click Server Settings.

   3. Click the Directory Server link to display the Directory Server Configuration page.

   4. Confirm that the new configuration DN and the policy base are correct, and then click Cancel.

   5. Extra Profiles in a Split Directory Server Configuration: Check for and remove any extra directory profiles that might have been added when Access Servers were reconfigured. For more information, see "Setting Up the Cloned COREid System to Use the New Branch" and the Oracle Access Manager Identity and Common Administration Guide.

10. Proceed as follows:

    • Successful: Proceed to "Upgrading Original Access Server Instances" to upgrade this instance.

    • Not Successful: Proceed to "Recovering From an Original Access System Upgrade Failure", and start again.

11. Repeat all steps in this procedure and in "Upgrading Original Access Server Instances" with each original Access Server instance, before proceeding to "Upgrading Original WebGates".

17.6.7 Upgrading Original Access Server Instances

This topic describes all activities that must be performed to upgrade an original Access Server instance after you have reconfigured it. This topic concludes with a step-by-step procedure that walks you through all activities.

Caution: Oracle recommends that you review all information in this topic before starting.

During original Access Server upgrades, parameter catalogs and component-specific configuration files are upgraded. Table 17-11 provides sample directory path names in columns that describe the progression of actions that you will perform. Additional information follows the table. The sample file system path names are for Windows platforms. The paths in your installation might differ.

Table 17-11 Activities to Prepare for an Original Access Server Instance Upgrade

1 Original Path	2 Source Creation	3 Destination Creation and Obtaining Tools
Access Server Instances np611\aaa_01\access np611\aaa_02\access	In the original file system, rename the subdirectory containing each original instance. For example: np611\aaa_01\access_source np611\aaa_02\access_source	After creating the source (see column 2): A. Extract 10g (10.1.4.0.1) Access Server libraries and files and specify original path as the installation (destination) directory. For example: np611\aaa_01\access Note: The destination path of the 10g (10.1.4.0.1) instance must exactly match the original path before it was renamed (see column 1). See "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files". B. Apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the 10g (10.1.4.0.1) instance to obtain the tools. See "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)". C. Repeat steps A and B for each clone instance.

After performing the activities outlined in Table 17-11, the 10g (10.1.4.2.0) MigrateOAM script will be available in the destination path for original Access Server instances. For example:

np611\aaa_01\access\oblix\tools\migration_tools\MigrateOAM.bat
np611\aaa_02\access\oblix\tools\migration_tools\MigrateOAM.bat
and so on.

Table 17-12 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to upgrade original Access Servers.

Table 17-12 MigrateOAM Production Arguments for Original Access Server Upgrades

MigrateOAM Original (Production) Mode Syntax	Values and Operations
-M Prod	Specify Prod as the mode to upgrade original components. The production mode is required to upgrade original components.
-C AAA	Specify AAA to upgrade an original Access Server. Note: Upgrade each original Access Server before upgrading original WebGates.
-F nnn	Specify the number that identifies your earlier release. For example: 610 (for 6.1 or 6.1.1), 650 (for 6.5.x), or 700 (for 7.x)
-T 1014	Specify1014 as the release to which this data will be upgraded.
-S "source directory"	Specify the full path (in quotation marks) to the renamed original Access Server directory (see column 1 of Table 17-11). For example: -S "C:\np611\aaa_01\access_source" -S "C:\np611\aaa_02\access_source" and so on.
-D "destination directory"	Specify the full path (in quotation marks) to the 10g (10.1.4.2.0) Access Server directory that replaced the original instance directory (see columns 1 and 4 of Table 17-11). For example: -D "C:\np611\aaa_01\access" -D "C:\np611\aaa_02\access" and so on.
-I "installation directory"	The installation directory should be the same as the destination directory. For example: -I "C:\np611\aaa_01\access" -I "C:\np611\aaa_02\access" and so on.
-L "Languages"	Specify all installed languages to be upgraded by the appropriate code, in quotations. For example, English, "en-us"; French, "fr-fr"; German, "de-de".

In the following procedure, directory path names, the starting release, and languages are provided as samples only. Your details will differ.

Caution: If you do not perform all preparation steps, you might not be able to recover from a problem or to roll back after a failed upgrade.

To upgrade original Access Server instances

1. Preparation: Perform tasks in "Preparing Original Access System Components for the Upgrade", which includes:

   • Preparing Earlier Customizations

   • Preparing the Default Logout in the Policy Manager

   • Creating Individual Profiles for WebGates that Share a Profile

   • Preparing Host Computers

     • Changing Read Permissions on Password Files

     • Confirming Free Disk Space

   • Preparing Release 6.x Environments

   • Preparing Multi-Language Installations

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

     
     

     Note: With this upgrade method, you do not need to back up the file system directory.

     
     

   • Stopping Servers and Services

   • Logging in with Appropriate Administrative Rights

2. Source Creation: Rename the subdirectory that contains the original Access Server instance to create a source for the upgrade. For example:

   
   Rename: np611\aaa_01\access
   As: np611\aaa_01\access_source
   Description of the illustration orig_aaa_rename.gif
   
   

3. Destination Creation: Extract 10g (10.1.4.0.1) Access Server libraries and files and specify a destination path that exactly matches the original before you renamed it. For example:

   
   Destination Path: np611\aaa_01\access
   

   The destination path must exactly match the source before it was renamed in Step 2. For a destination example, see Table 17-11. For extraction details, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".

4. Obtaining the Tools: Apply the 10g (10.1.4.2.0) patch to the 10g (10.1.4.0.1) instance, as described "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".

   When your file system is set up appropriately, you are ready to upgrade the original instance.

   
   Description of the illustration orig_aaa_extract.gif
   
   

5. Change to the destination_dir that includes the 10g (10.1.4.2.0) MigrateOAM script for the instance that you will upgrade. For example:

   np611\aaa_01\access

6. Run the MigrateOAM script in Prod mode and specify your starting release and path names for the instance. For example:

   MigrateOAM -M Prod -C AAA -F 610 -T 1014 -S "C:\np611\aaa_01\access_source" -D 
   "C:\np611\aaa_01\access" -I "C:\np611\aaa_01\access" -L "en-us"
   

   1. Use Automatic mode for each sequence so that you do not need to confirm each process.

   2. Continue as requested through all processes; do not skip any processes.

   3. Finish according to on-screen messages.

      The source remains intact. The destination now includes a 10g (10.1.4.2.0) instance configured with the same parameters and details as the source.

      
      Description of the illustration orig_aaa_end.gif
      
      

7. Verify that the upgrade was successful as follows:

   1. Start the Access Server service. If the Access Server Service Does Not Start:

      Check your event and Access Server log output files. For more information about logging and log output files, see the Oracle Access Manager Identity and Common Administration Guide.

      Check migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".

   2. Windows: Verify that the registry entry is updated by running the Registry editor (regedit) using one of the following methods:

      In the Registry Editor Window, click My Computer, HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Services, and then look for ObAAAServer-<Service Name>. Within this, check the Image path.

      View the registry entryHKEY_LOCAL_MACHINE, SOFTWARE,Oblix,Oblix Netpoint. Check for the respective installed version and, under that, check the entry for ObAAAServer-<Service Name>.

   3. Verify that the version file in the destination path is updated for 10.1.4. For example:

      destination_dir\access\oblix\config\np1014_aaa.txt

      
      

      Note: The Web Server must remain stopped until all Web components on the host computer have been upgraded.

      
      

   4. Upgrade Not Successful: Proceed to "Recovering From an Original Access System Upgrade Failure".

   5. Upgrade Successful: Proceed to step 8.

8. Repeat all steps in this procedure for all other original Access Server instances on this host.

9. Proceed to "Upgrading Original WebGates".

17.6.8 Upgrading Original WebGates

After upgrading Access Server instances on a single host, Oracle recommends that you upgrade the WebGate so that you can finish reconfiguring the system and restart it. The Web Server must remain stopped until all Web components on the host computer have been upgraded.

When multiple WebGates share a single profile in the earlier installation, before upgrading the WebGate you will be instructed to create an individual profile for each WebGate if you have not already done so.

Each WebGate upgrade requires that at least one Access Server configured for that WebGate is running. This is required to enable the migration of information from the WebGateStatic.lst file to the WebGate profile in the System Console.

To upgrade original WebGates, see:

• Upgrading Original WebGates

• Reconfiguring Upgraded WebGates

17.6.8.1 Upgrading Original WebGates

During WebGate upgrades, profile information is used when migrating information from the original WebGateStatic.lst file. If you have not created the profile as described in "Adding a Temporary Directory Profile for Original Access System Upgrades", this will be your first step to upgrading.

Caution: Oracle recommends that you review all information in this topic before proceeding with the activities. You will be instructed to rename and move directories and it is critical that you track instance directories and names.

To help illustrate some activities that you will perform, Table 17-13 organizes sample file system path names in columns that describe the progression of actions that you will take. Additional information follows the table. The sample path names are for Windows platforms. The paths in your installation will be different.

Table 17-13 Activities to Prepare for an Original WebGate Instance Upgrade

1 Original Path	2 Source Creation	3 Destination Creation and Obtaining Tools
WebGate Instances np611\webgate_01\ access	In the original file system, rename the subdirectory containing each original instance. For example: np611\webgate_01\ access_source	After creating the source (see column 2): A. Extract 10g (10.1.4.0.1) WebGate libraries and files and specify the original path as the installation (destination) directory. For example: np611\webgate_01\access Note: The path of the 10g (10.1.4.0.1) instance must exactly match the original path before it was renamed (see column 1). See "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files". B. Apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the 10g (10.1.4.0.1) instance to obtain the tools for this upgrade. See "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)". C. Repeat steps A and B for each WebGate instance.

After performing activities outlined in Table 17-13, the 10g (10.1.4.2.0) MigrateOAM script will be stored in the destination you created. For example:

np611\webgate_01\access\oblix\tools\migration_tools\MigrateOAM.bat
and so on.

Table 17-14 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to execute the original instance upgrade for each individual WebGate.

Table 17-14 MigrateOAM Script for Original WebGate Instance Upgrades

MigrateOAM Original Mode Syntax	Values and Operations
-M Prod	Specify Prod as the mode, which is required to upgrade original components.
-C WG	Specify WG to upgrade an original WebGate component.
-F nnn	Specify the number that identifies your earlier release. For example: 610 (for 6.1 or 6.1.1), 650 (for 6.5.x), or 700 (for 7.x)
-T 1014	Specify1014 as the release to which this data will be upgraded.
-S "source directory"	Specify the full path (in quotation marks) to the renamed original WebGate directory (see column 2 of Table 17-13). For example, when you have multiple instances: -S "C:\np611\webgate_01\access_source" -S "C:\np611\webgate_02\access_source" and so on
-D "destination directory"	Specify the full path (in quotation marks) to the 10g (10.1.4.2.0) WebGate directory that replaced the earlier WebGate directory (see columns 1 and 4 of Table 17-13). For example: -D "C:\np611\webgate_01\access" -D "C:\np611\webgate_02\access" and so on
-I "installation directory"	The installation directory should be the same as the destination directory. For example: -I "C:\np611\webgate_01\access" -I "C:\np611\webgate_02\access" and so on. Note: Refer to Table 17-13 for details about path names and directory content.
-L "Languages"	Specify all installed languages to be upgraded by the appropriate code, in quotations. For example, English, "en-us"; French, "fr-fr"; German, "de-de".
-W "Web server type"	Specify the appropriate code for the Web Server used by this original, in quotations. For example, "nsapi", "apache2", "isapi", apache", "ihs", "ohs", "ohs2", "domino".

Upgrading an original WebGate instance includes message and parameter file upgrades, as well as a Web server configuration upgrade.

Note: When you have a single Web server instance serving more than one Oracle Access Manager Web component, the Web server must remain stopped until all serviced Web components on the host computer are upgraded.

Each WebGate upgrade requires that at least one Access Server configured for that WebGate is running. This is required to enable the migration of information from the WebGateStatic.lst file to the WebGate profile in the System Console.

In the following procedure, directory path names, the starting release, and languages are provided as samples only.

Caution: If you do not perform all preparation steps, you might not be able to recover from a problem or to roll back after a failed upgrade.

To upgrade the original WebGate

1. Preparation: Perform tasks in "Preparing Original Access System Components for the Upgrade", which includes:

   • Preparing Earlier Customizations

   • Preparing the Default Logout in the Policy Manager

   • Creating Individual Profiles for WebGates that Share a Profile

   • Preparing Host Computers

     • Changing Read Permissions on Password Files

     • Confirming Free Disk Space

   • Preparing Release 6.x Environments

   • Preparing Multi-Language Installations

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

     
     

     Note: With this upgrade method, you do not need to back up the file system directory.

     
     

   • Stopping Servers and Services

   • Logging in with Appropriate Administrative Rights

2. Ensure that there is a temporary LDAP directory profile for the Access System, as described in "Adding a Temporary Directory Profile for Original Access System Upgrades".

3. Confirm that there is a unique, individual profile for each WebGate defined in the Access System Console. For more information, see "About Creating Individual Profiles for WebGates that Share a Profile".

4. Stop the original WebGate Web server and confirm that at least one Access Server that is configured to operate with this WebGate is running.

5. Source Creation: Rename the subdirectory that contains the original WebGate instance to create a source for the upgrade. For example:

   
   Rename: np611\webgate_01\access
   As: np611\webgate_01\access_source
   Description of the illustration orig_wg_rename.gif
   
   

6. Destination Creation: Extract 10g (10.1.4.0.1) WebGate libraries and files and specify a destination path that exactly matches the original before you renamed it. For example:

   
   Destination Path: np611\webgate_01\access
   

   For a destination example, see Table 17-13. For extraction details, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".

7. Obtaining the Tools: Apply the 10g (10.1.4.2.0) patch to the 10g (10.1.4.0.1) destination, as described "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".

   When your file system is set up appropriately, you are ready to upgrade the original instance.

   
   Description of the illustration orig_wg_extract.gif
   
   

8. Change to the destination_dir that includes the 10g (10.1.4.2.0) MigrateOAM script for the instance that you want to upgrade. For example:

   cd np611\webgate_01\access

9. Run the MigrateOAM script in Prod mode and specify your starting release and path names for the instance. For example:

   MigrateOAM -M Prod -C WG -F 610 -T 1014 -S "C:\np611\webgate_01\access_ 
   source" -D "C:\np611\webgate_01\access" -I "C:\np611\webgate_01\access" 
   -L "en-us" -W "nsapi"
   

   1. Use Automatic mode for each sequence so that you do not need to confirm each process.

   2. Accept Web server configuration changes by specifying the full directory path name to the Web server configuration file for which this original is configured.

   3. Continue as requested through all processes; do not skip any processes.

   4. Finish according to on-screen messages.

      Your destination directory is now upgraded based on the original source configuration.

      
      Description of the illustration orig_wg_end.gif
      
      

10. Verify that upgrading the original WebGate was successful as follows:

    1. Apply Web server changes, if needed.

       
       

       Note: The Web Server must remain stopped until all Web components on the host computer have been upgraded.

       
       

    2. Windows: Verify that the registry entry is updated by running the Registry editor (regedit) and:

       View the registry entry HKEY_LOCAL_MACHINE, SOFTWARE,Oblix,Oblix Netpoint. Check for the respective installed version and, under that, check the entry for WebGate.

    3. Verify that the version file in the destination path is updated to 10.1.4 (npversion_component.txt). For example:

       destination_dir\webgate\access\oblix\config\np1014_wg.txt

11. Proceed as follows:

    1. Upgrade Not Successful: Check the event log and the migration log file for this instance for any errors reported during the upgrade, as described in "Accessing Log Files".

    2. Upgrade Successful: Reconfigure the upgraded WebGate, as described in "Reconfiguring Upgraded WebGates".

12. After upgrading and configuring all original WebGates, validate your Access System.

17.6.8.2 Reconfiguring Upgraded WebGates

After upgrading a WebGate instance, you need to reconfigure the upgraded WebGate to communicate with the upgraded Access Server.

You use the configureWebGate (Windows) and start_configureWebGate (UNIX) setup tool to enable the WebGate to communicate with the associated upgraded Access Server. A WebGate setup tool is included in each WebGate file system path on all platforms. In this example, the destination file system path is:

np611\webgate_01\access\oblix\tools\configureWebGate

Options for configureWebGate and start_configureWebGate are shown in Table 17-15. If you have multiple WebGate instances, you must repeat this operation with each instance.

Table 17-15 Command Options for configureWebGate and start_configureWebGate

Command Options	Operation
-i "destination_dir"	Specifies the full directory path (in quotation marks) to the destination directory used to upgrade this instance. For example: Windows: "C:\np611\webgate_01\access" UNIX: "/home/np611/webgate_01/access"
-t WebGate	Specifies that this operation is for a WebGate.

As the command is performed, messages keep you informed and you might be asked to supply information for this upgraded WebGate. Be sure to specify information for your environment.

The following procedure provides the sequence of steps that you need to perform. Your details will vary.

To modify a WebGate to communicate with the upgraded Access Server

1. Go to the WebGate destination directory that was specified during the upgrade and locate the configureWebGate (or start_configureWebGate) utility. For example:

   
   Windows: C:\np611\webgate_01\access\oblix\tools\configureWebGate
   UNIX: /home/np611/webgate_01/access/oblix/tools/configureWebGate
   

2. From the tools directory, run configureWebGate using the following options (see also Table 17-15) and specifications for your original environment. For example:

   configureWebGate -i "C:\np611\webgate_01\access" -t WebGate 
   

   The command must be entered as one line without breaks.

3. Proceed as directed by on-screen messages:

   • The transport security mode for the original instance

   • The WebGate ID

   • The WebGate password (for simple or cert mode)

   • The Access Server ID

   • The Access Server Host

   • The port number on which the Access Server listens

4. Proceed as follows:

   • Successful: The Message "WebGate installed successfully" appears. Proceed to Step 5 after you back up this information as described in "Backing Up the Upgraded Original Access System".

   • Not Successful: Proceed to "Recovering From an Original Access System Upgrade Failure".

5. If the WebGate is in the same directory as the upgraded Access Manager, go to "Setting Up the Upgraded Original Access Manager". Otherwise, upgrade and reconfigure another WebGate.

6. Upgrade and reconfigure each earlier WebGate.

7. When all WebGate instances are reconfigured, proceed to "Validating the Upgraded Original Access System".

17.6.9 Validating the Upgraded Original Access System

Oracle recommends that you quickly validate the following items to ensure that the overall upgrade of your original Access System upgrade was successful. If you experience an issue, refer to the troubleshooting tips in Appendix G.

To validate your upgraded original Access System

1. Delete all Web browser caches once the upgrade is complete.

2. Make sure all upgraded original Access Server services and Access Manager and WebGate Web server instances are running.

3. Check that your message and parameter catalog customizations have been preserved. For example, if you have changed any message in a particular message catalog file, then it needs to be retained.

4. Perform all validation tasks for the upgraded Access System, as described in "Validating the Upgraded Cloned Access System".

5. Proceed to "Backing Up the Upgraded Original Access System".

17.6.10 Backing Up the Upgraded Original Access System

Oracle recommends that you validate successful operations and then perform back up activities. This will enable you to easily restore your environment to the newly upgraded state should that be needed.

To back up critical information after upgrading original Access System components

1. Back up the upgraded destination file system directory. This is similar to backing up an existing component installation directory. For details, see "Backing Up the Existing Component Installation Directory".

2. Web Server: Back up the upgraded Web server configuration file using instructions from your vendor and details in "Backing Up the Existing Web Server Configuration File".

3. Windows: Back up Windows Registry data as described in "Backing Up Windows Registry Data".

4. Proceed to "Looking Ahead", and "Upgrading SDKs, Integration Connectors, and Access System Customizations".

17.6.11 Recovering From an Original Access System Upgrade Failure

If an original Access System component upgrade was not successful, you can perform the following steps to restore your environment, then try again.

To recover from an unsuccessful original Access System component upgrade

1. Back up the source file system directory anew. You will retain one to use as a backup copy and use one to restart the upgrade.

2. For the instance to be retried, remove the 10g (10.1.4.0.1) libraries and files to which you applied Release 10.1.4 Patch Set 1 (10.1.4.2.0).

3. For the instance to be retried, install 10g (10.1.4.0.1) libraries and files and apply Release 10.1.4 Patch Set 1 (10.1.4.2.0)

4. Web Server: Restore the backed up Web server configuration file, if required.

5. Windows: Restore the backed up Registry data for the component.

6. Using a backup copy of your earlier original component installation directory (and Web server configuration, if needed), restart the upgrade as described in the appropriate topic.

17.6.12 Rolling Back After Upgrading the Original Access System

This procedure will undo all changes and leave you with your original installation as it was before being upgraded.

Having only one WebGate will result in downtime when rolling back.

To roll back after upgrading the original Access System

1. Confirm that your clone setup is operating properly and serving customers.

2. Shut down the upgraded original service or Web server.

3. Remove any destination file system directories that were added and patched.

4. Restore the original instance file system path by renaming the source.

5. Windows: Import the back up copy of the Windows registry entry for the original instance and release.

6. Web Server Configuration: Restore the backup copy of original Web server configuration files.

7. Restore the back up copy of the Access Server's \config subdirectory to return to the original configuration.

8. Restart the original service or Web server.

9. Repeat all steps for each upgraded original.

10. In the original System Console, remove entries for the clones

11. If you have a back up copy of the original schema before upgrading, you might be able to reinstate the copy using external tools.

12. Confirm that the original setup is operating properly, and then configure the DNS to enable the original setup to serve customers. For more information, see "Reconfiguring Domain Name Systems (DNS) to Use Upgraded Clones".

13. Roll back the upgraded clone setup, which includes all clone file system directories, any Web server instances created for clones, the new branch that was created in the LDAP directory server. Also remove entries added to the original System Console for clone components. For more information, see Chapter 16:

    • Rolling Back Changes Made for the New oblix Branch

    • Rolling Back After Upgrading Identity System Clones

    • Rolling Back After Upgrading Access System Clones

17.6.13 Looking Ahead

When you have a joint Identity and Access System, you perform activities in the following sequence to finish the upgrade.

Task overview: Remaining joint Identity and Access System activities include

1. Upgrading SDKs, Integration Connectors, and Access System Customizations

2. Validating the Entire Upgraded Original Environment

3. Starting On-the-fly User Data Migration

4. Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment

5. Deleting the Temporary Directory Server Profile

6. Reverting Backward Compatibility

7. Removing the Cloned System After Upgrading Originals

17.7 Upgrading SDKs, Integration Connectors, and Access System Customizations

Oracle recommends that you upgrade any customizations and test these with the upgraded clone Access System. The following overview outlines the tasks that you should perform.

Caution: You must upgrade the Access System before upgrading integration components or an independently installed SDK

Task overview: Upgrading SDKs, Integration Connectors, and Access System Customizations

1. Chapter 11

   • Upgrading Third-Party Integration Connectors

   • Upgrading Independently Installed Software Developer Kits

2. Chapter 13

   • Upgrading Auditing and Reporting for the Access Server

   • Confirming Access System Failover and Load Balancing

   • Upgrading Forms-based Authentication

   • 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

   • Validating Access System Customization Upgrades: See also "Validating the Entire Upgraded Original Environment", next.

3. This chapter: Validating the Entire Upgraded Original Environment.

17.8 Validating the Entire Upgraded Original Environment

Before you validate the entire upgraded original environment, be sure that you have integrated your upgraded customizations which were tested in the clone environment.

See Chapter 14 for details and suggestions to validate the entire upgraded original environment, including the Identity System and Access System. This is the same validation that you performed in "Validating Successful Operations in Your Environment".

If the upgrade is successful, you can restart automatic user data migration as explained "Starting On-the-fly User Data Migration".

17.9 Starting On-the-fly User Data Migration

You use the procedure here to start immediate (on-the-fly) user data migration after validating that your upgraded original environment is operating properly and that you will not be rolling back to the earlier release.

Note: If you roll back to an earlier release after performing activities here, any user data that has been migrated will not be reverted.

In the following procedure you locate the globalparams.xml.upgrade file in the upgraded and validated environment (clone or original) and change the value of the MigrateUserDataTo1014 parameter from false to true.

To start on-the-fly user data migration after a zero downtime upgrade

1. Locate the globalparams.xml file in the destination path of the upgraded and validated environment. For example:

   np611\ois_01\identity\oblix\apps\common\bin\globalparams.xml

2. Change the value of the MigrateUserDataTo1014 parameter from false to true so that user data migration can start. For example:

   <NameValPair ParamName="MigrateUserDataTo1014" Value="True" />
   

3. Restart the Identity Server Service.

4. If you are certain that the original upgraded system is operating properly, proceed to "Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment".

17.10 Reconfiguring Domain Name Systems to Use the Upgraded Original Deployment

When you are completely satisfied that the upgraded original system is fully operational, you can reconfigure the DNS to use the original environment instead of the cloned environment.

Reconfiguring DNS to redirect network traffic is outside the scope of this manual.

When this task is finished, you can proceed to "Deleting the Temporary Directory Server Profile".

17.11 Deleting the Temporary Directory Server Profile

After upgrading the first original WebPass, an administrator created a temporary directory profile to grant the Access Server write access to policy data stored in the directory server. This temporary directory profile was required when the Access Server gathered configuration information stored in the WebGatestatic.lst file and updated the directory server during WebGate upgrades.

After upgrading all earlier WebGates and confirming proper operation of the upgraded WebGates, you can delete the temporary directory server profile.

Note: Do not perform this task until all earlier WebGates in your environment have been upgraded and verified to be working.

For details, see "Deleting the Temporary Directory Server Profile". When this task is finished, proceed to "Reverting Backward Compatibility".

17.12 Reverting Backward Compatibility

You might recall that backward compatibility with earlier custom plug-ins (and WebGates/AccessGates) was enabled during Identity and Access Server upgrades.

After upgrading all older plug-ins, WebGates and AccessGates, and confirming that the entire system upgrade has been successful, Oracle recommends that you revert backward compatibility.

The steps that you must perform to manually revert backward compatibility are similar to those used to manually enable backward compatibility. For more information, see the following topics in Chapter 14:

• Reverting Identity Server Backward Compatibility

• Reverting Access Server Backward Compatibility

When this task is finished, proceed to "Removing the Cloned System After Upgrading Originals".

17.13 Removing the Cloned System After Upgrading Originals

After upgrading and validating the original environment, and after reconfiguring the DNS to use the upgraded original system, you can remove the cloned system if you like.

Task overview: Removing the cloned environment

1. Confirm that your original setup is operating properly and serving customers.

2. Shut down clone services and Web servers.

3. Remove all clone file system directories.

4. In the original System Console, remove entries for the clones.