| 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 provides information about the tools and utilities that are called into operation during the upgrade process.
Topics in this chapter include:
Oracle recommends that you upgrade the schema and data automatically, as described in Part II. However, errors occur during the upgrade process, you might need to use these instructions to perform an upgrade from one release to another manually.
Completing manual upgrades of the schema and data includes the use of specific utilities provided by Oracle Access Manager. For more information about these utilities, see Appendix C.
In examples in this chapter, release 5.2 is mentioned for illustration only. If you are starting the upgrade from a release earlier than 6.1.1, see "Indirect Upgrade Paths".
When upgrading your schema manually, you need to select the appropriate schema file for your directory server and the specific release you are upgrading from and to, as shown in Table D-1.
Note:
You might notice gaps in the from and to releases in Table D-1. This occurs when there is no schema or data update for the specific release. For example, there were no schema changes from release 6.0.0 to 6.1.0 and as a result there are no files named ...600_to_610_ schema_....| Directory Type | Schema Files |
|---|---|
|
Active Directory |
osd_520_to_600_schema_ad.ldif policy_520_to_600_schema_ad.ldif user_520_to_600_schema_ad.ldif osd_610_to_650_schema_ad.ldif policy_610_to_650_schema_ad.ldif user_610_to_650_schema_ad.ldif osd_650_to_700_schema_ad.ldif policy_650_to_700_schema_ad.ldif user_650_to_700_schema_ad.ldif osd_700_to_1014_schema_ad.ldif policy_700_to_1014_schema_ad.ldif user_700_to_1014_schema_ad.ldif |
|
ADAM |
osd_650_to_700_schema_adam.ldif policy_650_to_700_schema_adam.ldif user_650_to_700_schema_adam.ldif osd_700_to_1014_schema_adam.ldif policy_700_to_1014_schema_adam.ldif user_700_to_1014_schema_adam.ldif |
|
IBM SecureWay |
osd_520_to_600_schema_ibm.ldif policy_520_to_600_schema_ibm.ldif user_520_to_600_schema_ibm.ldif osd_610_to_650_schema_ibm.ldif policy_610_to_650_schema_ibm.ldif osd_650_to_700_schema_ibm.ldif policy_650_to_700_schema_ibm.ldif user_650_to_700_schema_ibm.ldif osd_700_to_1014_schema_ibm.ldif policy_700_to_1014_schema_ibm.ldif user_700_to_1014_schema_ibm.ldif |
|
Novell e-Directory |
osd_520_to_600_schema_nds.ldif policy_520_to_600_schema_nds.ldif user_520_to_600_schema_nds.ldif osd_610_to_650_schema_nds.ldif policy_610_to_650_schema_nds.ldif osd_650_to_700_schema_nds.ldif policy_650_to_700_schema_nds.ldif user_650_to_700_schema_nds.ldif osd_700_to_1014_schema_nds.ldif policy_700_to_1014_schema_nds.ldif user_700_to_1014_schema_nds.ldif |
|
Oracle Internet Directory |
osd_700_to_1014_schema_oid.ldif policy_700_to_1014_schema_oid.ldif user_700_to_1014_schema_oid.ldif |
|
Siemens DirX |
osd_700_to_1014_schema_dirx.ldif policy_700_to_1014_schema_dirx.ldif user_700_to_1014_schema_dirx.ldif |
|
Sun 4.x and 5.x |
osd_520_to_600_schema_ns.ldif policy_520_to_600_schema_ns.ldif user_520_to_600_schema_ns.ldif osd_610_to_650_schema_ns.ldif policy_610_to_650_schema_ns.ldif osd_650_to_700_schema_ns.ldif policy_650_to_700_schema_ns.ldif user_650_to_700_schema_ns.ldif osd_700_to_1014_schema_ns.ldif policy_700_to_1014_schema_ns.ldif user_700_to_1014_schema_ns.ldif |
|
Oracle Virtual Directory Server (VDS) |
user_700_to_1014_schema_vde.ldif |
To upgrade the schema manually
Navigate to the upgrade directory:
IdentityServer_install_dir\identity\oblix\tools\migration_tools
Locate the appropriate schema file for the directory server and specific fromrelease_to_release.
Invoke the schema upgrade tool ds_conf_update using the command here.
For example:
IdentityServer_install_dir\identity\oblix\tools\ldap_tools \ds_conf_update -f schema_file
where schema_file is the name of the schema file as shown in the samples in Table D-1.
Respond to prompts for various options, such as host, port, userid, and password.
Any errors produced while running this tool are printed to stdout. You can use this tool for any directory server that is compatible with Oracle Access Manager 10.1.4.
Oracle Access Manager includes several files that are called and used during the upgrade from earlier releases to 10.1.4. You can copy and use these files as a template to display or suppress the prompts you see and respond to during the upgrade. For example, you can allow the prompts to enable automatic data upgrades or you can suppress the prompts to enable manual upgrade.
The template in "Sample Default obmigratenpparams.lst File" determines which data upgrade prompts you see during the upgrade from Oracle Access Manager 5.2 to 10.1.4.
\IdentityServer_install_dir\identity\oblix\tools
\migration_tools\obmigratenpparams.lst
Included in this file are sections for upgrades from each major release to the next major release starting with release 5.2 and continuing through release 10.1.4. A complete, annotated version of the obmigratenpparams.lst file is shown in "Sample Default obmigratenpparams.lst File".
WARNING:
The order of parameters in the file might not indicate the upgrade order.
The appropriate value must be supplied for each parameter in the file. For True/False values:
A value of True triggers the automatic data upgrade prompt and program.
A value of False suppresses the data upgrade prompt and program; you can use this when you want a manual data upgrade.
WARNING:
Although not recommended, you can suppress automatic upgrades of the Oracle Access Manager configuration data and user data, as described in "Suppressing Automatic Data Upgrades". In that case, you must manually upgrade the configuration data and user data as described in "Upgrading User Data Manually".
Oracle recommends that you upgrade the schema and data automatically. However, when you must upgrade the schema and data manually use the overview here as a guide.
Task overview: Upgrading data manually includes
WARNING:
Oracle recommends that you upgrade the schema and data automatically.
When you choose manual data upgrades, two files provide parameters for the configuration data and user data in the directory:
\install_dir\identity\oblix\tools\migration_tools\obmigratedata
data_520_to_600_osd.lst—drives the manual upgrade of the Oracle Access Manager configuration data, for example:
osd_migration:true
policy_migration:true
wf_migration:true
user_migration:false
Note:
A value of True upgrades data. A value of False suppresses the upgrade.data_520_to_600_user.lst—drives the upgrade of user data, which occurs only during the upgrade from Oracle Access Manager 5.2.x to 6.0.0, for example:
osd_migration:false
policy_migration:false
wf_migration:false
user_migration:true
Both the osd.lst and user.lst files contain similar information. However, procedures must be completed for both user data and configuration data and a specific value must be provided for each parameter in the files. See Table C-7. An annotated example is shown in "Sample data_520_to_600_xxx.lst" . See also, "Data Upgrade: obmigratedata".
In addition to the two .lst files mentioned earlier, Oracle Access Manager 10.1.4 provides the following files:
data_610_to_650_multi_lang.lst—multi_lang_migration:true
data_610_to_650_osd.lst—osd_migration:true
data_610_to_650_psc.lst—psc_migration:true
data_650_to_700_osd.lst—osd_migration:true and wf_migration:true
data_650_to_700_psc.lst—psc_migration:true
data_700_to_1014_osd.lst—osd_migration:true
data_700_to_1014_psc.lst—psc_migration:true
If you intend to upgrade data manually, you need to suppress automatic data upgrades.
To suppress automatic data upgrades
Copy the file obmigratenpparams.lst and rename the original to retain it.
For example:
IdentityServer_install_dir\identity\oblix\tools
\migration_tools\obmigratenpparams.lst
Edit the ois section of the copy and set the values shown in bold, next, to "false" to prohibit automatic data upgrades.
For example:
ois
BEGIN:vCompoundList
520_to_600:
BEGIN:vNameList:
kMigrateData:false
kMigrateSchema:false
kMigratePublisher:false
Note:
See "Sample Default obmigratenpparams.lst File" for sections on individual upgrades from one major release to the next. For example, from 520_to_600, and so on.Complete a manual data upgrade as described in "Upgrading the Configuration Tree Manually".
You begin upgrading data manually by upgrading the configuration data tree. The following commands provide an example only. Your environment might vary.
To upgrade the configuration tree manually
Copy the data_fromrelease_to_release_osd.lst file and rename it to retain the original.
For example:
From
\install_dir\identity\oblix\tools\migration_tools\obmigratedata
\data_520_to_600_osd.lst
To
\install_dir\identity\oblix\tools\migration_tools\obmigratedata \config_data_520to600_osd.lst
Edit the file to provide the information for your environment based on the annotated sample in "Sample data_520_to_600_xxx.lst".
Confirm that the configuration tree and data parameter values are true.
osd_migration:true policy_migration:true wf_migration:true
Confirm that the user data migration parameter value is false.
user_migration:false
Back up (export) the old configuration tree to an LDIF.
Locate the obmigratedata tool, then upgrade the configuration tree by running obmigratedata and specifying the name of your updated file. For example:
\IdentityServer_install_dir\identity\oblix\tools \migration_tools\obmigratedata\obmigratedata.exe run obmigratedata.exe -f config_data_520to600_osd.lst -I install_dir
This program generates an LDIF based on the options selected in FunctionalityTBMigrated. The resulting LDIF file will be named as specified by the outputFileName parameter.
Delete the existing configuration tree after the OSD upgrade completes.
From 6.5 to 10.1.4—Before continuing with step 9 when upgrading the Identity Server and Policy Manager, you can proceed to "Removing Obsolete Schema Elements for Release 6.5 and 7.0" next.
All Upgrades—Complete the upgrade of configuration data with:
Oracle provides cleanup files for use during the incremental upgrade sequence between release 6.5 and 7.0. There are no cleanup files for any directory servers for the incremental upgrade sequence between release 7.x and 10.1.4.
You can skip this procedure if your starting release is 7.0 or if you do not want to remove the obsolete schema from the directory server.
During an upgrade from release 6.5 to 10.1.4, you can use the following procedures to clean up the obsolete schema elements from the directory server. If you choose to do this, it must be done after the configuration tree is deleted in the manual upgrade flow:
During Identity Server upgrades
During Policy Manager upgrades
After schema cleanup, LDIF files are available for you to upload to the directory server. Schema files for the configuration schema and the policy schema are separate. As a result, there are two scenarios to consider when you clean up the obsolete schema:
Are configuration and policy data stored in same directory server?
Are configuration and policy data stored in different directory servers?
Table D-2 shows configuration data cleanup files for specific directory server types.
Table D-2 Configuration Data Cleanup Files
| Directory Type | Schema Cleanup Files |
|---|---|
|
Active Directory |
osd_650_to_700_schema_delete_ad.ldif |
|
ADAM |
osd_650_to_700_schema_delete_adam.ldif |
|
IBM SecureWay |
osd_650_to_700_schema_delete_ibm.ldif |
|
Novell e-Directory |
osd_650_to_700_schema_delete_nds.ldif |
|
Oracle Internet Directory |
Support for Oracle Internet Directory was introduced with Oracle COREid release 7.0.4 (also available as part of Oracle Application Server 10g Release 2 (10.1.2)). Therefore, there are no obsolete schema entries to be deleted and no such files for Oracle Internet Directory. |
|
Sun 4.x 5.x Note: 10.1.4 does not support Sun 4.x directory servers. See "Sun Directory Server Considerations and Preparation". |
osd_650_to_700_schema_delete_ns.ldif |
Table D-3 shows the policy data cleanup files for specific directory server types.
Table D-3 Policy Data Cleanup Files
| Directory Type | Schema Cleanup Files |
|---|---|
|
Active Directory |
policy_650_to_700_schema_delete_ad.ldif |
|
ADAM |
policy_650_to_700_schema_delete_adam.ldif |
|
IBM SecureWay |
policy_650_to_700_schema_delete_ibm.ldif |
|
Novell e-Directory |
policy_650_to_700_schema_delete_nds.ldif |
|
Oracle Internet Directory |
Support for Oracle Internet Directory was introduced with Oracle COREid release 7.0.4 (also available as part of Oracle Application Server 10g Release 2 (10.1.2)). Therefore, there are no obsolete schema entries to be deleted and no such files for Oracle Internet Directory. |
|
Sun 4.x 5.x Note: Oracle Access Manager 10.1.4 does not support Sun 4.x directory servers. See "Sun Directory Server Considerations and Preparation". |
policy_650_to_700_schema_delete_ns.ldif |
Depending upon your directory server and starting release, you can complete the procedures here more than once:
Cleaning Up Obsolete Elements During Identity Server Upgrades
Cleaning Up Obsolete Elements During Policy Manager Upgrades
Use the following procedure to remove obsolete elements during Identity Server upgrades from release 6.5 to 7.0.
To remove obsolete elements during Identity Server upgrades
Navigate to the upgrade directory:
IdentityServer_install_dir/identity/oblix/tools/migration_tools
Locate the appropriate file for your directory server, as specified in Table D-2, so that you can provide this name in step 3.
Take the appropriate action for your environment:
Same Directory Server—If configuration data and policy data are in the same directory server, invoke the schema upgrade tool ds_conf_update using the command:
IdentityServer_install_dir/identity/oblix/tools/ldap_tools /ds_conf_update -f schema_file
where schema_file is the name of the schema cleanup file from Table D-2.
Different Directory Server—If configuration and policy data are in different directory servers, invoke ds_conf_update twice: once for the configuration schema and a second time for the policy schema as follows:
IdentityServer_install_dir/identity/oblix/tools/ldap_tools
/ds_conf_update -f identity/oblix/tools/migration_tools
where schema_file is the name of the appropriate schema cleanup file from Table D-2.
Respond to prompts for various options, such as host, port, userid, and password.
Continue the upgrade with "Uploading the Generated LDIF".
Use the next procedure to remove obsolete elements during Policy Manager upgrades from release 6.5 to 7.0.
To remove obsolete elements during Policy Manager upgrades
Navigate to the upgrade directory:
PolicyManager_install_dir/identity/oblix/tools/migration_tools
Locate the appropriate schema file for the directory server as specified in Table D-3.
Take the appropriate action for your environment:
Same Directory Server—If configuration data and policy data are in the same directory server, invoke the schema upgrade tool ds_conf_update using the command:
PolicyManager_install_dir/identity/oblix/tools/ldap_tools
/ds_conf_update -f schema_file
where schema_file is the name of the policy schema cleanup file from Table D-3.
Different Directory Server—If configuration and policy data are in different directory servers, invoke the schema upgrade tool ds_conf_update twice: once for the configuration schema and a second time for the policy schema as follows.
PolicyManager_install_dir/identity/oblix/tools/ldap_tools
/ds_conf_update -f schema_file
where schema_file is the name of the configuration/policy schema cleanup file from Table D-3 or Table D-2.
Respond to prompts for various options such as host, port, userid, and password.
Note:
The tool might generate errors of type Attribute/Object does not exist. These can occur when LDIF files contain a list of all obsolete schemas from Oracle Access Manager release 3.6 which might not be present in your directory server.After upgrading the configuration tree and optionally removing obsolete schema elements, you are ready to upload the generated LDIF.
Run ldapmodify to upload the generated LDIF. For example:
\IdentityServer_install_dir\identity\oblix\tools\ldap_tools\ldapmodify run ldapmodify.exe -f generated_ldif
This program prompts for various options, such as host, port, userid, and password.
Upgrade user data, as described in "Upgrading User Data Manually".
Repeat earlier steps using the next highest data_fromrelease_to_release_osd.lst file, until you have upgraded all data to release 10.1.4.
Release numbers used here are simply for illustration. If you have an earlier release than 6.1.1, be sure to contact Oracle Support before upgrading: http://www.oracle.com/support/contact.html
User data upgrades are required only while making a move, either a direct or an intermediate move, from Oracle Access Manager 5.2.x to Oracle Access Manager 6.x.
To upgrade the user data manually
Copy the data_fromrelease_to_release_user.lst file and rename it to retain the original.
For example:
From
\IdentityServer_install_dir\identity\oblix\tools
\migration_tools\obmigratedata\data_520_to_600_user.lst
To
\install_dir\identity\oblix\tools\migration_tools\obmigratedata
\config_data_520to600_user.lst
See Table D-4 as you edit the keys in the file to provide the information for your environment based on the annotated samples here.
A complete, annotated version of the data_520_to_600_xxx.lst file is shown in "Sample data_520_to_600_xxx.lst". Both the osd.lst and user.lst files contain similar information.
Confirm that the Oracle Access Manager configuration tree and data parameter values are false.
osd_migration:false
policy_migration:false
wf_migration:false
Confirm that the user data upgrade parameter value is true.
user_migration:true
Note:
Although a user-data upgrade does not do anything with the configuration data tree, it is a good idea to complete step 5.Back up the configuration tree.
Upgrade user data by running obmigratedata.exe and specifying the name of your updated file. For example:
run obmigratedata.exe -f config_data_520to600_user.lst
Table D-4 Keys to Add or Edit
| Key | Description |
|---|---|
|
hostname: host name |
Directory server host |
|
portNo: port number |
Directory server port |
|
bindDN: DS credentials |
The DN of the directory server administrator account. This can be found in installdir/oblix/config/ldap/AppDB.xml. |
|
password: encrypted password |
Password of the directory server administrator account. This can be found in installdir/oblix/config/ldap/AppDB.xml. |
|
directoryType: NS|AD|NDS|IBM |
The type of directory server you are running |
|
directoryMode: SSL|OPEN |
The mode of the directory server you are using. Values can be either SSL or Open. |
|
Oblixnode: ou=Oblix|o=Oblix |
RDN of the Oracle Access Manager configuration tree |
|
groupOC: name of Group object class |
Example: group or groupOfUniqueNames |
|
PersonOC: name of Person object class |
Example: user or inetOrgPerson |
|
oldVersion: release number |
Exact release number of the Oracle Access Manager 5.2 system. This can be found in ./oblix/config/np52_is.txt. Example: 5.2, 5.2.1.12 |
|
oldVersionSearchBase: searchbase |
The searchbase to use. Typically, this is the global searchbase. |
|
binAttrFileName:at_520_to_600_binary.lst |
Accept this file as shown. It contains important information for the upgrade program. |
|
objclassMapFileName:oc_520_to_600_map.lst |
Accept this file as shown. It contains important information for the upgrade program. |
|
logFileName: filename |
Name of the file to receive logging information during the conversion process. |
|
outputFileName: filename |
Name of the LDIF file to receive the converted data. |
|
missedSuppliedAttrsDetailsFileName: filename |
Name of the file to receive workflows containing Provisioned attributes in Oracle Access Manager 5.2. These workflows must be modified manually in the applet to associate the appropriate subflow with them. |
|
WFDefContainer: |
DN of the workflow definitions container. Example: obcontainerID=workflowDefinitions,OU= oblix,DC=company,DC=com |
|
WFInstanceContainer |
DN of the workflow instance container. Example: obcontainerId=workflowInstances, OU=oblix,DC=company,DC =com |
|
FunctionalityTBMigrated BEGIN:vNameList |
|
|
osd_migration: true|false |
Perform data upgrades on the configuration tree. Note: If you are running data upgrades because of errors in an earlier run:
|
|
policy_migration: true|false |
Refer to details for osd_migration. |
|
wf_migration: true|false |
Perform data upgrades on workflow containers specified earlier. Note: If you are running data upgrades manually because workflows are on a separate directory server and you want to upgrade them:
|
|
user_migration: true|false |
Perform data upgrades on User entries (non-Oracle data). Between release 5.2 and 10.1.4, the Challenge Phrase Response encryption format is changed from RC-4 to RC-6. User data upgrade is performed inline by default. The user entries are modified directly without generating an intermediate LDIF. |
|
END:vNameList |
|
|
Additional_DS_Info: |
If you are upgrading user data and you have multiple user directories, you can specify the additional directory servers in this section. |
|
BEGIN:vCompoundList |
|
|
user_migration_ds_1: |
For additional user directory servers, the format is user_migration_ds_n Where n is 1, 2, 3, and so on. |
|
BEGIN:vCompoundList |
|
|
hostname: host name |
Directory server host |
|
portNo: port number |
Directory server port |
|
bindDN: DS credentials |
The DN of the user data directory server administrator account, which can be found in installdir/oblix/config/ldap/AppDB.xml. Note: If you have user data stored separately from configuration data, the AppDB.xml file might not contain the appropriate bind DN and encrypted password for the user data directory. |
|
password: encrypted password |
The Password of the user data directory server administrator account, which can be found in installdir/oblix/config/ldap/AppDB.xml. |
|
directoryType: NS|AD|NDS|IBM |
The type of directory server you are running |
|
directoryMode: SSL|OPEN |
The mode of the directory server you are using: Values can be either SSL or Open. |
|
oldVersionSearchBase: searchbase |
The searchbase to use. Typically, this is the global searchbase. Note: Every directory server in "Additional DS" in the config.lst file once had the searchbase given with keyword 'oldVersionSearchbase' . However, with 10.1.4, there is no 'oldVersionSearchBase' keyword present in additional directory server sections. Instead, the keyword is 'searchbase'. The value of this keyword need not always be the global searchbase. One additional directory server (for example, user_migration_ds_1) represents one directory-profile from the configuration tree. The 'searchbase' keyword from this section will give you the 'Namespace' covered by this directory-profile. |
|
END:vCompoundList |
|
|
END:vCompoundList |
BEGIN:vCompoundList am: Policy Manager Parameters BEGIN:vCompoundList kMigrateLicense:false 520_to_600: BEGIN:vNameList: kMigrateWS:true kMigrateData:false kMigrateSchema:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateWS:false kMigrateData:false kMigrateSchema:false END:vNameList 610_to_650: BEGIN:vNameList: kMigrateWS:true kMigrateData:true kMigrateSchema:true END:vNameList 650_to_700: BEGIN:vNameList: kMigrateWS:true kMigrateData:true kMigrateSchema:true END:vNameListr 700_to_1014: BEGIN:vNameList: kMigrateWS:false kMigrateData:true kMigrateSchema:true END:vNameListr END:vCompoundList wg: (WebGate) BEGIN:vCompoundList 520_to_600: BEGIN:vNameList: kMigrateWS:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateWS:false END:vNameList 650_to_700: BEGIN:vNameList: kMigrateWS:true END:vNameList 700_to_1014: BEGIN:vNameList: kMigrateWS:true END:vNameList END:vCompoundList wp: (webPass) BEGIN:vCompoundList 520_to_600: BEGIN:vNameList: kMigratePublisher:true END:vNameList 600_to_610: BEGIN:vNameList: kMigratePublisher:false END:vNameList 610_to_650: BEGIN:vNameList: kMigratePublisher:false END:vNameList 650_to_700: BEGIN:vNameList: kMigrateWS:true END:vNameList 700_to_1014: BEGIN:vNameList: END:vNameList END:vCompoundList aaa: (Access Server) Authentication, Authorization, Auditing Parameters BEGIN:vCompoundList 520_to_600: BEGIN:vNameList: kMigrateData:true kMigrateSchema:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateData:false kMigrateSchema:false END:vNameList 610_to_650: BEGIN:vNameList: kMigrateSchema:false kMigrateData:true END:vNameList 700_to_1014: BEGIN:vNameList: END:vNameList END:vCompoundList bea: BEGIN:vCompoundList 600_to_610: BEGIN:vNameList: kMigrateASDK:true END:vNameList 650_to_700: BEGIN:vNameList: kMigrateASDK:true END:vNameList END:vCompoundList idlk: BEGIN:vCompoundList kMigrateLicense:false END:vCompoundList ois: Identity Server Parameters: True triggers automatic data migration BEGIN:vCompoundList kMigrateLicense:false kMigrateASDK:true 520_to_600: BEGIN:vNameList: kMigrateData:true kMigrateSchema:true kMigratePublisher:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateASDK:true kMigrateData:false kMigrateSchema:false kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList 610_to_650: BEGIN:vNameList: kMigrateASDK:true kMigrateSchema:true kMigrateData:true kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList 650_to_700: BEGIN:vNameList: kMigrateASDK:true kMigrateData:true kMigrateSchema:true kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList 700_to_1014: BEGIN:vNameList: kMigrateASDK:true kMigrateData:true kMigrateSchema:true kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList END:vCompoundList was: BEGIN:vCompoundList kMigrateASDK:true 600_to_610: BEGIN:vNameList: kMigrateASDK:true END:vNameList 650_to_700: BEGIN:vNameList: kMigrateASDK:true END:vNameList END:vCompoundList END:vCompoundList
Again, release numbers shown here are for illustration only. If your starting release is earlier than 6.1.1, be sure to contact Oracle Support before upgrading: http://www.oracle.com/support/contact.html
Both the osd.lst and user.lst files contain similar information. For additional details, see Table C-7. User migration occurs only during the upgrade from Oracle Access Manager 5.2.x to Oracle Access Manager 6.0.0. When you have ADAM as the directory server with Oracle Access Manager 6.5.1 or later, the directory type to be used is ADAM.
BEGIN:vCompoundList hostName:<hostName> portNo:<portNo> bindDN:<bindDN> password:<password> Copy encrypted credentials from \COREid\identity\oblix\config\ldap\AppDB.xml directoryMode:<directoryMode> Open or SSL directoryType:<directoryType> NS or AD or NDS or IBM oldConfigDN:<oldConfigDN> o=company,c=us oldVersionSearchbase:<oldVersionSearchbase>Global Searchbase binAttrFileName:at_520_to_600_binary.lst objclassMapFileName:oc_520_to_600_map.lst logFileName:output_520_to_600_osd.log Okay to change outputFileName:output_520_to_600_osd.ldif Okay to change missedSuppliedAttrsDetailsFileName:output_520_to_600_supplied_osd.txt oblixnode:o=oblix For AD use ou=oblix groupOC:<groupOC> Your Group personOC:<personOC> doUTFConversion:<doUTFConversion> True or False oldVersion:5.2.1.7 Must be specific newVersion:6.0.0 Use proper Release encryptionType:Oblix Changes the encryption scheme from RC4 to RC6; use Oblix unless you have a customized encryption scheme #We want to know wf-containers names Workflow definition containers WFDefContainer:<wfdefcontainer> WFInstanceContainer:<wfdefcontainer> FunctionalityTBMigrated: In the following parameters, True migrates automatically; False does not BEGIN:vNameList osd_migration:true Configuration tree migration (True or False) policy_migration:true wf_migration:true user_migration:false (True migrates data, False does not) END:vNameList oblixdeletedobjects: BEGIN:vCompoundList ad: BEGIN:vList 0ADEL: CN=Deleted Objects adam: BEGIN:vList 0ADEL: CN=Deleted Objects END:vList END:vCompoundList END:vCompoundList
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|