11 Migrating Oracle Access Manager 10g Environments

This chapter describes how to migrate Oracle Access Manager 10g to Oracle Access Management Access Manager (Access Manager) 11g Release 2 (11.1.2.1.0).

This chapter contains the following sections:

Section 11.1, "Migration Overview"
Section 11.2, "Topology Comparison"
Section 11.3, "Migration Roadmap"
Section 11.4, "Prerequisites for Migration"
Section 11.5, "Installing Oracle Identity and Access Management 11.1.2.1.0"
Section 11.6, "Configuring Oracle Access Management Access Manager 11.1.2.1.0"
Section 11.7, "Configuring Transport Security Mode for Access Manager 11.1.2.1.0 Server"
Section 11.8, "Starting Administration Server and Access Manager 11.1.2.1.0 Managed Servers"
Section 11.9, "Creating the Properties File"
Section 11.10, "Generating the Assessment Report"
Section 11.11, "Restarting the Administration Server"
Section 11.12, "Additional Steps for Incremental Migration"
Section 11.13, "Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0"
Section 11.14, "Configuring Centralized Logout for 10g WebGates with Access Manager 11.1.2.1.0"
Section 11.15, "Associating the WebGates with Access Manager 11.1.2.1.0 Server"
Section 11.16, "Verifying the Migration"
Section 11.17, "Troubleshooting"

11.1 Migration Overview

The procedure described in this chapter can be used to migrate the following artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0.

Host identifiers
Agents
Data stores
Authentication schemes
Resource types
Policy domains

During this migration, you must install Access Manager 11g Release 2 (11.1.2.1.0), create a new Oracle Home (IAM_HOME), and migrate the policy data from the Oracle Access Manager 10g installation to the new Access Manager 11g Release 2 (11.1.2.1.0) Oracle Home.

This section contains the following topics:

Modes of Migration
Migration Summary

11.1.1 Modes of Migration

The following are the three modes of migration that you can perform using the procedure described in this chapter:

Complete Migration
Incremental Migration
Delta Migration

11.1.1.1 Complete Migration

This mode of migration migrates all artifacts of Oracle Access Manager 10g, which are compatible with 11.1.2.1.0, to Access Manager 11.1.2.1.0. You can perform complete migration only once. You can perform delta migration after performing complete migration, whereas incremental migration is not supported after complete migration.

11.1.1.2 Incremental Migration

Incremental migration is a mode of migration where the selected agents, policy domains and their related artifacts like host identifiers, resource types of the resources, and authentication schemes of Oracle Access Manager 10g are migrated to Access Manager 11.1.2.1.0. While migrating selected policy domains in incremental migration, the migration utility checks for any dependant artifacts, such as authentication schemes, host identifiers, and resource types; and migrates them first. This migration is followed by the migration of the associated policy domain.

You can migrate the artifacts that are not present in the Access Manager 11.1.2.1.0 environment. If an artifact that you wish to migrate is already present in the Access Manager 11.1.2.1.0 environment, the artifact is ignored and is not migrated.

You can perform incremental migration for more than once. You can also perform complete migration after incremental migration, or you can migrate all artifacts by performing incremental migration multiple times.

The incremental migration procedure is the same as the complete migration procedure. In addition, you must complete the additional steps required for incremental migration, as described in Additional Steps for Incremental Migration.

11.1.1.3 Delta Migration

Delta migration can be performed only after complete migration. Delta migration refers to the migration of changes (referred to as delta) that you make to the 10g artifacts after the complete migration.

When you perform delta migration, changes made in the policy domains are migrated along with their corresponding changes in the dependent artifacts. For example, after complete migration, if you add a new resource which uses a newly created host identifier, the next delta migration migrates the newly created host identifier first, and then the resource.

Newly added resource types and agents are not migrated as part of the delta migration. To migrate the resource types, you must associate them with any of the policy domains.

Delta migration migrates 'add' or 'modify' types of changes. This means that, if you add any new artifacts or modify any artifacts (except for resource types and agents) in the 10g deployment, you can migrate those changes using delta migration. Delta migration does not migrate the 'deletions', which means, if you delete any artifact in the 10g deployment, you cannot get the same artifact deleted in the 11g deployment using delta migration. Migration tool ensures that it maintains the integrity of the existing data in Access Manager 11g if it cannot migrate any particular changes.

You cannot perform complete migration or incremental migration after delta migration. However, you can perform delta migration multiple times.

Note:

Oracle Access Manager 10g to Access Manager 11.1.2.1.0 delta migration depends on the availability of the changes made to the Oracle Access Manager 10g deployment. Oracle Access Manager 10g keeps track of the changes made to the 10g deployment using Sync Records. Sync Records are created only if you select the check box Update Cache that is available on the policy administration webpage, when you modify any policy related artifact using the Oracle Access Manager 10g Policy Manager console.

11.1.2 Migration Summary

Table 11-1 summarizes the artifacts of Oracle Access Manager 10g that can be migrated to Access Manager 11.1.2.1.0:

Table 11-1 Compatibility of Artifacts

Artifact	Description
Host Identifiers	All host identifiers in Oracle Access Manager 10g map to a corresponding host identifier in Access Manager 11.1.2.1.0. Host name variations in Oracle Access Manager 10g, which contain non-numeric characters in the port values, are not migrated to Access Manager 11.1.2.1.0. Such non-numeric port value is removed, and the host part of the variation is retained. Variations duplicated in multiple host identifiers in Oracle Access Manager 10g are ignored. If all variations in a given host ID are duplicated, all variations are removed and a new variation is added with the name of the host ID.
Agents	All attributes of the Oracle Access Manager 10g agent profile are supported in migration except for IIS impersonation user name and password. If the Oracle Access Manager 10g deployment has a mix of WebGates with `Open`/`Simple`/`Cert` transport security mode, the migration utility attempts to migrate WebGate with its transport security mode. In this case, you must configure the Access Manager 11.1.2.1.0 server depending to the security mode of the WebGates. For more information, see Section 11.7, "Configuring Transport Security Mode for Access Manager 11.1.2.1.0 Server". If all WebGates are to be migrated in the same mode, you must set the `agent_mode_to_override` property in the properties file to `OPEN` /`SIMPLE` /`CERT` depending on the mode required. For more information about the properties specified in the properties file, see Table 11-4. The migration utility does not generate artifacts like `ObAccessClient.xml`, `password.xml`, `certificates`, as the WebGates already have those artifacts from the Oracle Access Manager 10g deployment. If required, you can generate those artifacts by updating the WebGate profile manually using the Access Manager 11.1.2.1.0 administration console.
Data Stores	Directory instances of Oracle Access Manager 10g directory profiles are supported for migration. All relevant attributes of directory instances are migrated and mapped to corresponding data store of Access Manager 11.1.2.1.0. If the directory profile contains a secondary directory instance, it is migrated as a separate data store. Data stores must be up and running during the migration process. Offline data stores are ignored.
Authentication Schemes	Migration of authentication schemes like Form, Basic, and X509 is supported. Migration of authentication schemes with customized authentication flows is also supported. Authentication schemes with custom authentication challenge parameters are migrated without the custom challenge parameters. After migration, you must manually add or change the challenge parameters in the migrated authentication schemes with the same values used in the corresponding Oracle Access Manager 10g authentication schemes. External authentication schemes from Oracle Access Manager 10g are not supported in Access Manager 11.1.2.1.0. Therefore, external authentication schemes are migrated to 11.1.2.1.0 using Delegated Authentication Protocol (DAP). The migrated scheme requires some post-migration steps. Migration of custom authentication is not supported. If an authentication scheme contains custom plug-ins, such schemes may not be migrated correctly. All authentication schemes of type Anonymous in Oracle Access Manager 10g are directly mapped to one single Authentication scheme NONE in Access Manager 11.1.2.1.0.
Resource Types	Oracle Access Manager 10g resource types and the migrated Access Manager 11.1.2.1.0 resources types have one-to-one mapping. Resource types with name HTTP, wl_authen are not migrated, as they are available out-of-the-box in Access Manager 11.1.2.1.0.
Policy Domains	Policy domains of Oracle Access Manager 10g map to a distinct application domain in Access Manager 11.1.2.1.0. URL prefixes are migrated to Access Manager 11.1.2.1.0. For every prefix, an additional resource `<urlprefix>/` is created and protected by default authentication and authorization policies. If any of the internal policies contain URL prefixes with all operations selected and without any URL Pattern, then the resources `<urlprefix>` and `<urlprefix>/` are removed from the default authentication scheme. The resources are protected by the authentication scheme configured for that particular internal policy. Such resource is created by selecting all of the operations defined in its resource type. The default authentication rule and the authorization expression is migrated to the default authentication and authorization policy, respectively. Only success/failure responses and redirects associated with authorization expressions are supported for migration. Inconclusive responses and redirects are ignored. Responses and redirects associated with authorization rules are not considered for migration because Access Manager 11.1.2.1.0 does not support them. For authentication rules, both the success and failure redirects and responses are migrated to Access Manager 11.1.2.1.0. However, in the user interface, only success responses are displayed. Authorization rules that do not form part of any authorization expression are ignored during migration. While migrating Oracle Access Manager 10g internal policies to Access Manager 11.1.2.1.0: If the authentication rule is using the default authentication rule associated with the policy domain, resources defined in the internal policy are associated with the default authentication policy after the migration. Otherwise, a new authentication policy is created for the authentication rule. If the authorization expression is using the default authorization expression associated with the policy domain, resources defined in the internal policy are associated with the default authorization policy after migration. Otherwise, a new authorization policy is created for the authorization expression. In Oracle Access Manager 10g, ALLOW and DENY conditions associated with an authorization rule taking part in the expression are converted into conditions during migration. Later ALLOW and DENY rules are created for the migrated authorization policy using the migrated conditions. Timing conditions are migrated as temporal conditions, and they form part of the ALLOW or DENY rule in Access Manager 11.1.2.1.0. After migration, only ALLOW rule is created, which will have a combined expression containing ALLOW and DENY conditions such that the evaluation results in ALLOW or DENY. DENY rule will always be empty.

11.2 Topology Comparison

Figure 11-1 compares the topologies of Oracle Access Manager 10g and Access Manager 11.1.2.1.0.

Figure 11-1 Comparison of Oracle Access Manager 10g and Access Manager 11.1.2.1.0 Topologies

Description of "Figure 11-1 Comparison of Oracle Access Manager 10g and Access Manager 11.1.2.1.0 Topologies"

11.3 Migration Roadmap

Table 11-2 lists the steps to migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0.

Table 11-2 Migration Tasks

Task No	Task	For More Information
1	Complete the prerequisites.	See, Prerequisites for Migration
2	Install Oracle Identity and Access Management 11g Release 2 (11.1.2.1.0).	See, Installing Oracle Identity and Access Management 11.1.2.1.0
3	Configure Access Manager 11.1.2.1.0.	See, Configuring Oracle Access Management Access Manager 11.1.2.1.0
4	Configure the security mode of the Access Manager 11.1.2.1.0 server instance and the WebGates, so that the Access Manager 11.1.2.1.0 server accepts connections from the agents when WebGates start communicating with Access Manager 11.1.2.1.0 after migration.	See, Configuring Transport Security Mode for Access Manager 11.1.2.1.0 Server
5	Start the Administration Server and the Access Manager 11.1.2.1.0 Managed Servers.	See, Starting Administration Server and Access Manager 11.1.2.1.0 Managed Servers
6	Create a properties file with the LDAP details and the required information.	See, Creating the Properties File
7	Generate the assessment report, and analyze what agents and artifacts can be migrated to Access Manager 11.1.2.1.0. You can perform this task multiple times before you migrate your Oracle Access Manager 10g environment.	See, Generating the Assessment Report
8	Restart the Administration Server for the domain that has Access Manager 11.1.2.1.0.	See, Restarting the Administration Server
9	If you wish to perform incremental migration, complete the additional steps (for example, creating an input file). Ignore this task if you wish to perform complete migration.	See, Additional Steps for Incremental Migration
10	Migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0.	See, Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0
11	If you are using 10g WebGates with Access Manager 11.1.2.1.0, you must configure the centralized logout for 10g WebGates to work with Access Manager 11.1.2.1.0 server.	See, Configuring Centralized Logout for 10g WebGates with Access Manager 11.1.2.1.0
12	Associate the migrated WebGates with the Oracle Access Management 11.1.2.1.0 Server.	See, Associating the WebGates with Access Manager 11.1.2.1.0 Server
13	Verify the migration.	See, Verifying the Migration

11.4 Prerequisites for Migration

You must complete the following prerequisites for migrating Oracle Access Manager 10g to Access Manager 11.1.2.1.0:

Read the Oracle Fusion Middleware System Requirements and Specifications document to ensure that your environment meets the minimum requirements for the products you are installing, upgrading, and migrating.

Note:

For information about Oracle Fusion Middleware concepts and directory structure, see "Understanding Oracle Fusion Middleware Concepts and Directory Structure" in the Oracle Fusion Middleware Installation Planning Guide for Oracle Identity and Access Management.
Verify that the Oracle Access Manager 10g version that you are using is supported for migration. For information about supported starting points for Oracle Access Manager 10g migration, see Section 10.1, "Supported Starting Points for Oracle Access Manager 10g Migration".
Make sure that all the user stores configured in your Oracle Access Manager 10g deployment are running.

Note:

The migration utility does not support connections with the configuration store over SSL port.

11.5 Installing Oracle Identity and Access Management 11.1.2.1.0

As part of the migration process, you must install Oracle Identity and Access Management 11g Release 2 (11.1.2.1.0). Oracle Identity and Access Management is a suite that contains Oracle Access Management Access Manager 11.1.2.1.0. This installation can be on the same machine where Oracle Access Manager 10g is installed, or on a different machine.

For more information about installing Oracle Identity and Access Management 11.1.2.1.0, see "Installing Oracle Identity and Access Management (11.1.2.1.0)" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

11.6 Configuring Oracle Access Management Access Manager 11.1.2.1.0

After installing Oracle Identity and Access Management 11.1.2.1.0, you must configure Access Manager 11.1.2.1.0, and create a domain.

For information about configuring Access Manager 11.1.2.1.0, see "Configuring Oracle Access Management" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

11.7 Configuring Transport Security Mode for Access Manager 11.1.2.1.0 Server

You must configure the security mode of the Access Manager 11.1.2.1.0 Server, so that the migrated WebGates communicate with the Access Manager 11.1.2.1.0 Server after migration. The following are the security modes listed in the increasing order of their security level:

Open
Simple
Cert

Open is the least secured mode, and Cert is the most secured mode. Open is the default security mode. The security mode in which the Access Manager 11.1.2.1.0 server must be configured depends on the security modes of the Oracle Access Manager 10g WebGates that you wish to migrate.

This section contains the following topics:

Deciding the Security Mode of Access Manager 11.1.2.1.0 Server
Configuring Cert Mode Communication for Access Manager 11.1.2.1.0 Server
Configuring Simple Mode Communication for Access Manager 11.1.2.1.0 Server

11.7.1 Deciding the Security Mode of Access Manager 11.1.2.1.0 Server

If all the WebGates that you migrate have the same security mode, you must configure the Access Manager 11.1.2.1.0 Server in the respective modes. If you have mix of migrated WebGates configured in different security modes, you must configure the Access Manager 11.1.2.1.0 Server in the mode with the lower security level. Table 11-3 lists the various use cases and the security mode in which you must configure the Access Manager 11.1.2.1.0 Server.

Table 11-3 Choosing the Security Mode for Access Manager 11.1.2.1.0 Server

Transport Security Mode of Oracle Access Manager 10g WebGates	Security Mode to be Configured for Access Manager 11.1.2.1.0 Instance	Configuration Procedure
Some or all `Open`	`Open`	`Open` mode is the default mode. No additional steps are necessary.
All `Cert`	`Cert`	See Configuring Cert Mode Communication for Access Manager 11.1.2.1.0 Server.
All `Simple`	`Simple`	See Configuring Simple Mode Communication for Access Manager 11.1.2.1.0 Server.
Mix of `Open`, `Simple`, and `Cert`	`Open`	`Open` mode is the default mode. No additional steps are necessary.
Mix of `Simple` and `Cert`	`Simple`	See Configuring Simple Mode Communication for Access Manager 11.1.2.1.0 Server.

11.7.2 Configuring Cert Mode Communication for Access Manager 11.1.2.1.0 Server

To configure Cert mode communication for Access Manager 11.1.2.1.0, complete the following tasks in section "Configuring Cert Mode Communication for Access Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management:

Reviewing "Introduction to Securing Communication Between OAM Servers and Webgates", and "About Cert Mode Encryption and Files"

Complete all of the steps described in this task.
"Generating a Certificate Request and Private Key for OAM Server"

Complete all of the steps described in this task.
"Retrieving the OAM Keystore Alias and Password"

Complete all of the steps described in this task.
"Importing the Trusted, Signed Certificate Chain Into the Keystore"

In this task, you import the Certificate Authority (CA) certificate used to issue the Cert mode certificate for WebGate. If this CA certificate is different from the certificate that is already trusted by the Access Manager 11.1.2.1.0 Server, perform the following steps under this task. Otherwise, ignore these tasks.
- "aaa_chain.pem: Using a text editor, modify the aaa_chain.pem file to remove all data except that which is contained within the CERTIFICATE blocks, then save the file"
- "Import the trusted certificate chain using the following command with details for your environment"
- "When prompted to trust this certificate, type yes"
"Adding Certificate Details to Access Manager Settings"

Ignore the step "Open the OAM Server registration page, click the Proxy tab, change the Proxy mode to Cert, and click Apply" under this task.

If the root certificate authority (CA) used for the Cert mode certificate of the Access Manager 11.1.2.1.0 Server is different from the CA certificate present in aaa_chain.pem file on the WebGate side, you must update the aaa_chain.pem file with the root CA certificate used to issue the server Cert mode certificates. To do this, complete the following steps:

Obtain the CA certificate in PEM format that was used to generate Cert mode certificates for the Access Manager 11.1.2.1.0 Server instance.
Open this CA certificate in any text editor, copy the content from this file, including the BEGIN, END markers. For example:

----BEGIN CERTIFICATE-----

...

CERTIFICATE

...

-----END CERTIFICATE-----
Open the aaa_chain.pem file from the location OHS_INSTANCE_HOME/config/OHS/ohs2/webgate/config using any text editor, and paste the content of server CA certification base 64 encoded contents to the end of the aaa_chain.pem file.
Save the file, and close.

11.7.3 Configuring Simple Mode Communication for Access Manager 11.1.2.1.0 Server

To configure Simple mode communication for the Access Manager 11.1.2.1.0 Server, complete the following steps:

Log in to the Oracle Access Management 11.1.2.1.0 Administration console, using the following URL:

http://<host>:<port>/oamconsole

where <host> is the machine on which Access Manager 11.1.2.1.0 is running, and <port> is the port number.
Go to the System Configuration tab.
Expand Access Manager, and double-click Access Manager Settings.
Expand the Access Protocol section.
Set Global Passphrase to the same value used in your Oracle Access Manager 10g deployment.

11.8 Starting Administration Server and Access Manager 11.1.2.1.0 Managed Servers

Before you start migrating Oracle Access Manager 10g to Access Manager 11.1.2.1.0, make sure that the WebLogic Administration Server and the Access Manager 11.1.2.1.0 Managed Servers are up and running before you start migrating Oracle Access Manager 10g. If you have not started the WebLogic Administration Server and the Access Manager 11.1.2.1.0 Managed Servers, start them using the following procedure:

Starting Administration Server

To start the Administration Server, do the following:

On UNIX:

Move from your present working directory to the directory MW_HOME/user_projects/domains/domain_name/bin using the command:
```
cd MW_HOME/user_projects/domains/domain_name/bin/
```
Run the following command:
```
./startWebLogic.sh
```
When prompted, enter the WebLogic Administration Server username and password.

On Windows:

Move from your present working directory to the directory MW_HOME\user_projects\domains\domain_name\bin using the following command on the command line:
```
cd MW_HOME\user_projects\domains\domain_name\bin\
```
Run the following command:
```
startWebLogic.cmd
```
When prompted, enter the WebLogic Administration Server username and password.

Starting Access Manager 11.1.2.1.0 Managed Servers

To start a Access Manager 11.1.2.1.0 Managed Server, do the following:

On UNIX:

Move from your present working directory to the directory MW_HOME/user_projects/domains/domain_name/bin using the command:
```
cd MW_HOME/user_projects/domains/domain_name/bin/
```
Run the following command:
```
./startManagedWebLogic.sh oam_managed_server admin_url
```
In this command,

oam_managed_server is the name of the Access Manager 11.1.2.1.0 Managed Server to be started.

admin_url is the URL of the WebLogic administration console. It must be specified in the format http://host:port/console.

When prompted, enter the WebLogic Administration Server username and password

On Windows:

Move from your present working directory to the directory MW_HOME\user_projects\domains\domain_name\bin using the following command on the command line:
```
cd MW_HOME\user_projects\domains\domain_name\bin\
```
Run the following command:
```
startManagedWebLogic.cmd oam_managed_server admin_url
```
In this command,

oam_managed_server is the name of the Access Manager 11.1.2.1.0 Managed Server to be started.

admin_url is the URL of the administration console. It must be specified in the format http://host:port/console.

When prompted, enter the WebLogic Administration Server username and password.

11.9 Creating the Properties File

Create a properties file in any accessible location. For example, create an oam_migration.properties file.

The content of the properties file should be the following:

## Configuration store details
## If the configuration store is SSL enabled, the LDAP url should begin with 'ldaps'.
config_store_ldap_url=ldap://<Host Name>:<Port>/
config_store_ldap_base=<Configuration store ldap base>
config_store_principal=<Configuration store LDAP Principal>
config_store_password=<Configuration store OAM 10g encrypted password>
config_store_initial_context_factory=com.sun.jndi.ldap.LdapCtxFactory

## Policy store details
## If the policy store is SSL enabled, the LDAP url should begin with 'ldaps'.
policy_store_ldap_url=ldap://<Host Name>:<Port>/
policy_store_ldap_base=<Policy store ldap base>
policy_store_principal=<Policy store LDAP Principal>
policy_store_password=<Policy store OAM 10g encrypted password>
policy_store_initial_context_factory=com.sun.jndi.ldap.LdapCtxFactory

## This property indicates the path of trust store file which is a collective
## store of CA certs of all directory serves viz. policy store, config store,
## identity store.
ldap_trust_store=<path to ldap trust-store>

## This property is required if client authentication in directory
## server is enabled and it contains the path of file having client
## certificates
client_keystore=<path to ketstore file in jks format>

## If ldap_trust_store_password and client_keystore_password are left empty,
## then wlst commandline prompts for these passwords after migration utility
## is run.
ldap_trust_store_password=<plain text password of trust store file>
client_keystore_password=<plain text password of keystore file>

## migration_mode indicates what type of migration does the administrator intends
## to perform.
## 1. COMPLETE : A full migration will be performed. Ideal for a new OAM 11g
## environment with a clean database.
## 2. INCREMENTAL: Incremental mode can be used to migrate selective artifacts
## from 10g enviroment. Incremental mode will be dictated by the
## include and exclude file properties. Incremental Migration
## cannot be performed after Complete Migration.
## 3. DELTA : When the administrator intends to migrate the changes performed to the 10g artifacts
## then delta migration can be performed. This will include all the artifacts depending upon
## the GSN number.
## Defaults to COMPLETE if not specified.
migration_mode=COMPLETE

## The include filename property indicates the absolute filename that would
## contain the list of artifacts that the administration wishes to selectively
## migrate to the 11g environment in incremental mode. For migration modes other
## than incremental, this property will be directly ignored.
include_file=<include input filename>

## The exclude filename property indicates the absolute filename that would
## contain the list of artifacts that the administration wishes to selectively
## exclude from migrating to the 11g environment in incremental mode. For
## migration modes other than incremental, this property will be directly ignored.
## In incremental mode migration, if the administrator specifies both the include
## and exclude files then the include file wiil take precedence and exclude file
## will be ignored.
exclude_file=<exclude input filename>

## This flag denotes whether the preview file should be created or not. If true,
## then preview report will be created irrespective of the value of the
## evaluate_only flag. If set to false, then preview report will not be created.
## Defaults to TRUE if not specified.
preview_enabled=true

## Parameter to filter out preview report file based on the compatibility of an
## artifact. It can take values as COMPATIBLE, INCOMPATIBLE and ALL.
## If set to INCOMPATIBLE, it will include records with compatibility as
## INCOMPATIBLE,INCOMPATIBLE_WITH_LESS_FEATURES and IGNORE. If set to COMPATIBLE,
## it will include records with compatibility as COMPATIBLE. If set to ALL,
## it will include all types of record.
## Defaults to INCOMPATIBLE if not specified.
preview_level=ALL

## Indicates the absolute path and filename of the evaluation preview record file.
## If not specified, defaults to
## <MW_Home>/user_projects/domains/base_domain/MigrationPreviewFile.txt
evaluate_filename=<Preview report filename>

## Flag indicating whether the migration utility runs in evalute mode. If true,
## only preview records will be generated and actual migration to 11g environment
## will be skipped. If false, then actual migration will take place.
## Defaults to FALSE if not specified.
evaluate_only=false

## Parameter for indicating the threashold limit for the artifacts processed in
## memory. Can be used on machines with less memory. If not provided, then
## defaults to 5000. If the migration utility is being used in 'evaluate only'
## mode, this value will be ignored.
## If you feel that the memory will not prove to be insufficient for the amount
## of data that is being migrated, set the value to "MAX".
artifact_queue_limit=3000

## Parameter to provide mode of an agent while migration. It will migrate all the
## agents in the mode specified here. The values can be, OPEN, SIMPLE, CERT
## and RETAIN_EXISTING. Defualt value will be RETAIN_EXISTING. This value will
## migrate agent in its existing mode.
agent_mode_to_override=RETAIN_EXISTING

Table 11-4 describes the values you must provide for each of the properties in the properties file.

Table 11-4 Property File Values

Property	Description
`config_store_ldap_url`	Specify the LDAP host and the port of the configuration store used in Oracle Access Manager 10g deployment in the format: `ldap://<hostname>:<port>` If the configuration store is SSL enabled, the LDAP URL should begin with '`ldaps`'.
`config_store_ldap_base`	Specify the LDAP search base for the configuration store of the Oracle Access Manager 10g deployment. This is the same search base that you provided during the installation of Oracle Access Manager 10g. To get this value, do the following: Log in to the Oracle Access Manager 10g Administration console. Go to the System Configuration tab. Click Server settings on the left navigation pane. Check for the value displayed for Configuration Base. Use the parent node of `oblix`. For example, if the Configuration Base value displayed on the console is o=Oblix,dc=company,dc=us, then the value for this property `configuration_store_ldap_base` must be `dc=company,dc=us`.
`config_store_principal`	Specify the LDAP DN of the administrator for the configuration store.
`config_store_password`	Specify the encrypted password of the Oracle Access Manager 10g configuration LDAP store. To get the encrypted password, do the following: Move from your present working directory to the location: `Access_Server_Installation Directory/oblix/config/ldap/` Copy the value of `ldapRootPasswd` from the `ConfigDB.xml` file. Use this value for the `config_store_password` property in the properties file.
`config_store_initial_context_factory`	The value of this property must be `com.sun.jndi.ldap.LdapCtxFactory`. Do not modify this value.
`policy_store_ldap_url`	Specify the LDAP host and the port of the policy store used in Oracle Access Manager 10g deployment in the format: `ldap://<hostname>:<port>`. If the policy store is SSL enabled, the LDAP URL should begin with '`ldaps`'.
`policy_store_ldap_base`	Specify the LDAP search base for the policy store of the Oracle Access Manager 10g deployment. This is the same search base that you provided during the installation of Oracle Access Manager 10g. To get this value, do the following: Log in to the Oracle Access Manager 10g Administration console. Go to the System Configuration tab. Click Server settings on the left navigation pane. Check for the value displayed for Policy Base. Use the parent node of `oblix`. For example, if the Policy Base value displayed on the console is o=Oblix,dc=company,dc=us, then the value for this property `policy_store_ldap_base` must be `dc=company,dc=us`.
`policy_store_principal`	Specify the LDAP DN of the administrator for the policy store.
`policy_store_password`	Specify the encrypted password of the Oracle Access Manager 10g policy LDAP store. To get the encrypted password, do the following: Move from your present working directory to the location: `Access_Server_Installation_Directory/oblix/config/ldap/` Copy the value of `ldapRootPasswd` from the `WebResrcDB.xml` file. Use this value for the `policy_store_password` property in the properties file.
`policy_store_initial_context_factory`	The value of this property must be `com.sun.jndi.ldap.LdapCtxFactory`. Do not modify this value.
`ldap_trust_store`	Specify the path to the trust store file in `jks` format, which contains the CA certs of all SSL enabled directory servers.
`client_keystore`	Specify the path to the keystore file in `jks` format, which contains the client certificates. This property is required only if the client authentication is enabled. Otherwise, comment out this property using `#`.
`ldap_trust_store_password`	Specify the plain text password for the trust store file that you specified for the property `ldap_trust_store`. If the value of this property is empty, the WLST command line prompts for password when you run the migration utility.
`client_keystore_password`	Specify the plain text password for the keystore file that you specified for the property `client_keystore`. This property is required only if you have specified the path of the keystore file for the `client_keystore` property. If the value of this property is empty, the WLST command line prompts for password when you run the migration utility.
`migration_mode`	This property indicates the mode of migration you wish to perform. Set one of the following values: `COMPLETE` Specify this value if you wish to perform complete migration. This is ideal for a new Access Manager 11.1.2.1.0 environment with a clean database. `INCREMENTAL` Specify this value if you wish to perform incremental migration. Incremental mode is dictated by the `include_file` and `exclude_file` properties that you specify in the properties file. `DELTA` Specify this value if you wish to perform delta migration. For more information about the modes of migration, see "Modes of Migration".
`include_file`	If you wish to perform incremental migration and migrate some of the artifacts to Access Manager 11.1.2.1.0, you must use the `include_file` property. The value of the `include_file` property must be the absolute path to the file that contains the list of artifacts that you wish to migrate to Access Manager 11.1.2.1.0. For more information about creating the include file, see "Additional Steps for Incremental Migration". If you wish to perform incremental migration with the `include_file` property, comment out the `exlcude_file` property. If you specify both `include_file` and `exclude_file` properties when you perform incremental migration, the `include_file` property takes precedence over `exclude_file` property, and the `exclude_file` property is ignored. For complete migration, this property is ignored.
`exclude_file`	If you wish to perform incremental migration and exclude some of the artifacts from the migration, you must use the `exclude_file` property. The value of the `exclude_file` property must be the absolute path to the file that contains the list of artifacts that you wish to exclude from the migration. For more information about creating the exclude file, see "Additional Steps for Incremental Migration". If you wish to perform incremental migration with the `exclude_file` property, comment out the `inlcude_file` property. If you specify both `include_file` and `exclude_file` properties when you perform incremental migration, `include_file` property takes precedence over `exclude_file` property, and the `exclude_file` property is ignored. For complete migration, this property is ignored.
`preview_enabled`	This property indicates whether the assessment report should be created. If the value of this property is set to `true`, the assessment report is generated irrespective of the value of the `evaluate_only` property. If the value of the `preview_enabled` property is set to `false`, the assessment report is not generated. If you do not specify any value, the default value `true` is used and the assessment report is generated.
`preview_level`	This property filters the data in the assessment report based on the compatibility of an artifact. You can provide one of the following values for this property: `COMPATIBLE` I`NCOMPATIBLE` `ALL` If the value of this property is set to `COMPATIBLE`, the assessment report includes the artifacts of Oracle Access Manager 10g that are compatible in Access Manager 11.1.2.1.0. If the value of this property is set to `INCOMPATIBLE`, the assessment report includes the artifacts of Oracle Access Manager 10g that are incompatible in Access Manager 11.1.2.1.0, compatible with less features in Access Manager 11.1.2.1.0, and the artifacts that are ignored in Access Manager 11.1.2.1.0. If the value of this property is set to `ALL`, the assessment report contains artifacts of Oracle Access Manager 10g that are compatible in Access Manager 11.1.2.1.0, incompatible in Access Manager 11.1.2.1.0, compatible with less features in Access Manager 11.1.2.1.0, and the artifacts that are ignored in Access Manager 11.1.2.1.0. For more information about the artifacts that are incompatible, and compatible with less features, see Table 11-6.
`evaluate_filename`	You must provide the absolute path and the filename for the assessment report file that you wish to generate. The default path is `MW_HOME/user_projects/domains/base_domain/MigrationPreviewFile.txt`, and the default name of the assessment report is `MigrationPreviewFile.txt`.
`evaluate_only`	This properties indicates if the migration utility is run in evaluate mode. If the value of this property is set to `true`, only the assessment report is generated, and Oracle Access Manager 10g is not migrated to Access Manager 11.1.2.1.0. If the value of this property is set to `false`, the assessment report is generated, and Oracle Access Manager 10g is migrated to Access Manager 11.1.2.1.0. If you do not specify any value to this property, the default value `false` is used.
`artifact_queue_limit`	This property indicates the threshold limit for the artifacts processed in memory. This property can be specified when you are using machines with less memory for the migration process. If the amount of data that is migrated is more, and the memory is sufficient, set the value of this property to `MAX`. The default value of this property is `5000`. If the migration utility is run in evaluate mode, the value of this property is ignored.
`agent_mode_to_override`	This property indicates the mode in which all agents are migrated. You can specify one of the following values to this property: `OPEN` Specify this value if you wish to migrate all the agents in `OPEN` mode. `SIMpLE` Specify this value if you wish to migrate all the agents in `SIMPLE` mode. `CERT` Specify this value if you wish to migrate all the agents in `CERT` mode. `RETAIN_EXISTING` Specify this value if you wish to migrate the agents in their existing modes. The default value is `RETAIN_EXISTING`.

Note:

The value for the config_store_password property must be encrypted. You can obtain the encrypted password from 10g_Installation_Directory/Access/oblix/config/ldap/ConfigDB.xml file.

The value for the policy_store_password property must be encrypted. You can obtain the encrypted password from 10g_Installation_Directory/Access/oblix/config/ldap/WebResrcDB.xml file.

11.10 Generating the Assessment Report

You should generate an assessment report before you can migrate the Oracle Access Manager 10g artifacts to Access Manager 11.1.2.1.0.

An assessment report is a text file generated when you run the migration utility by setting the appropriate properties in the properties file. The assessment report is generated at the location specified for the property evaluate_filename in the properties file.

This report contains the information about all the artifacts in Oracle Access Manager 10g along with the information about their compatibility in Access Manager 11.1.2.1.0.

This report contains three sections of data:

Notes about how to analyze the report, and some generic information about the compatibility of the artifacts.
Number of artifacts that are compatible, incompatible, compatible with less features, and ignored in Access Manager 11.1.2.1.0
Detailed information about all the artifacts of Oracle Access Manager 10g in a tabular format.

Table 11-5 lists the columns of the table, which displays information about the artifacts of Oracle Access Manager 10g:

Table 11-5 Assessment Report Content

ColumnNo	Column	Description
1	ARTIFACT TYPE	This column displays the type of the artifact in Oracle Access Manager 10g. The following are the types of artifacts: DATA SOURCES AUTHENTICATION SCHEMES RESOURCE TYPES HOST IDs AGENTS POLICY DOMAINS
2	ARTIFACT	This column lists the names of all the artifacts of Oracle Access Manager 10g. The name of the policy domain is divided into two parts. The first part indicates the name of the policy domain, and the second part indicates the content of the policy domain.
3	DETAILS	This column displays information about each of the artifacts. For the artifact type DATA SOURCES, the name, host and port are listed here. For the artifact type AUTHENTICATION SCHEMES, a description of each of the artifacts is displayed. For the artifact type RESOURCE TYPES, the details of the artifact are displayed, if any. For the artifacts type HOST IDs, the host and the port of each artifact is displayed. For the artifacts type AGENTS, the mode of the artifact is displayed. For the artifact type POLICY DOMAINS, the name of the policy domain is displayed.
4	COMPATIBILITY	This column displays information about the compatibility of artifacts in Access Manager 11.1.2.1.0.if the artifact is compatible with Access Manager 11.1.2.1.0 or not. The value for every artifact in this column can be one of the following: COMPATIBLE: This indicates that the artifact is supported in Access Manager 11.1.2.1.0 and the migration utility does not perform any additional modelling. INCOMPATIBLE: This indicates that the artifact is not supported in Access Manager 11.1.2.1.0, and will not be migrated. COMPATIBLE_WITH_LESS_FEATURES: This indicates that the artifact is compatible in Access Manager 11.1.2.1.0, but with less features. The migration utility performs some modelling in order to map this artifact to 11.1.2.1.0. All the artifacts with this compatibility mode are migrated. IGNORE: This indicates that the artifact is not useful in Access Manager 11.1.2.1.0, and hence will be ignored while migration.
5	MESSAGE	This column displays any message relevant to the migration of the respective artifact.
6	ACTION REQUIRED	This column displays the action required by the user, if any.

Note:

The level of data generated by the assessment report is determined by the property preview_level in the properties file.

You can generate the assessment report multiple times before you can actually migrate the artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0.

Table 11-6 shows the types of artifacts of Oracle Access Manager 10g that are incompatible and compatible with less features in Access Manager 11.1.2.1.0.

Table 11-6 Assessment Reports Summary

Artifacts Description

Artifacts	Description
INCOMPATIBLE	Policy domains that contain URL prefixes for heterogeneous resource types are incompatible with the Access Manager 11.1.2.1.0 environment. Operation OTHER for type HTTP is incompatible with Access Manager 11.1.2.1.0, and is not migrated. Delegated administration rights associated with policy domains are not considered for migration. WebGate profile names greater than 255 characters are not migrated. Authentication schemes containing custom authentication plug-ins are not migrated.
COMPATIBLE_WITH_LESS_FEATURES	Resources that are identified as `IGNORE` in the policy domain are marked as `COMPATIBLE_WITH_LESS_FEATURES`. Access Manager 11.1.2.1.0 supports specifying either query string pattern or query name-value pairs. During migration, if a policy has both query string and query name-value pairs, only query string is migrated. External authentication schemes such as DAP are not supported. If the host name variation is in the incorrect format or the port value is non-numeric, the host identifier is marked as `COMPATIBLE_WITH_LESS_FEATURES`. If host name variation exists in some other host identifier, it is removed from the host identifier and is marked as `COMPATIBLE_WITH_LESS_FEATURES`. Timing conditions like Time of the Day and Day of the Week from the authorization rules in Oracle Access Manager 10g policy domain are migrated to Access Manager 11.1.2.1.0. The other conditions such as Months of the Year and Days of the Month are not supported in Access Manager 11.1.2.1.0, so they are not migrated. Artifacts with names exceeding 255 characters, and description exceeding 1024 characters are migrated with less features. The migration utility truncates the name of the artifact if its name exceeds 255 characters, and adds this truncated name to the beginning of the description. If the description of an artifact exceeds 1024 characters, the extra characters are lost during migration.

INCOMPATIBLE

Policy domains that contain URL prefixes for heterogeneous resource types are incompatible with the Access Manager 11.1.2.1.0 environment.
Operation OTHER for type HTTP is incompatible with Access Manager 11.1.2.1.0, and is not migrated.
Delegated administration rights associated with policy domains are not considered for migration.
WebGate profile names greater than 255 characters are not migrated.
Authentication schemes containing custom authentication plug-ins are not migrated.

COMPATIBLE_WITH_LESS_FEATURES

Resources that are identified as IGNORE in the policy domain are marked as COMPATIBLE_WITH_LESS_FEATURES.
Access Manager 11.1.2.1.0 supports specifying either query string pattern or query name-value pairs. During migration, if a policy has both query string and query name-value pairs, only query string is migrated.
External authentication schemes such as DAP are not supported.
If the host name variation is in the incorrect format or the port value is non-numeric, the host identifier is marked as COMPATIBLE_WITH_LESS_FEATURES.
If host name variation exists in some other host identifier, it is removed from the host identifier and is marked as COMPATIBLE_WITH_LESS_FEATURES.
Timing conditions like Time of the Day and Day of the Week from the authorization rules in Oracle Access Manager 10g policy domain are migrated to Access Manager 11.1.2.1.0. The other conditions such as Months of the Year and Days of the Month are not supported in Access Manager 11.1.2.1.0, so they are not migrated.
Artifacts with names exceeding 255 characters, and description exceeding 1024 characters are migrated with less features. The migration utility truncates the name of the artifact if its name exceeds 255 characters, and adds this truncated name to the beginning of the description. If the description of an artifact exceeds 1024 characters, the extra characters are lost during migration.

To generate the assessment report, do the following:

Edit the properties file that you created in Section 11.9, "Creating the Properties File" as follows:
1. Set the value of the migration_mode property to COMPLETE.
2. Set the value of the preview_enabled property to true.
3. Set the value of the evaluate_only property to true.
4. Make sure that you have set the absolute path of the assessment report file to the evaluate_filename property.
5. Save the properties file, and close.
Perform step-2 to step-6 in the Section 11.13, "Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0".

This generates the assessment report at the location specified by the evaluate_filename property in the properties file that you created. You can also open this report in Microsoft Excel. The records included in the assessment report are according to the value set for the preview_level property in the properties file.

Since the evaluate_only property in the properties file is set to true, the migration utility only generates the assessment report, and it does not migrate the Oracle Access Manager 10g artifacts.

Note:

You can analyze the evaluation report, and make any necessary changes to the Oracle Access Manager 10g environment before proceeding with the migration.

If you wish to generate the assessment report and migrate the Oracle Access Manager 10g artifacts, set the value for evaluate_only property to false, and follow the steps described in Section 11.13, "Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0".

Note:

When you generate the assessment report, the migration utility also generates a text file called IncludeFile.txt at the same location where the assessment report is generated. This file can be used to specify the artifacts that you wish to migrate while performing incremental migration. For more information about using the IncludeFile.txt for incremental migration, see "Additional Steps for Incremental Migration".

11.11 Restarting the Administration Server

Restart the WebLogic Administration Server for the domain with Access Manager 11.1.2.1.0 as follows:

Stopping Administration Server
Starting Administration Server

Stopping Administration Server

To stop the Administration Server, do the following:

On UNIX:

Move from the present working directory to the directory MW_HOME/user_projects/domains/domain_name/bin using the command:
```
cd MW_HOME/user_projects/domains/domain_name/bin/
```
Run the following command:
```
./stopWebLogic.sh admin_username admin_password admin_url
```
In this command,

admin_username is the username of the WebLogic Administration Server.

admin_password is the password of the WebLogic Administration Server.

admin_url is the URL of the administration console. It must be specified in the format http://host:port/console.

On Windows:

Move from your present working directory to the directory MW_HOME\user_projects\domains\domain_name\bin using the following command on the command line:
```
cd MW_HOME\user_projects\domains\domain_name\bin\
```
Run the following command:
```
stopWebLogic.cmd
```
When prompted, enter the Administration Server username and password.

Starting Administration Server

To start the WebLogic Administration Server, do the following:

On UNIX:

Move from your present working directory to the directory MW_HOME/user_projects/domains/domain_name/bin using the command:
```
cd MW_HOME/user_projects/domains/domain_name/bin/
```
Run the following command:
```
./startWebLogic.sh
```
When prompted, enter the WebLogic Administration Server username and password.

On Windows:

Move from your present working directory to the directory MW_HOME\user_projects\domains\domain_name\bin using the following command on the command line:
```
cd MW_HOME\user_projects\domains\domain_name\bin\
```
Run the following command:
```
startWebLogic.cmd
```
When prompted, enter the WebLogic Administration Server username and password.

11.12 Additional Steps for Incremental Migration

Complete the following steps only if you wish to perform incremental migration:

Set the property migration_mode to INCREMENTAL in the properties file (Section 11.9, "Creating the Properties File") that you create during the migration process.
When you generate the assessment report (as described in Generating the Assessment Report), an input file called IncludeFile.txt is generated at the same location where the assessment report is generated. This text file contains agents and application domains of Oracle Access Manager 10g deployment. The agents and application domains are listed in the IncludeFile.txt as shown in the following example:
```
AGENT##ag_one_12752##ag_one_12752##N
AGENT##temp##temp##N
APPLICATION_DOMAIN##20120304T01055680323##my_domain##N
APPLICATION_DOMAIN##20120306T03491413638##Finance##N
APPLICATION_DOMAIN##20120306T04155393859##HR##N
APPLICATION_DOMAIN##20120319T0255014722##Domain With Resources Only##N
APPLICATION_DOMAIN##20120319T03241993733##Domain with Policy##N
APPLICATION_DOMAIN##20120319T03300047441##Domain with policy and authn rule##N
APPLICATION_DOMAIN##20120319T03324669347##domain with policy and authz rule##N
```
To perform incremental migration, you must specify either a list of artifacts (agents and application domains) that you wish to migrate, or a list of artifacts (agents and application domains) that you wish to exclude from the migration. Therefore, you must create one of the following files:
- include file: This is a text file that contains the list of agents and application domains that you wish to migrate. You can either use the auto-generated IncludeFile.txt as the include file by marking the agents and application domains that you wish to migrate as Y, or manually create a new include file. However, it is recommended that you use the IncludeFile.txt to create the include file.
  
  To create the include file using the IncludeFile.txt, do the following:
  
  a. Copy the IncludeFile.txt to any accessible location, and rename it to include.txt, if required.
  
  b. Mark the agents and application domains that you wish to migrate as Y. Y indicates that the artifact is selected for incremental migration.
  
  c. Set the property include_file in the properties file (oam_migration.properties) to the absolute path to the include file.
  
  Note:
  
  If you wish to manually create the include file, specify the agents and application domains that you wish to migrate in the format specified in the following example:
  
  AGENT##temp##temp##Y
  
  APPLICATION_DOMAIN##20120304T01055680323##my_domain##Y
- exclude file: This is a text file that contains the list of agents and application domains that you wish to exclude from migration. You can either use the auto-generated IncludeFile.txt as the exclude file by marking the agents and application domains that you wish to exclude from migration as Y, or manually create a new exclude file. However, it is recommended that you use the IncludeFile.txt to create the exclude file.
  
  To create the exclude file using the IncludeFile.txt, do the following:
  
  a. Copy the IncludeFile.txt to any accessible location, and rename it to exclude.txt, if required.
  
  b. Mark the agents and application domains that you wish to exclude from migration as Y. Y indicates that the artifact is not selected for incremental migration.
  
  c. Set the property exclude_file in the properties file (oam_migration.properties) to the absolute path to the exclude file.
  
  Note:
  
  If you wish to manually create the exclude file, specify the agents and application domains that you wish to exclude from the incremental migration in the format specified in the following example:
  
  AGENT##temp##temp##Y
  
  APPLICATION_DOMAIN##20120304T01055680323##my_domain##Y

Note:

If you create both the include file and the exclude file, and specify paths to both the files in the properties file, then the include file takes precedence, and the exclude file will be ignored.

If you do not specify any of these input files in the properties file, the migration will be aborted.

You can perform incremental migration more than once.

11.13 Migrating the Artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0

Before you migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0, it is recommended that you generate an assessment report (as described in Section 14.9, "Generating the Assessment Report"), and analyze what artifacts are compatible and incompatible in Access Manager 11.1.2.1.0.

Note:

If you decide to migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0 after analyzing the assessment report, perform the steps 1 to 6 described in this section.

If you wish to perform incremental migration, make sure that you have set the property migration_mode to INCREMENTAL in the properties file. Also, ensure that you have completed the additional steps described in Section 11.12, "Additional Steps for Incremental Migration" before you follow the steps described in this section.

If you wish to perform complete migration, make sure that you have set the property migration_mode to COMPLETE in the properties file.

Complete the following steps to perform complete migration or incremental migration:

Set the value of evaluate_only property to false in the properties file that you created in Creating the Properties File. Save the file and close.
Run the following command to launch the WebLogic Scripting Tool (WLST):

On UNIX:
1. Move from your present working directory to the IAM_HOME/common/bin directory by running the following command on the command line:
  
  cd IAM_HOME/common/bin
2. Run the following command to launch the WebLogic Scripting Tool (WLST):
  
  ./wlst.sh
On Windows:
1. Move from your present working directory to the IAM_HOME\common\bin directory by running the following command on the command line:
  
  cd IAM_HOME\common\bin
2. Run the following command to launch the WebLogic Scripting Tool (WLST):
  
  wlst.cmd
Run the following command to connect WLST to the WebLogic Server instance:
```
connect('wls_admin_username','wls_admin_password','t3://hostname:port');
```
In this command,

wls_admin_username is the username of the WebLogic Administration Server.

wls_admin_password is the password of the WebLogic Administration Server.

hostname is the host on which WebLogic Administration Server is running.

port is the port of the WebLogic Administration Server.

For example:
```
connect('weblogic','password','t3://localhost:7001');
```
Run the following command:
```
domainRuntime();
```

Run the following command:

setLogLevel(logger="oracle.oam",level="TRACE:32",persist="0",target="AdminServer");

Run the following command to migrate the artifacts of Oracle Access Manager 10g to Access Manager 11.1.2.1.0:
```
oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="absolute_path_of_properties_file");
```
where

absolute_path_of_properties_file is the absolute path of the properties file that you created in Creating the Properties File. For example:

On UNIX: oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="abc/def/oam_migration.properties"

On Windows: oamMigrate(oamMigrateType="OAM10g",pathMigrationPropertiesFile="abc\\def\\oam_migration.properties"

When the migration is complete, the WLST console displays a message that indicates the result of the migration. The log files are generated at the following location:

On UNIX: MW_HOME/user_projects/domains/base_domain/servers/AdminServer/logs/Adminserver-diagnostic*.log

On Windows: MW_HOME\user_projects\domains/base_domain\servers\AdminServer\logs/Adminserver-diagnostic*.log

In case of any errors during the migration process, refer to the log files.

11.14 Configuring Centralized Logout for 10g WebGates with Access Manager 11.1.2.1.0

If you are using 10g WebGates with Access Manager 11.1.2.1.0, you must configure the centralized logout settings for 10g WebGates to work with Access Manager 11.1.2.1.0 server, after migrating Oracle Access Manager 10g to Access Manager 11.1.2.1.0.

For more information about configuring centralized logout for 10g WebGates, see "Configuring Centralized Logout for 10g Webgate with 11g OAM Servers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Note:

Skip this step if you are not using 10g WebGates with Access Manager 11.1.2.1.0.

11.15 Associating the WebGates with Access Manager 11.1.2.1.0 Server

After you migrate Oracle Access Manager 10g to Access Manager 11.1.2.1.0, you must associate all of the migrated WebGates with the Access Manager 11.1.2.1.0 Server. To do this, complete the following steps:

Create a new server profile on Oracle Access Manager 10g Access System console with the hostname and port details of the Access Manager 11.1.2.1.0 Server instance, by doing the following:
1. Log in to the Oracle Access Manager 10g Access System console.
2. Go to the Access System Configuration tab.
3. Click Access Server Configuration on the left navigation pane.
4. Click Add to create a new server profile.
5. Specify the following details:
  
  Name: Specify a name for this server.
  
  Hostname: Specify the hostname of the machine on which Access Manager 11.1.2.1.0 Server instance is running.
  
  Port: Specify the proxy port for Access Manager 11.1.2.1.0 Server instance. The default proxy port for Access Manager 11.1.2.1.0 is 5575.
  
  Transport Security: Specify the same transport security mode as that of the Access Manager 11.1.2.1.0 Server instance.
  
  Keep the default values for other parameters.
6. Click Save.
Set the value of MAX Connections parameter of the WebGate (AccessGate) in the WebGate profile such that the WebGate does not establish connection with the Access Manager 11.1.2.1.0 Server after association.

If all of the Oracle Access Manager 10g primary servers are up, set the value of MAX Connections equal to the sum of the number of connections to all the primary Oracle Access Manager 10g servers.

For more information about modifying a WebGate profile, see "Modifying an AccessGate" in the Oracle Access Manager Access Administration Guide for release 10g (10.1.4.3).
Associate each of the WebGates with the Access Manager 11.1.2.1.0 Server as one or more primary servers, by retaining the existing Oracle Access Manager 10g server. Set the number of connections to the Access Manager 11.1.2.1.0 server as 1 or more.

After the inactive reconfiguration period, the WebGate is updated with the new list of servers.
Optional: For each WebGate, make sure that the file ObAccessClient.xml at the location webgate_installation_directory/oblix/lib/ObAccessClient.xml is updated with the host and port of the Access Manager 11.1.2.1.0 Server in the list of primary servers. To do this, open the ObAccessClient.xml file and look for the list of primary servers.
Point the WebGate to the Access Manager 11.1.2.1.0 server by performing one of the following tasks:
- Stop all the Oracle Access Manager 10g Servers. If the number of connections to Oracle Access Manager 10g servers is high, WebGate takes a few minutes to start talking to the Access Manager 11.1.2.1.0 Server. If you restart the web server that hosts the WebGate, WebGate starts talking to the Access Manager 11.1.2.1.0 server immediately.
- Increase the value of the parameter MAX Connections by one, so that the WebGate establishes the connection with Access Manager 11.1.2.1.0 server. If the load on WebGate is more, it takes less time to connect to the Access Manager 11.1.2.1.0 Server.
WebGate now gets the new configuration information from the Access Manager 11.1.2.1.0 Server, which has only one primary server. Thus, the WebGate communicates only with the Access Manager 11.1.2.1.0 server. Once this is done, you can reduce the value of MAX Connections as there is only one server.

11.16 Verifying the Migration

To verify the migration, do the following:

The message "Migration completed successfully" is displayed on the WLST console if the migration is successful.
Verify the migration details like upgraded status, type of migration, timestamp and so on, in the oam-config.xml file that is generated in the following directory:

On UNIX:

MW_HOME/user_projects/domains/Domain_Name/config/fmwconfig/

On Windows:

MW_HOME\user_projects\domains\Domain_Name\config\fmwconfig\
Log in to the Oracle Access Management console using the following URL:
```
http://host:port/oamconsole
```
In this URL, host is the machine on which Access Manager 11.1.2.1.0 is running, and port is the port number.

Verify that the Oracle Access Manager 10g artifacts are migrated to Access Manager 11.1.2.1.0.

Note:

This completes the migration. For more information on managing the Oracle Access Management Access Manager 11.1.2.1.0, see Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

11.17 Troubleshooting

This section describes solutions to the common problems that you might encounter when migration Oracle Access Manager 10g to Access Manager 11.1.2.1.0. It contains the following topics:

Increasing the Size of the Log File to Avoid the Loss of Migration Data
Increasing the Heap Size of the WebLogic Server

11.17.1 Increasing the Size of the Log File to Avoid the Loss of Migration Data

If the size of the log file is too small, the migration data might get lost when the logs files are rotated. To overcome this, you must increase the size of the log file in the WebLogic console by doing the following:

Log in to the WebLogic Administration console using the following URL:
```
http://host:port/console
```
In this URL, host is the hostname of the machine hosting WebLogic Administration Server, and port is the port number of the Administration Server.
Under Domain Structure on the left navigation pane, expand Environment under the respective domain name.
Click Servers.
On the Summary of Servers page, go to the Configuration tab, and click on the name of the Administration Server (For example, AdminServer(admin)).
Go to the Logging tab, and click the General tab.
Specify the right values for the following fields:
1. Rotation file size: Specify the size of the log file in KiloBytes. The maximum value that can be specified is 65535 KB.
2. Files to retain: Specify the number of rotated log files you wish to retain.
Click Save.

11.17.2 Increasing the Heap Size of the WebLogic Server

If the Oracle Access Manager 10g policy data is large in terms of number of various policy related artifacts, the migration tool may need large memory for processing. If the WebLogic Administration Server has small heap size, you can increase it by doing the following:

On UNIX:

Open the setDomainEnv.sh file in any text editor, from the directory MW_HOME/user_projects/domains/Domain_Name/bin/.
Search for the following line:
```
if [ "${USER_MEM_ARGS}" != "" ]
```
Add the following lines just before the line identified in the previous step.
```
USER_MEM_ARGS="new_heap_size"
export USER_MEM_ARGS
```
where, new_heap_size is the new heap size of the WebLogic Administration Server in MegaBytes.

For example, if you wish to increase the heap size of the WebLogic Administration Server to 2GB, specify as shown below:
```
USER_MEM_ARGS="-Xms2048m -Xmx2048m"
export USER_MEM_ARGS
```

On Windows:

Open the setDomainEnv.cmd file in any text editor, from the directory MW_HOME\user_projects\domains\Domain_Name\bin\.
Search for the following line:
```
if NOT "%USER_MEM_ARGS%"=="" (
```
Add the following line just before the line identified in the previous step.
```
set USER_MEM_ARGS="new_heap_size"
```
where, new_heap_size is the new heap size of the WebLogic Administration Server in MegaBytes.

For example, if you wish to increase the heap size of the WebLogic Administration Server to 2GB, specify as shown below:
```
set USER_MEM_ARGS=-Xms2048m -Xmx2048m
```