| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
This chapter describes how to upgrade the schema, the data, and how to create and upgrade a clone system when you are 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 provides the following topics:
Preparing the Original Installation for a Zero Downtime Upgrade
About Destination Creation and Obtaining Tools for a Zero Downtime Upgrade
Copying Configuration and Policy Data to a New Branch in the LDAP Directory Server
Upgrading SDKs, Integration Connectors, and Access System Customizations
Note:
If you are using the in-place upgrade method, skip this chapter.Oracle recommends that before you start the zero downtime upgrade you become familiar with the following information:
General information about deployments; upgrade planning, concepts and methods; and upgrade processing as described in Part I of this book.
Details about in-place upgrades, as described in Part II and Part III, include some preparation tasks that are relevant regardless of the upgrade method that you choose.
Details about performing manual customization upgrade tasks, as described in Part IV of this book. These tasks must be performed manually regardless of the upgrade method you are using.
General validation tasks are introduced in Part V. Tasks that you perform with the zero downtime upgrade method are described in "Validating Successful Operations in Your Environment".
All information about zero downtime upgrades, as described in this chapter and in Chapter 15 and Chapter 17.
New product terms are used in this chapter when referring to the Oracle Access Manager 10.1.4 components and System Console. Earlier product terms (COREid Server and Access Manager) are used when referring to original instances before they are upgraded and to clones of original component instances. The name COREid System Console is used when referring to activities that you perform using the earlier (original) System Console. For details about name changes with Oracle Access Manager, see "Product and Component Name Changes".
This section describes the unique planning and preparation tasks that are related to the clone system that you will create for the zero downtime upgrade method. 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 start, you must add new component profiles for the clones that you will create. To do this, you will use the existing (original) COREid System Console. In addition, you must add new LDAP directory server profiles for the copy of the original oblix tree that you will create in a new branch of the LDAP directory server.
When creating new profiles, you will use the original COREid System Console. If you have a joint Identity and Access System, you will also use the original Access System Console. For example:
Identity System Only: You must perform tasks 1 through 6 in the following task overview.
Joint Identity and Access System: You must perform all tasks in the following task overview.
Note:
Task overviews include a description of the task and a link to the topic where you will find the information needed to perform the task. In some task overviews, like the one here, the description is the actual topic heading and link.Task overview: Preparing your original installation for a zero downtime upgrade includes
Bringing Host Computers to Oracle Access Manager 10.1.4 Support Levels
Optional: Adding New Hardware or Earlier Instances to Your Deployment
Adding Profiles for Planned COREid Server Clones in the System Console
Adding Profiles for Planned WebPass Clones in the System Console
Associating WebPass Clone Profiles with COREid Server Clone Profiles
Adding New Directory Server Profiles for Cloned COREid Servers
Joint Identity and Access System: After performing tasks 1-7, perform the following tasks:
Adding a Profile for Access Server Clones
Note:
The only profiles in the System Console for Access Managers are related to the directory server profile used by Access Manager.Creating New Directory Server Profiles for Access System Clones
Associating Original WebGates with Access Server Clones: You perform this task because you will defer WebGate upgrades and will not have WebGate clones.
Before starting the upgrade, you must ensure that all computers that are hosting earlier components and the LDAP directory server are supported by Oracle Access Manager 10g (10.1.4.2.0). If you want to add new computers to the deployment or upgrade the Operating System or Web server, Oracle recommends that you set up these systems before you start the upgrade.
To locate the latest certification details
Go to Oracle Technology Network:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Locate and click the link for Oracle Access Manager Certification.
System Requirements and Supported Platforms for Oracle Access Manager 10gR3 (xls)
Describing how to bring an older system up to currently supported levels is outside the scope of this manual. For information about upgrading the host computer, operating system, and Web server, see your vendor documentation.
This topic is presented as an overview of tasks that you will be instructed to perform.
Configuration or Policy DNs with Spaces: A problem can occur when you copy configuration and policy data to a new branch when the old configuration DN or policy DN contains a space. To avoid a potential problem, you must apply the latest 10g (10.1.4.2.0) bundle patch available on My Oracle Support (formerly Metalink) before creating the new branch using 10g (10.1.4.2.0) tools. For details, see "Creating and Populating a New oblix Branch".
Oracle recommends that you review the topics in Chapter 5 that are listed next and perform tasks as needed.
Task overview: Preparing directory server instances before a zero downtime upgrade includes
Configuring Unique Namespaces for Directory Connection Information
Unique Namespaces for Directory Connections: Each directory server profile contains connection information that includes the profile name, a domain or namespace to which it applies, a directory type, and a set of operational requirements for Read, Write, Search, and so on. Before you add a new directory server profile for use by clones, Oracle recommends that you ensure that the namespace is unique on the directory server.
Configuring the Challenge/Response Phrase at the Object Class Level
Configuring the Challenge/Response Phrase at the Object Class Level: If Challenge and Response attributes are configured at the Employees tab level (rather than at the object class level), then the configuration data upgrade might not complete correctly. Oracle recommends that before starting other activities in this task, that you ensure that the Challenge and Response attributes are configured at the object class level.
Preparing Your Directory Instances for the Schema and Data Upgrade
Preparing Directory Instances: This includes changing the directory server search size limit parameter, and performing any other tasks that are relevant for you specific directory server type.
Reviewing Strategies for Upgrading in a Replicated Environment and applying these when needed.
Replicated Environment: When you have a replicated environment, you can disable the replication agreement before you work on the master and then enable the agreement when you are ready to push changes out to the replicas. For example, disable it before upgrading the schema and enable it after ugrading the data.
This task is optional. There are a number of reasons that you might consider adding new hardware or earlier instances to your existing deployment before starting the upgrade. For instance:
When you want to expand your deployment to add more host computers or earlier component instances
When you have original instances operating with an IIS Web server on a Windows platform, you must place the clone on a different computer host.
In this case, you also need to install the earlier component instance (as a clone) on the new host and then copy any customizations and configuration changes from the original file system to the clone file system. If the instance uses either Simple or Cert mode to communicate with existing components, you must copy the \config subdirectory from the original instance to the newly installed instance to ensure that all certificates are in order.
Oracle recommends that you perform these tasks before you begin other upgrade activities. If you are adding components, Oracle recommends that you perform a complete installation for each earlier component that you want to add. You can add hardware and install and setup additional earlier component instances using the following procedure as a guide.
To add hardware and additional component instances before the upgrade
Review hardware considerations in the following topics before you add any new hardware to host additional earlier components or to host cloned components:
Set up the new system as needed to host components, as described in the preparation chapter of your earlier Oracle COREid or Oblix NetPoint Installation Guide.
Install additional earlier components using instructions in your earlier Oblix NetPoint or Oracle COREid Installation Guide, and the following considerations:
All Components: Perform prerequisite tasks for the specific components that you will install, as described in the preparation chapter of your earlier Oracle COREid or Oblix NetPoint Installation Guide.
All Components: Answer questions and perform activities based on appropriate specifications for your earlier installation.
Identity Server: Answer No when asked if this is the first Identity Server for this LDAP directory server.
Confirm that the component installations were successful and that all earlier components are operating properly.
Add profiles in the original System Console for the new instance, and then add profiles for all planned clones.
Before you can clone an original COREid Server instance you must add an entry for the clone in the original COREid System Console. Only Master Administrators and Master Identity (or Master Access) Administrators can access the COREid System Console.
Clone details should be the same as the original instance with the following exceptions:
A different instance name for the clone is recommended. If you use the same instance name, Oracle recommends that you move the clone to a different host.
A different port number is needed for the clone instance to communicate with other clone instances.
The name of the host computer might differ.
To add entries for COREid Servers clones, you need either NetPoint Administrator or Master Identity Administrator login credentials and privileges.
The following procedure uses a release 6.1.1 installation. Your release and details will vary. For more information, see your Oracle COREid Administration Guide.
To add a profile for a COREid Server clone in the System Console
In your browser, enter the path to the original COREid System Console. For example:
https://hostname:port/identity/oblix
In this sample URL, hostname is the name of the computer on which the WebPass is installed and port is the Web server port for the WebPass. You can log in using the HTTP or HTTPS protocol.
Click COREid System Console, and log in as a user who is authorized as a Master Administrator or Master Identity Administrator.
In the System Console, click System Admin and then click System Configuration.
Select Configure COREid Server in the left navigation pane.
When the List all COREid Servers page appears, double click the name of an existing COREid Server to display its specifications and then print these to use as a reference.
Note:
You can find Directory Server Details, including the transport security mode used between this instance and the LDAP directory server, on the Configure LDAP directory server page. For example: click Configure Directory Options, and then look for the Directory Server Security Mode beneath Directory Server Details on the Configure Directory Server page. For additional information, click the name of the LDAP Directory Server Profile.Click System Admin, click System Configuration, select Configure COREid Server, and then click the Add button.
On the Add a New COREid Server page fill in details for this clone as follows:
Name: The unique name of the clone instance, which can include the port number for this clone. For example: clone_ois_7022.
Hostname: The name of the computer on which the cloned COREid Server will be running, which can be a different host from the original.
Port: A new port number for the cloned COREid Server. For example: 7022.
All remaining information should be the same for the clone as it is for the original COREid Server instance.
Figure 16-1 provides a sample page with values filled in.
Figure 16-1 Sample Release 6.1.1 Add a new COREid Server Page with Clone Details
Click Save to finish and keep the new information (or Cancel to exit without saving).
Repeat the steps in this procedure to define a new instance for each cloned COREid Server that will be added and upgraded.
Proceed as follows:
Successful: Continue with "Adding Profiles for Planned WebPass Clones in the System Console".
Not Successful: If there is a problem with an entry in the System Console, see "Recovering From Issues With Information Entered in the System Console".
Before you clone an existing WebPass instance you must add an entry in the original COREid System Console that mirrors the specifications for the existing WebPass. Only Master Administrators and Master Identity (or Master Access) Administrators can access the COREid System Console.
The Windows registry is not updated when you clone components. This can cause issues because the IIS Web server requires the entries for Web components in the registry. If the original Web component uses an IIS Web server, you should store the clone on a different Windows host with a fresh IIS Web server installation. In this case, the host name of the computer will differ for the clone.
Differences between the details for the original instance and details for the clone instance include the clone instance name and the Web server port number for the clone.
A different instance name for the clone is recommended. If you use the same instance name, Oracle recommends that you move the clone to a different host.
A different port number is needed for the clone instance to communicate with other clone instances.
The name of the host computer might differ.
To add entries for WebPass clones, you need either NetPoint Administrator or Master Identity Administrator login credentials and privileges. The following procedure provides the steps you must perform and is based upon a release 6.1.1 installation. For more information, see your Oracle COREid Administration Guide.
To add WebPass Profiles for clones in the System Console
From the COREid System Console click the System Admin tab, then click the System Configuration tab, and then click WebPass in the left column.
The List all WebPasses page appears.
Click the name of a WebPass instance to display its specifications, and then print these to use as a reference.
From the List all WebPasses page, click Add.
The Add a new WebPass page appears.
On the Add a new WebPass page, enter information for the clone as follows:
Name: The name of the WebPass instance clone, which can include the port number for this clone. For example: clone_webpass_84.
Note:
You cannot change the name you save with this instance. To change the name, delete this instance and reconfigure it with a different name.Hostname: The name of the computer on which the cloned WebPass instance will run; it might differ from the host of the original instance.
Port: A new port number for the cloned WebPass and new Web server. For example: 84.
All remaining information should be the same for the clone as it is for the original WebPass instance.
Figure 16-2 Sample Release 6.1.1 Add a new WebPass Page with Clone Details
Click Save to finish defining details for the cloned WebPass (or Cancel to exit without saving).
Repeat the steps in this procedure to define a clone instance for each WebPass in your original installation.
Proceed as follows:
Successful: Continue with "Associating WebPass Clone Profiles with COREid Server Clone Profiles".
Not Successful: If there is a problem with an entry in the System Console, see "Recovering From Issues With Information Entered in the System Console".
You must now associate COREid Server clones with WebPass clones using the System Console. The associations for clones must mirror original COREid Server and WebPass associations. As a result, you must perform two procedures.
The following task overview provides the steps you must perform and is based upon a release 6.1.1 installation. For more information, see your Oracle COREid Administration Guide.
Task overview: Associating COREid Server clones with WebPass clones includes
The following procedure explains how to view details for existing COREid Servers that are associated with a specific WebPass instance. This information will come into play in two ways:
Cloned Environment: You can ensure that your cloned environment includes the same associations that you find in the original installation.
Original Environment: You will upgrade original COREid Servers that are associated with a WebPass, and then you will upgrade the associated WebPass before upgrading other COREid Server instances.
To view existing COREid Server and WebPass associations
From the COREid System Console, click the System Admin tab, the System Configuration tab, and then click Configure WebPass in the left navigation pane.
The List all WebPasses page appears. From this page you can add, modify, or delete a WebPass.
In the List all WebPasses page, click the name of an original WebPass (not a clone).
The Details for WebPass page appears.
Click the List Identity Servers button.
A page appears that lists the primary and secondary servers configured for the existing WebPass.
Print the page to use as a reference and, if needed, click the name for a COREid Server to view details for it.
The Details for Identity Server page appears.
You perform activities in the following procedure to associate COREid Server clones with appropriate WebPass clones. You will base your association decisions on information that you collected in the previous procedure, "Viewing Details for Existing COREid Servers Associated with a WebPass".
To associate a COREid Server clone with a WebPass clone
From the COREid System Console, click the System Admin tab, the System Configuration tab, and then click Configure WebPass in the left navigation pane.
In the List all WebPasses page, click the name of a WebPass clone.
In the Details for WebPass page, click List COREid Servers to display a page listing the Primary and Secondary servers associated with the WebPass (which might be empty).
Click Add.
In the Select Server drop-down list, select a COREid Server clone that is to be associated with the WebPass clone.
Based on information for the original association, indicate whether this clone COREid Server is a Primary or Secondary server and ensure that this and other information for this association mirror the original association.
This information is required for COREid-related load balancing and fail over.
Click Add to associate this COREid Server clone with the WebPass clone (or click Cancel to terminate this operation and start over).
Repeat the steps in this procedure to associate all COREid Server clones with WebPass clones to be used during the zero downtime upgrade.
You must perform this task to add new directory server profiles for planned clones only when the original directory server profiles are separate for each COREid Server (Access Manager, and Access Server). If original directory server profiles are in use by all existing COREid Servers and Access Servers, you can skip this task.
Only Master Administrators and Master Identity Administrators can access the COREid System Console. You must add as many directory profiles for clone instances as you have existing directory profiles for original instances. The profile will serve only the clone instances and will be named differently than the original profile.
The new branch is created in the same LDAP directory server where the original oblix configuration and policy branches are present. There is no change in the LDAP directory server computer name or port number for the new branch.
If you have Database Instance Profiles configured in your original installation, any new LDAP directory server profile that you create for Identity Servers and Access Servers will use the same DB instances. However, the Database Instance Profiles will use the namespace (also known as the searchbase for user data) of the new branch.
If you have multiple searchbases (known as a disjoint searchbase), the new profile will use the same disjoint searchbase as the original profile used. Disjoint searchbases must be set up manually.
The following procedure uses a release 6.1.1 System Console. Your environment might vary and your details will be different. For information, see your earlier NetPoint or Oracle COREid Administration Guide.
To enter a new LDAP directory server profile for Identity System clones
Ensure that the directory server is ready, as described in "Preparing Directory Server Instances and Data".
From the COREid System Console click the System Admin tab, then click the System Configuration tab, then click Configure Directory Options in the left column.
Click Configure Directory Options in the left column.
On the Configure Server profiles page, click the name of an existing directory profile to display its specifications, and then print these to use as a reference.
On the Configure Directory Server profiles page, click the Add button under the label Configure LDAP Directory Server Profiles to display the Create Directory Server Profile page.
On the Create Directory Server Profile page add a name for this profile, the original searchbase, the clone servers that will use this profile, and use the original profile as a guide to fill in details about the LDAP directory server.
Name: The name of this profile, which will be used by clones (for example, it will be used by a cloned COREid Server instance).
This name is for informational purposes only. The Identity System uses the naming convention default <Identity Server id> for all default LDAP directory server profiles that are automatically created during COREid System installation. However, this profile will be used only by cloned components.
Name Space: The original searchbase specified for the original LDAP directory server profile, which is used by both the new branch and the original branch.
Note:
Use caution that this namespace does not overlap with other LDAP directory server profile namespaces. Overlapping name spaces result in duplicate entries. Exceptions to overlapping name spaces include a LDAP directory server profile for a Microsoft Active Directory sub-domain, and the LDAP directory server profile containing the
oblix configuration base (also known as the configuration DN).In the Used by area of the page, select the clone servers (not the original servers) that will use this profile.
All remaining details should be the same for this clone profile as for the original profile.
Click the option beside Enable Profile.
Your profile for the clone might look something like Figure 16-3.
Figure 16-3 Sample Release 6.1.1 Create Directory Server Profile Page for the Clone
Select Save, Cancel, or Reset as needed.
Click OK to confirm your addition.
Note:
You will not restart Identity Servers or Access Servers to enable the new profile until the clones are ready to use.Proceed as follows:
Successful, Identity System Only: Repeat this entire procedure as needed to create a new directory server profile to serve clone instances for each existing directory server profile. Then see "About Destination Creation and Obtaining Tools for a Zero Downtime Upgrade".
Successful, Joint Identity and Access System: Proceed with "Adding a Profile for Access Server Clones".
Not Successful: Proceed to "Recovering From Issues With Information Entered in the System Console".
For information, see your earlier NetPoint or Oracle COREid Administration Guide.
There are no entries in the System Console for Access Managers and none are needed for their clones. The only System Console entries relating to the Access Manager pertain to directory profiles that are used by the Access Manager. Continue as follows:
Identity System Only: Proceed to "Cloning Earlier Components for a Zero Downtime Upgrade".
Joint Identity and Access System: Proceed to the next topic, "Adding a Profile for Access Server Clones".
You perform the following task only if your original installation is a joint Identity and Access System deployment. Otherwise, skip to "Cloning Earlier Components for a Zero Downtime Upgrade".
Before creating Access Server clones, you must add a new instance for each clone in the Access System Console. Most clone specifications should mirror those of the original Access Server that the clone will temporarily replace.
A different instance name for the clone is recommended. If you use the same instance name, Oracle recommends that you move the clone to a different host.
A different port number is needed for the clone instance to communicate with other clone instances.
The name of the host computer might differ.
To add entries for Access Server clones, you need either NetPoint Administrator or Master Access Administrator login credentials and privileges.
The following procedure uses a release 6.1.1 installation. Your release and details will vary. For more information, see earlier NetPoint or Oracle COREid Administration Guide.
To add a profile for each planned Access Server clone
Go to the original Access System Console from your browser. For example:
http://hostname:port/access/oblix
In the sample URL, hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.
Click the Access System Console link.
From the Access System Console, Click the Access System Configuration tab, then click Access Server Configuration when the side navigation bar appears.
Click the name of an existing Access Server instance to display its specifications, and then print these to use as a reference.
Click Access Server Configuration in the side navigation bar, then click Add.
On the Add a New Access Server page, fill in details for this clone as follows:
Name: The name of the clone Access Server instance, which can include a port number for the clone if desired. For example: clone_aaa_7023
Hostname: The name of the computer on which the cloned Access Server will run, which might differ from the existing Access Server host.
Port: A new port number for the cloned Access Server. For example: 7023
All remaining information should be the same for the clone as it is for the original Access Server instance.
Figure 16-4 shows a completed page for this example. Your details will vary.
Figure 16-4 Sample Release 6.1.1 Add a new Access Server Page for a Clone
Click Save to finish defining details for the cloned Access Server (or Cancel to exit without saving).
Repeat the steps in this procedure to define a new instance for each cloned Access Server to be upgraded using the zero downtime method.
Proceed as follows:
Successful: Continue with "Creating New Directory Server Profiles for Access System Clones".
Not Successful: If there is a problem with an entry in the System Console, see "Recovering From Issues With Information Entered in the System Console".
In joint Identity and Access System deployments, you might need to create new directory profile instances for planned clones for Access Server instances. You perform this task only when the original directory profiles are separate for each COREid Server (Access Manager, and Access Server). If original directory profiles are in use by all existing COREid Servers and Access Servers, you can skip this task.
Only Master Administrators and Master Access Administrators can access the Access System Console. You must add as many directory server profiles for clone instances as you have existing directory server profiles for original instances. The profile will server only the clone instances and will be named differently than the original profile.
A default directory profile is created for the Access Server during Access Server installation. LDAP directory server details and directory server profiles that are available in the Access System Console include those for configuration data and policy data.
If you install more than one Access Server instance, each server uses the same default LDAP directory server profile. If you modify a shared LDAP directory server profile for a particular Access Server instance, all of the other Access Server instances are affected. If you do not also change the profiles for these servers, you will receive a warning whenever you:
View the server configuration
Restart the server
Reconfigure the server
Each directory server profile contains connection information that includes the profile name, a domain or namespace to which it applies, a directory type, and a set of operational requirements for Read, Write, Search, and so on. Before you add a new directory server profile for use by clones, Oracle recommends that you ensure that the namespace is unique on the directory server.
The following procedure describes how to add directory server profiles for Access System clones using the original Access System Console. In this example, a release 6.1.1 Access System is presented. Your Access System release and details might vary.
To add a directory profile for cloned Access System components
Ensure that the directory server is ready, as described in "Preparing Directory Server Instances and Data".
From the original Access System Console, click System Configuration, then click View Server Settings.
The View Server Settings page appears.
Beneath the Configure LDAP Directory Server Profiles label, click the name of a directory profile for the Access Manager to display the original specifications, and then print these to use as a reference.
Click View Server Settings in the left column, and then click Add under the Configure LDAP Directory Server Profiles label to display the Create Directory Server Profile page.
On the Create Directory Server Profile page, fill in the name and namespace for this clone profile, select the clone servers that will use this profile, and then use the original profile as a guide to fill in LDAP directory server details.
Name: The name for this profile to be used by the cloned Access System components.
Name space: The original searchbase for user data.
In the Used by area of the page, select the clone servers (not the original servers) that will use this profile.
All remaining details should be the same for this profile as for the original profile.
Select Enable Profile.
Select Save, Cancel, or Reset as needed.
Click OK to confirm your addition.
Note:
You will not restart the Access Manager Web servers or Access Server service to enable the new profile until the clones are ready to use.Repeat all steps in this procedure to create a new profile instance for each original profile used by the Access Manager.
Repeat the steps in this procedure to create as many new directory server profiles for Access Server clones as you have existing directory server profiles used by original Access Servers.
Proceed as follows:
Successful: Continue with "Associating Original WebGates with Access Server Clones".
Note:
There are no entries in the System Console for Access Managers and none needed for their clones. The only System Console entries relating to the Access Manager pertain to directory profiles that are used by the Access Manager.Not Successful: If there is a problem with an entry in the System Console, see "Recovering From Issues With Information Entered in the System Console".
Do not create a clone of any WebGate instance. Instead, Oracle recommends that you configure original WebGates to operate with cloned Access Server.
Each original WebGate must be reconfigured to operate with a cloned Access Server as a secondary server. This is accomplished manually by adding the clone Access Server as a secondary Access Server for each original WebGate.
In general, earlier Access Servers are not compatible with later WebGates. For example, if you have a release 6.1.1 Access Server it will not be compatible with a release 6.5 or later WebGate. However, when you upgrade an earlier Access Server, backward compatibility with earlier custom plug-ins and earlier WebGates is enabled automatically. As a result, you can delay original WebGate upgrades. For more information about backward compatibility, see Chapter 4.
You will not create a clone of any original WebGate. Instead, you will configure original WebGates to work with cloned Access Servers. Should you decide to uncouple the original and clone environments at some point, see "About Isolating the Original and Cloned Environments".
Note:
Having only one WebGate will result in downtime when upgrading that WebGate (or when rolling back). Oracle recommends that you have more than one WebGate to avoid downtime.The procedure here uses a release 6.1.1 System Console. Your system and your details will vary. For information, see your earlier NetPoint or Oracle COREid Administration Guide. For an alternative procedure, see "Alternative Procedure to Associate Original WebGates and Clone Access Servers".
To associate an Access Server clone with an original WebGate
From the Access System Console, click Access System Configuration and then click AccessGate Configuration.
Click an original WebGate name on the List all NetPoint AccessGates page.
Click Add to configure an Access Server clone to communicate with this original WebGate.
Select an Access Server clone from the Select Server list.
From the Select priority options, choose Secondary.
In the Number of connections field, type the maximum number of connections this WebGate clone can establish to this Access Server clone.
The default is 1. Your page might look like the sample in Figure 16-5.
Figure 16-5 Sample Release 6.1.1 Page When Associating a WebGate Original with an Access Server Clone
Click Add to complete the configuration of this server, or click Back to return to the previous screen.
Click the link to display a summary and print this page for use later.
Repeat Step 3 through Step 7 to associate another original WebGate with an Access Server clone, if needed.
Proceed as follows:
Successful: Continue with "Cloning Earlier Components for a Zero Downtime Upgrade".
Not Successful: If there is a problem with an entry in the System Console, see "Recovering From Issues With Information Entered in the System Console".
If you have a significant number of WebGates, you might find it quicker to use this alternative method to associate original WebGates with Access Server clones. This alternative method involves modifying the following ldif template and then importing it.
Note:
This template will configure only one WebGate at a time. To configure multiple WebGates you must create and concatenate individual WebGate templates.Example 16-1 WebGate Reconfiguration LDIF Template
Entry 1 dn: obname=%UniqueIdentifier%,obapp=PSC,o=Oblix,%OblixBase%
obname: %UniqueIdentifier% obMaxAAAServerConnections: %NoOfConnections% obServerID: obname=%AAASeverId%,obapp=PSC,o=Oblix,%OblixBase% objectClass: top objectClass: oblixAAAServerIDNode obver: %OAMVer% Entry 2 dn: obname=%WebGateId%,obapp=PSC,o=Oblix,%OblixBase% changetype: modify replace: %ServerType% %ServerType%: %ExistingAAAS%:%UniqueIdentifier%
The following procedure guides you as you edit the WebGate template to associate Access Servers and WebGates.
Note:
When editing Entry 2, you can use the%AAASeverId% and %WebGateId% together as a unique identifier.If the WebGate has no existing Access Servers configured to work with it, then you must replace "replace: %ServerType%: " in Entry 2 with "add: %ServerType%".To edit the template for your environment
Edit Entry 1 as follows:
Replace the %UniqueIdentifier% with a unique timestamp of your choosing, for example:
20070101T44444444444
Replace %OblixBase% with the original Oblix Base for example:
o=company,c=us
Replace %AAASeverId% with the clone Access Server's identifier, for example:
AAA_new
Replace %NoOfConnections% with the maximum number of connections to named Access Server, for example:
1
Replace %OAMVer% with your current WebGate release, for example:
6.1.0
For more information about release numbering see details about the -f option in Table 15-2, "MigrateOAM Argument and Specifications Summary".
Edit Entry 2 as follows:
Replace %OblixBase% with the original Oblix Base for example, for example:
o=company,c=us
Replace %WebGateId% with the WebGate name that was entered into the System Console when the WebGate was set up, for example:
WebGate_one
Replace %ServerType% with "obAAAPrimaryServerID" if this is a primary server connection (or with "obAAASecondaryServerID" if this is a secondary server connection to the WebGate.
Replace the %ExistingAAAS% with the value of the %ServerType% attribute, for example:
obAAAPrimaryServerID
For more information about specifying release numbers, see details about the -f option in Table 15-2, "MigrateOAM Argument and Specifications Summary".
Replace %UniqueIdentifier% with the Timestamp that you specified in entry 1, for example:
20070101T44444444444
Compare your edited file to the one shown in Example 16-2.
Import this LDIF file to the LDAP directory server.
Verify that the association appears in the Access System Console.
Repeat this entire sequence for the next WebGate that you want to reconfigure.
dn: obname=20070101T44444444445,obapp=PSC,o=Oblix,o=company,c=us obname: 20070101T44444444445 obMaxAAAServerConnections: 1 obServerID: obname=Reconf_AAA2,obapp=PSC,o=Oblix,o=company,c=us objectClass: top objectClass: oblixAAAServerIDNode obver: 6.1.0 Entry 2 dn: obname=Reconf_WG,obapp=PSC,o=Oblix,o=company,c=us changetype: modify replace: obAAAPrimaryServerID obAAAPrimaryServerID: 20070228T21065545822:20070101T44444444445
If you discover a problem with an entry for a clone instance, you can click the Cancel button during profile entry and start the profile anew.
If you see a problem after entering information, you can either modify the profile in the System Console or you can delete the profile altogether and start a new one for the clone.
To recover from issues when entering clone details
Using the System Console, perform the following activities as appropriate and as described in your earlier NetPoint or Oracle COREid Administration Guide.
Re-select or re-enter the information, or click the Cancel button.
Select the profile and click the Modify button to modify a saved profile.
Select the profile and click the Delete button to remove the profile.
Re-enter the information for the clone in the System Console, if needed.
Rolling back returns you to the starting point, where you have only the original setup in its original configuration. All clone entries will be removed, and any other changes that you have made for the cloned environment will also be removed.
To roll back at this stage, you can remove the clones and the Web Server instance that was created for clones. You also need to remove entries added in your original System Console for clone components.
To roll back to the starting point after entering clone details
In the original System Console, remove entries added for all clones.
Undo any other changes that you have made to support the cloned environment.
Continue to use your original installation, or begin the upgrade anew.
This section describes how to clone original component instances when performing a zero downtime upgrade. You must create a clone of each original component instance in the deployment that you are upgrading. Your original instances remain intact and continue to provide services to users while you perform operations on the clones.
You will need a new Web server instance for cloned Web components. If you have additional applications protected by Oracle Access Manager using the original Web server instance, you should also clone these applications. These cloned applications will use the Web server instance that you create for the cloned Web components. For more information, see "Web Server Requirements for Zero Downtime Upgrades".
For more information, see the following topics:
Oracle recommends that you keep cloned instances on the same computer that is hosting the original component. However, this is not a requirement. If you want to add a new computer and install another earlier instance, Oracle recommends that you do so before you create any clones. For more information, see "Adding New Hardware or Earlier Instances to Your Deployment".
After adding entries to the System Console for each planned Oracle Access Manager clone, you are ready to clone the original components. You will start by creating a clone file system directory structure. You will then copy each original-component's file system directory into the clone file system. Each clone instance will provide source information during the instance upgrade.
Note:
Cloning components is a manual task that you perform as described in this topic. Do not use np_sync to clone directories for a zero downtime upgrade. Do not clone WebGate instances.Figure 16-6 shows a sample installation on the left (the original). In this example, the original top-level file system path is named np611. It is expanded to show component directories and subdirectories in a tree structure. This example includes two instances of each component (labeled with _01 and _02). Your environment will be different. In the center of Figure 16-6, is the clone folders that were created as containers. On the right, the clone structure is shown as it will look after populating it by copying original component subdirectories into the appropriate clone folder.
Figure 16-6 Original and Clone Directory Hierarchies in the File System
Guidelines for Creating a Clone
Oracle recommends that you follow these guidelines when creating a clone:
The clone can reside on the same disk partition or on a different partition on the computer hosting the original component instance. For more information, see "Hardware Requirements for Zero Downtime Upgrades".
The clone file system name must have at least one difference when compared with the original directory name in the file system. For example, name the clone directory differently at the top level: clone_np, for example.
The clone file system directory can use the same structure as the original instance, which is a good practice. However, maintaining the original structure in the clone file system is not required. During later zero downtime upgrade tasks, you will be instructed to extract 10g (10.1.4.0.1) libraries and files to the clone setup and then apply the Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Note:
You will not create a clone of earlier WebGates. As a result, the clone directory in the file system does not include WebGate directories.Including a release number in the clone directory path might cause confusion after upgrading the clones. You can eliminate release numbers in cloned path names.
If your original installation includes an independently installed Software Developer Kit (SDK) for custom AccessGates, you must also clone the SDK.
Note:
However, on Windows systems, you can choose to use only the 10g (10.1.4.3) .NET 2 SDK after upgrading and patching to 10g (10.1.4.3). In this case, you might not need to upgrade the earlier SDK. For more information, see "Platform and SDK .NET Support".The procedure in this section provides step-by-step instructions to help you clone your original components (except WebGates).
Table 16-1 outlines the sample path names that are used in this procedure. In this example, the original directory structure is set up to contain two instances of each component (labeled _01 and _02 in this example) to provide load balancing. The sample clone file system structure matches the original structure. Your environment will be different.
Table 16-1 Sample Original and Clone Path Names for Zero Downtime Upgrades
| Original File System Directory Structure | Clone File System Directory Structure | |
|---|---|---|
|
Note: This sample original file system includes two instances of each component stored independently. np611 aaa_01 aaa_02 ois_01 ois_02 webcomponent_01 webcomponent_02 webgate_01 webgate_02 SDK Note: If your original installation includes a separately installed Software Developer Kit (SDK), you must also clone the SDK. However, on Windows systems, you can choose to use the 10g (10.1.4.3) .NET 2 SDK after upgrading and patching to 10g (10.1.4.3). In this case, you might not need to upgrade the earlier SDK. For more information, see "Platform and SDK .NET Support". |
Create a clone file system that mirrors the original so that you can populate it. For example: clone_np aaa_01 aaa_02 ois_01 ois_02 webcomponent_01 webcomponent_02 webgate_01 webgate_02 asdk_01\ Note: Only the top-level clone file system directory must have a different name from the original. Clone subdirectories can be named after the originals. |
Back Up Copy: After populating the clone file system with a copy of each original instance on the host, the clone instance provides a back up copy of the original. In later tasks, you will rename each clone subdirectory to create a source for the clone upgrade. The source becomes a back up copy and remains intact while the destination that contains the 10.1.4.2.0 tools, libraries, and files, is upgraded based on information from the source. The original file system is untouched during clone upgrades.
The sample path names that are used for the zero downtime upgrade method illustrate an environment that includes multiple instances of each component. The sample that illustrates multiple instances was selected to help reinforce the actions that are needed for each and every instance. The sample path names are not intended to recommend a particular distribution of components in your installation.
Added Components: You can install another instance of an earlier release Oracle Access Manager component to use as a clone. For example, if you have original instances operating with an IIS Web server on a Windows platform you must place the clone on a different computer host. After you install the earlier instance on the new host you remove the installer and then copy any customizations and configuration changes from the original instance to the newly installed clone. If the instance uses either Simple or Cert mode to communicate with existing components, you must copy the \config subdirectory from the original instance to the newly installed instance to ensure that all certificates are in order.
In the following procedure, you will replace sample path names with appropriate names from your deployment. Your environment will be different and might not include multiple instances of one component on a single host, nor all components on a single host.
To clone earlier component instances for a zero downtime upgrade
Create a new top-level file system directory to act as a container for clones. For example:
Create a container for clones. For example:
Original top-level directory: np611
Create clone: clone_np
Create a clone COREid Server file system directory for each instance in your original file system. For example:
Create clone Web component file system directories, as needed, to provide a container for cloned subdirectories. For example:
Create clone Access Server directories, as needed, to provide a container for cloned subdirectories. For example:
Do not create a clone WebGate directory.
SDK: Create clone SDK directories if your original installation includes this. For example:
Populate the clone file system directory by copying original component instances into the clone structure. For example:
Copy each original COREid Server subdirectory into the clone structure. For example:
Copy each original WebPass directory into the clone structure. For example:
Copy each original Access Manager structure into the clone structure. For example:
Copy each original Access Server instance into the clone structure. For example:
Do not copy an original WebGate directory into a clone directory.
SDK: Copy the original SDK directory into the clone directory. For example:
Repeat Steps 1 and 2 on every host in your original deployment to create a clone each original component instance.
After cloning, proceed to "Creating A New Web Server Instance for Cloned Web Components".
A new Web server instance is required for cloned Web components. This new Web server instance will be used by upgraded clones while the original installation is upgraded. For more information, see "Hardware Requirements for Zero Downtime Upgrades".
If you have additional applications protected by Oracle Access Manager, be sure to clone these applications and configure them to use the Web server instance that is configured for clones.
When you have one Web server instance serving multiple Web components, the Web server must be shut down before you upgrade the first Web component (WebPass, for example) and must remain shut down until you upgrade the last serviced Web component. You will be instructed to shut down the Web server in future procedures. For all Web server requirements, see "Web Server Requirements for Zero Downtime Upgrades".
To create a new Web server instance for cloned Web components
Go to Oracle Technology Network and confirm that the new Web server is supported for Oracle Access Manager Release 10.1.4 Patch Set 1 (10.1.4.2.0):
Go to Oracle Technology Network:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Locate and click the link for Oracle Access Manager Certification.
System Requirements and Supported Platforms for Oracle Access Manager 10gR3 (xls)
Use your Web server vendor documentation as a guide as you install the new Web server instance. Installing the Web server is outside the scope of this manual.
Create clones of any additional applications that are protected by the original Oracle Access Manager installation and this Web server, and configure the application clones to use the Web server instance for Oracle Access Manager clones.
If you find a problem with a cloned instance, you can use Step 1 in the following procedure to recover and start anew. Otherwise, use all steps to roll back all changes and return to your original installation.
If you perform all steps, every trace of cloned components will be removed. In this case, you can either restart the zero downtime upgrade from the beginning, or use the in-place method described elsewhere in this manual, or continue using your original environment.
To recover or roll back after cloning a component instance
Shut down clone services and Web servers, and delete the cloned file system directory from the host computer.
Note:
To continue cloning, return to the procedure "To clone earlier component instances for a zero downtime upgrade".Remove the Web server instance for the cloned Web component.
Remove any cloned applications that operate with this Web server instance.
Repeat all steps for each clone on each computer host.
From the original System Console, delete entries for clones using instructions in your earlier NetPoint or Oracle COREid Administration Guide.
Confirm that your original setup is operating properly.
This task must be performed for each and every instance in the deployment that you are upgrading, whether it is a small sandbox-type deployment or a full production deployment.
The tools that support the zero downtime upgrade method are provided with Oracle Access Manager Release 10.1.4 Patch Set 1 (10.1.4.2.0). You obtain the zero downtime upgrade tools by extracting 10g (10.1.4.0.1) component libraries and files (also known as an instance) and then applying Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the instance. Additional information is provided in the following topics:
Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files
Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)
You can review the information in the previous topics. However, do not perform these tasks now. Instead, wait until you are referred to these tasks as you make a new branch in the directory server, or as you upgrade the schema, or as you upgrade clone instances, or as you upgrade original instance. To avoid repeating information, the following topics will direct you to this section.
Topic overview: Creating a destination and obtaining tools is needed as described in
This chapter
Before you can perform any zero downtime upgrade activities, you must create a destination file system path and extract the appropriate Oracle Access Manager 10g (10.1.4.0.1) libraries and files for the component that will be involved. After creating the destination, you can apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the instance.
You will perform this task before you make a new branch in the LDAP directory server or upgrade the schema, and before you can upgrade each clone or original instance.
Destination Path Names: You must create a source before you start extracting 10.1.4 libraries and files for clone and original instance upgrades. The destination path that you assign must exactly match the initial clone or original path (before you renamed it to create a source). During library and file extraction, a default file system directory path is provided:
Windows Platforms: \Program Files\NetPoint\
UNIX Platforms: /opt/netpoint/ (all lowercase)
You can change default path name to suit any requirements for your enterprise. If you change the default name to something else, Oracle recommends that you use consistent naming conventions for all platforms. For instance, the Windows Operating System allows spaces in a path name while UNIX-based systems do not. For consistency, you might use an underscore rather than a space in path names on all platforms.
The following path name designations help you identify individual components:
\identity is appended automatically to all Identity System path names, including Web component path names, regardless of any changes you might make. For example, a COREid Server might be installed as clone_np\identity.
\access is appended automatically to all Access System path names, including Web component path names, regardless of any changes you might make. For example, an Access Server might be installed as clone_np\access.
\webcomponent is part of the default path for WebPass and Policy Manager. However, \identity or \access are automatically appended. If you remove \webcomponent it is not automatically appended.
A WebPass might be installed as clone_np\webcomponent\identity.
A Policy Manager (formerly known as the Access Manager) might be installed as clone_np\webcomponent\access.
WebGate default path names vary depending on your platform and Web server type. Following are several examples that you might see if your original deployment is installed as np611.
Win32 ISAPI WebGate: \np611\webgate
Win32 OHS2 WebGate: \np611\WebComponent\access
Win32 NSAPI WebGate: \np611\WebGate\access
Linux Apache2 WebGate: /home/np611/webgate
Linux OHS2 WebGates: /home/np611/webgate
and so on.
Using the zero downtime method, WebGate upgrades are deferred until you upgrade the original Access System. You can install the latest WebGate even though you will not use it until the very end of the zero downtime upgrade tasks. For more information about source and destination creation, see "Preparation Tasks for the Zero Downtime Method".
The following information should be taken into account before you begin extracting and patching 10g (10.1.4.0.1) components:
Locations and Details: You cannot copy libraries and files from one location and reuse these in another location. Libraries and files are extracted with specific location and configuration details. Certain details are not transferable. For example, on a Windows platform, the registry entry points to the original location.
Note:
You cannot copy libraries and files from one location and reuse these in another location because certain location and configuration details are not transferable.To obtain the 10g (10.1.4.2.0) tools that are required to perform a zero downtime upgrade, you must extract 10g (10.1.4.0.1) component libraries and files for each installed instance and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0). After applying the patch, you will have the 10g (10.1.4.2.0) files and tools needed for the upgrade (whether it is for a clone instance or for an original instance). The 10g (10.1.4.2.0) file system directory becomes the destination that is used during the earlier instance upgrade. For example:
For Each Clone Instance Upgrade: You must first rename the existing clone file system to create a source for the upgrade (for example, from clone_np/ois_01/identity to clone_np/ois_01/identity_source). You then extract 10g (10.1.4.0.1) component libraries and files into the initial file system directory (for example, clone_np/ois_01/identity). Next, you apply the 10g (10.1.4.2.0) patch to the 10.1.4 destination. For example, if you are upgrading a COREid Server clone, the file system directories might look like the following:
Original Instance: np/ois_01/identity
Clone Instance: clone_np/ois_01/identity
Source Name: clone_np/ois_01/identity_source
10.1.4 Destination Name: clone_np/ois_01/identity
For Each Original Instance Upgrade: You first rename the existing original file system to create a source for the upgrade. You will extract 10g (10.1.4.0.1) component libraries into the original file system directory, and then apply the 10g (10.1.4.2.0) patch.
Original Instance: np/ois_01/identity
Source Name: np/ois_01/identity_source
10.1.4 Destination Name: np/ois_01/identity
For Creating and Populating the New oblix Branch: In this case, you use the clone directory as the source and assign a new name for the destination directory. You then extract 10g (10.1.4.0.1) component libraries into the new path and apply the 10g (10.1.4.2.0) patch. For example:
Original COREid Server: np/ois_01/identity
Clone COREid Server: clone_np/ois_01/identity
Destination Name: 1014/identity
Original Access Manager: np/webcomponent_01/access
Clone Access Manager: clone_np/webcomponent_01/access
Destination Name: 1014/webcomponent/access
For Schema Upgrades: You use the same destination as you did when creating and populating the new branch. There is no need to create a new destination nor obtain the tools for this procedure.
Languages: When your earlier installation includes languages other than English, the 10g (10.1.4.0.1) libraries and files that you extract should include the same Language Packs as the original instance. Only after upgrading and before applying the 10g (10.1.4.3) patch should you follow instructions in "Preparing Upgraded Environments for 10g (10.1.4.3) Language Packs".
Set Up and Validation Caveats: After extracting 10g (10.1.4.0.1) component libraries and files and applying Release 10.1.4 Patch Set 1 (10.1.4.2.0), you will not have a fully configured instance. However, you will have everything needed to perform zero downtime upgrade activities, including a destination directory for the instance to be upgraded.
Cleaning Up the Obsolete Schema: After extracting the Identity Server and Policy Manager component libraries and files, the kCleanupObsoleteSchema parameter in the obmigratedsparams.lst file is set to false. This will ensure that the obsolete schema is not cleaned up. As a result, the original system can coexist with the cloned system. If you have only the Identity System, you perform steps only for the Identity Server.
WebGates: These upgrades can be deferred until all other components are upgraded. You extract 10g (10.1.4.0.1) WebGate libraries and files and patch these only when upgrading original WebGate instances. If you decide to uncouple your clone and original deployments, you will need to add new WebGates to the upgraded clone system to replace original WebGates. For more information, see "About Isolating the Original and Cloned Environments".
The following task overview describes specific extraction requirements to support out-of-place zero downtime upgrades. You will not perform a full component installation. Instead, you will extract only the component libraries and files and then stop the installation process.
Note:
Do not extract any 10g (10.1.4.0.1) component libraries and files until you are instructed to do so during later zero downtime upgrade tasks. You will only extract component libraries and files; you will not perform a full installation.Task overview: Destination creation
Ensure that the host computer meets all Oracle Access Manager 10g (10.1.4.0.1) requirements, as described in:
When directed to do so in later procedures, create the clone, source, and destination paths. For example, when upgrading a clone:
Original Instance: np/ois_01/identity
Clone Instance: clone_np/ois_01/identity
Source Name: clone_np/ois_01/identity_source
10.1.4 Destination Name: clone_np/ois_01/identity
Note:
When creating and populating a new oblix branch, you do not need to create a source directory. Instead, create only a new destination for the 10.1.4 libraries and files. For details about creating a source and destination for original component upgrades, see "About Upgrading Original Identity System Instances".When directed to do so in later procedures, perform the following extraction tasks on the computer that is hosting the instance to be upgraded (whether a clone or an original instance).
Perform any prerequisite tasks as described in the discussion that directed you here.
Locate and launch the appropriate Oracle Access Manager 10g (10.1.4.0.1) component installer for the instance and platform. For more information, see the Oracle Access Manager Installation Guide.
Respond to questions about the license, and about languages. For details about languages, see the Oracle Access Manager Installation Guide.
When asked for the installation directory, specify the destination path for the instance (this typically must match the initial name of the clone or original instance before it was renamed to create the source). For example: /clone_np/ois_01/identity.
Write the destination path in your planning document if you have not already done so.
You are notified that the component libraries and files are being installed (extracted), which can take several seconds.
When all component libraries and files are extracted, click Cancel.
Note:
Do not continue the installation. You have all that is needed to apply the patch (Release 10.1.4 Patch Set 1 (10.1.4.2.0)).Proceed to "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".
After extracting 10g (10.1.4.0.1) component libraries and files to create a destination path for the upgrade (whether clone or original), you must apply Release 10.1.4 Patch Set 1 (10.1.4.2.0). You apply the patchset to the destination path that you created in the previous procedure. This will enable you to obtain the script and utilities that are required for an out-of-place zero downtime upgrade. The file system path will not change when you apply the patch.
As you patch component libraries and files, a backup folder is created that contains the files that should be restored if you remove the patch. The backup files are stored in the identity|access folder, at the same level as the \oblix directory. For example, when you patch the Identity Server, the back up directory is located in: a path like the following
Release 10.1.4 Patch Set 1 (10.1.4.2.0) Application and Removal Conditions
Before you can apply Oracle Access Manager Release 10.1.4 Patch Set 1 (10.1.4.2.0), you must ensure that the host computer meets 10g (10.1.4.2.0) support requirements. In addition, the following conditions apply:
Before you upgrade using the zero downtime method you will extract Oracle Access Manager 10g (10.1.4.0.1) component libraries and files, and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
When upgrading using the zero downtime method, you will use the 10g (10.1.4.2.0) MigrateOAM script to create a new directory branch and to upgrade the earlier component instance.
Configuration or Policy DNs Containing a Space: In this case only, before you create a new directory server branch using Oracle Access Manager tools, you must apply Bundle Patch 10.1.4.2.0-BP04 (or the latest 10g (10.1.4.2.0) bundle patch).
When the latest 10g (10.1.4.2.0) bundle patch is applied to the 10g (10.1.4.2.0) clone of the first installed Identity Server (and the 10g (10.1.4.2.0) clone of the first installed Access Manager), the Mkbranch tool can replace the old configuration or policy DN with the new one even if the old one includes a space.
The following procedure provides steps to obtain the patch set and steps to help you verify that the patch set was properly applied. Detailed patch set application instructions are located in the Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems.
To obtain and apply Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Locate Patch 5957301 on My Oracle Support (formerly MetaLink) to obtain Release 10.1.4 Patch Set 1 (10.1.4.2.0), as follows:
Go to the My Oracle Support site and log in as usual:
http://metalink.oracle.com
From the Quick Find list, choose Patch Number, in the empty field to the right, enter 5957301, and then click Go.
On the Patch 5957301 page, click the Download button beside each zip file name.
Readme: Click the View Readme button to display the Release Notes, which you can print to review the list of bugs fixed, enhancements, and more.
Use instructions in the Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems to apply the 10g (10.1.4.2.0) patch to your 10g (10.1.4.0.1) component libraries and files in the destination:
Identity Server
WebPass
Policy Manager
Access Server
WebGate
Confirm that the version file in the destination path is updated to 10g (10.1.4.2.0) (npversion_component.txt). For example:
IdentityServer_install_dir\identity\oblix\config\np1014_is.txt
WebPass_install_dir\webcomponent\identity\oblix\config\np1014_wp.txt
PolicyManager_install_dir\webcomponent\access\oblix\config\np1014_am.txt
AccessServer_install_dir\access\oblix\config\np1014_aaa.txt
WebGate_install_dir\webgate\identity\oblix\config\np1014_wg.txt
Verify that the history of the files in Install_Log was updated automatically, by looking for: Component_install_dir\identity or Component_install_dir\access.
Look for the back up files that were created during the patch operation. For example:
Making a New Branch: If you have configuration or policy DN with a space, you must apply Bundle Patch 10.1.4.2.0-BP04 before you create a new branch in the directory server. For details, see "Creating and Populating a New oblix Branch".
Back up the Web server configuration file using instructions from your vendor and details in "Backing Up the Existing Web Server Configuration File".
Windows: Back up the updated registry data for the patched component as described in "Backing Up Windows Registry Data".
After creating clones, you need to create a new branch in the LDAP directory server and then copy the configuration and policy data from the original oblix branch into the new branch. Copied information includes details such as workflow specifications and configuration data that govern the appearance and functionality of the Identity System and Access System.
After populating the new branch with a copy of the data, you will reconfigure cloned components to use the new branch. Your original installation will continue to use the original branch. Only during the final zero downtime upgrade tasks, will you upgrade and reconfigure original components to use the new branch.
For complete instructions, see the following topics:
You might also need the topic, "Rolling Back Changes Made for the New oblix Branch".
Oracle Access Manager supports storing user data, Oracle Access Manager configuration data, and policy data on a single directory server.Alternatively, you can store user data separately on one directory server type and Oracle Access Manager configuration and policy data on a different type of directory server. For example, you might store user data in Active Directory and Oracle Access Manager configuration and policy data on ADAM (or Oracle Internet Directory).
When storing user data on a separate directory server type from configuration and policy data, Oracle recommends that you observe the following guidelines:
Ensure that all user data is stored on the same directory server type.
Ensure that configuration and policy data are stored on the same type of directory server.
You must manually create the new branch node to contain the copy of the configuration and policy data. Generally this is created as a child node of original configuration base (also known as the configuration DN) and policy base (also known as the policy DN). When data is stored separately you can create parallel nodes.
Identity System Only: When you have only the Identity System, there is no policy data. In this case, you perform this procedure for only the clone of the first COREid Server that was installed and set up. In this case, the configuration data is copied.
Joint Identity and Access System: When you have a joint Identity and Access System with configuration and policy data stored together in the same LDAP directory server node, both are copied at one time. However, if policy data is stored in a different branch or on a different directory instance, you must repeat this operation with the clone of the first installed Access Manager to copy policy data into the new branch.
Suspend Operations, All Environments: Oracle recommends that you start this procedure by notifying all administrators to suspend operations that would result in the alteration, addition, or removal of information in the LDAP directory server. This suspension should last from the time you copy the data until you finish all zero downtime upgrade activities. Here is a partial list of operations that should be suspended:
Processing workflow tickets
Applet-based modifications such as workflow creation, change, or removal
Modifying user profiles
Modifications to "Challenge" and "Response" attributes
Creating, changing, or deleting new policies
Creating, changing, or deleting authentication schemes
Creation of host identifiers
Creating of deleting directory server profiles
Updating object classes
Updating the access attribute control, delegated administrators, or setting the searchbase
Any other operations that result in the alteration, addition, or removal of information in the LDAP directory server
After suspending operations, you will create the new node for configuration and policy data. Oracle recommends that you back up the directory server instance and your earlier Oracle Access Manager data in the original branch in the LDAP directory server.
Note:
There are no tools to automatically enforce the suspension of operations that affect your data. There is an alternative that you can use if data in your original environment is changed after you upgrade the clone system and before you upgrade the original system. For more information, see "About Retrieving Changes to the Original Branch Before Upgrading Original Instances".Obtaining the Tools: Before you populate the new branch, you need to extract 10g (10.1.4.0.1) Identity Server component libraries and files, and apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) as described in "About Destination Creation and Obtaining Tools for a Zero Downtime Upgrade". You will then run the MigrateOAM script in Mkbranch mode from the 10g (10.1.4.2.0) Identity Server directory.
If you have a joint Identity and Access System, you must also extract 10g (10.1.4.0.1) Policy Manager component libraries and files, and apply Release 10.1.4 Patch Set 1 (10.1.4.2.0). You will run the MigrateOAM script in Mkbranch mode from the 10g (10.1.4.2.0) Policy Manager file system directory.
Note:
If the old configuration or policy DN includes a space, you must apply Bundle Patch 10.1.4.2.0-BP04 to avoid a potential problem when creating the new branch. For details, see "Creating and Populating a Newoblix Branch" .Destination Path: When you extract the libraries and files, you can specify any installation path that you like. After extracting the libraries and files, the 10g (10.1.4.2.0) MigrateOAM script might be located in a path similar to the following sample:
Windows:
Linux:
In this situation, you do not need to create a source and you do not need to name the destination after an existing instance. In the sample path names:
1014\identity refers to the file system directory where the 10g (10.1.4.2.0) Identity Server component libraries and files reside.
1014\webcomponent\access refers to the file system directory where the 10g (10.1.4.2.0) Policy Manager (formerly known as the Access Manager component) component libraries and files reside.
Using MigrateOAM: Table 16-2 shows the arguments that you must supply to copy configuration and policy data from the original branch in the LDAP directory server into the new branch. The new branch node must exist in the LDAP directory server before you use the script. The MigrateOAM script will call utilities that prompt you for the new configuration DN and policy DN and then automatically copy configuration and policy data from the original branch in the LDAP directory server into the new branch. Sample file system path names are provided to help illustrate the task. Your details will be different.
Table 16-2 MigrateOAM Mkbranch Command Summary
| MigrateOAM Mkbranch Parameters | Values and Operations |
|---|---|
|
-M Mkbranch |
Specify Mkbranch as the mode. The Mkbranch mode is required to copy the schema and configuration and policy data from the original branch to the new branch in the LDAP directory server. |
|
-C component |
Specify OIS (Identity Server) to copy configuration data and policy data. Specify AM (Access Manager) to copy policy data that is stored separately from configuration data. |
|
-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 eventually be upgraded. |
|
-S "source directory" |
Specify the full path to the directory that contains the cloned Identity Server or Access Manager (in quotation marks). For example:
|
|
-D "destination directory" |
Specify the full path to the directory that contains the latest MigrateOAM script for the component you have specified (in quotation marks). For example:
|
|
-I "installation directory" |
The installation directory should be the same as the specified destination. For example:
|
The full command and options for configuration data must be entered as one contiguous line.
During execution, messages keep you informed about the process and you are asked to specify the location of the new ConfigDN. In this case, the configuration DN defines the new node in the directory tree under which the copied information is to be stored.
If configuration data and policy data are stored separately, you are asked for the new Policy base when you run the Mkbranch command with the clone of the first installed Access Manager. In this case, the policy base defines the new node in the directory tree under which the copied information is to be stored.
If you have configuration or policy DN with spaces, you must apply Bundle Patch 10.1.4.2.0-BP04 before you create a new branch in the directory server. However, do not use these patches when performing any other upgrade task. For details, see "Creating and Populating a New oblix Branch".
For more information about the storage of user data, configuration data, and policy data, as well as details about searchbases and configuration and policy DNs, see the Oracle Access Manager Installation Guide.
oblix BranchYou use the procedure in this topic to create a new branch in the LDAP directory server, and then populate it with a copy of the configuration and policy data from the original branch.
Caution:
Oracle recommends that you review all information in "About Creating and Populating a New Branch in the LDAP Directory Server" before you perform activities here.The following procedure includes sample configuration and policy DNs for both an original branch and a new branch. Also included, are sample path names for the libraries and files that you extract and patch as well as sample paths names for a clone of the first installed COREid Server and the clone of the first installed Access Manager. Your environment and specifications will be different. Some steps are conditional and should only be performed if your deployment includes that condition. Step 3 in the following procedure is one example of a conditional step.
To copy existing configuration and policy data to a new branch
Ensure that the directory server is ready, as described in "Preparing Directory Server Instances and Data".
Notify administrators to suspend any operations that will add, change, or remove configuration or policy data from the LDAP directory server until all components are upgraded and configured to use the new branch (including clones and original instances). For more information, see the list of operations earlier in this topic.
Configuration and Policy Data are Stored Together: Create a new node in the LDAP directory server to contain copied configuration data. For example:
o=company,c=uso=Newbranch,o=company,c=usConfiguration and Policy Data are Stored Separately: Perform Step 3 for configuration data, and then create a new node in the LDAP directory server (as a child node of your original policy base) to contain copied policy data. For example:
o=Policy_base,o=company,c=uso=NewPolicyBase,o=Policy_base,o=company,c=usBack up the original branch in the LDAP directory server and perform the following tasks as described in Chapter 5 topics:
First Installed COREid Server Clone: On the computer hosting the clone of the first COREid Server that was installed and set up:
Create a Destination: Extract 10g (10.1.4.0.1) Identity Server component libraries and files into a new destination path. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files". For example:
Obtain 10g (10.1.4.2.0) Tools: Apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the Identity Server component libraries and files that you just extracted, as described in "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".
Configuration DN with Spaces: In this situation only, perform the following steps to apply Bundle Patch 10.1.4.2.0-BP04 (or a later 10g (10.1.4.2.0) bundle patch) to the 10g (10.1.4.2.0) Identity Server component libraries and files that you extracted when obtaining the tools in Step b.
Go to the My Oracle Support site and log in as usual:
http://metalink.oracle.com
From the Quick Find list, choose Patch Number, in the empty field to the right, enter 7113405, and then click Go.
On the Patch 7113405 page, choose your platform from those listed, and then click the Download button beside each zip file name.
Unzip the files and locate the Oracle Access Manager Bundle Patch Notes 04 for Release 10g (10.1.4.2.0) for Linux, Microsoft, and Solaris Operating Systems.
Apply the bundle patch to the clone of the first installed COREid Server using steps in the bundle patch notes.
Note:
You can include Bundle Patch 10.1.4.2.0-BP04 when creating a new branch only. Do not apply Bundle Patch 10.1.4.2.0-BP04 for any other upgrade task.Change to the file system path that contains the MigrateOAM script for the Identity Server instance. For example:
cd 1014\identity\oblix\tools\migration_tools
Enter the following command on one line, without breaks, to run MigrateOAM in Mkbranch mode and then specify the new configuration DN when it is requested. For example:
1014\identity\oblix\tools\migration_tools>MigrateOAM.bat -M Mkbranch -C OIS -F 610 -T 1014 -S "C:\clone_np\ois_01\identity" -D "C:\1014\ \identity" -I "C:\1014\identity" ... Enter new ConfigDN : o=Newbranch,o=company,c=us The tool ran successfully Press enter key to continue ... ENTER ... Importing data to directory server..... The tool ran successfully Press enter key to continue ... ENTER
Proceed as follows:
Copy Successful, Data Stored Together (for Identity System Only): A message tells you that data was imported to the LDAP directory server and that the tool ran successfully. Proceed to "Validating Successful Operations in Your Environment" before you configure cloned components to use the new branch.
Note:
Do not repeat these steps with any other COREid Server instance. Making a new branch is a one time activity with a single COREid Server. If you have a joint Identity and Access System with configuration and policy data stored separately, you will perform Step 10.Copy Successful, Separate Data: When you have configuration and policy data stored separately in a joint Identity and Access System, proceed to Step 9.
Copy Not Successful: Perform activities in "Recovering from Problems With Populating the New Branch". Also, see the MakeBranch.log file in destination_dir/oblix/tools/MakeBranch.log.
First Installed Access Manager Clone: On the computer hosting the clone of the first Access Manager that was installed and set up:
Create a Destination: Extract 10g (10.1.4.0.1) Policy Manager component libraries and files in a new destination path. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files". For example:
Obtain the Tools: Apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the Policy Manager component libraries and files that you just extracted, as described in "Obtaining Tools: Applying Release 10.1.4 Patch Set 1 (10.1.4.2.0)".
Policy DN with Spaces: In this situation only, perform the following steps to apply Bundle Patch 10.1.4.2.0-BP04 (or a later 10g (10.1.4.2.0) bundle patch) to the 10g (10.1.4.2.0) Policy Manager component libraries and files that you extracted when obtaining the tools in Step b.
Go to the My Oracle Support site and log in as usual:
http://metalink.oracle.com
From the Quick Find list, choose Patch Number, in the empty field to the right, enter 7113405, and then click Go.
On the Patch 7113405 page, choose your platform from those listed, and then click the Download button beside each zip file name.
Unzip the files and locate the Oracle Access Manager Bundle Patch Notes 04 for Release 10g (10.1.4.2.0) for Linux, Microsoft, and Solaris Operating Systems.
Apply the bundle patch to the clone of the first installed Access Manager using steps in the bundle patch notes.
Note:
You can include Bundle Patch 10.1.4.2.0-BP04 (or a later 10g (10.1.4.2.0) bundle patch) only when creating a new branch. Bundle Patch 10.1.4.2.0-BP04 has no impact on any other upgrade task.Copy the policy data if it is stored separately, as follows.
Change to the file system path containing the 10g (10.1.4.2.0) MigrateOAM script for the Policy Manager instance. For example:
cd 1014\webcomponent\access\oblix\tools\migration_tools
Run MigrateOAM in Mkbranch mode for the Policy Manager to copy policy data that is stored separately to the new branch, and respond to prompts appropriately for your environment. For example:
1014\webcomponent\access\oblix\tools\migration_tools>MigrateOAM.bat -M Mkbranch -C AM -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\access" -D "C:\1014\webcomponent\access" -I "C:\1014\webcomponent\access" ... Enter new Policy Base : o=NewPolicyBase,o=Policy_base,o=company,c=us The tool ran successfully Press enter key to continue ... ENTER ... Importing data to directory server..... The tool ran successfully Press enter key to continue ... ENTER ....
Copy Successful: A message tells you that data was imported to the LDAP directory server and that the tool ran successfully. Proceed to "Validating Successful Operations in Your Environment" before you configure cloned components to use the new branch.
Note:
Do not repeat these steps with any other Access Manager instance. Making a new branch is a one time activity with a single Access Manager.Copy Not Successful: Perform activities in "Recovering from Problems With Populating the New Branch". Also see the MakeBranch.log file in destination_dir/oblix/tools/MakeBranch.log.
If the directory connection failed during the Mkbranch operation, ensure that the LDAP directory server is live and online.
You can check the MakeBranch.log file in destination_dir/oblix/tools/MakeBranch.log to locate the point of failure. For example, the setup.xml file might not have been read
If the old configuration or policy DN includes a space, and you did not apply Bundle Patch 10.1.4.2.0-BP04 (or later), the Mkbranch tool might not be able to replace the old configuration or policy DN with a new one.
You can remove the new configuration and policy node that you added to the LDAP directory server so that you can retry the procedure "Copying Configuration and Policy Data to a New Branch in the LDAP Directory Server" anew.
If you do not want to continue upgrading and you want to return to the earlier release, see "Rolling Back Changes Made for the New oblix Branch".
oblix BranchIf you have a problem after populating the new branch, you might need to roll back changes.
You can perform Step 1 to remove the new nodes that you added to the LDAP directory server, and then create and populate the branch anew. You can perform all steps in the following procedure to undo all changes to the environment for the zero downtime upgrade and return to the original setup and release.
After rolling back all changes, you will have only the original installation and release available for use. In this case you can use the original installation, or start an in-place upgrade, or restart the zero downtime upgrade from the beginning.
To roll back changes made for the new oblix branch
Remove the branches in the LDAP directory server that were added for the new configuration and policy DNs.
Remove the following from host computers:
Clone file system directories
10g (10.1.4.0.1) component libraries and files to which you applied Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Any file system directories that you have added or that were added automatically as part of any upgrade process
The Web server instance for the clones, and any cloned applications that are protected by Oracle Access Manager and that operate with this Web server
From the original System Console, remove all clone profiles.
Confirm that your original setup is operating properly.
You perform activities in this section only after creating the new branch (or branches) in the LDAP directory server that were contain a copy of the configuration and policy data.
To ensure that all cloned components are configured properly and that the Identity System and Access System are configured to operate with the data in the new branch, you perform tasks in this section with every cloned component instance. Individual topics in the following task overview provide step-by-step instructions that you can follow when you are ready to do so.
Task overview: Reconfiguring cloned components to use the new branch includes
Configuring Cloned WebPass Instances to Operate with Cloned COREid Servers
Configuring Cloned Access Servers
Note:
You should not have a cloned WebGate. There is no need to reconfigure the SDK.Removing Setup Files: At the start of some tasks outlined in the previous overview, you will be instructed to remove several items:
setup.*
configInfo.*
\ldap subdirectory (if there is one)
New versions of these files will be generated during reconfiguration and set up. At the conclusion of the browser-based set up procedures that you perform in tasks 3 and 4, these files will contain the new configuration DN and policy DN. Removing these files when instructed will help ensure that the Identity Server service will start up after set up.
You perform the following procedure using command-line tools that are available within each cloned COREid Server file system directory. On a Windows system, you first need to configure the clone COREid Server service. On all systems, you need to configure the cloned component based on the information for the clone in the System Console.
Note:
In tool names, the abbreviation "ois" refers to the Oracle Identity ServerWindows: To add the cloned COREid Server service entry to the Windows registry, you first run config_ois.exe. The config_ois.exe tool is stored in the file system directory of the clone: \identity\oblix\apps\common\bin. The sample path shown next contains two COREid Server clones, which are used for load balancing. Your environment will be different. For example:
Table 16-3 lists the options and parameters that you will use with the config_ois tool. When you have multiple COREid Server clones, you must perform this task for each instance individually.
Table 16-3 Options for config_ois (Windows Only)
| Command Options | Operation |
|---|---|
|
-i "clone_dir" |
Specifies the full directory path (in quotation marks) to the cloned COREid Server. For example: Windows: -i "C:\clone_np\ois_01\identity" UNIX: -i "/home/clone_np/ois_01/identity" |
|
-v clone_COREidServer_service |
Specifies the unique name of this cloned COREid Server Service. |
|
-a install |
Specifies the action to be performed. In this case, use install as the action. |
The command must be entered as one line without breaks. As the command runs, messages keep you informed.
Note:
Be sure to specify the information for each clone instance based on what is entered in the System Console for that instance.All Platforms: You run the setup_ois (Windows) and start_setup_ois (non-Windows) tool to configure the host name, port, and other details for the cloned instance. When you run this tool, you will use only the -i option and specify the cloned instance file system path, as shown in Table 16-4.
Table 16-4 setup_ois and start_setup_ois parameters
| Command Options | Operation |
|---|---|
|
-i "clone_dir" |
Specifies the full file system path (in quotation marks) to the cloned COREid Server. For example: Windows: -i "C:\clone_np\ois_01\identity" UNIX: -i "/home/clone_np/ois_01/identity" |
Be sure to enter the command and parameters on a single line. You will be prompted to provide details for the cloned instance, including:
The unique clone COREid Identifier
The clone COREid Server Hostname
The port on which the clone COREid Server listens.
The security mode for the clone.
Whether this is the first installed COREid Server: Answer No
Be sure to specify information for each clone instance based on the information for the instance in the System Console. Answer "No" when asked if this is the first COREid Server in the installation. When you have multiple COREid Server clones, you must perform this task for each instance individually.
When the command finishes, the clone is reconfigured based on the information that you supplied. The ois_server_config.xml file in clone_dir\identity\oblix\config file system directory will reflect the details that you supplied. For more information about these tools, see your Oblix NetPoint or Oracle COREid Administration Guide.
Browser-Based Setup: After reconfiguring the cloned COREid Server, you need to reconfigure the cloned WebPass. After reconfiguring WebPass, you will also need to perform a browser-based setup for the cloned Identity System. Details are provided in later topics as you need them.
Audit Policy Data for a Joint Identity and Access System: During COREid Server reconfiguration in a joint Identity and Access System, audit policy values might be returned to original default values as shown in Table 16-5. Step 1 of the following reconfiguration procedure directs you to export your audit policy data to a Lightweight Directory Interchange Format (LDIF) file using an external tool. After reconfiguring the clone, you then import this data. LDIF files are ASCII format files that you can use to exchange and synchronize data between Lightweight Directory Access Protocol (LDAP) servers using an external tool. Details about using external tools is outside the scope of this manual.
Table 16-5 Example of Audit Policies Before and After Reconfiguring COREid Server Clones
| Event Name | Application Auditing Enabled | Audit Success | Audit Failure | |
|---|---|---|---|---|
|
Before Reconfiguring |
Search |
Yes |
Yes |
Yes |
|
After Reconfiguring |
Search |
Yes |
No |
Yes |
Specific file system paths and other details in the following procedure are shown only as an example. Your details will be different.
To reconfigure the cloned COREid Server service
Audit Policy Correction for a Joint Identity and Access System: On a computer hosting the cloned COREid Server, export the following nodes to a backup LDIF file (you perform this step one time only):
obname=common,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN obname=corpdir,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN obname=objservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN obname=userservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN obname=groupservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN
On a computer hosting the cloned COREid Server instance, delete the following files from the file system path \identity\oblix\config directory. For example:
clone_np\ois_01\identity\oblix\config
setup.xml*
configInfo.xml*
\ldap subdirectory (if there is one)
Windows, config_ois: Perform the following steps to set up the registry entry for this clone:
Change to the file system path that contains the config_ois tool for this clone. For example:
cd \clone_np\ois_01\identity\oblix\apps\common\bin\config_ois.exe
Run the config_ois.exe tool using the -i, -v, and-a parameters with specifications for this cloned instance. For example:
config_ois.exe -i "C:\clone_np\ois_01\identity" -v clone_COREid_Service -a install
Confirm that the COREid Server service entry was added to the Windows registry and that the component's messagedll.dll library was copied to the Windows/system32/messagedll.dll directory.
Change to the cloned file system path that contains the COREid Server set up tool:
Windows: clone_np\ois_01\identity\oblix\tools/setup/setup_ois
UNIX: /home/clone_np/ois_01/identity/oblix/tools/setup/start_setup_ois
Run the tool using the following command parameters and provide specifications for your cloned COREid Server service and environment:
Windows:
setup_ois.exe -i "C:\clone_np\ois_01\identity"
UNIX:
./start_setup_ois -i "/home/clone_np/ois_01/identity"
Follow the on-screen prompts and respond with details for this cloned COREid Server instance and COREid Server service.
Unique COREid Identifier: Enter the name of the clone COREid Service that you entered in the System Console.
COREid Server Hostname: Enter the DNS host name where the clone COREid Server resides.
COREid Server Port: Enter the port on which the clone COREid Server listens, as specified in the System Console.
Security Mode [open\simple\cert]: Enter the mode that is specified in the System Console.
Do you want to set up SSL between the COREid Server and the Directory Server [y/n]: Respond appropriately for your original connection.
First COREid Server: Answer "No" when asked if this is the first COREid Server in the installation.
Check the ois_server_config.xml file in the clone file system path: \identity\oblix\config file system directory to ensure that it includes the details that you supplied during Step 6.
Proceed as follows:
Successful: If the information appears in the file mentioned in step 7, the operation was successful. Proceed to Step 9.
Not Successful: If the configuration DN does not appear in the files mentioned in step 7, the operation failed. In this case, see "Rolling Back Changes for Reconfigured Clones".
Restart the cloned COREid Server service, and proceed as follows:
Successful: Proceed to Step 10 if you have a joint Identity and Access System. Otherwise, skip to step 11.
Not Successful: Confirm that the cloned COREid Server service is running.
Repeat steps 2 through 7 to configure and check every cloned COREid Server instance.
Continue with Step 11 only after configuring every cloned COREid Server instance.
Audit Policy Correction for a Joint Identity and Access System: Perform the following steps (one time only) to replace default audit policy data with your original audit policy data:
Delete the following nodes from the new branch in the directory (your new configuration DN):
obname=common,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN obname=corpdir,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN obname=objservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix,your_new_configuration_DN obname=userservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN obname=groupservcenter,obpolicyContainerId=WebResrcDB, obcontainerId=Policies, o=oblix, your_new_configuration_DN
Import the LDIF file that you created for audit policy data correction in Step 1.
Proceed to "Configuring Cloned WebPass Instances to Operate with Cloned COREid Servers".
You use the procedure in this topic using command-line tools that are stored in the cloned WebPass file system directory. The tools enable you to reconfigure your cloned WebPass to communicate with cloned COREid Servers. This task is divided into the following phases:
Web server configuration
WebPass set up
Web Server Configuration: The tool that you use to configure a new Web server instance to operate with this WebPass clone is included in the file system path of the cloned WebPass. For example:
In the example, the term UNIX-based systems refers to supported platforms such as Linux and Solaris. In the sample path clone_np\webcomponent_01\identity refers to one of two cloned WebPass instances on this host. The Web server configuration tool name depends upon the type of Web server you are using. For example:
EditObjConf is used for Sun (formerly Netscape/iPlanet) Web servers
EditHttpConf is used for Apache, Oracle HTTP Server, and IBM HTTP (IHS) Web servers
configureIIS4webpass.bat is used for Microsoft Internet Information Server (IIS Web server for Windows environments)
The Web server configuration tool is interactive. You must provide all requested details for the WebPass clone.
During the update, the Web server configuration file is backed up automatically. The backup files are stored in the same directory as the original configuration file. For example, if your Web server instance is Apache the backup files are http.conf.ORIG, http.conf.ORIG1, http.conf.ORIG2. If you are using an iPlanet/SunOne Web server, configuration files are magnus.conf and obj.conf, which are stored as:
iPlanet/SunOne: WebServer_install_dir/https-instanceName/config
You need to restart the Web server instance each time you update the Web server configuration file. Changes will not take effect until you restart the Web server.
WebPass Set Up: After configuring the Web server to operate with the WebPass clone, you use the WebPass set up tool to enable the cloned WebPass to communicate with the cloned COREid Server. The tool is included in each cloned WebPass file system path but is named differently depending on the platform. For example:
In the example, UNIX refers to supported UNIX-based platforms such as Linux and Solaris. Options for tool are shown in Table 16-6. When running this tool, you can specify only the -i option and all other information will be requested automatically. If you have multiple WebPass clone instances, you must repeat this operation with each clone instance.
Table 16-6 Options for setup_webpass and start_setup_webpass
| Command Options | Operation |
|---|---|
|
-i "WebPass_clone_dir" |
Specifies the full directory path to (in quotation marks) your cloned WebPass is stored. For example: Windows: -i "C:\clone_np\webcomponent_01\identity" UNIX: -i "/home/clone_np/webcomponent_01/identity" |
|
-q -n WebPass _name |
Specifies the unique name of this WebPass clone. |
|
-h clone_COREidServer_Hostname |
Specifies the computer name where the cloned COREid Server resides. |
|
-p clone_COREidServer_port_# |
Specifies the port number of the computer where the cloned COREid Server resides. |
|
-s mode |
Specifies the transport security mode for the cloned COREid Server and cloned 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 |
The command should be entered as one line, without breaks. As the command is performed, messages keep you informed and you might be asked to supply information for this WebPass clone. Be sure to specify information for the specific instance and environment.
The following procedure provides the steps that you need to perform. Steps 1 through 4 are related to Web server reconfiguration. In this example, the EditObjConf is used as an example. Steps 5 through 8 describe WebPass reconfiguration. After reconfiguring all WebPass clone instances, you perform step 9. Path and host names in following steps are presented as an example. Your details will be different.
To modify a cloned WebPass to operate with the cloned COREid Server
Change to the file system path that contains the Web server configuration update tool for the cloned WebPass. For example:
cdIn this sample path, clone_np\webcomponent_01\identity is the file system where the cloned WebPass resides and EditObjConf is the name of the Web server configuration update tool for this (Sun) Web server.
Run the update tool using the -f, -d, and -i options with specifications for the cloned WebPass, and then respond to prompts with details for your environment. For example:
Windows:
EditObjConf.exe -f "C:\clone_Webserver_config_dir" -d "C:\clone_np\ webcomponent_01\identity" -i
UNIX:
./EditObjConf -f "/home/clone_Webserver_config_dir" -d "/home/clone_np/ webcomponent_01/identity" -i
Note the location of the backed up Web server configuration file that is created automatically during this operation.
Restart the Web server.
Proceed as follows:
Successful: Status messages tell you that this operation was successful. Afterward, you can compare the back up copy of the Web server configuration file with the updated version. Proceed to Step 5.
Not Successful: Proceed to "Rolling Back Changes for Reconfigured Clones".
Change to the file system path that contains the set up utility for the cloned WebPass instance. For example:
cdRun the tool using the following options (see also Table 16-6) and specifications for your cloned environment. For example:
setup_webpass -i "C:\clone_np\webcomponent_01\identity"
Follow the on-screen prompts and respond with details for this cloned WebPass and the associated COREid Server clone.
Unique WebPass Identifier: Enter the name of the clone WebPass that appears in the System Console.
COREid Server Hostname: Enter the DNS host name where the associated clone COREid Server resides.
COREid Server Port: Enter the port on which the associated cloned COREid Server listens, as specified in the System Console.
Security Mode [open\simple\cert]: Enter the mode that is specified in the System Console.
Proceed as follows:
Successful: Proceed to Step 9.
Not Successful: Proceed to "Rolling Back Changes for Reconfigured Clones".
Repeat this entire procedure to reconfigure every cloned WebPass.
When all cloned WebPass instances are reconfigured, proceed to "Setting Up the Cloned COREid System to Use the New Branch".
After configuring all cloned COREid Servers and WebPass instances, you perform tasks in this topic to set up the cloned COREid System to use the new configuration DN.
During this browser-based set up, you will need to provide some details from the original installation: for example, the LDAP directory server type, the location of user data, and the searchbase that was defined when you set up the original COREid System. You can locate these details in the setup.xml file within the original file system path of the first COREid Server to be installed. In this example, the file will be stored within np611\ois_01\identity\oblix\config\setup.xml. For more information about setting up the COREid System, see your earlier NetPoint or Oracle COREid Installation Guide.
Extra Directory Profiles for Split Directory Configurations: When you have data stored separately, extra directory server profiles containing the old configuration DN might be created during the COREid Server reconfiguration. For example, you might have user data stored in Active Directory and policy and configuration data stored in ADAM.
All the directory server profiles are stored in the directory server under obcontainerId=DBAgents,o=Oblix,<Config DN>. When a profile is created during system setup, the name in the System Console is same in the backend directory server under the mentioned node. However, when profiles are manually created, the nodes in the backend directory server are created with a timestamp as their name. Example 16-3, illustrates a directory profile created in a typical 10.1.4 installation.
Example 16-3 LDAP Directory Profile for Oracle Access Manager
obcontainerId=DBAgents,o=Oblix,dc=us,dc=oracle,dc=com -obname=default-IDSERVER,obcontainerId=DBAgents, o=Oblix,dc=us,dc=oracle,dc=com -obname=AccessManager_setup_user_profile,obcontainerId=DBAgents, o=Oblix,dc=us, dc=oracle,dc=com -obname=AccessServer_default_user_profile,obcontainerId=DBAgents, o=Oblix,dc=us, dc=oracle,dc=com
After setting up the clone COREid Server and WebPass, you need to check for and then delete the "Oblix Base" profile for the original COREid Server because this profile does not include the new configuration DN. Before you set up the Access Manager clone, you will also need to delete the "Policy Base" profile for the original Access Manager because it does not include the new policy DN.
Note:
Removing "Oblix Base" and "Policy Base" profiles for the original COREid Server and the original Access Server is required only when data is stored in a split directory server configuration.Tools to Remove Extra Directory Server Profiles: When the profiles are in a consistent state, you can delete them from the System Console. However, if you cannot delete the older profiles using the System Console, you will have to use external tools to perform the removal.
Note:
While using external tools is outside the scope of this manual, you can view an example of steps to remove an extra profile using the LDP Console program in "Alternative: Using the External LDP Console to remove a profile". These are only an example.The following procedure provides the steps that you must perform to set up the clone COREid System for the new branch. Path and host names are provided as an example only. Your details will be different. For more information about setting up the COREid System, see your Oblix NetPoint or Oracle COREid Installation Guide.
To set up the cloned COREid System with the new branch
Locate original details for the installation in the setup.xml in the original COREid Server installation directory. For example:
Original: np611\identity_01\oblix\config\setup.xml
Ensure that the Web server that is serving the clone WebPass is running and go to the cloned COREid System Console, as usual. For example:
Clone:
http://hostname:port/identity/oblix/
In the sample URL, hostname refers to computer that hosts the cloned WebPass Web server; port refers to the HTTP port number of the new Web server instance for the WebPass clone; and /identity/oblix connects to the cloned COREid home page that includes the COREid System Console link.
The cloned WebPass will connect to the cloned COREid Server and launch the setup page.
Click the COREid (or Identity) System Console link.
The clone System Console setup page appears.
Click the Setup button.
Follow the on-screen instructions and those here to set up the cloned Identity System:
Confirm LDAP directory server details for the new directory branch.
Enter the root bind DN for user data.
Enter the new configuration DN and the original user data searchbase. For example:
Configuration DN—o=Newbranch,o=company,c=us
Searchbase—Supply the original searchbase
Finish this setup procedure leaving all other details as they are.
Restart the clone COREid Server service when instructed to do so by an on-screen message.
Go to the \identity\oblix\config file system directory and confirm that the new information you supplied appears in the following files:
setup.xml
configInfo.xml
\ldap directory
Go to the clone COREid System Console and verify that the Directory Server profile for the cloned COREid Server has the new configuration DN, as follows:
Go to your clone COREid System Console, as usual.
http://hostname:port/identity/oblix/
From the COREid System Console click the System Admin tab, then click the System Configuration tab.
Click Configure Directory Options in the left column to display the Configure Profiles page.
Click the name of an existing directory profile to display its specifications.
Confirm that the new configuration DN appears in the profile.
Extra Directory Profiles in a Split Directory Server Configuration: When you have data stored in different directory servers, perform the following steps to remove any directory profiles that contain original (older) configuration or policy DNs in a split directory server situation:
From your clone COREid System Console, click the System Admin tab, then click the System Configuration tab.
Click Configure Directory Options in the left column of the System Configuration tab.
On the Configure Directory Server profiles page, check the box beside the name of any old directory profile that is present with the old configuration DN.
Note:
Do not select or delete the original LDAP directory server profile, or any profile that you or the team added for the cloned set up.Click the Delete button to remove the extraneous LDAP directory server profile.
When prompted, click OK to confirm your decision.
Note:
If you cannot delete the profile using the System Console you need to use external tools to remove the older profiles as described in "Alternative: Using the External LDP Console to remove a profile".Restart cloned COREid Server services (and Access Manager Web servers).
Proceed as follows:
Configuration Successful, Identity System Only: Proceed to "Upgrading the Schema During a Zero Downtime Upgrade".
Configuration Successful, Joint Identity and Access System: Proceed to "Setting Up Cloned Access Managers to Use the New Branch".
Configuration Not Successful: Remove the files named in Step 6 and re-run setup_ois (Windows) or start_setup_ois (non-Windows) as described in "Configuring Cloned COREid Server Services and Details". Otherwise, see "Rolling Back Changes for Reconfigured Clones".
If you need to remove an extra profile using an external tool, the following sample procedure might be helpful. Using external tools is outside the scope of this manual.
Alternative: Using the External LDP Console to remove a profile
Open the Console using ldp.exe.
From the Connection tab, select Connect.
Enter the LDAP directory server computer name and port, and then click OK.
Select the Bind from the Connection tab.
In the User text box, enter the bind DN for your LDAP directory server; enter the password; ensure that the domain is unchecked; click OK.
Success is indicated by an message saying "Authenticated....". Otherwise, an error message appears.
Proceed as follows:
Successful: Proceed with Step 7.
Not Successful: Retry the bind operation again and ensure that you enter the exact bind DN and password.
Select Tree from the View tab.
Enter the configuration DN (Identity Server or policy DN for the Access Manager) for the LDAP directory server, then click OK.
Select the new node that was created during the make branch operation (Mkbranch).
Within the new node, locate the node that starts with the following:
obcontainerId=DBAgents,OU=Oblix,OU=NewNode.....
Within the node you located, check for extra profiles by looking for attribute values (mostly identified by profile name).
After confirming the extra profile is to be deleted, right-click the profile and then select Delete.
Verify the node in the DN field; if it is the correct one, check all boxes (extended, synchronous and recursive), and then click OK.
Ensure that you receive a message confirming the removal. For example "deleted 1 entries."
You perform this task only if you have a joint Identity and Access System. Otherwise, skip to "Upgrading the Cloned Identity System".
This task is divided into two parts.
Task overview: Configuring cloned Access Managers to use the new branch
The steps that you perform to configure cloned Access Managers to operate with the new branch in the LDAP directory server are similar to the steps that you have already performed for the cloned COREid System. In this case, you update the Web server configuration file using the tools provided in your cloned Access Manager file system directory.
Web Server Configuration: The tool that you use to update the Web server configuration to operate with the cloned Access Manager resides in the cloned Access Manager file system path. For example:
In the sample path, clone_np\webcomponent_01\access refers to one of two cloned Access Manager instances. The name of the Web server configuration tool depends upon the type of Web server that you are using. For example:
EditObjConf is used for Sun (formerly Netscape/iPlanet) Web servers
EditHttpConf is used for Apache, Oracle HTTP Server, and IBM HTTP (IHS) Web servers
configureIIS4accesssystem.bat is used for Microsoft Internet Information Server (IIS Web server for Windows environments)
The command must be entered on one line with no breaks. During the update, the Web server configuration file is backed up automatically. The backup files are stored in the same directory as the original configuration file. For example, if your Web server instance is Apache the backup files are http.conf.ORIG, http.conf.ORIG1, http.conf.ORIG2. If you are using an iPlanet/SunOne Web server, configuration files are magnus.conf and obj.conf, which are stored as:
iPlanet/SunOne: WebServer_install_dir/https-instanceName/config
You need to restart the Web server instance each time you update the Web server configuration file. Changes will not take effect until you restart the Web server.
The following procedure provides the steps that you need to perform. Path and host names are presented as an example only. Your details will vary.
To modify a cloned Access Manager Web server
Change to the file system path that contains the appropriate update tool for the Web server serving the clone Access Manager. For example:
cdRun the tool using the -f, -d, and -i options, and specifications for your cloned Access Manager; respond to any prompts with details for your environment. For example:
Windows:
EditObjConf.exe -f "C:\clone_Webserver_config_dir" -d "C:\clone_np\ webcomponent_01\access" -i
UNIX:
./EditObjConf -f "/home/clone_Webserver_config_dir" -d "/home/clone_np/ webcomponent_01\access" -i
In the sample path name, clone_Webserver_config_dir is the directory for the Web server configuration file that will be used with the cloned Access Manager.
Note the location of the backed up Web server configuration file that is created automatically during this operation.
Restart the Web server instance and confirm that the Access Manager Web server configuration update was successful and proceed as follows:
Successful: Proceed to "Setting Up the Cloned Access Manager to use the New Branch".
Not Successful: Proceed to "Rolling Back Changes for Reconfigured Clones".
After updating the configuration file of the Web server for the clone Access Manager, you need to set up the cloned Access Manager. You perform this task to use the cloned Access Manager is using the new configuration DN and policy DN.
During this browser-based setup you will need to provide details from the original installation. For example, you need to provide the LDAP directory server type, the location of user data, the searchbase, and the Person Object Class that was defined when you set up the original COREid System. You can locate the Person Object Class and other details in the setup.xml file within the original COREid Server file system. For example, np611\ois_01\identity\oblix\config\ setup.xml.
Note:
If your starting release is 6.1.1, you will have files named setup.lst and configInfo.lst rather than setup.xml and configInfo.xml.You will also need to supply new information, including the new branch in the directory where configuration and policy data are stored.
The following procedure provides the steps that you need to perform. Path and host names are presented as an example only. Your details will be different. For more information about setting up the Access Manager, see also your NetPoint or Oracle COREid Installation Guide.
To set up a cloned Access Manager to operate with the new branch
Locate details for the original installation in the setup.xml file of the original COREid Server. For example:
Original Installation: np611\identity_01\oblix\config\setup.xml
Delete the following files in the file system path for the cloned Access Manager instance. For example:
clone_np\webcomponent_01\access\oblix\config
setup.*
setup_am.*
configInfo
\ldap subdirectory (if there is one)
Ensure that the Access Manager Web server is running.
Go to the clone Access System Console.
http://hostname:port/access/oblix/
In the sample URL, hostname refers to computer that hosts the clone WebPass; port refers to the HTTP port number of the new Web server instance for the WebPass clone; /access/oblix connects to the clone Access System Console.
The WebPass will connect to the cloned Access System Console.
Click the clone Access System Console link to display the Setup page, and then click the Setup button.
Set up the Access Manager to use the new configuration DN and policy base, as follows:
Enter and confirm LDAP directory server details, including the LDAP directory server type and the location and details for user data and configuration data.
Enter information for user data (the original search base), and the new configuration DN and new policy DN (base). 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
Proceed through remaining Access Manager setup pages and leave all other details as they are.
Enter the original Person Object Class that was selected during the original COREid System setup.
Restart the Web server and Identity Server service when instructed to do so.
After the Web server restarts, click Next and accept the default Policy Domain Root (or specify the root for your original installation).
Continue, but do not configure authentication schemes or policies to protect NetPoint URLs.
Click done when set up is complete.
Verify that the Directory Server profile has the new configuration DN and policy base, as follows:
Go to the clone Access System Console, as usual.
http://hostname:port/access/oblix/
Click Access System Console, click System Configuration, then click Server Settings.
Click the Directory Server link to display the Directory Server Configuration page.
Confirm that the configuration DN and the policy base are correct for the new branch in the directory, and then click Cancel.
Extra Directory Profiles in a Split Directory Server Configuration: Check for and remove any extra directory server profiles containing the old configuration DN that might have been added for the Access Manager and Access Server. 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.
Note:
Do not select or delete the original LDAP directory server profile, or any profile that you or the team added for the cloned set up.Proceed as follows:
Successful: Proceed with Step 9.
Not Successful: Remove the files named in Step 2 and re-run browser-based setup as described in this procedure. Otherwise, perform to "Rolling Back Changes for Reconfigured Clones".
In the configuration files for this clone instance, confirm that the new configuration DN appears. For example:
clone_np\webcomponent_01\access\oblix\config
setup.* (setup.xml is the name on the COREid Server but setup.lst was used for Access Manager 7.0 and earlier)
setup_am*
configInfo
Proceed as follows:
Successful: If the new configuration DN and policy base appear in the files mentioned in step 9, the operation was successful. Proceed to Step 11.
Not Successful: If the new configuration DN and policy base do not appear in the files mentioned in step 9, the operation failed. In this case, perform this entire procedure again. Otherwise, see "Rolling Back Changes for Reconfigured Clones".
Repeat the following procedures to reconfigure every cloned Access Manager instance:
When all cloned Access Manager instances are reconfigured, proceed to "Configuring Cloned Access Servers".
You perform this task only if you have a joint Identity and Access System deployed. Otherwise, skip to "Upgrading the Cloned Identity System".
You will use the configureAAAserver.exe tool (Windows) to perform this procedure. On UNIX-based platforms this tool is called start_configureAAAServer. The tool is stored in the file system path for the instance. The name of the file differs between platforms. For example:
These are interactive tools. After starting the tool, you will be asked to provide details for the cloned Access Server, including:
The transport security mode for the cloned Access Server
The security mode in which the user directory is running
The host computer on which the user directory resides
The port number on which the user directory listens
The bind DN of the user directory
The password of the user directory
The directory type for user data
The location where copied oblix (configuration) data is stored
The new configuration DN
The new policy base
The cloned Access Server ID
Start the Access Server service
Specify failover information if you want to
The information that you enter for each clone must match the information for the clone that appears in the System Console.
Extra directory profiles containing the old configuration DN might be created for cloned Access Servers during this reconfiguration. You will be instructed to remove any extra directory profiles when you verify the reconfigured Access System.
Path and host names in the following procedure are samples only. Your details will be different. For more information, see the NetPoint or Oracle COREid Administration Guide for information on the configureAAAserver tool and LDAP directory server configurations.
To reconfigure a cloned Access Server to use the new branch
Change to the file system path that contains the configureAAAserver tool for the clone Access Server. For example:
cdRun the tool using the install option. For example:
Windows:
configureAAAServer.exe install "C:\clone_np\aaa_01\access"
UNIX:
./start_configureAAAServer install "/home/clone_np/aaa_01/access"
Read the on-screen prompts and specify details for your clone when prompted.
The transport security mode for the cloned Access Server
The security mode in which the user directory is running
The host computer on which the user directory resides
The port number on which the user directory listens
The bind DN of the user directory
The password of the user directory
The directory type for user data
The location where copied oblix (configuration) data is stored
The new configuration DN
The new policy base
The cloned Access Server ID
Start the Access Server service
Specify failover information if you want to
Write the name of the cloned Access Server service, then restart the service (do not specify or update the failover information).
Confirm that the information you entered is included in the aaa_server_config.xml file (in the clone_np\aaa_01\access\oblix\config\aaa_server_config.xml).
Proceed as follows:
Successful: If the new policy base appears in the files mentioned in step 6, the operation was successful. Proceed to Step 7.
Not Successful: If the new policy base does not appear in the files mentioned in step 5, the operation failed. In this case:
Check migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".
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.
Verify that the LDAP directory server profile for the cloned Access Server has the new configuration DN and policy base, as follows:
Go to the clone Access System Console, as usual.
http://hostname:port/acces/oblix/
Click Access System Console, click System Configuration, then click Server Settings.
Click the Directory Server link to display the Directory Server Configuration page.
Confirm that the new configuration DN and the policy base are correct for the copied directory, and then click Cancel.
Extra Directory Profiles in a Split Directory Server Configuration: Check for and remove any extra directory server profiles containing the old configuration DN that might have been added for the Access Manager and Access Server. For more information, refer to the discussion about extra profiles in "Setting Up the Cloned COREid System to Use the New Branch" and see the Oracle Access Manager Identity and Common Administration Guide.
Note:
Do not select or delete the original LDAP directory server profile, or any profile that you or the team added for the cloned set up.Proceed as follows:
Successful: Perform this entire procedure to configure each Access Server clone and then proceed to step 10.
Not Successful: Proceed to "Rolling Back Changes for Reconfigured Clones".
When all Access Server clones are configured for the new policy base, proceed to "Upgrading the Schema During a Zero Downtime Upgrade".
This task is optional. This is helpful when you plan to have an extended testing and familiarization period with the upgraded cloned environment. The clone environment and the original environment are upgraded and operate independently whether you perform this optional task or not. The two environments will share the upgraded schema, whether you perform this optional task or not.
You can perform this optional task at any time after you reconfigure clones to use the new branch in the LDAP directory. You can add new WebGates to the cloned environment. However, adding new WebGates can only be done after upgrading the entire clone setup. Until then, retain original WebGates that are associated with cloned Access Servers.
You can choose to isolate either the clone environment, the original environment, or both environments:
Immediately after reconfiguring clones
Caution:
Retain original WebGates that are associated with cloned Access Servers until you have upgraded the entire clone system.Immediately after upgrading clones
Not at all
As discussed in "About Isolating the Original and Cloned Environments", if the clone profiles are removed from the original System Console and you decide to perform a roll back and restart the clone upgrade, you must re-enter the clone profiles. Also, if you decide to retrieve new information that was added to the original branch you will need to reconfigure and upgrade clone instances again. In this case, you will need clone profiles in the original System Console.
For more information about isolating environments, see the following topics:
This task is optional. This procedure explains how you can isolate the upgraded clone setup.
To isolate the clone setup, you remove original instance profiles from the clone System Console. Within the clone setup, you will need to replace original WebGates with new WebGates. However, you can add new WebGates to the cloned environment only after upgrading the entire clone setup.
In an Identity System only environment, you disable or remove original COREid Server and WebPass profiles from the clone System Console. In a joint Identity and Access System, you also disable or remove original Access Server from the clone System Console.
Before you disable or remove original WebGate profiles that are associated with Access Server clones, you must add new WebGate instances to replace the functionality of the originals. You can add new WebGates to the cloned environment only after upgrading the entire clone setup. Until then, retain original WebGates that are associated with cloned Access Servers.
Oracle recommends that you have more than one WebGate to avoid downtime. Alternatively, you can keep the older WebGate and not upgrade it because it will work with the upgraded Access Server. Having only one WebGate will result in downtime when upgrading that WebGate (or when rolling back).
To isolate the clone setup and provide WebGate coverage
In the clone System Console:
Disable or remove profiles for original COREid Servers
Disable or remove profiles for original WebPass instances
Disable or remove original Directory Profiles
Disable or remove profiles for original Access Server
Do not disable or remove the profiles of original WebGates that are associated with clone Access Servers until you have upgraded the entire clone system.
Add New WebGates After Upgrading and Validating the Upgraded Clone System:
In the clone Access System Console, add specifications for a new WebGate that match those of an original WebGate that is associated with a clone Access Server.
Note:
The WebGate name and port should be unique. For more information, see the Oracle Access Manager Installation Guide.In the clone Access System Console, associate the new WebGate with an Access Server clone.
Install a 10g (10.1.4.0.1) WebGate and assign the WebGate identifier that you just added in the clone Access System Console, as described in the Oracle Access Manager Installation Guide.
Apply the Release 10.1.4 Patch Set 1 (10.1.4.2.0) to the new WebGate, as described in the Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems.
Add as many new WebGates to the upgraded clone setup as you need by repeating Steps a through d.
Test the cloned system to ensure that it is operating properly with the new WebGates.
In the clone Access System Console, disable profiles for all original WebGates that are associated with Access Server clones.
This task is optional.
To isolate the original setup, you can disable or remove all clone profiles from the original System Console. In the System Console, there are no profiles for Access Managers. There are no clone WebGate instances or profiles.
In the original System Console:
Disable or remove clone COREid Server profiles from the original System Console
Disable or remove clone WebPass profiles from the original System Console
Disable or remove clone Directory Profiles from the original System Console
Disable or remove clone Access Server profiles from the original System Console
Caution:
You can add new WebGates to the cloned environment only after upgrading the entire clone setup. Until then, retain cloned Access Server profiles that are associated with original WebGates.Test the original system to ensure that it is operating properly.
Before you upgrade original instances, Oracle recommends that you:
Determine whether you need to reconcile changes that might have been made in the original system or not. For details, see "About Retrieving Changes to the Original Branch Before Upgrading Original Instances".
Ensure that the clone setup is providing service to your customers. For details, see "Reconfiguring Domain Name Systems (DNS) to Use Upgraded Clones".
To recover from a single issue and continue with a zero downtime upgrade, you can perform Step 1 and then re-create the clone and reconfigure it. Performing all steps in the following procedure will removes all traces of the cloned configuration from host computers and the System Console.
If you want to use the original release (or switch to using the in-place method described elsewhere in this manual), perform all steps in the following procedure.
To roll back changes for reconfigured clone components
Shut down clone services and Web servers and remove the clone file system directory.
Remove the following items from host computers:
Clone file system
10g (10.1.4.0.1) component libraries and files to which you applied Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Any file system directories that you have added or that were added automatically as part of any upgrade process
The Web server instance for the clones
The branches in the LDAP directory server that were added for the new configuration and policy DNs
From the original System Console, remove all clone profiles if they exist.
Confirm that your original setup is operating properly.
Oracle recommends that you upgrade the schema after configuring earlier cloned components to use the data in the new branch of the LDAP directory server. There is only one schema and it is used by both originals and clones.
Only the schema is upgraded during this operation. The Identity System schema includes objectclasses and their attributes. Depending on how your data is stored, you might need to upgrade the Access System schema. For more information, see the following topics:
This topic describes considerations and methods for upgrading the schema. The terms "first installed COREid Server" and "first installed Access Manager" refer to the first instance of the respective component that was installed and set up in the original environment. These are the instances that were used when you added the schema to the directory server and initially set up the original Identity and Access Systems.
To upgrade the schema you will use the 10g (10.1.4.2.0) MigrateOAM script. It will be available in the destination file system path that is created when you extract 10g (10.1.4.0.1) Identity Server libraries and files and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
If you need to upgrade the Access System schema, you will also need the 10g (10.1.4.2.0) MigrateOAM script that is available in the destination file system path that is created when you extract the 10g (10.1.4.0.1) Policy Manager libraries and files and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Guidelines for Upgrading the Schema with the Zero Downtime Upgrade Method
You might perform the schema upgrade more than once, depending on how data is stored in your environment. The following guidelines will help you determine how to approach the schema upgrade in your environment:
All Data Stored Together: If you have user data, configuration data (sometimes referred to as oblix data), and policy data stored together in the same directory server (or when you have no Access System and no policy data), you execute MigrateOAM in Schema mode with the clone of the first installed COREid Server instance and provide the bind credentials for the single LDAP directory server.
User Data Stored Separately from Configuration and Policy Data: If you have user data in one directory server and configuration and policy data in another, you must execute MigrateOAM in Schema mode, as follows:
One time with the clone of the first installed COREid Server instance using bind credentials for user data
Another time with the clone of the first installed COREid Server using credentials for the configuration and policy data.
All Data Stored Separately: If you have user data in one directory server, configuration data in another, and policy data in a third, you must run MigrateOAM in Schema mode as indicated here:
One time with the clone of the first installed COREid Server instance and user data credentials
A second time with the clone of the first installed COREid Server instance and configuration data credentials
A third time with the clone of the first installed Access Manager instance and policy data credentials
User Data Stored in Multiple Directory Servers: Each directory server can have different credentials. In this case, you need to run MigrateOAM in Schema mode once for each directory server where you have user data stored (and specify the credentials for the particular directory server each time you run the script).
When you have user data divided across more than one directory server, before you upgrade the schema you must upload the appropriate directoryserver_user_schema_add.ldif for all but the first directory server instance. The first directory server instance is the one that was specified when you initially installed and set up the original COREid Server. This is when the initial directory server profile was created. Additional directory server profiles were added at a later time. As a result, the schema that was uploaded during installation is not automatically loaded for other directory server instances.
Each ldif file is prefixed with a specific directory server type. The directoryserver_user_schema_add.ldif file is located in the clone of the COREidServer_install_dir \identity\oblix\data\common file system directory. In most cases, you use the ldapmodify tool to perform the update. For example:
ldapmodify –h DS_hostname -p DS_port_number -D bind_dn -w password -a –c -f iPlanet_user_schema_add.ldif
Note:
With Oracle Internet Directory, Oracle recommends that you set the LDAP_PASSWORD_PROMPTONLY variable to TRUE or 1 to disable the less secure -w and -P password options whenever possible, and use the -q (or -Q) options, to prompt you for the user password (or wallet password).For more information about manual schema update files, see the Oracle Access Manager Installation Guide.
The example in this chapter presumes that you have configuration data and policy data stored separately. In this case, you will need to upgrade the Identity System schema and the Access System schema independently. Figure 16-7 illustrates two file system directories that will be used for the sample schema upgrade.
Figure 16-7 New 1014 and Clone File System Directories
Based on the example depicted in Figure 16-7, the MigrateOAM script for the schema upgrade will be stored in the destination_dir. For example:
In the sample path names, 1014\identity is where the 10g (10.1.4.2.0) Identity Server is stored, and 1014\webcomponent\access contains the 10g (10.1.4.2.0) Policy Manager.
Table 16-7 lists the arguments that you specify with the MigrateOAM script in Schema mode. You run the script in Schema mode only with the clone of the first installed COREid Server (and the clone of the first installed Access Manager, if policy data is stored separately).
Table 16-7 MigrateOAM Script, Schema Mode Syntax
| MigrateOAM Schema Upgrade Syntax | Values and Operations |
|---|---|
|
-M Schema |
Specify Schema as the mode. Schema mode is required to upgrade the schema new branch in the directory as well as in the old branch. This occurs all at one time. |
|
-C component |
Specify OIS (Oracle Identity Server) to upgrade Identity System schema. Specify AM (Access Manager) to upgrade the Access System schema that is stored separately from configuration data. |
|
-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 |
Specify 1014 as the release to which the schema will be upgraded. |
|
-S "source directory" |
Specify the full path name (in quotation marks) to the directory that contains the cloned earlier Identity Server or Access Manager. For example:
|
|
-D "destination directory" |
Specify the full path name (in quotation marks) to the directory that contains the 10g (10.1.4.2.0) MigrateOAM script for the component you have specified. For example:
|
|
-I "installation directory" |
The installation directory should be the same as the destination directory. For example:
|
|
-B "bind DN" |
Specify the distinguished name in quotation marks ("cn=Directory Manager", for example) that has full permissions for the user and configuration branches of the directory information tree (DIT). Oracle Access Manager will access the LDAP directory server as this account. |
|
-W Bind password |
Specify the password for the user specified as the bind DN. |
The schema upgrade process and messages will be repeated for every release between your starting release (6.1.1 for example) and the latest release. As a result, you will see the same sequence of messages and prompts when the schema is upgraded. Oracle recommends that you use Automatic rather than Confirmed mode for the quickest upgrade. Oracle also recommends that you do not skip any processes. For more information, see "About Schema Mode Processing".
For details and steps to upgrade the schema, see the following topics:
You use the following procedure to upgrade the Identity System schema. Both clone and original component instances will use the upgraded schema.
The upgraded schema offers backward compatibility with the earlier schema. If you back up the earlier schema before upgrading, using a third-party utility, you should be able to reinstate the backup copy if you decide to roll back to the original release. Details about external utilities is outside the scope of this manual.
Depending on how your data is stored, you might have to perform the Identity System schema upgrade more than one time. For more information, see details in "Guidelines for Upgrading the Schema with the Zero Downtime Upgrade Method".
Path names and the starting release in the following procedure are samples only, as shown in Table 16-7. Your path names and starting release might differ.
Caution:
Oracle recommends that you review all information about upgrading the schema before you begin the following procedure. There is no automated way to roll back a schema upgrade.To upgrade the Identity System schema
Perform activities to back up the schema before the upgrade, as described in "Backing up the Earlier Oracle Access Manager Schema".
Ensure that the directory server is ready, as described in "Preparing Directory Server Instances and Data".
Upload schema update files when you have user data stored on multiple directory servers, as described at the beginning of this topic. For example:
ldapmodify –h DS_hostname -p DS_port_number -D bind_dn -w password -a –c -f iPlanet_user_schema_add.ldif
Note:
With Oracle Internet Directory, Oracle recommends that you set the LDAP_PASSWORD_PROMPTONLY variable to TRUE or 1 to disable the less secure -w and -P password options whenever possible, and use the -q (or -Q) options, to prompt you for the user password (or wallet password).Change to the file system path that contains the MigrateOAM script for the 10g (10.1.4.2.0) Identity Server. For example:
1014\identity\oblix\tools\migration_tools\MigrateOAM.bat
Run MigrateOAM in Schema mode to start upgrading your Identity System schema. For example:
MigrateOAM -M Schema -C OIS -F 610 -T 1014 -S "C:\clone_np\ois_01\ identity" -D "C:\1014\identity" -I "C:\1014\identity" -b "cn=bindDN" -W password
Respond to prompts during each sequence as follows:
Use Automatic mode for each sequence so that you do not need to confirm each process.
Do not skip any processes.
Review the log files (obmigratenp.log and obmigrateschema.log in destination_dir\identity\oblix\tools\migration_tools\to see if any errors occurred. For more information, see Appendix C.
Verify that the upgrade was successful and proceed as follows.
Successful with Data Stored Together (or Identity System Only): Proceed to "Validating Identity System Operations".
Successful with Policy Data Stored Separately: Proceed to "Upgrading the Access System Schema" before you validate operations as described in "Validating Successful Operations in Your Environment".
Not Successful: Proceed to "Rolling Back After the Schema Upgrade".
You perform this task only when the following conditions apply to your cloned and original environments:
If you have a joint Identity and Access System deployed
If configuration data is stored separately from policy data
If you have upgraded the Identity System schema for the LDAP directory containing user data
For more information, see "Guidelines for Upgrading the Schema with the Zero Downtime Upgrade Method".
When these conditions apply to your environment, you perform steps in the following procedure using the clone of the first Access Manager that was installed and set up. You will run the MigrateOAM script from the 10g (10.1.4.2.0) Policy Manager directory. This is the same script that was used to make the new policy branch. It should already be stored in a file system directory on the computer hosting the clone of the first installed Access Manager: 1014\webcomponent\access, for example.
Running MigrateOAM in Schema mode to upgrade the Access System schema is similar to running MigrateOAM in schema mode to upgrade the Identity System schema. For example, as described in Table 16-7, you specify Access System details as follows:
-M Schema
-C AM
-S "C:\clone_np\webcomponent_01\access" is the source directory for the clone of one of two Access Manager instances on this host computer
-D "C:\1014\webcomponent\access" is the destination for the Access System schema upgrade, which contains the 10g (10.1.4.2.0) Policy Manager libraries and files and the MigrateOAM script
-I "C:\1014\webcomponent\access" is the same as the destination
-B "bind DN" specifies the distinguished name of the user with full permissions for the directory information tree (DIT)
-W bind password specifies the password for the user specified with -b parameter
The upgrade occurs for every release between your starting release and the latest release. Oracle recommends that you use Automatic rather than Confirmed mode for the quickest upgrade. Oracle also recommends that you do not skip any processes.
Path names and the starting release in the following procedure are samples only, as shown in Table 16-7. Your path names and starting release might differ.
Caution:
Oracle recommends that you review all information about upgrading the schema before you begin the following procedure.To upgrade the Access System schema
IIS Web Server: If the cloned Access Manager is operating with an IIS Web server, remove the 10g (10.1.4.2.0) Policy Manager installer before starting this procedure. For example:
Oracle_Access_Manager10_1_4_0_1__sparc-s2_NSAPI_Access_Manager.exe
Change to the file system path that contains the MigrateOAM script for the 10g (10.1.4.2.0) Policy Manager. For example:
Run MigrateOAM in Schema mode and specify arguments for the clone of the first installed Access Manager. For example:
MigrateOAM -M Schema -C AM -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\ access" -D "C:\clone_np\1014\webcomponent\access" -I "C:\clone_np\1014\ webcomponent\access" -b "cn=bindDN" -W password
Use Automatic mode for each sequence so that you do not need to confirm each process.
Review the log files (ogmigratenp.log and obmigrateschema.log) in the destination_dir to see if any errors occurred.
Verify that the Access System schema upgrade was successful and proceed as follows:
Successful: Proceed to "Validating Successful Operations in Your Environment".
Not Successful: Proceed to "Rolling Back After the Schema Upgrade".
The topics in this section describe how to validate successful operations in both your original and cloned environments at several critical points. The steps that you use are the same regardless of the environment you are validating (clone or original).
You will need to perform validation steps in both clone and original environments. Be sure to use the URL for the environment you are validating:
Clone Environment: Use only URLs to your cloned System Console.
Original Environment: Use only URLs to your original System Console.
Task overview: Validating successful operations
After the schema upgrade, validate operations in the cloned environment using URLs to your:
Cloned environment
Original environment
After clone upgrades, perform validation activities using URLs to your clone System Console.
After original upgrades, perform validation tasks using URLs to your original System Console.
The following list summarizes the environment in which you perform this validation:
Identity System: Perform steps in "Validating Identity System Operations".
Joint Identity and Access System: Perform steps to validate the Identity System and then perform steps in "Validating Access System Operations".
To validate that the Identity System is working properly, you will perform tasks using the COREid System Console and applications that rely on the schema and data.
The following procedure provides steps and an outline of activities that you might perform to validate Identity System operations. Step 6 includes several suggestions about activities that you might want to perform. However, the actual tasks that you perform will depend on your environment. For example:
If you are validating an original installation, be sure to use appropriate URLs to original components.
If you are validating a cloned setup, use URLs to cloned components.
Caution:
Oracle recommends that you do not make any changes to the data during the validation process. It is vital to learn whether the upgrade was successful by validating the system with the existing data only.To validate a successfully operating Identity System
Identify the COREid System applications and functions that are affected by your upgrade and develop a plan to test these.
Ensure all COREid Server services and WebPass Web server instances are running.
Go to the COREid System Console from your browser by specifying the appropriate URL for your setup (clone versus original). For example:
http://hostname:port/identity/oblix
In the sample URL, hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /identity/oblix connects to the COREid System Console.
The COREid landing page appears.
Landing Page Does Not Appear: Ensure that your COREid Server Service and WebPass Web server instance are running and confirm that you have entered the correct URL for the COREid System Console.
Log in as a Master Administrator.
Using the COREid System Console or applications, perform the following tasks, or others, to validate that the schema upgrade was successful:
Review panels in the User Manager, Group Manager, or Organization Manager.
Verify audit policies for the User Manager, Group Manager, or Organization Manager.
Review attribute access control policies in the User Manager, Group Manager, or Organization Manager.
Review the Master Auditing Policy and the Global Auditing Policy, if appropriate.
Verify Identity Server and WebPass definitions; server settings; administrator information; and directory options.
Proceed as needed for your environment.
Successful: Proceed as needed for your environment and the next task you need to perform. For more information about the next task, see "Zero Downtime Upgrade Tasks and Sequencing".
Not Successful: Proceed to "Rolling Back After the Schema Upgrade".
You perform activities in this topic only if you have a joint Identity and Access System deployed. Otherwise, skip this topic.
To validate Access System operations, you perform tasks in the Access System Console and applications that rely on the schema and data.
If you are validating an original setup, be sure to use URLs to original components.
If you are validating a cloned setup, specify URLs to cloned components.
The following procedure provides steps and an outline of activities that you might perform to validate Access System operations. Step 6 includes several suggestions about activities that you might want to perform. However, the actual tasks that you perform will depend on your setup. For example:
Caution:
Oracle recommends that you do not make any changes to the data during the validation process. It is vital to learn whether the upgrade was successful by validating the system with the existing data only.To verify a successfully operating Access System
Identify the Access System applications and functions that might be affected and develop a plan to test these.
Ensure your Access Manager Web server and WebPass Web server instances are running.
Go to the Access System Console from your browser by specifying the appropriate URL for your environment (clone versus original). For example:
http://hostname:port/access/oblix
In the sample URL, hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.
The Access System landing page appears.
Landing Page Does Not Appear: Ensure that your Identity Server Service and WebPass Web server instance are running and confirm that you have entered the correct URL for the Access System Console.
Log in to the Access System Console as a Master Administrator.
Perform any of the following tasks, or others, to validate the upgraded schema:
Proceed as follows:
Successful: Proceed as needed for your environment and the next task you need to perform. For more information about the next task, see "Zero Downtime Upgrade Tasks and Sequencing".
Not Successful: Proceed to "Rolling Back After the Schema Upgrade".
Using this procedure will undo all changes, except the schema upgrade, so that you can return to your original setup. After performing this task you will have only the original setup and the upgraded schema.
The latest schema provides backward compatibility with your earlier schema. There are no automated tools to undo the schema upgrade. If you backed up the schema using external tools before the upgrade, you might be able to reinstate the original schema. Details about external tools are outside the scope of this manual.
To roll back after the schema upgrade
Shut down clone services and Web servers.
Remove the following from host computers:
Clone file system directories
10g (10.1.4.0.1) component libraries and files to which you applied Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Any file system directories that you have added or that were added automatically as part of any upgrade process
The Web server instance for the clones
The branches in the LDAP directory server that were added for the new configuration and policy DNs
From the original System Console, remove all clone profiles.
If you backed up the schema using external tools before the upgrade, you might be able to reinstate the original schema.
Confirm that your original setup is operating properly.
After upgrading the schema and then validating successful operations, you are ready to upgrade cloned Identity System components.
When you upgrade the clone of the first installed COREid Server, configuration data that is stored in the new branch of the LDAP directory server is also upgraded. For more information about Identity System data, see "About Configuration and Policy Data Upgrades".
The sequence of tasks that you must perform are outlined in the following topic and task overview. For more information, see individual topics for background details and step-by-step procedures that you can follow.
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.Task overview: Upgrading the cloned Identity System
Joint Identity and Access System: Turning Off the Access Server Cache Flush
Preparing Cloned Identity System Components for the Upgrade, which includes backing up configuration data before you upgrade the clone of the first installed COREid Server instance
For information about recovering if there is a problem, see "Recovering From a Cloned Identity System Upgrade Failure". For a look at what is next, see "Looking Ahead".
If you have a joint Identity and Access System deployment, before upgrading cloned components you must turn off the Access Server cache flush for each COREid Server (both clones and original COREid Servers). To do this, you locate the basedbparams.xml file in the following directory in both the original and cloned environment:
COREidServer_install_dir\identity\oblix\data\common\basedbparams.xml
and change the doAccessServerFlush parameter from true to false, as indicated in the following procedure.
To turn off the access server cache flush
Locate the basedbparams.xml file in the following file system path: \identity\oblix\data\common. For example:
clone_np\ois_01\identity\oblix\data\common\basedbparams.xml
np611\ois_01\identity\oblix\data\common\basedbparams.xml
Open the basedbparams.xml and edit the doAccessServerFlush parameter as follows:
From:
<SimpleList> <NameValPair ParamName="doAccessServerFlush" Value="true" /> </SimpleList>
To:
<SimpleList> <NameValPair ParamName="doAccessServerFlush" Value="false" /> </SimpleList>
Restart the COREid Server service (on the computer that is hosting the instance you just modified).
Repeat this procedure for each cloned (and original) COREid Server.
The procedures to prepare components for an upgrade are described in detail in Chapter 8 of this book. You must perform most of the same preparation tasks for cloned components before upgrading each clone, whether you perform a zero downtime upgrade or a in-place upgrade.
The following task overview outlines the tasks that you will be asked to perform for each clone before you upgrade it. The topics are located in Chapter 8.
Task overview: Preparing cloned Identity System components for the upgrade includes
Preparing Host Computers, which includes the following topics:
Backing Up File System Directories, Web Server Configurations, and Registry Details
Note:
With the zero downtime upgrade method, you do not need to create a backup of the file system directory. Instead, you will create a source that becomes a backup.Clone of the First Installed COREid Server: In addition to the activities in Steps 1-8, perform activities in Chapter 5, "Backing Up Existing Oracle Access Manager Data", which includes:
This topic describes all activities that must be performed to upgrade individual COREid Server clones on each computer host. At the end of this topic you will find a step-by-step procedure that walks you through all activities in detail.
Caution:
Oracle recommends that you review all information in this topic before proceeding with the activities.Before you begin upgrading the clones, take the following considerations into account:
Clone of the First Installed COREid Server: When you upgrade the clone of the first COREid Server that you installed, the configuration data in the new branch of the LDAP directory server is upgraded in addition to component-specific data.Before you start this upgrade, Oracle recommends that you back up the configuration data in the new branch of the LDAP directory server.
Enabling multi-language capability occurs only when you are starting from a release 6.1.1 environment. In this case, it occurs only when you upgrade the clone of the first installed COREid Server and configuration data and only during the incremental upgrade from release 6.1.1 to release 6.5. During this phase, the \lang directory structure is added to your destination and the \en-us subdirectory is provided. Other language subdirectories are included for each additional language that you are upgrading. For more information, see Appendix A.
All COREid Server Clones: No configuration data upgrade occurs when upgrading other COREid Server clones. However, the component-specific configuration is upgraded with each COREid Server clone upgrade. This includes registry entries for Windows, plug-ins, and component configuration files.
Windows Registry Entries: When you upgrade from an earlier release to the later release, registry entries for the originally installed release are deleted and new entries are created for the latest release. After upgrading an instance, the registry entry for the earlier release is no longer available. Oracle recommends that you back up the registry for the source before the upgrade. For more information, see "Reinstating Original Windows Registry Entries During a Rollback Operation".
Source, Destination, and Tools: You will start each upgrade by performing steps to ensure that for each cloned instance you have the 10g (10.1.4.2.0) MigrateOAM script in an appropriate location. These activities are introduced in "Preparation Tasks for the Zero Downtime Method" and are summarized as follows:
Source Creation: In the clone path, rename the subdirectory that contains the clone to create a source for the upgrade. The source also serves as a back up copy of the instance.
Destination Creation: Extract 10g (10.1.4.0.1) Identity Server libraries and files and specify the same file system directory path that the clone had before you renamed it.
Obtaining the Tools: 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 the zero downtime upgrade.
To help illustrate the activities that you will be instructed to perform, Table 16-8 organizes sample file system path names in to columns that describe the progression of actions that you will take. Additional information follows Table 16-8. The sample path names are for Windows platforms. The paths in your environment might differ.
Table 16-8 Activities to Prepare for a Clone COREid Server Instance Upgrade
| 1 Clone Path | 2 Source Creation | 3 Destination Creation and Obtaining Tools |
|---|---|---|
|
Identity Server Instances clone_np\ois_01\identity clone_np\ois_02\identity |
Rename the subdirectory that contains each clone instance. For example: clone_np\ois_01\ identity_source clone_np\ois_02\ identity_source Note: You perform this step for each clone instance |
After creating the source (see column 2): A. Extract 10g (10.1.4.0.1) Identity Server component libraries and files and specify the clone path as the installation (destination) directory. For example: clone_np\ois_01\identity Note: The destination path of the 10g (10.1.4.0.1) instance must exactly match the path of the clone before renaming (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 clone instance. |
Table 16-8 organizes information to illustrate the steps that you will be instructed to perform before you start to upgrade individual clones:
Column 1, Clone Path (left), identifies the file system path of individual cloned instances. In this example, two instances are used for load balancing purposes. This sample is on a Windows platform; your environment might be different.
Column 2, Source Creation (center), provides an example of how you will rename the subdirectory of each clone instance to create a source (which is also a backup) for the clone upgrade.
Column 3, Destination Creation and Obtaining Tools (right), outlines the steps that you must perform to create a destination for each instance upgrade and to obtain the 10g (10.1.4.2.0) MigrateOAM script.
After performing the activities outlined in Table 16-8, the 10g (10.1.4.2.0) MigrateOAM script and other files and utilities that are needed for the zero downtime upgrade will reside in the destination path of each COREid Server clone. For example:
Zero Downtime Upgrade Tools: You launch the zero downtime upgrade for each clone instance using the MigrateOAM script in the destination path. Table 16-9 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to execute the clone upgrade.
Table 16-9 MigrateOAM Script Arguments for COREid Server Clone Upgrade
| MigrateOAM Clone Mode Syntax | Values and Operations |
|---|---|
|
Change to the 10g (10.1.4.2.0) instance |
Windows: clone_np\ois_01\identity\oblix\tools\migration_tools\MigrateOAM. bat UNIX: /home/clone_np/ois_01/identity/oblix/tools/migration_tools/MigrateOAM.sh |
|
-M Clone |
Specify Clone as the mode. Clone mode is required to upgrade cloned components. |
|
-C component |
Specify OIS (Oracle Identity Server) to upgrade a cloned COREid Server. Note: Upgrade all COREid Server clones, on each computer, before upgrading any WebPass clones. |
|
-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 COREid Server directory (see column 1 of Table 16-8). For example, on a Windows platform you specify:
|
|
-D "destination directory" |
Specify the full path (in quotation marks) to the cloned 10g (10.1.4.2.0) Identity Server directory that replaced the earlier instance directory (see columns 1 and 4 of Table 16-8). For example:
|
|
-I "installation directory" |
The installation directory should be same as the destination directory. For example:
|
|
-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". |
When upgrading a cloned component, Oracle recommends that you use Automatic rather than Confirmed mode and that you do not skip any processes. The upgrade process repeats for every release between your starting release (6.1.1 for example) and the latest release. As a result, you will see the same sequence of messages and prompts for each sequence from the starting point to the conclusion. For more information, see "About Clone Mode Processing".
In the following procedure, directory path names, the starting release, and languages are provided as samples only. Your details might differ.
Caution:
If you skip any preparation activity, you might not be able to recover from an upgrade issue or roll back to the original release.To upgrade each COREid Server clone instance
Prepare All COREid Server Clones: Perform all activities outlined here (this is a repeat of the list in "Preparing Cloned Identity System Components for the Upgrade"; details are in Chapter 8):
Preparing Host Computers, which includes the following topics:
Backing Up File System Directories, Web Server Configurations, and Registry Details
Prepare the Clone of First Installed COREid Server: In addition to tasks in Step 1, perform the following activities (details are in ):
Source Creation: Rename the subdirectory that contains the clone to create a source for the upgrade. For example:
Destination Creation: In the top-level clone file system, extract 10g (10.1.4.0.1) Identity Server libraries and files and specify a destination path that exactly matches the clone path before it was renamed. For example:
Destination Path: clone_np\ois_01\identity
For extraction details, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".
Obtaining 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)".
Change to the destination_dir that contains the 10g (10.1.4.2.0) Identity Server MigrateOAM script for this upgrade. For example:
cd clone_np\ois_01\identity\oblix\tools\migration_tools\MigrateOAM.bat
Run the MigrateOAM script in Clone mode and specify your starting release and path names for the instance to be upgraded. For example:
MigrateOAM -M Clone -C OIS -F 610 -T 1014 -S "C:\clone_np\ois_01\identity_ source" -D "C:\clone_np\ois_01\identity" -I "C:\clone_np\ois_01\identity" -L "en-us"
Use Automatic mode for each sequence so that you do not need to confirm each process.
Continue as requested through all processes; do not skip any processes.
Finish according to on-screen messages.
Verify that the upgrade was successful as follows (do not restart the service):
Confirm that the value of the MigrateUserDataTo1014 is false in the globalparams.xml file in the destination_dir that you specified for the upgrade. For example:
clone_np\ois_01\identity\oblix\apps\common\bin\globalparams.xml
<NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
Auditing and Access Reporting: If your earlier installation included auditing and access reporting:
b1) Go immediately to "Upgrading Auditing and Access Reporting for the Identity System" before performing any other steps.
b2) If this is a second or subsequent COREid Server upgrade, you must also perform activities in "Renaming Audit Files After Upgrading Identity System Clones".
Start the upgraded COREid Server service to confirm that it will start (notice that the name has not changed from the one originally assigned).
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.
Check migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".
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 entryHKEY_LOCAL_MACHINE, SOFTWARE,Oblix,Oblix Netpoint. Check for the respective installed version and, under that, check the entry for ObOISServer-<Service Name>.
Verify that the version file in the destination path is updated for 10.1.4 (npversion_component.txt). For example:
clone_np\ois_01\identity\oblix\config\np1014_is.txt
Confirm that the ois_server_config.xml has the correct information for the instance that you upgraded.
Upgrade Not Successful: Proceed to "Recovering From a Cloned Identity System Upgrade Failure".
Upgrade Successful: Proceed to Step 9.
Repeat all steps in this procedure for other cloned COREid Server instances on this host.
When all cloned COREid Servers on a single host are upgraded, you can upgrade WebPass instances on the host. For more information, see "Upgrading Cloned WebPass Instances".
This topic describes how to upgrade WebPass clones. The activities that you perform when upgrading WebPass clones are similar to those that were performed when upgrading COREid Server clones. You will create a source, a destination, and obtain the tools that you need for the upgrade. You run MigrateOAM in Clone mode.
Caution:
Oracle recommends that you review all information about about upgrading clones before you begin activities here.To help illustrate some of the activities that you will perform, Table 16-10 organizes sample path names in columns that describe the progression of actions that you will take. Additional information follows Table 16-10. The sample path names are for Windows platforms. The paths in your environment might differ.
Table 16-10 Activities to Prepare for a Clone WebPass Instance Upgrade
| 1 Clone Path | 2 Source Creation | 3 Destination Creation and Obtaining Tools: |
|---|---|---|
|
WebPass Instances clone_np\webcomponent_ 01\identity clone_np\webcomponent_ 02\identity |
Rename the subdirectory containing each clone instance. For example: clone_np\webcomponent_ 01\identity_source clone_np\webcomponent_ 02\identity_source |
After creating the source (see column 2): A. Extract 10g (10.1.4.0.1) WebPass component libraries and files and specify the clone path as the installation (destination) directory. For example: clone_np\webcomponent_01\identity Note: The destination path of the 10g (10.1.4.0.1) instance must exactly match the path of the clone 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. |
For more information the source and destination creation described in Table 16-10, see "Preparation Tasks for the Zero Downtime Method".After performing activities in Table 16-10, the latest MigrateOAM script will be stored in the destination_dir. For example:
Table 16-11 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to execute the clone upgrade for each individual WebPass.
Table 16-11 MigrateOAM Script for WebPass Clone Upgrades
| MigrateOAM Clone Mode Syntax | Values and Operations |
|---|---|
|
-M Clone |
Specify Clone as the mode. The clone mode is required to upgrade cloned components. |
|
-C component |
Specify WP to upgrade a cloned WebPass. Note: Upgrade all WebPass clones, on each computer, before upgrading any Access System clones. |
|
-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 16-10). For example, when you have multiple instances:
|
|
-D "destination directory" |
Specify the full path (in quotation marks) to the cloned 10g (10.1.4.2.0) WebPass directory that replaced the earlier instance directory (see columns 1 and 4 of Table 16-10). For example:
|
|
-I "installation directory" |
The installation directory should be same as the destination directory. For example:
Note: Refer to Table 16-10 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 clone, in quotations. For example, "nsapi", "apache2", "isapi", "apache", "ihs", "ohs", "ohs2", "domino". |
WebPass clone upgrades do not affect the schema or data. Like other component upgrades, a WebPass upgrades includes component-specific configuration upgrades, parameter catalog, and message file upgrades. Like all Web compoent upgrades, WebPass upgrades includes Web server configuration changes.
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 and to ensure that you do not skip any processes.
In the following procedure, file system paths, the starting release, and languages are provided as samples only.
Caution:
When you have one Web server instance serving multiple Oracle Access Manager Web component clones, you must upgrade all serviced Web component clones before restarting the Web server.To upgrade each cloned WebPass instance
Prepare Each WebPass Clone: Perform all activities outlined here (this is a repeat of the list in "Preparing Cloned Identity System Components for the Upgrade"; details are in Chapter 8):
Preparing Host Computers, which includes the following topics:
Backing Up File System Directories, Web Server Configurations, and Registry Details
Note:
If you do not perform all preparation steps that are appropriate for this component, you might not be able to recover from a problem or to roll back after a failed upgrade.Source Creation: Rename the subdirectory that contains the WebPass clone to create a source for the upgrade. For example:
Destination Creation: In the top-level clone file system, extract 10g (10.1.4.0.1) WebPass libraries and files and specify a destination path that exactly matches the clone before you renamed it. For example:
Destination Path: clone_np\webcomponent_01\identity
For a destination path example, see column 1 of Table 16-10. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".
Obtaining 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)".
Change to the destination_dir that contains the 10g (10.1.4.2.0) MigrateOAM script for this WebPass upgrade. For example:
Run the MigrateOAM script in Clone mode and specify details for your starting release and path names for this instance. For example:
MigrateOAM -M Clone -C WP -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\ identity_source" -D "C:\clone_np\webcomponent_01\identity" -I "C:\clone_np\ webcomponent_01\identity" -L "en-us" -W "nsapi"
Use Automatic mode for each sequence so that you do not need to confirm each process.
Accept Web server configuration changes by specifying the full directory path name to the Web server configuration file for which this clone is configured.
Continue as requested through all processes; do not skip any processes.
Finish according to on-screen messages.
The destination now contains upgraded information based on the source.
Verify that the WebPass clone upgrade was successful as follows:
Apply Web server changes, if needed.
Stop, then restart the associated Identity Server service.
Note:
When you have one Web server instance servicing multiple Oracle Access Manager Web components, you must upgrade all serviced Web components before restarting the Web server. For more information, see "Web Server Support for Multiple Oracle Access Manager Releases".When all Web components on this host are upgraded, start the WebPass Web server instance.
Web Server Does Not Start: Perform the following activities:
Check event logs and the WebPass log output file. For more information about logging and log output files, see the Oracle Access Manager Identity and Common Administration Guide.
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.
Check the migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".
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.
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_wp.txt
Check the webpass.xml file to ensure that it includes the details for this instance: destination_dir\identity\oblix\apps\webpass\bin\webpass.xml.
Upgrade Not Successful: Proceed to "Recovering From a Cloned Identity System Upgrade Failure".
Upgrade Successful: Repeat this entire procedure to upgrade every cloned WebPass instance.
After upgrading all WebPass instances, proceed to "Validating the Upgraded Cloned Identity System".
After upgrading the clone Identity System, Oracle recommends that you quickly validate the following items to ensure that the upgrade was successful. If you experience an issue, refer to the troubleshooting tips in Appendix G.
Oracle recommends that you perform this task after upgrading clones, and after upgrading SDKs and Identity System customizations. For more information, see "Upgrading Identity System Customizations".
To validate your cloned Identity System upgrade
Make sure all Identity Server services and WebPass Web server instances are running.
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. For example:
Perform the same activities that you performed after upgrading the Identity System schema. For details, see "Validating Successful Operations in Your Environment".
Perform tasks in the following sections and then validate the upgraded environment again:
Proceed to "Backing Up Upgraded Identity System Clones".
Joint Identity and Access System: Only after confirming that system is operating without problem, should you proceed to "Upgrading the Cloned Access System".
No Access System: Finish all validation tests and tasks before you proceed to Chapter 17 and start upgrading original instances.
Oracle recommends that you back up the upgraded cloned Identity System after validating that it is operating properly. This will enable you to easily restore your environment to the newly upgraded state should that be needed.
To back up critical information after the upgrade
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".
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".
Windows: Back up Windows Registry data for the destination as described in "Backing Up Windows Registry Data".
Proceed to "Looking Ahead".
If a cloned Identity System component upgrade was not successful, you can perform the following steps to restore the earlier clone instance, and then try the component upgrade again. The source file system directory was not upgraded and remains intact.
If you do not want to continue with the zero downtime upgrade, see "Rolling Back After Upgrading Identity System Clones".
To recover from an unsuccessful cloned Identity System upgrade
Back up the clone source. You will retain a backup copy when you restart the clone upgrade. For example:
Remove the destination (the 10g (10.1.4.0.1) component libraries and files to which you have applied the Release 10.1.4 Patch Set 1 (10.1.4.2.0)).
Web Server: Restore the backed up Web server configuration file, if required for a cloned WebPass.
Windows: Restore (import) the backed up registry entry for the source instance.
Extract the 10g (10.1.4.0.1) component libraries and files for the instance to upgrade, and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) as described in "About Destination Creation and Obtaining Tools for a Zero Downtime Upgrade".
Restart the instance upgrade.
You can use the following procedure to roll back all changes and return to your original installation. When you finish this operation, you will have no clones in your environment and no clone entries in your System Console.
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 recover the schema is outside the scope of this manual.
To roll back after upgrading Identity System clones
Shut down clone services and Web servers.
Remove the following items from host computers:
Clone file system directories
10g (10.1.4.0.1) component libraries and files to which you applied Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Any file system directories that you have added or that were added automatically as part of any upgrade process
The Web server instance for the clones
The branches in the LDAP directory server that were added for the new configuration and policy DNs
From the original System Console, remove all clone profiles.
If you have a back up copy of the schema before the upgrade, you might be able to reinstate the original schema.
Confirm that your original setup is operating properly.
Upgraded 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 and might not work with earlier Identity System customizations. For more information about expected system behaviors and backward compatibility, see Chapter 4.
When all original Identity System components are successfully upgraded, proceed as needed based on the configuration for your earlier installation. For example:
Identity System Only: When your earlier installation does not include the Access System, you must perform activities in the sequence described in "Task overview: Remaining Identity System only upgrade activities".
Joint Identity and Access System: When your earlier installation includes the Access System and Oracle Access Manager integration connectors for certain third-party products, you must upgrade integration connectors before upgrading the SDK. In this case, perform tasks as described in "Task overview: Remaining joint Identity and Access System activities".
Note:
On Windows systems, you can choose to use only the 10g (10.1.4.3) .NET 2 SDK after upgrading and patching to 10g (10.1.4.3). In this case, you might not need to upgrade the earlier SDK. For more information, see "Platform and SDK .NET Support".Task overview: Remaining Identity System only upgrade activities
Perform tasks in "Renaming Audit Files After Upgrading Identity System Clones" as needed.
Finish by performing tasks in "Upgrading Identity System Customizations".
Perform as many tests and familiarization activities as your enterprise dictates before upgrading original instances.
After your validation period ends, proceed to Chapter 17 and upgrade original instances:
Caution:
When your earlier installation includes the Access System, you must upgrade integration connectors before upgrading independently installed SDKs. However, on Windows systems, you can choose to use only the 10g (10.1.4.3) .NET 2 SDK and in this case, you might not need to upgrade the earlier SDK. For more information, see "Platform and SDK .NET Support".Task overview: Remaining joint Identity and Access System activities
Finishing Cloned Identity System Upgrades: Proceed to the following topics in this chapter and perform tasks as directed in:
Finishing Cloned Access System Upgrades: Proceed to the following topics in this chapter and perform tasks as described in:
Perform as many tests and familiarization activities as your enterprise dictates before upgrading original instances.
After your own validation period ends, proceed to Chapter 17 and upgrade original instances.
After upgrading Identity System clones from releases earlier than 7.0, you must perform this task to correct the path name of audit files for original COREid Servers. If you have upgraded from release 7.x, you can skip this activity.
When upgrading from any release earlier than 700, the audit file name is changed by prefixing the path to the source COREid Server that was specified when using the MigrateOAM script in Clone mode. For example:
If your environment includes multiple COREid Servers, the audit file name for each will be prefixed by the same file system path as the source COREid Server from which the clone upgrade is performed. As a result, your original configuration is lost during the upgrade. For example, suppose you have two original release 611 COREid Server instances with audit files stored as follows:
In the sample path names here, the audit files might be stored in different file system paths. However, after the clone upgrade, both audit files will be stored in the path of the COREid Server that was specified as the source during the clone upgrade. For example:
To recover your audit files after upgrading the clones, you must perform the following task to change audit file paths to reflect the appropriate path to specific original COREid Server instances.
Caution:
You perform this task for all original COREid Servers only after the upgrading clones.To recover your original audit file names after upgrading Identity System clones
After upgrading the clones, go to the clone COREid System Console and log in as usual.
http://hostname:port/identity/oblix
where hostname refers to computer that hosts the Web server for the cloned WebPass; port refers to the HTTP port number of the Web server instance; and /identity/oblix connects to the COREid System Console.
From the COREid System Console, click System Configuration, and then click Identity Servers.
Select the name of an original COREid Server to display the information for this instance.
Check the Audit File Name field, to see if the path name is correct.
If the path name is correct, click Cancel and then repeat steps 3 and 4 to check the audit file path name of another instance. If the path name is not correct, proceed to Step 5.
Click the Modify button at the bottom of the page.
On the Modify page, change the path name in the Audit File Name field to the correct path for this instance and then click Save. For example:
Restart the original COREid Server whose details you just updated if it is running.
Repeat all steps in this procedure for each clone and original COREid Server instance.
Proceed to "Upgrading 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 cloned Identity System is operating properly.
The following overview describes where to locate the information for each task.
Task overview: Remaining Identity System upgrade activities
Upgrade your Identity System customizations as described in Chapter 12:
Proceed as follows:
Identity System Only: Perform tasks in "Validating Successful Operations in Your Environment" before you start upgrading originals.
Joint Identity and Access System: Go to "Upgrading the Cloned Access System".
You perform tasks in this section only if you have a joint Identity and Access System and you have completed all tasks to upgrade and validate the cloned Identity System and rename audit files. Otherwise, skip this topic and see Looking Ahead for details about how to proceed.
The tasks that you must perform are outlined in the following task overview. Individual topics are provided with background details and step-by-step procedures that you can follow.
Task overview: Upgrading the cloned Access System
For information about recovering if there is a problem, see "Recovering from a Failed Cloned Access System Component Upgrade". When you finish your preview of activities here, see "Looking Ahead" to familiarize yourself with activities that Oracle recommends you perform before upgrading the original system.
The procedures that you perform to prepare components for an upgrade are described in detail in Chapter 8. You must perform many of the same preparation tasks for cloned Access System components before upgrading each clone. Some of these tasks are similar to those that you performed when upgrading cloned Identity System components.
Upgraded Access Servers provide backward compatibility with earlier WebGates. As a result, you can delay WebGate upgrades until you upgrade the originals. You can also delay upgrading the Software Developer Kit (SDK). Items that must be handled manually can be migrated at any time. For more information about backward compatibility, see Chapter 4.
The preparation tasks that you must perform for Access System clones are outlined in the following overview. You will be instructed to perform these tasks as you upgrade each clone.
Note:
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.Task overview: Preparing cloned Access System instances for the upgrade includes
Preparing Host Computers, which includes the following topics:
Backing Up File System Directories, Web Server Configurations, and Registry Details
Note:
With the zero downtime upgrade method, you do not need to create a backup copy of the clone file system directory. Instead, you will rename the file system path to use as a source during the upgrade. The source becomes a backup that remains intact during the upgrade.Clone of the First Installed Access Manager: In addition to the activities in Steps 1-8, perform activities in Chapter 5, "Backing up Oracle Access Manager Configuration and Policy Data".
Upgrading an Access Manager cline is similar to the upgrading WebPass clones.
Caution:
Oracle recommends that you review all information in this topic before proceeding with the activities.You start by performing steps to ensure that for each cloned Access Manager instance you have the latest MigrateOAM script in an appropriate location. The following tasks are introduced in "Preparation Tasks for the Zero Downtime Method" and are summarized next:
Source Creation: Rename the subdirectory that contains the clone to create a source for the upgrade and a back up copy of the clone.
Destination Creation: Extract 10g (10.1.4.0.1) Policy Manager libraries and files and specify the specify a destination path that exactly matches the clone before you renamed it.
Obtaining the Tools: 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.
To help illustrate these tasks, Table 16-12 organizes sample file system path names in columns that describe the progression of actions that you will take. Additional information follows Table 16-12. The sample path names are for Windows platforms. The paths in your environment might differ.
Table 16-12 Activities to Prepare for a Clone Access Manager Instance Upgrade
| 1 Clone Path | 2 Source Creation | 3 Destination Creation and Obtaining Tools |
|---|---|---|
|
Access Manager Instances clone_np \webcomponent_01 \access clone_np \webcomponent_02 \access |
Rename the subdirectory containing each clone in column 1. For example: clone_np \webcomponent_01 \access_source clone_np \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 clone path before you renamed it as the installation (destination) directory. For example: clone_np\webcomponent_01\access Note: The destination path of the 10g (10.1.4.0.1) instance must exactly match the path of the clone 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 16-12, the latest MigrateOAM script will be stored in the destination path. For example:
Table 16-13 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to execute the Clone mode for each Access Manager clone upgrade.
Table 16-13 MigrateOAM Script for Access Manager Clone Upgrades
| MigrateOAM Clone Mode Syntax | Values and Operations |
|---|---|
|
-M Clone |
Specify Clone as the mode. Clone mode is required to upgrade cloned components. |
|
-C component |
Specify AM to upgrade a cloned Access Manager. Note: Upgrade all Access Manager clones, on each computer, before upgrading any Access Server clones. |
|
-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 Access Manager directory (see column 2 of Table 16-12). For example, when you have multiple instances:
|
|
-D "destination directory" |
Specify the full path (in quotation marks) to the cloned 10g (10.1.4.2.0) Access Manager directory that replaced the earlier instance (see columns 1 and 4 of Table 16-12). For example:
|
|
-I "installation directory" |
The installation directory should be same as the destination directory. For example:
Note: Refer to Table 16-12 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 clone, in quotations. For example, "nsapi", "apache2", "isapi", "apache", "ihs", "ohs", "ohs2", "domino". |
Clone of the First Installed Access Manager: When you upgrade the clone of the first Access Manager that you installed, the access policy data in the new branch of the LDAP directory server is upgraded in addition to component-specific data. Before you start this upgrade, Oracle recommends that you back up the policy data in the new branch of the LDAP directory server.
All Access Manager Clones: Upgrade processing for Access Manager clones includes Web server-related changes. Additionally, there are parameter catalogs and message files and compnent-specific changes.
When upgrading clones, you will see messages and prompts for each sequence from your starting release to the latest release.Oracle recommends that you use Automatic mode for the quickest upgrade and that you do not skip any processes.
Web Servers: When you have one Web server instance servicing multiple Oracle Access Manager Web components, you must upgrade all serviced Web components before restarting the Web server. For more information, see "Web Server Support for Multiple Oracle Access Manager Releases"
Windows Registry: Windows registry entries are updated when you upgrade the instance. Oracle recommends that you back up the registry entry for the source before you upgrade the instance. For more information, see "Reinstating Original Windows Registry Entries During a Rollback Operation".
In the following procedure, the path names, starting release, and languages are samples only. Your details will be different.
Note:
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 cloned Access Manager instances
All Access Manager Clones: Perform all activities outlined in "Preparing Cloned Access System Components for the Upgrade", which can be found in Chapter 8 and includes:
Preparing Host Computers, which includes:
Backing Up File System Directories, Web Server Configurations, and Registry Details
Note:
You do not need to create a backup copy of the clone file system directory. Instead, you will rename the path to use as a source.Clone of the First Access Manager: In addition to activities in Step 1, back up policy data in the new branch as described in "Backing up Oracle Access Manager Configuration and Policy Data".
Source Creation: Rename the subdirectory that contains the Access Manager clone to create a source for the upgrade. For example:
Destination Creation: Extract 10g (10.1.4.0.1) Policy Manager libraries and files and specify a destination path that exactly matches the clone path before it was renamed. For example:
Destination Path: clone_np\webcomponent_01\access
For a destination path example, see Table 16-12, column 1. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".
Obtaining 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)".
Change to the destination_dir that contains the 10g (10.1.4.2.0) MigrateOAM script for this Policy Manager instance. For example:
clone_np\webcomponent_01\access\oblix\tools\migration_tools\MigrateOAM. bat
Run the MigrateOAM script in clone mode and specify your starting release and path names. For example:
MigrateOAM -M Clone -C AM -F 610 -T 1014 -S "C:\clone_np\webcomponent_01\ access_source" -D "C:\clone_np\webcomponent_01\access" -I "C:\clone_np\ webcomponent_01\access" -L "en-us" -W "nsapi"
Use Automatic mode for each sequence so that you do not need to confirm each process.
Accept access policy data changes if you are asked.
Accept Web server configuration changes by specifying the full directory path to the Web server configuration file for which this clone is configured.
Continue as requested through all processes; do not skip any processes.
Finish according to on-screen messages.
When you finish, the destination directory contains the upgraded instance with configuration details based on the source.
Verify that the cloned Access Manager upgrade was successful as follows:
Apply Web server changes, if needed.
Check the migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".
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.
Stop, then restart the associated Identity Server service.
When all Web components on this host are upgraded, start the Web server instance for the cloned WebPass and Access Manager.
Note:
The Web server instance that is serving clone components must remain shut down until all serviced components are upgraded. For more information, see "Web Server Support for Multiple Oracle Access Manager Releases".Web Server Does Not Start: Perform the following activities:
Check event logs and the Access Manager log output file. For more information about logging and log output files, see the Oracle Access Manager Identity and Common Administration Guide.
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.
Upgrade Not Successful: Proceed to "Recovering from a Failed Cloned Access System Component Upgrade".
Upgrade Successful: Repeat this entire procedure to upgrade every cloned Access Manager instance on this host, and then proceed to "Upgrading Cloned Access Servers".
Upgrade all cloned Access Manager instances on all host computers.
You perform this task only if you are have a joint Identity and Access System and all earlier Access Manager clones have been upgraded.
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.Upgrading a clone Access Server is similar to the upgrading a cloned COREid Server. You start by performing steps to ensure that for each cloned Access Server instance you have the latest MigrateOAM script in an appropriate location. This involves source and destination creation and obtaining the 10g (10.1.4.2.0) tools, as sintroduced in "Preparation Tasks for the Zero Downtime Method".
To help illustrate the activities that you will be instructed to perform for each Access Server clone, Table 16-14 organizes sample file system path names in columns that describe the progression of actions that you will take. Additional information follows Table 16-14. The sample path names are for Windows platforms. The paths in your environment might differ.
Table 16-14 Activities to Prepare for a Clone Access Server Instance Upgrade
| 1: Clone Path | 2 Source Creation | 3 Destination Creation and Obtaining Tools |
|---|---|---|
|
Access Server Instances clone_np\aaa_01\ access clone_np\aaa_02\ access |
Rename the subdirectory containing each clone instance. For example: clone_np\aaa_01 access_source clone_np\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 the clone path as the installation (destination) directory. For example: clone_np\aaa_01\access Note: The path of the 10g (10.1.4.0.1) instance must exactly match the path of the clone before it was renamed (see column 1 for an example). 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 16-14, the latest MigrateOAM script will be stored in the destination_dir. For example:
Table 16-15 lists the arguments that you specify with the 10g (10.1.4.2.0) MigrateOAM script to execute the Clone upgrade mode for Access Server instances.
Table 16-15 MigrateOAM Script for Access Server Clone Upgrades
| MigrateOAM Clone Mode Syntax | Values and Operations |
|---|---|
|
-M Clone |
Specify clone as the mode. The clone mode is required to upgrade cloned components. |
|
-C component |
Specify AAA to upgrade a cloned Access Server. Note: Upgrade all Access Manager clones, on each computer, before upgrading any Access Server clones. |
|
-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 Access Manager directory (see column 2 of Table 16-14). For example, when you have multiple instances:
|
|
-D "destination directory" |
Specify the full path (in quotation marks) to the cloned 10g (10.1.4.2.0) Access Manager directory that replaced the earlier instance (see columns 1 and 4 of Table 16-14). For example:
|
|
-I "installation directory" |
The installation directory should be same as the destination directory. For example:
Note: Refer to Table 16-14 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". |
In the following procedure, directory path names, the starting release, and languages are provided as samples only. Oracle recommends that you choose Automatic mode and that you do not skip any processes.
Caution:
Oracle recommends that you review all information about about upgrading clones before you begin any of the activities in the following procedure. You will be instructed to rename the source, extract 10g (10.1.4.0.1) libraries and files, and apply patch 10g (10.1.4.2.0). It is critical that you perform all steps in sequence.To upgrade cloned Access Server instances
Perform all activities outlined in the task overview in "Preparing Cloned Access System Components for the Upgrade".
Note:
If you do not perform all preparation steps that are appropriate for this component, you might not be able to recover from a problem or to roll back after a failed upgrade.Source Creation: Rename the subdirectory that contains the Access Server clone to create a source for the upgrade. For example:
Destination Creation: Extract 10g (10.1.4.0.1) Access Server component libraries and files and specify a destination path that exactly matches the clone before it was renamed. For example:
Destination Path: clone_np\aaa_01\access
For a destination example, see Table 16-14, column 1. For more information, see "Destination Creation: Extracting 10g (10.1.4.0.1) Libraries and Files".
Obtaining 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)".
Change to the destination that contains the 10g (10.1.4.2.0) MigrateOAM script for this Access Server upgrade. For example:
cd clone_np\aaa_01\access\oblix\tools\migration_tools\MigrateOAM.bat
Run the 10g (10.1.4.2.0) MigrateOAM script in clone mode and specify your starting release and path names. For example:
MigrateOAM -M Clone -C AAA -F 610 -T 1014 -S "C:\clone_np\aaa_01\access_source" -D "C:\clone_np\aaa_01\access" -I "C:\clone_np\aaa_01\access" -L "en-us"
Use Automatic mode for each sequence so that you do not need to confirm each process.
Accept any data changes if you are asked to do so.
Continue as requested through all processes; do not skip any processes.
Finish according to on-screen messages.
The destination now contains an upgraded instance based on the source.
Auditing and Access Reporting: If your earlier installation included auditing and access reporting, go immediately to "Upgrading Auditing and Access Reporting for the Identity System" before performing any other steps.
Verify that the Access Server clone upgrade was successful as follows:
Start the Access Server service (notice that the name has not changed from the one originally assigned). For example, if you do not store the server password in the password.lst file, use the following command:
start_access_server -P mypassword port -d -t 61
Certain command options might disable the hide option and cause a password to appear in the command line.
Provide the password at the prompt, if needed.
On an IBM SecureWay LDAP directory server, the next time you start the Access Server it can take a few minutes for the dialog requesting the PEM pass phrase to appear.
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 the migration log files for any errors reported during the upgrade, as described in "Accessing Log Files".
Check the aaa_server_config.xml file to ensure that it includes the correct information for this upgraded clone.
Confirm that the value of the MigrateUserDataTo1014 is false in the globalparams.xml file for this instance. For example:
clone_np\aaa_01\access\oblix\apps\common\bin\globalparams.xml
<NameValPair ParamName="MigrateUserDataTo1014" Value="False" />
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 entry HKEY_LOCAL_MACHINE, SOFTWARE,Oblix,Oblix Netpoint. Check for the respective installed version and, under that, check the entry for ObAAAServer-<Service Name>.
Upgrade Not Successful: Proceed to "Recovering from a Failed Cloned Access System Component Upgrade".
Upgrade Successful: Repeat this entire procedure to upgrade remaining Access Server clone instances.
After upgrading all Access Server instances, proceed to "Validating the Upgraded Cloned Access System".
Oracle recommends that you validate the upgraded cloned Access System when all cloned components are upgraded. If you experience an issue, see Appendix G for troubleshooting tips.
Note:
Oracle recommends that you do not start user data migration until you have upgraded and validated all original instances.To validate your cloned Access System upgrade
Ensure that all Identity Server services and WebPass Web server instances are running, and Policy Manager Web server instances and Access Server services.
Perform the same activities that you performed after upgrading the Access System schema. For details, see "Validating Successful Operations in Your Environment".
Perform Access System customization upgrades, as described in Chapter 13.
Confirm that the upgraded Access System is operating properly with the upgraded customizations and plug-ins. For details, see "Validating Successful Operations in Your Environment".
Proceed to "Backing Up Upgraded Access System Clones".
When you are certain that your upgraded clone environment is operating properly, including your upgraded customizations, proceed to Chapter 17 and start upgrading original instances.
Oracle recommends that after validating a successful upgrade you back up critical information. This will enable you to easily restore your environment to the newly upgraded state should that be a requirement.
To back up critical information after the Access System clone upgrade
Back up all upgraded destination file system directories. This is similar to backing up an existing component installation directory. For details, see "Backing Up the Existing Component Installation Directory".
Web Server for Clones: Back up upgraded Web server configuration files using instructions from your vendor and details in"Backing Up the Existing Web Server Configuration File".
Windows: Back up Windows Registry data for the upgraded clone as described in "Backing Up Windows Registry Data".
If the cloned component upgrade was not successful, you can perform the following steps to undo a few changes, then retry the instance upgrade again.
The source file system directory is a back up copy of the cloned instance before the upgrade. The source provides information during the upgrade. The source file system directory remains intact.
If you want to remove all traces of the cloned system, see "Rolling Back After Upgrading Access System Clones".
To recover from an unsuccessful Access System clone upgrade
Back up the clone source. You will retain the backup copy when you restart the clone upgrade. For example:
Remove the 10g (10.1.4.0.1) component libraries and files to which you have applied the Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Extract the 10g (10.1.4.0.1) component libraries and files for the instance to upgrade, and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Web Server for Clones: Restore the backed up Web server configuration file, if required for a cloned WebPass.
Windows: Restore (import) the backed up registry entry for the source instance.
Restart the clone upgrade as described in this chapter.
You can use the following procedure to roll back all changes made to this point and to return to your original setup.
You cannot roll back the schema upgrade unless you used an external utility to back up the schema before upgrading the schema. Details about using external tools to back up and recover the schema is outside the scope of this manual.
To roll back after cloned Access System upgrades
Confirm that the original setup is operating properly and serving customers.
Shut down clone services and Web servers that service clones.
Remove the following items from host computers:
Clone file system directories
10g (10.1.4.0.1) component libraries and files to which you applied Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Any file system directories that you have added or that were added automatically as part of any upgrade process
The Web server instance for the clones
The branches in the LDAP directory server that were added for the new configuration and policy DNs
From the original System Console, remove all clone profiles.
If you have a back up copy of the schema before the upgrade, you might be able to reinstate the original schema using external tools.
Confirm that your original setup is operating properly.
Earlier components send and receive data in Latin-1 encoding. The ugpraded Access Server uses UTF-8 encoding and plug-in data will contain UTF-8 data. For more information about expected system behaviors, see Chapter 4.
When all earlier Access System clones are successfully upgraded, proceed as indicated in the following task overview.
Task overview: Remaining joint Identity and Access System activities include
Finishing Cloned Access System Upgrades: Proceed to the following topics::
Perform as many tests and familiarization activities as your enterprise dictates before upgrading original instances.
Oracle recommends that you upgrade any customizations and test these with the upgraded clone Access System, as described in Chapter 13. 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 SDKTask overview: Upgrading SDKs, Integration Connectors, and Access System Customizations
Perform tasks in "Validating Successful Operations in Your Environment".
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|