| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
This chapter is intended to be used by directory server administrators who are responsible for updating directory schemas and data. This chapter focuses on upgrading the Oracle Access Manager (formerly known as Oblix NetPoint or Oracle COREid) Identity System schema and data using the in-place method. The following topics are provided:
Upgrading the Schema and Data In Place with the Master Identity Server
Recovering From an Identity System Schema or Data Upgrade Failure
Note:
If you are using the zero downtime method, skip this chapter and see Part VI. If your starting Oracle Access Manager release is earlier than 6.1.1, contact Oracle Support before upgrading:
http://www.oracle.com/support/contact.htmlFigure 6-1 illustrates the tasks you must perform to complete the Identity System schema and data upgrade. Additional notes follow the figure. You will see references to the Identity Server (formerly known as the NetPoint or COREid Server). Refer to your own planning summaries and use the tracking summaries in Appendix F to check your progress.
Figure 6-1 Identity System Schema and Date Upgrade Task
Task overview: Upgrading the Identity System schema and data
Complete all prerequisite tasks outlined in "Master Identity System Schema and Data Upgrade Prerequisites".
Upgrade the newly added master Identity Server and accept the automatic schema and data upgrade as explained in .
Note:
Problems During the Upgrade: Review any recovery details that are present in the procedure and look for specific troubleshooting tips in Appendix G.Upgrade the master WebPass you added, as discussed in "Upgrading the Master WebPass"
Confirm the upgrade was successful, as described in "Verifying the Identity System Schema and Data Upgrade".
Upgrade Successful: Perform remaining activities in the following sequence:
Upgrade Not Successful: Proceed to "Recovering From an Identity System Schema or Data Upgrade Failure".
Summaries that can help you track the completion of upgrade tasks in your environment are provided in Appendix F.
In this task, you will use the 10g (10.1.4.0.1) Identity Server installer to upgrade the earlier COREid Server instance that you added as a master for this purpose. After launching the 10g (10.1.4.0.1) Identity Server installer, the sequence of events and questions to which you must respond are directed by the program.
Figure 6-2 illustrates the program-driven process and decision points where you are asked to provide specific responses to continue. Each box in the diagram points to a similarly named discussion that guides you through the procedure. You must complete all procedures for a successful upgrade.
Figure 6-2 Identity System Schema and Data Upgrade Process
Task overview: Upgrading the schema and data with the master Identity Server includes
Starting the Master Identity Server Upgrade describes how to launch the upgrade using your preferred method (GUI or Console).
Specifying the Target Directory and Languages describes how you indicate the directory where the existing component is installed as well as any languages to upgrade.
Updating the Identity System Schema and Data describes how to accept the automatic schema and data upgrade.
Oracle recommends that you accept the automatic schema and data upgrade for the master Identity Server.
Note:
With ADAM you must manually upgrade the schema; however, the data upgrade is automatic. For more information, see "Active Directory Application Mode Considerations and Preparation".Later, when upgrading remaining COREid Servers, the upgraded schema and data are detected automatically; related messages and events are suppressed.
Enabling Multi-Language Capability describes the automated process that occurs only when you upgrade a release 6.1.1 master COREid Server.
Note:
Enabling multi-language capability is automatically skipped if your starting release is 6.5 or 7.x.Upgrading Identity Server Configuration Files describes how to apply changes to the component-specific configuration files.
Upgrading the Software Developer Kit (SDK) Configuration shows how to accept or decline the SDK configuration changes.
Note:
If this master COREid Server does not have caching configured, you can decline the automatic SDK configuration upgrade.Finishing and Verifying the Master COREid Server Upgrade describes critical actions that you need to take to determine the success of the upgrade.
Before you begin upgrading the schema and data with the master Identity Server, ensure that you have completed the tasks in Table 6-1. Failure to complete prerequisites might adversely affect your upgrade.
Table 6-1 Schema and Data Upgrade Prerequisites
| Schema and Data Upgrade Prerequisites |
|---|
|
Perform all required schema and data preparation steps in Chapter 5.
|
|
Familiarize yourself with information in the introductory chapters in Part I |
This manual uses the GUI method and Automatic mode to illustrate the sequence of events, sample responses, and messages you might see. In this manual, differences are noted as needed. Even in Automatic mode, you are required to respond to questions about the schema and data upgrade.
If a step does not relate to your environment, you can ignore it. For example, if you have a Windows environment, ignore steps for Unix and vice versa:
Windows: If you are logged in with administrator rights, click Next.
Unix: Specify the username and group that the component will use, then click Next.
The sample upgrade explained in the following procedure starts from a release 6.1.1 installation and includes enabling a multi-language environment.
Note:
If errors are reported during the process, check the named log file and look for specific troubleshooting details in Appendix G.To start the master Identity Server upgrade
Ensure that all prerequisites are completed as described in "Master Identity System Schema and Data Upgrade Prerequisites".
Turn off the master COREid Server service and log in as a user with the appropriate administrator privileges to update the schema and Oracle Access Manager files.
Launch the 10g (10.1.4.0.1) Identity Server installer as usual. For example:
GUI Method, Windows: Oracle_Access_Manager10_1_4_0_1_win32_Identity_Server.exe
Console Method, Solaris: ./Oracle_Access_Manager10_1_4_0_1_sparc-s2_Identity_Server
The Welcome screen appears.
Dismiss the Welcome screen by clicking Next.
Respond to the administrator question based upon your platform. For example:
Windows: If you are logged in with administrator rights, click Next (otherwise click Cancel, log in as a user with administrator privileges, then restart the installation).
Unix: Specify the username and group that the Identity Server will use, then click Next. Typically, the defaults are "nobody."
Proceed as described in "Specifying the Target Directory and Languages" next.
In this sequence, you must specify the same target directory for the upgrade as the master COREid Server you just installed. When the earlier component is detected, you are asked if you want to upgrade. When you accept the upgrade, the target directory is created and 10g (10.1.4.0.1) files are extracted into it.
After the target directory is created, you are asked to select the languages to upgrade. Unless you have 10g (10.1.4.0.1) Language Packs stored in the same directory as the 10g (10.1.4.0.1) Identity Server installer, only English is upgraded. After upgrading, you can install languages as described in the Oracle Access Manager Installation Guide. You configure Oracle Access Manager to use installed languages as described in the Oracle Access Manager Identity and Common Administration Guide.
Unless indicated in the steps in the following procedure, the questions that you see and must respond to are the same regardless of the installation method (GUI versus Console) and mode (Automatic versus Confirmed) that you choose.
To specify the target directory and languages
Choose the same installation directory as the master COREid Server you installed and set up, then click Next.
Accept the upgrade by clicking Yes, then click Next.
If asked, ensure that a check mark appears beside English and any other languages you are upgrading, then click Next.
You might be presented with a list of languages that will be upgraded.
Confirm the languages selected by clicking Next.
The next screen tells you that the existing installation has been saved and provides the name of the renamed, time-stamped source directory that contains all files from the previous installation.
Record the time-stamped directory name and continue the upgrade as instructed.
A new screen confirms the installation directory for 10g (10.1.4.0.1) and tells you how much space is needed for the installation.
Start the file extraction into the target directory.
A status bar indicates the progress of the file extraction.
Press Enter to continue.
Enter
You are asked to specify a mode for the upgrade process: Automatic or Confirmed.
Note:
If you are upgrading using the Console method, you are asked to run the command displayed in the transcript. On Unix, the command is printed to a file (start_migration), and a message is printed to run this file.-------------------------------------
Please specify the mode for migration:
'1' - Automatic (recommended)
Each step is performed automatically.
No interaction from the user is required.
'2' - Confirmed
Each step needs confirmation from the user.
Enter choice ( '1' or '2' ) : 1
--------------------------------------------
Enter the number that corresponds to the upgrade mode you prefer: For example:
Automatic (recommended): Enter the number 1 to observe as the process completes automatically and respond to a few specific questions when needed.
Confirmed: Enter the number 2 to receive a prompt that you must respond to before each activity.
The declarative messages in this guide are based on Automatic mode. In this case, you are informed as folders are created, files are copied, and catalogs are upgraded. For example:
Creating original folders ... ---------------------------------------------------- Copying general configuration files OK. ---------------------------------------------------- Updating parameter catalogs ... OK. ----------------------------------------------------
When the upgrade program connects with the directory server, a transcript appears as shown next.
Starting migration (6.1.1 -> 6.5.0) ---------------------------------------------------- Oracle Access Manager schema migration ... ----------------------------------------------------
Regardless of the mode you have chosen, continue with "Updating the Identity System Schema and Data", next.
Oracle recommends that you upgrade the schema and data automatically. Aside from the instructions related to specific directory servers, the upgrade transcript is similar regardless of the from and to versions or the directory server type.
Unless you are upgrading from Oracle Access Manager 7.0, some portions of the transcript will repeat during the component-specific upgrade sequence. For example if you are upgrading from release 6.1.1, a portion of the dialog will appear once during the upgrade to release 6.5, then repeat during the upgrade to release 7, then repeat again during the upgrade to release 10g (10.1.4.0.1).
Note:
All schema modifications can be applied to only a master Read/Write directory instance (not against a read-only replica, if any). For more information, see "Strategies for Upgrading in a Replicated Environment".The following steps presume that you have chosen Automatic mode. Even so, you will be asked to respond to certain questions.
To upgrade the schema and data
Review the information about the schema upgrade and note the from and to versions. For example:
Oracle Access Manager schema migration ...
Retrieving Oracle configuration parameters ...
OK.
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'Yes" to proceed:
Note:
You are asked if you want to migrate (upgrade) the schema. Do not skip this activity. With ADAM, automatic schema updates are not supported. See "Active Directory Application Mode Considerations and Preparation".At the prompt, type the full word "yes" to load the schema.
yes
The program updates the schema, while the transcript keeps you informed:
Updating schema. Please wait ...
OK.
-------------------------------------------------
During this step, configuration data is also retrieved, parameters are upgraded, and you are informed in the transcript.
Note:
You are asked if you want to migrate (upgrade) the data. Do not skip this activity.At the prompt, type the full word "yes" to load the data.
yes
The program converts configuration data, removes older configuration data that is no longer needed, imports new configuration parameters, and so on, while the transcript keeps you informed.
Continue as instructed, and proceed to "Enabling Multi-Language Capability".
If your starting release is 6.5 or later, this process does not occur and you can skip this discussion. releases 6.5 and 7.x automatically support a multi-language environment. As a result, when you start upgrading from release 6.5 or 7.x, this event is skipped automatically.
Enabling multi-language capability occurs only during the incremental upgrade of the schema and configuration data from release 6.1.1 to release 6.5. During this phase, the \lang directory structure is included in your upgraded environment 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.
The following sample shows the messages that keep you informed, and actions you need to take, during the multiple language enabling sequence. In Automatic mode, the only input required from you is acknowledgment of the events.
To respond during the multi-language sequence
Read the messages on language upgrades.
For example:
-------------------------------------
Oracle Access Manager language migration....
Retrieving Oracle configuration parameters...
OK.
Support for multiple languages is not enabled.
Performing language migration...
Updating language migration parameters...
OK.
The following directory server's data will be updated to
support multiple languages:
Host:DNShostname.domain.com
Port: port#
Type:ns
The default language (detected from your existing installation) is: en-us
Press <Enter> to continue
Press the Enter key to continue:
ENTER
The transcript now describes that data is converted for enabling multiple languages and that new language migration data is being imported.
At the prompt following successful language migration, press the Enter key to continue:
ENTER
Each component upgrade includes a sequence of events that upgrade the component configuration files. Depending on your starting release, aspects of the sequence might repeat to bring the earlier release up to 10g (10.1.4.0.1) incrementally. For example, if your starting release is 6.1.1 the schema and data are upgraded with component configuration data for release 6.5. During the component sequence in the next procedure, the schema and data are upgraded again for release 7.0, then again for 10g (10.1.4.0.1).
In Automatic mode, you must type the full word "yes" or press the Enter key when asked to continue the upgrade through each sequence of events.
Note:
Your environment might vary. If interim schema and data upgrade messages appear, respond to continue. Do not skip any events. However, if interim schema upgrade messages do not appear, skip to step 5.To accept the Identity Server configuration file changes
Read the messages regarding the component upgrade. For example:
Updating component-specific configuration ... OK.
Starting migration ( 6.5.0 -> 7.0.0 )...
-------------------------------------
Oracle Access Manager schema migration....
Retrieving Oracle configuration parameters...
OK.
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'yes' to proceed:
If Interim Schema Upgrade Messages Appear: Type the full word "yes," when asked on the screen, then review the next set of messages and proceed with step 3.
yes
Updating schema. Please wait...
OK.
Retrieving User configuration parameters...
OK.
-------------------------------------
Oracle Access Manager data migration....
Retrieving Oracle configuration parameters...
OK.
Could not detect the language for your installation!
Checking product version...
Version not up to date. Performing Configuration data migration...
Updating Oracle migration parameters...
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'yes' to proceed:
Respond when requested to continue and review messages to track the process. For example:
OK.
Converting Configuration data. Please wait...
..........................
OK.
Removing old Configuration data. Please wait...
..........................
.......................... ............
OK.
Cleaning up obsolete schema from the directory.
Deleting obsolete schema for osd. Please wait...
Importing new Configuration data. Please wait ...
OK.
-------------------------------------
Oracle Access Manager data migration has completed successfully!
Press <ENTER> to continue :
Enter
Updating component-specific configuration files.
Review messages for the upgrade from release 7.x to 10g (10.1.4.0.1). For example:
Starting migration ( 7.0.0 -> 10.1.4 )...
-------------------------------------
Oracle Access Manager schema migration....
Retrieving Oracle configuration parameters...
OK.
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'yes' to proceed:
Continue as directed. For example:
yes
The final sequence you see during the upgrade from release 7.x through to 10g (10.1.4.0.1) is shown next. Again, you are required to type the full word "yes" or press the Enter key when asked to continue. For example:
Updating schema. Please wait...
OK.
Retrieving User configuration parameters...
OK.
-------------------------------------
Oracle Access Manager data migration....
Retrieving Oracle configuration parameters...
OK.
Could not detect the language for your installation!
Checking product version...
Version not up to date. Performing Configuration data migration...
Updating Oracle migration parameters...
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'yes' to proceed:
yes
Review messages as the process continues. For example:
OK.
Converting Configuration data. Please wait...
..........................
OK.
Removing old Configuration data. Please wait...
..........................
..........................
OK.
Importing new Configuration data. Please wait ...
OK.
-------------------------------------
Oracle Access Manager data migration has completed successfully!
Press <ENTER> to continue :
Continue when asked and review the final message. For example:
Enter
Updating component-specific configuration files...
OK.
Migration has completed successfully!
Press <ENTER> to continue :
-----------------------+++++++++++++--------------
Proceed with "Upgrading the Software Developer Kit (SDK) Configuration" next.
This event can be skipped when you are upgrading a master COREid Server that has not been configured to use the SDK. However, if the SDK was configured for this COREid Server, Oracle recommends that you upgrade the configuration now to preserve current settings.
Note:
If you do not upgrade current SDK configuration settings, these are not preserved and you must reconfigure them later using the configureAccessGate tool. See the Oracle Access Manager Identity and Common Administration Guide.To skip the SDK upgrade for the master COREid Server instance
Enter the appropriate number to respond to the question (about migrating the SDK), based on this instance in your environment.
This component has the Access Server SDK installed
Would you like to automatically migrate the SDK at this time?
Note: If you do not want to migrate the SDK at this time, you will
need to reconfigure the SDK after migration has finished
by running the 'configureAccessGate' program
'1' - Yes
'2' - No
Enter choice ( '1' or '2' ) :
2
Press Enter to continue when asked. For example:
Enter
Go to "Finishing and Verifying the Master COREid Server Upgrade".
You complete this procedure to finish the upgrade of the master COREid Server and the Identity System schema and data.
To finish the master COREid Server upgrade
Start the COREid Server service to confirm that it will start (notice that the name has not changed from the one originally assigned).
COREid Server Service Does Not Start: See troubleshooting tips in Appendix G.
Check the migration log files for any errors reported during the schema or data upgrade. See "Accessing Log Files".
Upgrade Not Successful: Proceed to "Recovering From an Identity System Schema or Data Upgrade Failure".
Upgrade Successful: Proceed with "Upgrading the Master WebPass" next.
Note:
The new product term for COREid Server is Identity Server, which will be used in the remainder of this guide. For more information, see "Product and Component Name Changes".After upgrading the master Identity Server, you must upgrade the master WebPass instance. There is no WebPass connection to a directory server. Therefore, there is no schema or data upgrade during a WebPass upgrade.
When upgrading WebPass (and other Oracle Access Manager Web components), the component-specific upgrade includes both Web component and Web server configuration file updates. There are no differences between upgrading the master WebPass now and upgrading subsequent WebPass instances later on.
Figure 6-3 illustrates the program-driven WebPass upgrade process and the points at which you need to provide specific input or acknowledge events. Additional comments follow the figure.
Figure 6-3 Master WebPass Upgrade Process
Task overview: Upgrading master WebPass includes
Starting the Master WebPass Upgrade, Specifying a Target Directory and Languages
Upgrading WebPass Configuration Files and Web Server Configuration
Again, unless you are upgrading from release 7, certain processes repeat automatically for each major release until you reach 10g (10.1.4.0.1).
Before you begin upgrading the master WebPass instance, check Table 6-2 to ensure you have completed all tasks. Failure to complete prerequisites can adversely affect your upgrade.
Table 6-2 WebPass Upgrade Prerequisites
| WebPass Upgrade Prerequisites |
|---|
|
Upgrade the master Identity Server as described in "Upgrading the Schema and Data In Place with the Master Identity Server". |
|
Complete all component preparation activities in Chapter 8 for this WebPass instance, and:
|
The sample upgrade described here starts from release 6.1.1 using the GUI method and Automatic mode. The sequence of events and messages directed by the program require very little input from you. Much of this is similar to upgrading the master Identity Server. The target directory for the 10g (10.1.4.0.1) master WebPass upgrade must be the same as the earlier component.
Note:
If errors are reported at any time during the process, check the named log file. See "Accessing Log Files".To start the master WebPass upgrade
Ensure that all prerequisites are completed as described in "Master WebPass Upgrade Prerequisites".
Turn off this WebPass Web server instance.
Log in as a user with the administrator privileges to update the WebPass and Web server configuration.
Locate and launch the 10g (10.1.4.0.1) WebPass installer for your Web server. For example:
GUI Method Windows: Oracle_Access_Manager10_1_4_0_1_win32_NSAPI_WebPass.exe
Console Method Solaris: ./Oracle_Access_Manager10_1_4_0_1_sparc-s2_NSAPI_WebPass
The Welcome screen appears.
Dismiss the Welcome screen, then respond when asked about your administrator rights.
Choose the directory that contains the earlier WebPass instance.
Accept the upgrade when asked.
Ensure that a check mark appears beside English and any other languages you want to upgrade, then continue.
You might be presented with a list of languages that will be upgraded or added.
Confirm the languages listed by clicking Next.
Record the name of the time-stamped directory, then continue.
Start the file extraction.
A status bar indicates the progress of the file extraction.
With the GUI method, a new window appears asking you to specify either Automatic or Confirmed mode for the upgrade. Using the Console method, you are asked to run the command displayed in the transcript, then continue as instructed.
Here you specify the mode to use (Oracle recommends Automatic). For brevity, steps are provided with little explanatory text.
To upgrade the WebPass and Web server configuration
Enter the number that corresponds to the mode you prefer and follow the dialog on screen. For example:
1
Creating orig folders ... ---------------------------------------------------- Copying general configuration files ... OK. ---------------------------------------------------- Updating parameter catalogs ... OK. ---------------------------------------------------- Starting migration (6.1.1 -> 6.5.0) ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting migration ( 6.5.0 -> 7.0.0 )... ------------------------------------- Updating web server configuration files... OK. ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting migration (7.0.0 -> 10.1.4) ------------------------------------- Updating web server configuration files... OK. ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Migration has completed successfully! Press <ENTER> to continue :
Press the Enter Key.
Enter If the Access System is also configured, you need to create a DB Profile manually after first WebPass component upgrade is completed and before upgrading the first Policy Manager. The profile gives the Access Server write permission to Policy data in the directory server and will be used while upgrading the WebGate component. The profile can be deleted after all the WebGates are successfully upgraded. Directory permissions copied ... C:\NetPoint\WebComponent\identity_20060223_180406\oblix) C:\NetPoint\WebComponent\identity\oblix) --------------------------------------------------- Migration has completed successfully! Press <ENTER> to continue.
Conclude the master WebPass upgrade and proceed to the next discussion, "Finishing and Verifying the Master WebPass Upgrade".
Note:
If you have a joint deployment that includes the Access System, you create a temporary directory profile after finishing all activities in this chapter and after upgrading the Access System schema and data with the master Access Manager component upgrade. Details are provided in the next chapter.You finish this master WebPass upgrade as described in the following procedure.
To finish the master WebPass upgrade
Apply Web server changes, if needed.
Stop, then restart Identity Server service.
Start the WebPass Web server instance.
Web Server Does Not Start: See troubleshooting tips in Appendix G.
Check the migration log files for any errors reported during the master WebPass upgrade. See "Accessing Log Files".
Upgrade Successful: Proceed with "Verifying the Identity System Schema and Data Upgrade" next.
Upgrade Not Successful: Proceed to "Recovering From an Identity System Schema or Data Upgrade Failure".
You complete this task to confirm that the Identity System upgrade has been successful.
To verify the schema and data upgrade
Check to ensure that the schema contains 10g (10.1.4.0.1) attributes obPolicyEnabled and objectclass oblixLPMPolicy.
View the configuration node in the configuration directory server and confirm that the value of the obver attribute is 10.1.4.0.
Upgrade Successful: Perform the tasks in the following list, as described in:
Upgrade Not Successful: Proceed to "Recovering From an Identity System Schema or Data Upgrade Failure".
During the master Identity Server (and master Access Manager if you have the Access System installed) upgrade, schema files that include only changes from one release to the next are used to upgrade the existing schema. As a result, the schema and data upgrade repeats for each major product release (for example, from release 6.1.1 to release 6.5, from release 6.5 to release 7.x, and from release 7.x to release 10g (10.1.4.0.1)).
For many directory servers, the indexes are automatically updated during the schema and data upgrade. However, when your Oracle Access Manager deployment includes Sun (formerly iPlanet) directory, Novell eDirectory (NDS), and Oracle Internet Directory, you must manually update the directory index files after upgrading the master Identity Server (and master Policy Manager), you need to update the directory index files. The files you use to perform this task are stored in:
IdentityServer_install_dir/identity/oblix/data.ldap/common
PolicyManager_install_dir/access/oblix/data.ldap/common
Two index files are provided for each directory server upgrade: the Sun (formerly iPlanet) directory, Novell eDirectory (NDS), and Oracle Internet Directory. One file contains the complete set of 10g (10.1.4.0.1) attributes for the user data index and the other contains the complete set of 10g (10.1.4.0.1) attributes for the Oracle Access Manager configuration and policy data index, respectively:
iPlanet5_user_index_add.ldif and iPlanet5_oblix_index_add.ldif
NDS_user_index_add.ldif and NDS_oblix_index_add.ldif
OID_user_index_add.ldif and OID_oblix_schema_index_add.ldif
If policy data is stored on the same directory instance as user data, the _oblix_index_add.ldif is added once after first Identity Server upgrade only. However, if the policy data is stored on a different directory instance, you must upload the oblix_index_add.ldif file after both the first (Master) Identity Server upgrade and after the first (Master) Policy Manager upgrade.
Note:
In addition to uploading the index files mentioned earlier for your specific directory server, you will also need to manually add an index for theobpolicykeyword attribute after the master Policy Manager (formerly known as the Access Manager component) upgrade (if you have Access System configured). The obpolicykeyword attribute is currently missing from all 10g (10.1.4.0.1) index ldif files and cannot be added automatically during the master Policy Manager upgrade.Table 6-3 provides a list of the specific attributes to which indexes might need to be manually applied after schema and data upgrades. These apply to all directory servers except Oracle Internet Directory. As mentioned earlier, for most directories the indexes are automatically updated during the schema and data upgrade. However, for Sun, Novell eDirectory, and Oracle Internet Directory you must manually upload directory index files, as described in this chapter.
Table 6-3 Indexed Attributes for All Directories Except Oracle Internet Directory
| Specific Attributes |
|---|
|
obactionname |
|
obactordn |
|
obapp |
|
obattr |
|
obclass |
|
obdatecreated |
|
obdateprocessed |
|
obdirectreports |
|
obentrycondition |
|
obgroupadministrator |
|
obgroupcreator |
|
obgroupdynamicfilter |
|
obgroupexpandeddynamic |
|
obgrouppuredynamic |
|
obgroupsubscribemessage |
|
obgroupsubscribenotification |
|
obgroupsubscriptionfilter |
|
obgroupsubscriptiontype |
|
obgroupunsubscribemessage |
|
obid |
|
obindirectmanager |
|
oblocationdn |
|
oblocationname |
|
oblocationtitle |
|
oblockedby |
|
obname |
|
obobjectclass |
|
obpaneltype |
|
obparentlocationdn |
|
obparentstep |
|
obparentworkflow |
|
obparticipant |
|
obpasswordpolicyid |
|
obpolicyconditiongroupStr |
|
obpolicyconditionuidStr |
|
obready |
|
obrectangle |
|
obresourceattribute |
|
obresourceoperation |
|
obresourcetype |
|
obresourceuidStr |
|
obretrycount |
|
obtargetdn |
|
obuniquememberStr |
|
obuseraccountcontrol |
|
obwfinstanceid |
|
obwfstatus |
|
obwfstepid |
|
obwfstepinstid |
|
obwftypename |
|
obworkflowname |
|
obworkflowtype |
|
obwftargetlabel |
|
obworkflowdn |
|
obworkflowstepdn |
|
obisworkflowprovisioned |
|
obdynamicparticipantsset |
|
obLPMName |
|
oburlprefix |
|
obSiteDomainID |
|
obHostContext |
|
obdescription |
|
obpolicyKeyword |
The steps you must complete to update the indexes depend on your directory server type, as described in:
Note:
If you do not upload the indexes for iPlanet and NDS directories, the product will work. However, searching will be inefficient and impact performance. If you do not upload the indexes for Oracle Internet Directory, users will not be able to log in.The goal here is to obtain the newly introduced indexes associated with 10g (10.1.4.0.1) attributes and ignore any earlier indexes that might be present. If you see errors this is because your environment might already include existing indexes that belong to an earlier release. You can use the Continuous Mode option to continue adding new 10g (10.1.4.0.1) attributes in the event that one or more attributes were found to be indexed in an earlier release
To upload the Sun (formerly iPlanet) or Oracle Internet Directory index files
Oracle Internet Directory: Manually execute directory-specific commands or the directory Administrator Interface to confirm that the indexes have been added using information in the Oracle Access Manager Schema Description as a guide.
Sun (formerly iPlanet): Manually execute directory-specific commands or the directory Administrator Interface to confirm that the indexes have been added using Table 6-3 as a guide.
Locate the appropriate files for your directory server. For example:
Run the ldapmodify command (or use any import tool provided by your directory vendor) and use the Continuous Mode option to avoid any errors that can result when an earlier indexed attribute is found. For example
\IdentityServer_install_dir\identity\oblix\tools\ldap_tools\ldapmodify run ldapmodify.exe –h DS_hostname -p DS_port_number -D bind_dn -w password -f OID_user_index_add.ldif -a -e reject_filename -c
Repeat step 2 using the directory_oblix_schema_index_add.ldif for your specific directory.
When finished, proceed to "Backing Up Upgraded Identity Data".
When you have Novell eDirectory, the goal is to obtain the newly introduced indexes associated with 10g (10.1.4.0.1) attributes and ignore any earlier indexes that might be present. However, in this case, you cannot use the Continuous Mode option.
To confirm or update indexes for Novell eDirectory
Manually execute NDS-specific commands or the NDS Administrator Interface to confirm that the indexes have been added using Table 6-3 as a guide.
If needed, manually execute NDS-specific commands or the NDS Administrator Interface to upload the indexes.
Manually index the obpolicykeyword attribute using the appropriate NDS-specific commands or the NDS Administrator Interface.
When finished, proceed to "Backing Up Upgraded Identity Data".
After upgrading the schema and data from releases earlier than 7.0, you must perform this task to correct the path name of audit files. If you have upgraded from release 7.x, you can skip this activity.
Caution:
If you are performing a zero downtime upgrade, see Chapter 15.When upgrading the master Identity Server and the schema and data from any release earlier than 700, the audit file name is changed by prefixing the path to the master Identity Server.
If your deployment includes multiple Identity Servers, the audit file name for each will be prefixed by the same installation directory path as the Identity Server from which the data upgrade is performed. The result is that your original configuration is lost during the Identity Server upgrade. For example, suppose you have two release 611 Identity Server instances with audit files stored as follows:
In the sample path names shown here, the audit files can be stored in different directory paths.
After the upgrade, however, both audit files will be stored in the directory path of the Identity Server that was used with the schema and data upgrade. For example:
To recover your audit files after upgrading multiple Identity Servers, you must perform the following task to change audit file paths to reflect the appropriate path to specific Identity Server instances. If you are performing a zero downtime upgrade, you perform this task only for clones.
To recover your original audit file names after upgrading Identity Servers
After upgrading the schema and data, go to the Identity System Console and log in as usual.
http://hostname:port/identity/oblix
where hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; and /identity/oblix connects to the Identity System Console.
From the Identity System Console, click System Configuration, then click Identity Servers.
Select the name of an Identity 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 Identity Server whose details you just updated if it is running.
Repeat all steps in this procedure for each Identity Server instances.
After you finish the schema and data upgrade, Oracle recommends that you back up the 10g (10.1.4.0.1) component directory and directory server instances. 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 upgrade
Back up the 10g (10.1.4.0.1) Identity Server directory and store it in a new location.
Back up upgraded directory server instances using your directory vendor documentation as a guide.
Back up Identity System data as described in"Backing Up Existing Oracle Access Manager Data" .
Windows: Back up the upgraded registry for the component as described in "Backing Up Windows Registry Data".
WebPass Web Server: Back up the upgraded Web server configuration file using your vendor documentation as a guide.
Proceed to "Looking Ahead".
You perform Phase 2 for an in-place upgrade only, after completing all other activities in this chapter. You can skip this if Phase 1 was not performed before the upgrade; however, a roll back operation cannot revert migrated user data. For more information, see Chapter 5.
Note:
If you are performing an upgrade using the zero downtime method, you can skip this activity.This discussion provides the information you need to perform Phase 2 of the procedure to halt immediate (also known as on-the-fly) migration of user data (multiple values in challenge and response attributes for Lost Password Management only) at first login.
Note:
You must perform Phase 2 now, after upgrading the schema and data and before any administrator or user login, even if you have a joint Identity and Access System deployment.During Phase 1, the obVer attribute for the Master Administrator entry was set before the schema and data upgrade as described in Chapter 5. During Phase 2 you must reset the obVer value for the configuration base to 7.0.4 and remove the Challenge and Response semantic types at both the tab level and the object class level.
When you finish this Phase 2 procedure, Oracle recommends that you stop processing or performing the following actions to ensure that user data will maintain its backward compatibility:
Stop processing workflow tickets: for example, create user, change attributes, and the like.
Stop modifying challenge and response attributes from the Modify Profile page.
To temporarily stop the immediate migration of user data (Phase 2)
After upgrading the schema and data, change the value of obVer in the configuration base to 7.0.4 as follows:
ldapmodify.exe -h <Host> \ -p <Port> -D <Bind DN> -w <Bind Password> \ -f <ldif file containing attribute to be modified>
A bind DN for configuration data (also known as the configuration DN) is similar to the searchbase for user data. The configuration bind DN must be specified to identify the node in the DIT under which the Oracle Access Manager schema and all configuration data is stored for the Identity and Access Systems.
The format of LDIF file to be created is as follows. This example is for the Netscape Directory Server:
dn: o=oblix,<configuration DN>
changetype: modify
replace: obver
obver: 7.0.4
Restart the master Identity Server.
Go to the Identity System Console by specifying the URL for your environment, and then log in as the Master Administrator. For example:
http://hostname:port/identity/oblix
In the URL example, hostname refers to computer that hosts the WebPass Web server; port refers to the HTTP port number of the WebPass Web server instance; /identity/oblix connects to the Identity System Console (formerly known as the COREid System Console).
Tab Level: Disable the Challenge and Response semantic types at the tab level, as follows:
Click Identity System Console, click User Manager Configuration, and then click Tabs.
From the Existing Tabs listed on the page, select Employees to display information about this Person class tab on the View Tab page.
Note:
Object Classes on the View Tab page might include OblixOrgPerson and others (gensiteorgperson, for example). The obVer attribute is a member of only the OblixOrgPerson class. There is no impact to other object classes.On the View Tab page, click Modify Attributes to open the Modify Attributes page.
From the Attribute list select the attribute that is configured with Challenge as the Semantic Type, set the Semantic Type to None and click Save.
From the Attribute list select the attribute that is configured with Response as the Semantic Type, set the Semantic Type to None and click Save.
Click Done.
Object Class Level: Remove the Challenge and Response semantic types at the object class level, as follows:
Click Identity System Console, click Common Configuration, and then click Object Classes.
Select the person object class from the list, then click Modify Attributes to open the Modify Attributes page.
From the Attribute list select the attribute that is configured with Challenge as the Semantic Type, set the Semantic Type to None and click Save.
From the Attribute list select the attribute that is configured with Response as the Semantic Type, set the Semantic Type to None and click Save.
Click Done.
Proceed to "Looking Ahead".
For details about restarting user data migration after validating that your deployment is successfully upgraded, see "Restarting On-the-fly User Data Migration for In-place Upgrades".
If the schema and data upgrade was not successful, you can perform the following steps to rollback this upgrade, then try again.
Note:
Step 4 is only for WebPass. If only your master WebPass upgrade failed, skip step 1 in the procedure here and complete step 4.To recover from an unsuccessful schema and data upgrade
Restore the directory instance that you backed up before the upgrade to recover the earlier schema and data from backup.
Restore the earlier component installation directory that you backed up before the upgrade (to recover the earlier environment), then back it up again. You will retain one of the earlier directories as a backup copy and use one to restart the upgrade
Windows: Restore the backed up registry for the component.
WebPass Web Server: Restore the backed up Web server configuration file.
Using a backup copy of your earlier information and component installation directory, restart the upgrade, as described in "Upgrading the Schema and Data In Place with the Master Identity Server".
Upgraded Identity System components send and receive information sent 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 an earlier Access System.
When all earlier Identity System components are successfully upgraded, proceed as appropriate for your earlier installation. For example:
Identity System Only: When your earlier installation does not include the Access System, you can complete activities in the following sequence using information in:
Joint Identity and Access Systems: When your earlier installation does include the Access System, you must complete activities in the next sequence using information in:
Chapter 7, "Upgrading Access System Schema and Data In Place"
Chapter 9, "Upgrading Remaining Identity System Components In Place"
Chapter 11, "Upgrading Integration Components and an Independently Installed SDK"
Chapter 12, "Upgrading Your Identity System Customizations" after upgrading all Identity System components.
For more information about expected system behaviors, see Chapter 4.
