5 Configuring High Availability for Oracle Identity Manager Components

This chapter describes how to design and deploy a high availability environment for Oracle Identity Manager.

Oracle Identity Manager is a user provisioning and administration solution that automates the process of adding, updating, and deleting user accounts from applications and directories. It also improves regulatory compliance by providing granular reports that attest to who has access to what. Oracle Identity Manager is available as a stand-alone product or as part of Oracle Identity and Access Management Suite.

Automating user identity provisioning can reduce IT administration costs and improve security. Provisioning also plays an important role in regulatory compliance. Key features of Oracle Identity Manager include password management, workflow and policy management, identity reconciliation, reporting and auditing, and extensibility through adapters.

Oracle Identity Manager provides the following functionalities:

• User Administration

• Workflow and Policy

• Password Management

• Audit and Compliance Management

• User Provisioning

• Organization and Role Management

For details about Oracle Identity Manager, see the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

This section includes the following topics:

• Section 5.1, "Oracle Identity Manager Component Architecture"

• Section 5.2, "Oracle Identity Manager High Availability Concepts"

• Section 5.3, "Oracle Identity Manager High Availability Configuration Steps"

5.1 Oracle Identity Manager Component Architecture

Figure 5-1 shows the Oracle Identity Manager architecture:

Figure 5-1 Oracle Identity Manager Component Architecture

Description of "Figure 5-1 Oracle Identity Manager Component Architecture"

5.1.1 Oracle Identity Manager Component Characteristics

Oracle Identity Manager Server is Oracle's self-contained, standalone identity management solution, based on Java EE standards. It provides User Administration, Workflow and Policy, Password Management, Audit and Compliance Management, User Provisioning and Organization and Role Management functionalities.

Oracle Identity Manager is a standard Java EE application that is deployed on Oracle WebLogic Sever and uses a database to store runtime and configuration data. The MDS schema contains configuration information; the runtime and user information is stored in the OIM schema.

Oracle Identity Manager connects to the SOA managed servers over RMI to invoke the SOA EJBs.

Oracle Identity Manager uses the human workflow module of the Oracle SOA Suite to manage its request workflow. Oracle Identity Manager connects to SOA using the T3 URL for the SOA server, which is the front end URL for SOA. Oracle recommends using the load balancer or web server URL for clustered SOA servers. When the workflow completes, SOA calls back Oracle Identity Manager web services using OIMFrontEndURL. Oracle SOA is deployed along with the Oracle Identity Manager.

Several Oracle Identity Manager modules use JMS queues. Each queue is processed by a separate Message Driven Bean (MDB), which is also part of the Oracle Identity Manager application. Message producers are also part of the Oracle Identity Manager application.

Oracle Identity Manager uses embedded Oracle Entitlements Server, which is also part of the Oracle Identity Manager engine. Oracle Entitlements Server (OES) is used for authorization checks inside Oracle Identity Manager. For example, one of the policy constraints determines that only users with certain roles are allowed to create users. This is defined using the Oracle Identity Manager user interface.

Oracle Identity Manager uses a Quartz based scheduler for scheduled activities. There are various scheduled activities that happen in the background. For example, one of the scheduled tasks is to disable users after the end date of the users.

Oracle Identity Manager links to Oracle BI Publisher for all the reporting features. BI Publisher is expected to be in a different domain or same domain, so the integration is only a simple static URL integration. There is no interaction between BI Publisher and Oracle Identity Manager runtime components. BI Publisher is configured to use the same OIM database schema for reporting purposes.

When you enable LDAPSync to communicate directly with external Directory Servers such as Oracle Internet Directory, ODSEE, and Microsoft Active Directory, support for high availability/failover features requires that you configure the Identity Virtualization Library (libOVD).

To configure libOVD, use the WLST command addLDAPHost. To manage libOVD, see Managing Identity Virtualization Library (libOVD) Adapters in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for a list of WLST commands.

5.1.2 Runtime Processes

Oracle Identity Manager is a Java EE application that is deployed on WebLogic Server as a no-stage application. The Oracle Identity Manager server is initialized when the WebLogic Server it is deployed on starts up. As part of the application initialization, the quartz-based scheduler is also started. Once initialization is done, the system is ready to receive requests from clients.

Remote Manager and Design Console need to be started as standalone utilities separately.

5.1.3 Component and Process Lifecycle

Oracle Identity Manager is deployed to an Oracle WebLogic Server as an externally managed application. By default, the WebLogic Server starts, stops, monitors and manages other lifecycle events for the Oracle Identity Manager application.

Oracle Identity Manager is a standard Java EE application that starts after the application server components start. Also, Oracle Identity Manager uses the authenticator which is part of the Oracle Identity Manager component mechanism; it starts up before the WebLogic JNDI are initialized and the application is started. This is loaded from the OIM ORACLE_HOME.

Oracle Identity Manager uses a Quartz technology-based scheduler. Quartz starts the scheduler thread on all the WebLogic Server instances. It uses the database as the centralized storage for picking and running the scheduled activities. If one of the scheduler instances picks up a job, the other instances will not pick up that same job.

Oracle Identity Manager caches certain system configuration values in the cache in memory of the server instance from the database. These caches load independently and are not shared among the servers. Any changes to the system configuration triggers cache cleanup, which notifies all servers in the cluster. Oracle Identity Manager uses oscache, jgroups for this purpose. Jgroups use multicast addresses. A valid multicast address is randomly generated during installation and seeded to the Oracle Identity Manager metadata repository file.

WebLogic Node Manager can be configured to monitor the server process and restart it in case of failure.

The Oracle Enterprise Manager Fusion Middleware Control is used to monitor as well as to modify the configuration of the application.

5.1.4 Starting and Stopping Oracle Identity Manager

You can manage Oracle Identity Manager lifecycle events with one or more of the following command line tools and consoles:

• Oracle WebLogic Scripting Tool (WLST)

• WebLogic Server Administration Console

• Oracle Enterprise Manager Fusion Middleware Control

• Oracle WebLogic Node Manager

5.1.5 Configuration Artifacts

The configuration for the Oracle Identity Manager server is stored in the MDS repository and is managed using MBeans. The oim-config.xml file is the main configuration file. Manage the OIM configuration using the MBean browser through the Oracle Enterprise Manager Fusion Middleware Control or through the command line MDS utilities. The oim-config.xml file is stored in the /db/oim-config.xml location of the MDS repository.

For more information about the MDS utilities, see the MDS utilities section of the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

JMS is configured out-of-the-box by the installer. All the necessary JMS queues, connection pools, data sources and so on are configured on the WebLogic application servers. The following queues are created when Oracle Identity Manager deploys:

• oimAttestationQueue

• oimAuditQueue

• oimDefaultQueue

• oimKernelQueue

• oimProcessQueue

• oimReconQueue

• oimSODQueue

The xlconfig.xml file stores Design Console and Remote Manager configuration.

5.1.6 External Dependencies

Oracle Identity Manager is a Java EE application that is deployed on an Oracle WebLogic Managed Server. Oracle Identity Manager uses the Worklist and Human workflow modules of the Oracle SOA Suite for request flow management. Oracle Identity Manager interacts with external repositories to store configuration and runtime data. Oracle Identity Manager requires these repositories to be available during initialization and during runtime. All Oracle Identity Manager credentials are stored in the OIM repository. The external components required for the Oracle Identity Manager server to function are listed below:

• WebLogic Server

  • Administration Server

  • Managed Server

• Data Repositories

  • Configuration Repository (MDS Schema)

  • Runtime Repository (OIM Schema)

  • User Repository (OIM Schema)

  • SOA Repository (SOA Schema)

• External LDAP Stores (when using LDAP Sync)

• BI Publisher

The Design Console is a tool used by the administrator for development and customization. The Design Console communicates directly with the Oracle Identity Manager engine, so it relies on the same components that the Oracle Identity Manager server relies on.

Remote Manager is an optional independent standalone application, which calls the custom APIs on the local system. So it needs the JAR files for those custom APIs in its classpath.

5.1.7 Oracle Identity Manager Log File Locations

Oracle Identity Manager is a Java EE application deployed on Oracle WebLogic Server. All server related logs messages are logged in the server log file and all Oracle Identity Manager specific messages are logged into the diagnostic log file of the WebLogic Server where the application is deployed.

The WebLogic Server log files are located under the following directory:

DOMAIN_HOME/servers/serverName/logs

The three main log files are serverName.log, serverName.out, and serverName-diagnostic.log, where serverName is the name of the WebLogic Server. For example, if the WebLogic Server name is wls_OIM1, then the diagnostic log file name would be wls_OIM1-diagnostic.log.

You can view the log files using the Oracle Enterprise Manager Fusion Middleware Control.

5.2 Oracle Identity Manager High Availability Concepts

This section provides an introduction to Oracle Identity Management high availability concepts and describes how to design and deploy a high availability environment for Oracle Identity Manager.

Note:

Be aware of the following when you deploy Oracle Identity Manager in a high availability configuration:

• Oracle Identity Manager can be deployed on an Oracle RAC database, but Oracle RAC failover is not transparent for Oracle Identity Manager in this release. If an Oracle RAC failover occurs, end users may have to resubmit their requests.

• Oracle Identity Manager always requires that at least one of the nodes in the SOA cluster be available. If the SOA cluster is not available, end user requests will fail. Oracle Identity Manager does not retry for a failed SOA call. Therefore, the end user must retry when a SOA call fails.

5.2.1 Oracle Identity Manager High Availability Architecture

Figure 5-2 shows Oracle Identity Manager deployed in a high availability architecture in an active-active configuration.

Figure 5-2 Oracle Identity Manager High Availability Architecture

Description of "Figure 5-2 Oracle Identity Manager High Availability Architecture"

On OIMHOST1, the following installations have been performed:

• An Oracle Identity Manager instance has been installed in the WLS_OIM1 Managed Server and a SOA instance has been installed in the WLS_SOA1 Managed Server.

• The Oracle RAC database has been configured in a JDBC multi data source to protect the instance from Oracle RAC node failure.

• A WebLogic Server Administration Server has been installed. Under normal operations, this is the active Administration Server.

On OIMHOST2, the following installations have been performed:

• An Oracle Identity Manager instance has been installed in the WLS_OIM2 Managed Server and a SOA instance has been installed in the WLS_SOA2 Managed Server.

• The Oracle RAC database has been configured in a JDBC multi data source to protect the instance from Oracle RAC node failure.

• The instances in the WLS_OIM1 and WLS_OIM2 Managed Servers on OIMHOST1 and OIMHOST2 are configured as the OIM_Cluster cluster.

• The instances in the WLS_SOA1 and WLS_SOA2 Managed Servers on OIMHOST1 and OIMHOST2 are configured as the SOA_Cluster cluster.

• A WebLogic Server Administration Server has been installed. Under normal operations, this is the passive Administration Server. You make this Administration Server active if the Administration Server on OIMHOST1 becomes unavailable.

The following virtual host names are used in the Oracle Identity Manager high availability configuration in Figure 5-2:

• OIMVHN1 is the virtual hostname that maps to the listen address for the WLS_OIM1 managed server, and it fails over with server migration of the WLS_OIM1 managed server. It is enabled on the node where the WLS_OIM1 managed server is running (OIMHOST1 by default).

• OIMVHN2 is the virtual hostname that maps to the listen address for the WLS_OIM2 managed server, and it fails over with server migration of the WLS_OIM2 managed server. It is enabled on the node where the WLS_OIM2 managed server is running (OIMHOST2 by default).

• SOAVHN1 is the virtual hostname that is the listen address for the WLS_SOA1 managed server, and it fails over with server migration of the WLS_SOA1 managed server. It is enabled on the node where the WLS_SOA1 managed server is running (OIMHOST1 by default).

• SOAVHN2 is the virtual hostname that is the listen address for the WLS_SOA2 managed server, and it fails over with server migration of the WLS_SOA2 managed server. It is enabled on the node where the WLS_SOA2 managed server is running (OIMHOST2 by default).

• VHN refers to the virtual IP addresses for the Oracle Real Application Clusters (Oracle RAC) database hosts.

5.2.2 Starting and Stopping the Oracle Identity Manager Cluster

In a high availability architecture, Oracle Identity Manager is deployed on an Oracle WebLogic cluster that has at least two servers as members of the cluster.

By default, WebLogic Server starts, stops, monitors, and manages the various lifecycle events for the application. The Oracle Identity Manager application leverages the high availability features of the underlying Oracle WebLogic clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

You can use one or more of the following command line tools and consoles to manage Oracle Identity Manager lifecycle events:

• WebLogic Server Administration Console

• Oracle Enterprise Manager Fusion Middleware Control

• Oracle WebLogic Scripting Tool (WLST)

5.2.3 Cluster-Wide Configuration Changes

For high availability environments, changing the configuration of one Oracle Identity Manager instance changes the configuration of all the other instances, because all the Oracle Identity Manager instances share the same configuration repository.

5.2.4 Considerations for Synchronizing with LDAP

Synchronization information between LDAP and the Oracle Identity Manager database is handled by a process called Reconciliation, which is a scheduled process that runs in the background primarily. It is also possible to manually run this process.

If an LDAP outage occurs during the Synchronization process, the data which did not get into Oracle Identity Manager will be picked up during the next run of the reconciliation task.

5.3 Oracle Identity Manager High Availability Configuration Steps

This section provides high-level instructions for setting up a high availability deployment for Oracle Identity Manager.

This section includes the following topics:

• Section 5.3.1, "Prerequisites for Oracle Identity Manager Configuration"

• Section 5.3.2, "Creating and Configuring the WebLogic Domain for OIM and SOA on OIMHOST1"

• Section 5.3.3, "Upgrading Oracle Platform Security Services Schemas"

• Section 5.3.4, "Configuring the Database Security Store for the Domain"

• Section 5.3.5, "Post-Installation Steps on OIMHOST1"

• Section 5.3.6, "Configuring Oracle Identity Manager on OIMHOST1"

• Section 5.3.7, "Post-Configuration Steps for the Managed Servers"

• Section 5.3.8, "Validate the Oracle Identity Manager Instance on OIMHOST1"

• Section 5.3.9, "Propagating Oracle Identity Manager to OIMHOST2"

• Section 5.3.10, "Post-Installation Steps on OIMHOST2"

• Section 5.3.11, "Validate the Oracle Identity Manager Instance on OIMHOST2"

• Section 5.3.12, "Updating SOA Server Default Composite"

• Section 5.3.13, "Configuring Oracle Internet Directory using the LDAP Configuration Post-setup Script"

• Section 5.3.14, "Configuring Server Migration for the OIM and SOA Managed Servers"

• Section 5.3.15, "Configuring a Shared JMS Persistence Store"

• Section 5.3.16, "Configuring a Default Persistence Store for Transaction Recovery"

• Section 5.3.17, "Install Oracle HTTP Server on WEBHOST1 and WEBHOST2"

• Section 5.3.18, "Configuring Oracle Identity Manager to Work with the Web Tier"

• Section 5.3.19, "Validate the Oracle HTTP Server Configuration"

• Section 5.3.20, "Oracle Identity Manager Failover and Expected Behavior"

• Section 5.3.21, "Troubleshooting Oracle Identity Manager High Availability"

• Section 5.3.22, "Scaling Up and Scaling Out the Oracle Identity Manager Topology"

5.3.1 Prerequisites for Oracle Identity Manager Configuration

Before you configure Oracle Identity Manager for high availability, you must:

• Run the Repository Creation Utility to create the OIM schemas in a database. See Section 5.3.1.1, "Running RCU to Create the OIM Schemas in a Database" for instructions.

• Install WebLogic Server on OIMHOST1 and OIMHOST2. See Section 5.3.1.1.1, "Installing Oracle WebLogic Server" for instructions.

• Install the Oracle SOA Suite on OIMHOST1 and OIMHOST2. See Section 5.3.1.2, "Installing the Oracle SOA Suite on OIMHOST1 and OIMHOST2" for instructions.

• Install the Oracle Identity Management software on OIMHOST1 and OIMHOST2. See Section 5.3.1.3, "Installing the Oracle Identity Manager on OIMHOST1 and OIMHOST2" for instructions.

• Ensure that a highly available LDAP implementation is available.

  Note:

  This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Management.

  If you are not planning to enable the LDAPSync option or to integrate with Oracle Access Management, you can skip this section.

  Note that Oracle Identity Manager does not communicate directly with Oracle Internet Directory. It communicates with Oracle Virtual Directory, which communicates with Oracle Internet Directory.

• Create the wlfullclient.jar file on OIMHOST1 and OIMHOST2.

  Oracle Identity Manager requires the wlfullclient.jar library for certain operations. For example, the Design Console uses the library for server connections. Oracle does not ship this library; you must create it manually. Oracle recommends creating this library under the MW_HOME/wlserver_10.3/server/lib directory on all the machines in the application tier of your environment. You do not need to create this library on directory tier machines such as OIDHOST1, OIDHOST2, OVDHOST1 and OVDHOST2. See Developing a WebLogic Full Client in the guide Oracle Fusion Middleware Programming Stand-alone Clients for Oracle WebLogic Server for more information.

  To create the wlfullclient.jar file:

  1. Go to the MW_HOME/wlserver_10.3/server/lib directory.

  2. Set your JAVA_HOME to MW_HOME/jdk160_18 and ensure that your JAVA_HOME/bin directory is in your path.

  3. Create the wlfullclient.jar file by running:

     java -jar wljarbuilder.jar

5.3.1.1 Running RCU to Create the OIM Schemas in a Database

Before you can install the Oracle Identity Manager and SOA instances on OIMHOST1 and OIMHOST2, you must use the Repository Creation Utility (RCU) to create the collection of schemas used by Oracle Identity Manager.

RCU ships on its own CD as part of the Oracle Fusion Middleware 11g kit.

To run RCU and create the Oracle Identity Manager schemas in an Oracle RAC database repository:

1. Issue this command:

   prompt> RCU_HOME/bin/rcu &
   

2. On the Welcome screen, click Next.

3. On the Create Repository screen, select the Create operation to load the component schemas into an existing database.

   Click Next.

4. On the Database Connection Details screen, enter connection information for the existing database as follows:

   • Database Type: Oracle Database

   • Host Name: Name of the computer on which the database is running. For an Oracle RAC database, specify the VIP name or one node name. Example: OIMDBHOST1-VIP or OIMDBHOST2-VIP

   • Port: The port number for the database. For example: 1521

   • Service Name: The service name of the database. For example: oim.example.com

   • Username: SYS

   • Password: The SYS user password

   • Role: SYSDBA

   Click Next.

5. Click OK on the Checking Prerequisites screen after the Global Prerequisites complete successfully.

6. On the Select Components screen, create a new prefix and select the components to be associated with this deployment:

   Create a New Prefix: ha

   Components:

   • Under Identity Management:

     • Oracle Identity Manager - OIM

     • Oracle Platform Security Services - OPSS

     • Note that Metadata Services - MDS is selected by default.

   • Under SOA and BAM Infrastructure:

     • SOA Infrastructure - SOAINFRA is selected by default.

     • User Messaging Service - ORASDPM is selected by default.

   Click Next.

7. Click OK on the Checking Prerequisites screen after the Component Prerequisites complete successfully.

8. On the Schema Passwords screen, enter the passwords for the mail and additional (auxiliary) schema users.

   Click Next.

9. On Map Tablespaces screen, select the tablespaces for the components.

10. On the Summary screen, click Create.

11. On the Completion Summary screen, click Close.

5.3.1.1.1 Installing Oracle WebLogic Server

Prior to installing the WebLogic Server, ensure that your machines meet the system, patch, kernel, and other requirements that the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server specifies.

Start the installer, then perform these steps on OIMHOST1 and OIMHOST2:

1. On the Welcome screen, click Next.

2. On the Choose Middleware Home Directory screen, select Create a New Middleware Home.

   For Middleware Home Directory, enter:

   ORACLE_BASE/product/fmw

   Note:

   ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

   Click Next.

3. On the Register for Security Updates screen, enter your contact information so that you can be notified of security updates.

   Click Next.

4. On the Choose Install Type screen, select Custom.

   Click Next.

5. On the Choose Products and Components screen, select only Oracle JRockit SDK, and click Next.

6. On the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3.

   Click Next.

7. On the Installation Summary screen, click Next.

8. On the Installation Complete screen, deselect Run Quickstart.

   Click Done.

5.3.1.2 Installing the Oracle SOA Suite on OIMHOST1 and OIMHOST2

Perform these steps to install Oracle Fusion Middleware Components on OIMHOST1 and OIMHOST2.

If the /etc/oraInst.loc file exists, verify that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware Component as follows:

HOST1> runInstaller

When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit_160_14_<version>.

Then proceed as follows:

1. On the Welcome screen, click Next.

2. On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.

3. On the Specify Installation Location screen, enter the following values:

   • Oracle Middleware Home: Select the previously installed Middleware home from the list for MW_HOME, for example

     /u01/app/oracle/product/fmw

   • Oracle Home Directory:

     • Enter soa as the Oracle home directory name when installing the Oracle SOA Suite in the ORACLE_HOME

   Click Next.

4. On the Installation Summary screen, click Install.

5. On the Installation Complete screen, click Finish.

5.3.1.3 Installing the Oracle Identity Manager on OIMHOST1 and OIMHOST2

Perform these steps to install Oracle Fusion Middleware Components on OIMHOST1 and OIMHOST2.

If the /etc/oraInst.loc file exists, verify that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware Component as follows:

HOST1> runInstaller

When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit_160_<version>.

Then proceed as follows:

1. On the Welcome screen, click Next.

2. On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.

3. On the Specify Installation Location screen, enter the following values:

   • Oracle Middleware Home: Select the previously installed Middleware home from the list for MW_HOME, for example

     /u01/app/oracle/product/fmw

   • Oracle Home Directory:

     • Enter iam as the Oracle home directory name when installing the Oracle Identity and Access Management Suite in the ORACLE_HOME

   Click Next.

4. On the Installation Summary screen, click Install.

5. On the Installation Complete screen, click Finish.

5.3.2 Creating and Configuring the WebLogic Domain for OIM and SOA on OIMHOST1

To create the domain on OIMHOST1:

1. Start the Configuration Wizard by running this command:

   MW_HOME/oracle_common/common/bin/config.sh
   

2. On the Welcome screen, select Create a WebLogic Domain.

   Click Next.

3. On the Select Domain Source screen, select Generate a domain configured automatically to support the following added products.

   From the list, select:

   • Oracle Identity Manager

     Note that Oracle SOA Suite, Oracle Enterprise Manager, Oracle Platform Security Service, Oracle JRF, Oracle JRF WebServices Asynchronous services, and Oracle WSM Policy Manager are selected automatically.

   • Oracle Enterprise Manager

     Note that Oracle JRF is selected automatically.

4. On the Specify Domain Name and Location screen, enter the name and location for the domain and all its applications.

   Provide the following:

   • Domain Name: IDMDomain

   • Domain Location: Accept the default.

   • Application Location: Accept the default.

   Click Next.

5. On the Configure Administration Server Username and Password screen, provide the following:

   • Name: weblogic

   • User Password: Enter the password for the weblogic user.

   • Confirm User Password: Enter the password for the weblogic user.

   • Description: Provide a description for the user.

   Click Next.

6. On the Configure Server Start Mode and JDK screen, select Production Mode and JRockit SDK 1.6.n.

   Click Next.

7. On the Configure JDBC Component Schemas screen, select the Component Schemas shown below:

   • SOA Infrastructure

   • User Messaging Service

   • OIM MDS Schema

   • OWSM MDS Schema

   • SOA MDS Schema

   • OIM Infrastructure

   • OPSS Schema

   Select the check box next to Configure selected component schemas as RAC multi data source schemas in the next panel.

   Note:

   You can also use GridLink data sources. See Section 3.13, "GridLink Data Sources" for more information.

   Click Next.

8. On the Configure RAC Multi Data Source Component Schemas screen, select all the multi data source schemas and enter the following:

   • Service Name: oim.example.com

   • For the first RAC node:

     • Host Name: OIMDBHOST1-VIP.example.com

     • Instance Name: oimdb1

     • Port: 1521

   • For the second RAC node:

     • Host Name: OIMDBHOST2-VIP.example.com

     • Instance Name: oimdb2

     • Port: 1521

   Select each schema individually and enter the schema's username and password, as shown in Table 5-1:

   Table 5-1 Entering the Schema Owner and Password for Each multi data Source Schema

   Schema Name	Schema Owner	Password
   SOA Infrastructure	HA_SOAINFRA	<enter the password>
   User Messaging Service	HA_ORASDPM	<enter the password>
   OIM MDS Schema	HA_MDS	<enter the password>
   OWSM MDS Schema	HA_MDS	<enter the password>
   SOA MDS Schema	HA_MDS	<enter the password>
   OIM Schema	HA_OIM	<password>
   OPSS Schema	HA_OPSS	<password>

   
   

   Click Next.

9. On the Test Component Schema screen, select All the Schemas and then click Test Connections. Validate that the test for all the schemas completed successfully.

   Click Next.

10. On the Select Optional Configuration screen, select:

    • Administration Server

    • JMS Distributed Destination (required only on the domain that has OIM)

    • Managed Servers, Clusters and Machines

    • JMS File Store (required only on the domain that has OIM)

    Click Next.

11. In the Configure the Administration Server screen, enter the following values:

    • Name: AdminServer

    • Listen Address: oimhost1.example.com

    • Listen Port: 7001

    • SSL listen port: Not applicable

    • SSL enabled: Leave unchecked

    Click Next.

12. On the Select JMS Distributed Destination Type screen, ensure that all JMS System Resources listed are Uniform Distributed Destinations. If they are not, select UDD from the drop down box. Validate that the entries look like those in Table 5-2:

    Table 5-2 Values to Choose for JMS System Resources

    JMS System Resource	Uniform/Weighted Distributed Destination
    UMSJMSSystemResource	UDD
    SOAJMSModule	UDD
    OIMJMSModule	UDD
    BPMJMSModule	UDD

    
    

    Click Next.

    An Override Warning box with the following message opens:

    "CFGFWK-40915: At least one JMS system resource has been selected for conversion to a Uniform Distributed Destination (UDD). This conversion will take place only if the JMS System resource is assigned to a cluster."

    Click OK on the Warning box.

13. When you first enter the Configure Managed Servers screen, the configuration wizard will have created two default managed servers (oim_server1 and soa_server1) for you. Change the details of the default managed servers and then add the second managed server. Follow the steps below:

    For the oim_server1 entry, change the entry to the following values:

    • Name: WLS_OIM1

    • Listen Address: OIMVHN1

    • Listen Port: 14000

    For the soa_server1 entry, change the entry to the following values:

    • Name: WLS_SOA1

    • Listen Address: SOAVHN1

    • Listen Port: 8001

    For the second OIM Server, click Add and supply the following information:

    • Name: WLS_OIM2

    • Listen Address: OIMVHN2

    • Listen Port: 14000

    For the second SOA Server, click Add and supply the following information:

    • Name: WLS_SOA2

    • Listen Address: SOAVHN2

    • Listen Port: 8001

    Click Next.

    Note:

    Follow the steps for adding the second managed server to add additional managed servers.

14. On the Configure Clusters screen, create two clusters by clicking Add.

    Supply the following information for the OIM Cluster:

    • Name: oim_cluster

    • Cluster Messaging Mode: unicast

    • Cluster Address: oimhost1:14000,oimhost2:14000

    Supply the following information for the SOA Cluster:

    • Name: soa_cluster

    • Cluster Messaging Mode: unicast

    • Cluster Address: oimhost1:8001,oimhost2:8001

    Leave all the other fields at the default settings and click Next.

15. On the Assign Servers to Clusters screen, associate the managed servers with the cluster. Click on the cluster name in the right window.

    Click on the managed server under servers, then click on the arrow to assign it to the cluster.

    Assign the WLS_OIM1 and WLS_OIM2 managed servers to be members of the oim_cluster.

    Assign the WLS_SOA1 and WLS_SOA2 managed servers to be members of the soa_cluster.

    Click Next.

16. On the Configure Machines screen, create a machine for each host in the topology.

    Click on the Unix tab if your hosts use a Unix operating system or click Machines.

    Provide the following information:

    • Name: Name of the host. A good practice is to use the DNS name here.

    • Node Manager Listen Address: Enter the DNS name of the machine here.

    • Node Manager Port: Supply a port for Node Manager to use.

    Click Next.

    Note:

    On UNIX, delete the default local machine entry under the Machines tab.

17. On the Assign Servers to Machines screen, you assign the managed servers that will run on the machines you just created. Follow these steps:

    Click on a machine in the right hand window.

    Click on the managed servers you want to run on that machine in the left window.

    Click on the arrow to assign the managed servers to the machine.

    Repeat these steps until all managed servers are assigned to the appropriate machine.

    A typical example would be:

    • Host1: Admin Server, WLS_OIM1, and WLS_SOA1

    • Host2: WLS_OIM2 and WLS_SOA2

    Click Next.

18. On the Configure JMS File Stores screen, update the directory locations for the JMS file stores. Enter the following values:

    Name	Directory
    UMSJMSFileStore_auto_1	/u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_1
    UMSJMSFileStore_auto_2	/u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_2
    BPMJMSFileStore_auto_1	/u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_1
    BPMJMSFileStore_auto_2	/u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_2
    JRFWSAsyncFileStore_auto_1	/u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_1
    JRFWSAsyncFileStore_auto_2	/u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_2
    SOAJMSFileStore_auto_1	/u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_1
    SOAJMSFileStore_auto_2	/u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_2
    OIMJMSFileStore_auto_1	/u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_1
    OIMJMSFileStore_auto_2	/u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_2
    PS6SOAJMSFileStore_auto_1	/u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_1
    PS6SOAJMSFileStore_auto_2	/u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_2

    
    

19. On the Configuration Summary screen, click Create to create the domain.

5.3.3 Upgrading Oracle Platform Security Services Schemas

You must upgrade the Oracle Platform Security Services schemas using Patch Set Assistant. To do this, complete the following steps:

1. Start the Patch Set Assistant from the location MW_HOME/oracle_common/bin using the following command:

   ./psa

2. Select opss.

3. Specify the Database connection details and select the schema to be upgraded.

4. After you upgrade Oracle Platform Security Services schema, verify the upgrade by checking the log file at the location MW_HOME/oracle_common/upgrade/logs/psa<timestamp>.log

   The timestamp refers to the actual date and time when Patch Set Assistant was run. If the upgrade fails, check the log files to fix the errors and run the Patch Set Assistant again.

5.3.4 Configuring the Database Security Store for the Domain

The Database Security Store contains security policies, audit meta-data, credentials, keys, and other security artifacts managed by OPSS. It facilitates high availability by serving as the single point of truth for policies in a topology, regardless of the domain organization (single, multiple, or extended).

You must configure the Database Security Store after you configure the domain but before you start the Administration Server. See Configuring Database Security Store for an Oracle Identity and Access Management Domain in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management for more information.

5.3.5 Post-Installation Steps on OIMHOST1

This section describes the post-installation steps to perform on OIMHOST1. It includes these topics:

• Section 5.3.5.2, "Update Node Manager on OIMHOST1"

• Section 5.3.5.3, "Start Node Manager on OIMHOST1"

• Section 5.3.5.4, "Start the Administration Server on OIMHOST1"

5.3.5.1 Creating boot.properties for the Administration Server on OIMHOST1

This section describes how to create a boot.properties file for the Administration Server on OIMHOST1. The boot.properties file enables the Administration Server to start without prompting for the administrator username and password.

To create the boot.properties file:

1. On OIMHOST1, create the following directory:

   MW_HOME/wlserver_10.3/server/bin
   

   For example:

   $ mkdir -p 
   MW_HOME/user_projects/domains/domainName/servers/AdminServer/security
   

2. Use a text editor to create a file called boot.properties under the security directory. Enter the following lines in the file:

   username=adminUser
   password=adminUserPassword
   

   Note:

   When you start the Administration Server, the username and password entries in the file get encrypted.

   For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, you should start the server as soon as possible so that the entries get encrypted.

5.3.5.2 Update Node Manager on OIMHOST1

Before you start the managed servers using the Administration Console, Node Manager requires that the StartScriptEnabled property be set to true.

To do this, run the setNMProps.sh script located under the following directory:

MW_HOME/oracle_common/common/bin

5.3.5.3 Start Node Manager on OIMHOST1

Start the Node Manager on OIMHOST1 using the startNodeManager.sh script located under the following directory:

MW_HOME/wlserver_10.3/server/bin

5.3.5.4 Start the Administration Server on OIMHOST1

Follow these steps to start the Administration Server and validate its startup:

1. Start the Administration Server on OIMHOST1 by issuing the command:

   DOMAIN_HOME/bin/startWebLogic.sh
   

2. Validate that the Administration Server started up successfully by opening a web browser and accessing the following pages:

   • Administration Console at:

     http://oimhost1.example.com:7001/console
     

   • Oracle Enterprise Manager Fusion Middleware Control at:

     http://oimhost1.example.com:7001/em
     

   Log into these consoles using the weblogic user credentials.

5.3.6 Configuring Oracle Identity Manager on OIMHOST1

This section describes how to configure the Oracle Identity Manager and SOA managed servers before starting them.

This section includes the following topics:

• Section 5.3.6.1, "Prerequisites for Configuring Oracle Identity Manager"

• Section 5.3.6.2, "Updating the Coherence Configuration for the Coherence Cluster"

• Section 5.3.6.3, "Running the Oracle Identity Management Configuration Wizard"

5.3.6.1 Prerequisites for Configuring Oracle Identity Manager

Before configuring Oracle Identity Manager, ensure that the following tasks have been performed:

Note:

This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Management.

If you are not planning to enable the LDAPSync option or to integrate with Oracle Access Management, you can skip this section.

1. "Extending the Directory Schema for Oracle Identity Manager"

2. "Creating Users and Groups for Oracle Identity Manager"

3. "Creating Adapters in Oracle Virtual Directory"

Extending the Directory Schema for Oracle Identity Manager

Pre-configuring the Identity Store extends the schema in the back end directory regardless of directory type.

To pre-configure the Identity Store, perform these steps on OIMHOST1:

1. Set the environment variables MW_HOME, JAVA_HOME and ORACLE_HOME.

   Set ORACLE_HOME to IAM_ORACLE_HOME.

2. Create a properties file extend.props that contains the following:

   IDSTORE_HOST : idstore.example.com
   

   IDSTORE_PORT : 389
   

   IDSTORE_BINDDN: cn=orcladmin
   

   IDSTORE_USERNAMEATTRIBUTE: cn
   

   IDSTORE_LOGINATTRIBUTE: uid
   

   IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com
   

   IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com
   

   IDSTORE_SEARCHBASE: dc=example,dc=com
   

   IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
   

   Where:

   • IDSTORE_HOST and IDSTORE_PORT are, respectively, the host and port of your Identity Store directory. If you are using a non-OID directory, then specify the Oracle Virtual Directory host (which should be IDSTORE.example.com.)

   • IDSTORE_BINDDN is an administrative user in the Identity Store Directory

   • IDSTORE_USERSEARCHBASE is the location in the directory where Users are Stored.

   • IDSTORE_GROUPSEARCHBASE is the location in the directory where Groups are Stored.

   • IDSTORE_SEARCHBASE is the location in the directory where Users and Groups are stored.

   • IDSTORE_SYSTEMIDBASE is the location of a container in the directory where users can be placed when you do not want them in the main user container. This happens rarely but one example is the Oracle Identity Manager reconciliation user which is also used for the bind DN user in Oracle Virtual Directory adapters.

3. Configure the Identity Store using the command idmConfigTool which is located at IAM_ORACLE_HOME/idmtools/bin.

   The command syntax is:

   idmConfigTool.sh -preConfigIDStore input_file=configfile

   For example:

   idmConfigTool.sh -preConfigIDStore input_file=extend.props
   

   After the command runs, the system prompts you to enter the password of the account with which you are connecting to the ID Store.

   Sample command output:

   ./preconfig_id.sh 
   Enter ID Store Bind DN password : 
   Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
   INFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif
   Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
   INFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif
   Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
   INFO: -> LOADING:
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif
   Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif
   The tool has completed its operation. Details have been logged to automation.log
   

4. Check the log file for any errors or warnings and correct them.

Creating Users and Groups for Oracle Identity Manager

Follow the steps in the procedure to add the oimadmin user to the Identity Store and assign it to an Oracle Identity Manager administrative group. You must also create a user outside of the standard cn=Users location to perform reconciliation. Oracle recommends that you select this user as the bind DN when connecting to directories with Oracle Virtual Directory.

Note:

This command also creates a container in your Identity Store for reservations.

To add the xelsysadm user to the Identity Store and assign it to an administrative group, perform the following tasks on OIMHOST1:

1. Set the Environment Variables: MW_HOME, JAVA_HOME, IDM_HOME, and ORACLE_HOME

   Set IDM_HOME to IDM_ORACLE_HOME

   Set ORACLE_HOME to IAM_ORACLE_HOME

2. Create a properties file oim.props that contains the following:

   IDSTORE_HOST : idstore.example.com
   

   IDSTORE_PORT : 389
   

   IDSTORE_BINDDN : cn=orcladmin
   

   IDSTORE_USERNAMEATTRIBUTE: cn
   

   IDSTORE_LOGINATTRIBUTE: uid
   

   IDSTORE_USERSEARCHBASE:cn=Users,dc=example,dc=com
   

   IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com
   

   IDSTORE_SEARCHBASE: dc=example,dc=com
   

   POLICYSTORE_SHARES_IDSTORE: true
   

   IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
   

   IDSTORE_OIMADMINUSER: oimadmin
   

   IDSTORE_OIMADMINGROUP:OIMAdministrators
   

   Where:

   • IDSTORE_HOST and IDSTORE_PORT are, respectively, the host and port of your Identity Store directory. Specify the back-end directory here, rather than OVD.

   • IDSTORE_BINDDN is an administrative user in the Identity Store Directory

   • IDSTORE_OIMADMINUSER is the name of the administration user you would like to use to log in to the Oracle Identity Manager console.

   • IDSTORE_OIMADMINGROUP is the name of the group you want to create to hold your Oracle Identity Manager administrative users.

   • IDSTORE_USERSEARCHBASE is the location in your Identity Store where users are placed.

   • IDSTORE_GROUPSEARCHBASE is the location in your Identity Store where groups are placed.

   • IDSTORE_SYSTEMIDBASE is the location in your directory where the Oracle Identity Manager reconciliation user are placed.

   • POLICYSTORE_SHARES_IDSTORE is set to true if your Policy and Identity stores are in the same directory. If not, it is set to false.

3. Configure the Identity Store by using the command idmConfigTool located at IAM_ORACLE_HOME/idmtools/bin:

   idmConfigTool.sh -prepareIDStore mode=OIM input_file=configfile

   For example:

   idmConfigTool.sh -prepareIDStore mode=OIM input_file=oim.props
   

   When the command runs, the system prompts you for the account password with which you are connecting to the Identity Store. The system also requests the passwords you want to assign to the accounts:

   IDSTORE_OIMADMINUSER
   oimadmin
   

   Oracle recommends that you set oimadmin to the same value as the account you create as part of the Oracle Identity Manager configuration.

   Sample command output:

   Enter ID Store Bind DN password : 
   *** Creation of oimadmin ***
   Apr 5, 2011 4:58:51 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
   INFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_user_template.ldif
   Enter User Password for oimadmin: 
   Confirm User Password for oimadmin: 
   Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
   INFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_template.ldif
   Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_member_template.ldif
   Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
   INFO: -> LOADING:
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_groups_acl_template.ldif
   Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
   INFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_reserve_template.ldif
   *** Creation of Xel Sys Admin User ***
   Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: 
   

   /u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_user_template.ldif
   Enter User Password for xelsysadm: 
   Confirm User Password for xelsysadm: 
   The tool has completed its operation. Details have been logged to /home/oracle/idmtools/oim.log
   

4. Check the log file for errors and warnings and correct them.

Creating Adapters in Oracle Virtual Directory

Oracle Identity Manager uses Oracle Virtual Directory to connect to external LDAP stores. You must create a user adapter and a change log adapter in Oracle Virtual Directory to enable Oracle Identity Manager to connect to the external LDAP store, such as Oracle Internet Directory. Follow these steps to create the adapters.

Note:

Creating adapters in Oracle Virtual Directory is not required if your implementation is Oracle Internet Directory only.

User Adapter

Create the user adapter on the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2 individually.

To create the User Adapter in Oracle Virtual Directory using Oracle Directory Services Manager:

1. Open a browser and bring up the ODSM console at http://admin.example.com/odsm.

   Note:

   Although Oracle Directory Services Manager is not shown in Figure 5-2, it is required to manage Oracle Internet Directory and Oracle Virtual Directory. Oracle Directory Services Manager must exist in your environment.

2. Create connections to each of the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2, if they do not already exist

3. Connect to each Oracle Virtual Directory instance by using the appropriate connection entry.

4. On the Home page, click the Adapter tab.

5. Start the New Adapter Wizard by clicking Create Adapter at the top of the adapter window.

6. Create a new adapter using the New Adapter Wizard, with the following parameters:

   Note:

   If you created a User Adapter previously, skip the steps to create the Adapter and follow the steps to edit the Adapter.

   Screen	Field	Value/Step
   Type	Adapter Type	LDAP
   	Adapter Name	User Adapter
   	Adapter Template	User_OID
   Connection	Use DNS Setting	No
   	Host	oid.example.com
   	Port	389
   	Server Proxy Bind DN	cn=oimadmin,cn=systemids,dc=example,dc=com
   	Proxy Password	oimadmin password. This is the same password in "Extending the Directory Schema for Oracle Identity Manager".
   Connection Test		Validate that the test succeeds.
   Namespace	Remote Base	dc=example,dc=com
   	Mapped Namespace	dc=example,dc=com
   Summary		Verify that the summary is correct and then click Finish.

   
   

7. Edit the User Adapter as follows:

   1. Select the OIM User Adapter.

   2. Click the Plug-ins Tab.

   3. Click the User Management Plug-in, then click Edit in the plug-ins table. The plug-in editing window appears.

   4. In the Parameters table, update the parameter values as follows:

      Parameter	value
      directoryType	oid
      pwdMaxFailure	10
      oamEnabled	true

      
      

   5. Click OK.

   6. Click Apply.

Change Log Adapter

Create the change log adapter on the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2 individually. Follow these steps to create the Change Log Adapter in Oracle Virtual Directory using Oracle Directory Services Manager.

1. Open a browser and bring up the ODSM console at http://admin.example.com/odsm.

2. Create connections to each of the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2, if they do not already exist.

3. Connect to an Oracle Virtual Directory instance by using the appropriate connection entry.

4. On the Home page click on the Adapter tab.

5. Start the New Adapter Wizard by clicking Create Adapter at the top of the adapter window.

6. Create a new adapter using the New Adapter Wizard and the following parameters:

   Screen	Field	Value/Step
   Type	Adapter Type	LDAP
   	Adapter Name	OIM Change Log Adapter
   	Adapter Template	Changelog_OID
   Connection	Use DNS Setting	No
   	Host	oid.example.com
   	Port	389
   	Server Proxy Bind DN	cn=oimadmin,cn=systemids,dc=example,dc=com
   	Proxy Password	oimadmin password. This is the same password provided in "Extending the Directory Schema for Oracle Identity Manager".
   Connection Test		Validate that the test succeeds.
   Naming Space	Remote Base	cn=changelog
   Mapped Namespace		cn=changelog
   Summary		Verify that the summary is correct then click Finish.

   
   

7. To edit the change adapter, follow these steps.

   1. Select the OIM Change Log Adapter.

   2. Click the Plug-ins tab.

   3. In the Deployed Plus-ins table, click the changelog plug-in, then click "Edit in the plug-ins table. The plug-in editing window appears.

   4. In the Parameters table, update the parameter values.

   5. Click OK.

   6. Click Apply.

   Edit the Change Log Adapter to either add or modify the properties so that they match the values shown in the following table. You must add the mapObjectclass, modifierDNFilter, sizeLimit, and targetDNFilter proprieties to the adapter.

   Parameter	Value
   directoryType	oid
   mapAttribute	targetGUID=orclguid
   requiredAttribute	orclguid
   modifierDNFilter	cn=oimadmin,cn=systemids,dc=example,dc=com
   sizeLimit	1000
   targetDNFilter	dc=example,dc=com Search based from which reconciliation needs to happen. This value must be the same as the LDAP SearchDN that is specified during OIM installation.
   mapUserState	true
   oamEnabled	true

   
   

Stopping and Starting Oracle Internet Directory and Oracle Virtual Directory

Stop and Start:

• The Oracle Virtual Directory instances running on both OVDHOST1 and OVDHOST2.

• The Oracle Internet Directory instances running on both OIDHOST1 and OIDHOST2.

5.3.6.2 Updating the Coherence Configuration for the Coherence Cluster

Follow the steps below to update the Coherence configuration for the SOA managed servers:

1. Log into the Administration Console.

2. In the Domain Structure window, expand the Environment node.

3. Click Servers. The Summary of Servers page appears.

4. Click the name of the server (represented as a hyperlink) in the Name column of the table. The settings page for the selected server appears.

5. Click the Server Start tab.

6. Enter the following for WLS_SOA1 and WLS_SOA2 into the Arguments field.

   For WLS_SOA1, enter the following (on a single line, without a carriage return):

   -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1
   

   For WLS_SOA2, enter the following (on a single line, without a carriage return):

   -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1
   

7. Click Save and activate the changes.

   This change requires that you restart the SOA servers.

5.3.6.3 Running the Oracle Identity Management Configuration Wizard

You must configure the Oracle Identity Manager server instances before you can start the Oracle Identity Manager managed servers. You perform these configuration steps only once, for example, during the initial creation of the domain. The Oracle Identity Management Configuration Wizard loads the OIM metadata into the database and configures the instance.

Before running the Configuration Wizard, you must verify the following:

• The administration server is up and running.

• You have set coherence for wls_soa1.

• wls_soa1 is running.

• The environment variables DOMAIN_HOME and WL_HOME are not set in the current shell.

The Oracle Identity Management Configuration Wizard is located under the Identity Management Oracle home. Type:

IAM_ORACLE_HOME/bin/config.sh

Proceed as follows:

1. On the Welcome screen, click Next

2. On the Components to Configure screen, select OIM Server. Select OIM Remote Manager, if required in your topology.

   Click Next.

3. On the Database screen, provide the following values:

   • Connect String: The connect string for the OIM database. For example:

     oimdbhost1-vip.example.com:1521:oimdb1^oimdbhost2-vip.example.com:1521:[e-mail]

   • OIM Schema User Name: HA_OIM

   • OIM Schema password: password

   • MDS Schema User Name: HA_MDS

   • MDS Schema Password: password

   Select Next.

4. On the WebLogic Administration Server screen, provide the following details for the WebLogic Administration Server:

   • URL: The URL to connect to the WebLogic Administration Server. For example: t3://oimhost1.example.com:7001

   • UserName: weblogic

   • Password: Password for the weblogic user

   Click Next.

5. On the OIM Server screen, enter the following values:

   • OIM Administrator Password: Password for the OIM Administrator. This is the password for the xelsysadm user, the same password you entered earlier for idmconfigtool.

   • Confirm Password: Confirm the password·

   • OIM HTTP URL: Proxy URL for the OIM Server. This is the URL for the Hardware load balancer that is front ending the OHS servers for OIM. For example: http://oiminternal.example.com:80.

   • Key Store Password: Key store password. The password must have an uppercase letter and a number. For example: MyPassword1

   Click Next.

6. On the LDAP Sync and OAM screen, select Configure BI Publisher and provide the BI Publisher URL, if required in your environment. Enter the URL to connect to the BI Publisher in your environment.

   Select Enable LDAP Sync.

   Notes:

   • Do not select Enable Identity Administration Integration with OAM.

   • BI Publisher is not a part of the IDMDomain.

   Click Next.

7. On the LDAP Server screen, provide the following LDAP server details:

   • Directory Server Type: The directory server type. Select OID, ACTIVE_DIRECTORY, IPLANET, or OVD. The default is OID.

   • Directory Server ID: The directory server ID.

   • Server URL: The URL to access the LDAP server. For example: ldap://ovd.example.com:389 if you use the Oracle Virtual Directory Server, ldap://oid.example.com:389 if you use Oracle Internet Directory.

   • Server User: The username to connect to the server. For example: cn=orcladmin·

   • Server Password: The password to connect to the LDAP server.

   • Server SearchDN: The Search DN. For example: dc=example,dc=com.

   Click Next.

8. On the LDAP Server Continued screen, enter the following LDAP server details:

   • LDAP Role Container: The DN for the Role Container. This is the container where the OIM roles are stored. For example: cn=Groups,dc=example,dc=com ·

   • LDAP User Container: The DN for the User Container. This is the container where the OIM users are stored. For example: cn=Users,dc=example,dc=com·

   • User Reservation Container: The DN for the User Reservation Container.

     Note:

     Use the same container DN Values that idmconfigtool creates during the procedure "Creating Users and Groups for Oracle Identity Manager."

   Click Next.

9. On the Remote Manager screen, provide the following values:

   Note:

   This screen appears only if you selected the Remote Manager utility in step 2.

   • Service Name: HA_RManager

   • RMI Registry Port: 12345

   • Listen Port (SSL): 12346

10. On the Configuration Summary screen, verify the summary information.

    Click Configure to configure the Oracle Identity Manager instance.

11. On the Configuration Progress screen, once the configuration completes successfully, click Next.

12. On the Configuration Complete screen, view the details of the Oracle Identity Manager Instance configured.

    Click Finish to exit the Configuration Assistant.

13. Stop the WebLogic Administration Server.

14. Start the WebLogic Administration Server.

5.3.7 Post-Configuration Steps for the Managed Servers

This section describes post-configuration procedure for the managed servers.

5.3.7.1 Start the WLS_SOA1 and WLS_OIM1 Managed Servers on OIMHOST1

To start the WLS_SOA1 and WLS_OIM1 managed servers on OIMHOST1:

1. Stop the WebLogic Administration Server on OIMHOST1. Use the WebLogic Administration Console to do this

2. Start the WebLogic Administration Server on OIMHOST1 using the startWebLogic.sh script under the DOMAIN_HOME/bin directory. For example:

   /u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&
   

3. Validate that the WebLogic Administration Server started up successfully by bringing up the WebLogic Administration Console.

4. Restart the WLS_SOA1 managed server using the WebLogic Administration Console.

5. Start the WLS_OIM1 managed server using the WebLogic Administration Console.

5.3.8 Validate the Oracle Identity Manager Instance on OIMHOST1

Validate the Oracle Identity Manager Server instance on OIMHOST1 by bringing up the Oracle Identity Manager Console using a web browser.

The URL for the Oracle Identity Manager Console is:

http://identityvhn1.example.com:14000/identity

Log in using the xelsysadm password.

5.3.9 Propagating Oracle Identity Manager to OIMHOST2

Once the configuration has succeeded on OIMHOST1, the configuration can be propagated to OIMHOST2. This is done by packing the domain on OIMHOST1 and then unpacking it on OIMHOST2.

Follow these steps to pack the domain on OIMHOST1 and unpack it on OIMHOST2:

1. On OIMHOST1, invoke the pack utility in the ORACLE_HOME/oracle_common/common/bin directory:

   pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
   template =/u01/app/oracle/admin/templates/oim_domain.jar -
   template_name="OIM Domain" -managed=true
   

2. The previous step created the oim_domain.jar file in the following directory:

   /u01/app/oracle/admin/templates
   

   Copy the oim_domain.jar file from OIMHOST1 to a temporary directory on OIMHOST2.

3. On OIMHOST2, invoke the unpack utility in the MW_HOME/oracle_common/common/bin directory and specify the location of the oim_domain.jar file in its temporary directory:

   unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
   template=/tmp/oim_domain.jar
   

5.3.10 Post-Installation Steps on OIMHOST2

This section describes the post-installation steps to perform on OIMHOST2. It includes these sections:

• Section 5.3.10.1, "Update Node Manager on OIMHOST2"

• Section 5.3.10.2, "Start Node Manager on OIMHOST2"

• Section 5.3.10.3, "Start the WLS_SOA2 and WLS_OIM2 Managed Servers on OIMHOST2"

5.3.10.1 Update Node Manager on OIMHOST2

Before managed servers can be started via the WebLogic Administration Console, Node Manager requires that the StartScriptEnabled property be set to true.

To do this, run the setNMProps.sh script located under the following directory:

MW_HOME/oracle_common/common/bin

5.3.10.2 Start Node Manager on OIMHOST2

Start the Node Manager on OIMHOST2 using the startNodeManager.sh script located under the following directory:

MW_HOME/wlserver_10.3/server/bin

5.3.10.3 Start the WLS_SOA2 and WLS_OIM2 Managed Servers on OIMHOST2

Follow these steps to start the WLS_SOA2 and WLS_OIM2 managed servers on OIMHOST2:

1. Validate that the WebLogic Administration Server started up successfully by bringing up the WebLogic Administration Console.

2. Start the WLS_SOA2 managed server using the WebLogic Administration Console.

3. Start the WLS_OIM2 managed server using the WebLogic Administration Console. The WLS_OIM2 managed server must be started after the WLS_SOA2 managed server is started.

5.3.11 Validate the Oracle Identity Manager Instance on OIMHOST2

Validate the Oracle Identity Manager Server instance on OIMHOST2 by bringing up the Oracle Identity Manager Console using a web browser.

The URL for the Oracle Identity Manager Console is:

http://identityvhn2.example.com:14000/oim

Log in using the xelsysadm password.

5.3.12 Updating SOA Server Default Composite

In an integrated environment, Oracle Identity Manager is front ended by OHS. All SOA server default composites must be updated. See Updating SOA Server Default Composite in the Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite for the procedure to update SOA server default composites.

5.3.13 Configuring Oracle Internet Directory using the LDAP Configuration Post-setup Script

Note:

This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Management.

If you do not plan to enable the LDAP-Sync option or to integrate with Oracle Access Management, you can skip this section.

In the current release, the LDAPConfigPostSetup script enables all the LDAPSync-related incremental Reconciliation Scheduler jobs, which are disabled by default. The LDAP configuration post-setup script is located under the IAM_ORACLE_HOME/server/ldap_config_util directory. To run the script, follow these steps:

1. Edit the ldapconfig.props file located under the IAM_ORACLE_HOME/server/ldap_config_util directory and provide the following values:

   Parameter	Value	Description
   OIMProviderURL	t3://OIMHOST1VHN.example.com:14000,OIMHOST2VHN.example.com:14000	List of Oracle Identity Manager managed servers.
   LDAPURL	Specify the URL for the Oracle Virtual Directory instance, for example: ldap://idstore.example.com:389	Identity Store URL. Only required if IDStore is accessed using Oracle Virtual Directory.
   LDAPAdminUserName	cn=oimadmin,cn=systemids,dc=example,dc=com	Name of user to connect to Identity Store. Only required if your Identity Store is in Oracle Virtual Directory. This user should not be located in cn=Users,dc=example,dc=com.
   LIBOVD_PATH_PARAM	MSERVER_HOME/config/fmwconfig/ovd/oim	Required unless you access your identity store using Oracle Virtual Directory.

   
   

   Note:

   usercontainerName, rolecontainername, and reservationcontainername are not used in this step.

2. Save the file.

3. Set the JAVA_HOME, WL_HOME, APP_SERVER, OIM_ORACLE_HOME, and DOMAIN_HOME environment variables, where:

   • JAVA_HOME is set to MW_HOME/jrockit_version

   • WL_HOME is set to MW_HOME/wlserver_10.3

   • APP_SERVER is set to weblogic

   • OIM_ORACLE_HOME is set to IAM_ORACLE_HOME

   • DOMAIN_HOME is set to MSERVER_HOME

4. Run LDAPConfigPostSetup.sh. The script prompts for the LDAP administrator password and the Oracle Identity Manager administrator password. For example:

   IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh path_to_property_file
   

   For example:

   IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh IAM_ORACLE_HOME/server/ldap_config_util
   

5.3.14 Configuring Server Migration for the OIM and SOA Managed Servers

For this high availability topology, Oracle recommends that you configure server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 managed servers. See Section 3.9, "Whole Server Migration" for information on the benefits of using Whole Server Migration and why Oracle recommends it.

• The WLS_OIM1 and WLS_SOA1 managed servers on OIMHOST1 are configured to restart automatically on OIMHOST2 if a failure occurs on OIMHOST1.

• The WLS_OIM2 and WLS_SOA2 managed servers on OIMHOST2 are configured to restart automatically on OIMHOST1 if a failure occur on OIMHOST2.

In this configuration, the WLS_OIM1, WLS_SOA1, WLS_OIM2 and WLS_SOA2 servers listen on specific floating IPs that WebLogic Server Migration fails over.

The following steps enable server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 managed servers, which in turn enables a managed server to fail over to another node if a server or process failure occurs:

• Step 1: Setting Up a User and Tablespace for the Server Migration Leasing Table

• Step 2: Creating a Multi Data Source Using the Oracle WebLogic Administration Console

• Step 3: Editing Node Manager's Properties File

• Step 4: Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

• Step 5: Configuring Server Migration Targets

• Step 6: Testing the Server Migration

5.3.14.1 Setting Up a User and Tablespace for the Server Migration Leasing Table

The first step to set up a user and tablespace for the server migration leasing table:

Note:

If other servers in the same domain are already configured with server migration, you can use the same tablespace and data sources. In this case, you don't need to recreate the data sources and multi data source for database leasing, however, you must retarget them to the clusters you're configuring for server migration.

1. Create a tablespace named leasing. For example, log on to SQL*Plus as the sysdba user and run the following command:

   SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;
   

2. Create a user named leasing and assign to it the leasing tablespace:

   SQL> create user leasing identified by welcome1;
   SQL> grant create table to leasing;
   SQL> grant create session to leasing;
   SQL> alter user leasing default tablespace leasing;
   SQL> alter user leasing quota unlimited on LEASING;
   

3. Create the leasing table using the leasing.ddl script:

   1. Copy the leasing.ddl file located in either the WL_HOME/server/db/oracle/817 or the WL_HOME/server/db/oracle/920 directory to your database node.

   2. Connect to the database as the leasing user.

   3. Run the leasing.ddl script in SQL*Plus:

      SQL> @Copy_Location/leasing.ddl;
      

5.3.14.2 Creating a Multi Data Source Using the Oracle WebLogic Administration Console

You create a data source to each of the Oracle RAC database instances during the process of setting up the multi data source, both for these data sources and the global leasing multi data source. When you create a data source:

• Ensure that this is a non-XA data source.

• The names of the multi data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.

• Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.

• Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for your database.

• Target these data sources to the cluster(s).

• Make sure the data source's connection pool initial capacity is set to 0 (zero). To do this, select Services, JDBC and then Datasources. In the Datasources screen, click the Datasource Name, click the Connection Pool tab, and enter 0 (zero) in the Initial Capacity field.

Creating a Multi Data Source

To create a multi data source:

1. Log into the Administration Console using administrator credentials.

2. In the Domain Structure window, expand the Services node then expand the DataSource node.

3. Click Lock and Edit in the Change Center.

4. Click New then click Multi Data Sources.

5. Enter leasing as the name.

6. Enter jdbc/leasing as the JNDI name.

7. Select Failover as algorithm (default). Click Next.

8. Select the target cluster(s). Click Next.

9. Select non-XA driver (the default). Click Next.

10. Click Create New Data Source.

11. Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for RAC server-Instance connection Version 10,11.

    Note:

    When you create multi data sources for the leasing table, enter names in the format <MultiDS>-rac0, <MultiDS>-rac1, and so on.

12. Click Next.

13. Deselect Supports Global Transactions. Click Next.

14. Enter the service name, database name (the RAC Node instance name such as racdb1, racdb2), host port, and password for your leasing schema. Click Next.

15. Click Test Configuration and verify that the connection works. Click Next.

    Note:

    Do not click Finish until you are done creating all of the data sources that you want to make. If you do not see the data sources that you created, this indicates that you clicked Finish too soon. When you click Finish, the Administration Console does not show the screen in which you target the data sources.

16. Target the data source to the cluster(s).

17. Select the data source and add it to the right screen.

18. Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the cluster(s), repeating the steps for the second instance of your Oracle RAC database.

19. Add the second data source to your multi data source.

20. Save and click Activate Changes.

5.3.14.3 Editing Node Manager's Properties File

You must edit the nodemanager.properties file to add the following properties for each node where you configure server migration:

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

• Interface: Specifies the interface name for the floating IP (such as eth0).

  Note:

  Do not specify the sub interface, such as eth0:1 or eth0:2. This interface is to be used without the :0, or :1. The Node Manager's scripts traverse the different :X enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0, eth1, or, eth2, eth3, ethn, depending on the number of interfaces configured.

• NetMask: Net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface; 255.255.255.0 is an example. The actual value depends on your network.

• UseMACBroadcast: Specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b flag in the arping command.

Verify in Node Manager's output (shell where Node Manager starts) that these properties are being used or problems may arise during migration. You should see an entry similar to the following in Node Manager's output:

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

Note:

The following steps are not required if the server properties (start properties) are properly set and Node Manager can start the servers remotely.

1. Set the following property in the nodemanager.properties file:

   • StartScriptEnabled: Set this property to true to enable Node Manager to start the managed servers.

2. Start Node Manager on OIMHOST1 and OIMHOST2 by running the startNodeManager.sh script in the WL_HOME/server/bin directory.

Note:

When running Node Manager from a shared storage installation, multiple nodes start using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in HOSTn, use the Interface environment variable as follows: HOSTn> export JAVA_OPTIONS=-DInterface=eth3 and start Node Manager after the variable is set in the shell.

5.3.14.4 Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

To set environment and superuser privileges for the wlsifconfig.sh script for each node where you configure server migration:

1. Ensure that your PATH environment variable includes these files:

   Table 5-3 Files Required for the PATH Environment Variable

   File	Located in this directory
   wlsifconfig.sh	DOMAIN_HOME/bin/server_migration
   wlscontrol.sh	WL_HOME/common/bin
   nodemanager.domains	WL_HOME/common

   
   

2. Grant sudo configuration for the wlsifconfig.sh script.

   • Configure sudo to work without a password prompt.

   • For security reasons, Oracle recommends restricting to the subset of commands required to run the wlsifconfig.sh script. For example, perform the following steps to set the environment and superuser privileges for the wlsifconfig.sh script:

   • Grant sudo privilege to the WebLogic user (oracle) with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.

   • Ensure that the script is executable by the WebLogic user. The following is an example of an entry inside /etc/sudoers granting sudo execution privilege for oracle and also over ifconfig and arping:

     oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
     

   Note:

   Ask the system administrator for the sudo and system rights as appropriate to this step.

5.3.14.5 Configuring Server Migration Targets

You first assign all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration. To configure cluster migration in a migration in a cluster:

1. Log into the Administration Console.

2. In the Domain Structure window, expand Environment and select Clusters.

3. Click the cluster you want to configure migration for in the Name column.

4. Click the Migration tab.

5. Click Lock and Edit.

6. In the Available field, select the machine to which to enable migration and click the right arrow.

7. Select the data source to use for automatic migration. In this case, select the leasing data source.

8. Click Save.

9. Click Activate Changes.

10. Set the candidate machines for server migration. You must perform this task for all managed servers as follows:

    1. In the Domain Structure window of the Administration Console, expand Environment and select Servers.

       Tip:

       Click Customize this table in the Summary of Servers page and move Current Machine from the Available window to the Chosen window to view the machine that the server runs on. This will be different from the configuration if the server migrates automatically.

    2. Select the server that you want to configure migration for.

    3. Click the Migration tab.

    4. In the Available field, located in the Migration Configuration section, select the machines you want to enable migration to and click the right arrow.

    5. Select Automatic Server Migration Enabled. This enables Node Manager to start a failed server on the target node automatically.

    6. Click Save then Click Activate Changes.

    7. Repeat the steps above for any additional managed servers.

    8. Restart the administration server, Node Managers, and the servers for which server migration has been configured.

5.3.14.6 Testing the Server Migration

To verify that server migration works properly:

From OIMHOST1:

1. Stop the WLS_OIM1 managed server. To do this, run this command:

   OIMHOST1> kill -9 pid
   

   where pid specifies the process ID of the managed server. You can identify the pid in the node by running this command:

   OIMHOST1> ps -ef | grep WLS_OIM1
   

2. Watch the Node Manager console. You should see a message indicating that WLS_OIM1's floating IP has been disabled.

3. Wait for Node Manager to try a second restart of WLS_OIM1. It waits for a fence period of 30 seconds before trying this restart.

4. Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.

From OIMHOST2:

1. Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_OIM1 on OIMHOST1, Node Manager on OIMHOST2 should prompt that the floating IP for WLS_OIM1 is being brought up and that the server is being restarted in this node.

2. Access the soa-infra console in the same IP.

Follow the steps above to test server migration for the WLS_OIM2, WLS_SOA1, and WLS_SOA2 managed servers.

Table 5-4 shows the managed servers and the hosts they migrate to in case of a failure.

Table 5-4 WLS_OIM1, WLS_OIM2, WLS_SOA1, WLS_SOA2 Server Migration

Managed Server	Migrated From	Migrated To
WLS_OIM1	OIMHOST1	OIMHOST2
WLS_OIM2	OIMHOST2	OIMHOST1
WLS_SOA1	OIMHOST1	OIMHOST2
WLS_SOA2	OIMHOST2	OIMHOST1

Verification From the Administration Console

Migration can also be verified in the Administration Console:

1. Log into the Administration Console at http://oimhost1.example.com:7001/console using administrator credentials.

2. Click Domain on the left console.

3. Click the Monitoring tab and then the Migration sub tab.

   The Migration Status table provides information on the status of the migration.

Note:

After a server is migrated, to fail it back to its original node/machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.

5.3.15 Configuring a Shared JMS Persistence Store

Configure the location for all of the persistence stores as a shared directory that is visible from both OIMHOST1 and OIMHOST2. As JMS messages are persisted in the file system for each server's local file system, shared storage is necessary for the JMS persistence store for WebLogic server migration. Without shared storage, a migrated server cannot access pending JMS messages.

Note:

See Considerations for Using File Stores on NFS for information about JMS messages and transaction logs, as well as releasing locks on file stores.

To change all persistent stores to use a shared base directory:

1. Log into the Administration Console at http://oimhost1.example.com:7001/console using the administrator credentials.

2. In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page is displayed.

3. Select the hyperlink(s) for the persistence store from the Name column of the table: BPM, SOA, OIM, and UMS. The Settings page for the persistence store opens.

4. On the Configuration tab, in the Directory field, enter the location of a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster. Specifying this location enables pending JMS messages to be sent.

5. The location should follow this directory structure:

   • For the WLS_SOA1 and WLS_SOA2 servers, use a directory structure similar to:

     ORACLE_BASE/admin/domainName/soaClusterName/jms
     

   • For the WLS_OIM1 and WLS_OIM2 servers, use a directory structure similar to:

     ORACLE_BASE/admin/domainName/oimClusterName/jms
     

     Note:

     The WLS_OIM1 and WLS_OIM2 servers must be able to access this directory.

     The WLS_SOA1 and WLS_SOA2 servers must be able to access this directory.

     This directory must exist before you restart the server.

6. Click Save and Activate.

7. Restart the servers to make the change in the persistent stores take effect.

5.3.16 Configuring a Default Persistence Store for Transaction Recovery

Each Oracle WebLogic Managed Server has a transaction log that stores information about inflight transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system fails or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to all the servers in the cluster. Without shared storage, other servers in the cluster cannot do a transaction recovery in the case of a server failure, so the operation may need to be retried.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

Perform these steps to set the location for the default persistence stores for the Oracle Identity Manager and SOA Servers:

1. Log into the Administration Console at http://oimhost1.example.com:7001/console using administrator credentials.

2. In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page is displayed.

3. Select the name of the server (represented as a hyperlink) in the Name column of the table. The Settings page for the selected server is displayed, and it defaults to the Configuration tab.

4. Click the Services tab.

5. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store their data files. The directory structure of the path should be:

   • For the WLS_SOA1 and WLS_SOA2 servers, use a directory structure similar to:

     ORACLE_BASE/admin/domainName/soaClusterName/tlogs
     

   • For the WLS_OIM1 and WLS_OIM2 servers, use a directory structure similar to:

     ORACLE_BASE/admin/domainName/oimClusterName/tlogs
     

6. Click Save.

   Note:

   To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to the managed servers in the cluster. WLS_SOA1, WLS_SOA2, WLS_OIM1, and WLS_OIM2 must be able to access this directory.

5.3.17 Install Oracle HTTP Server on WEBHOST1 and WEBHOST2

Install Oracle HTTP Server on WEBHOST1 and WEBHOST2.

5.3.18 Configuring Oracle Identity Manager to Work with the Web Tier

This section describes how to configure Oracle Identity Manager to work with the Oracle Web Tier.

5.3.18.1 Prerequisites

Verify that the following tasks have been performed:

1. Oracle Web Tier has been installed on WEBHOST1 and WEBHOST2.

2. Oracle Identity Manager has been installed and configured on OIMHOST1 and OIMHOST2.

3. The load balancer has been configured with a virtual hostname (sso.example.com) pointing to the web servers on WEBHOST1 and WEBHOST2.

4. The load balancer has been configured with a virtual hostname (oiminternal.example.com) pointing to web servers WEBHOST1 and WEBHOST2.

5.3.18.2 Configuring Oracle HTTP Servers to Front End the OIM and SOA Managed Servers

1. On each of the web servers on WEBHOST1 and WEBHOST2, create a file called oim.conf in the directory ORACLE_INSTANCE/config/OHS/component/moduleconf. This file must contain the following information:

   # oim admin console(idmshell based)
      <Location /admin>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
      </Location>
    
   # oim self and advanced admin webapp consoles(canonic webapp)
    
     <Location /oim>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
      </Location>
   
     <Location /identity>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid 
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
       </Location>
   
     <Location /sysadmin>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
       </Location>
   
   # SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
     <Location /sodcheck>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:8001,oimvhn2.example.com:8001
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
      </Location>
   
   # Callback webservice for SOA. SOA calls this when a request is approved/rejected
   # Provide the SOA Managed Server Port
     <Location /workflowservice>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
   
   # xlWebApp - Legacy 9.x webapp (struts based)
      <Location /xlWebApp>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
   
   # Nexaweb WebApp - used for workflow designer and DM
     <Location /Nexaweb>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
   
   # used for FA Callback service.
     <Location /callbackResponseService>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
   
   # spml xsd profile
     <Location /spml-xsd>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
   
     <Location /HTTPClnt>
       SetHandler weblogic-handler
       WLCookieName    oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
    
   
     <Location /reqsvc>
       SetHandler weblogic-handler
       WLCookieName oimjsessionid
       WebLogicCluster oimvhn1.example.com:8001,oimvhn2.example.com:8001
       oimvh1.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
    
    
     <Location /integration>
       SetHandler weblogic-handler
       WLCookieName oimjsessionid
       WebLogicCluster oimvhn1.example.com:8001,oimvhn2.example.com:8001
       oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
   
    
     <Location /provisioning-callback>
       SetHandler weblogic-handler
       WLCookieName oimjsessionid
       WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
       WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
       WLProxySSL ON
       WLProxySSLPassThrough ON
     </Location>
   

2. Create a file called virtual_hosts.conf in ORACLE_INSTANCE/config/OHS/component/moduleconf. The file must contain the following information:

   NameVirtualHost *:7777
   <VirtualHost *:7777>
   
     ServerName http://sso.example.com:7777
     RewriteEngine On
     RewriteOptions inherit
     UseCanonicalName On
     </VirtualHost>
   
   <VirtualHost *:7777>
     ServerName http://oiminternal.example.com:80
     RewriteEngine On
     RewriteOptions inherit
     UseCanonicalName On
   </VirtualHost>
   

3. Save the file on both WEBHOST1 and WEBHOST2.

4. Stop and start the Oracle HTTP Server instances on both WEBHOST1 and WEBHOST2.

5.3.19 Validate the Oracle HTTP Server Configuration

To validate that Oracle HTTP Server is configured properly, follow these steps:

1. In a web browser, enter the following URL for the Oracle Identity Manager Console:

   http://sso.example.com:7777/identity
   

   The Oracle Identity Manager Console login page should display.

2. Log into the Oracle Identity Manager Console using the credentials for the xelsysadm user.

5.3.20 Oracle Identity Manager Failover and Expected Behavior

In a high availability environment, WebLogic Node Manager is configured to monitor the Oracle WebLogic Servers. In case of failure, Node Manager restarts the WebLogic Server.

In a high availability environment, a hardware load balancer is used to load balance requests between the multiple Oracle Identity Manager instances. If one of the Oracle Identity Manager instances fails, the load balancer detects the failure and routes requests to the surviving instances.

In a high availability environment, the state and configuration information is stored in a database that is shared by all the members of the cluster.

The surviving Oracle Identity Manager instances will continue to seamlessly process any unfinished transactions started on the failed instance, since the state information is in the shared database and is available to all the members in the cluster.

When an Oracle Identity Manager instance fails, its database and LDAP connections are released. The surviving instances in the active-active deployment make their own connections to continue processing unfinished transactions on the failed instance.

Be aware of the following when you deploy Oracle Identity Manager in a high availability configuration:

• Oracle Identity Manager can be deployed on an Oracle RAC database, but Oracle RAC failover is not transparent for Oracle Identity Manager in this release. If an Oracle RAC failover occurs, end users may have to resubmit their requests.

• Oracle Identity Manager always requires that at least one of the nodes in the SOA cluster be available. If the SOA cluster is not available, end user requests will fail. Oracle Identity Manager does not retry for a failed SOA call. Therefore, the end user must retry when a SOA call fails.

5.3.21 Troubleshooting Oracle Identity Manager High Availability

If you are creating a user in Oracle Identity Manager (by logging into Oracle Identity Manager, clicking the Administration tab, clicking the Create User link, entering the required information in the fields, and clicking Save) in an active-active Oracle Identity Manager configuration, and the Oracle Identity Manager server that is handling the request fails, you may see a ResourceConnectionValidationxception in the Oracle Identity Manager log file, similar to:

[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
        at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
        at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
         .
         .
         .

Although this exception is received, the user is created fine.

5.3.22 Scaling Up and Scaling Out the Oracle Identity Manager Topology

You can scale out or scale up the Oracle Identity Manager high availability topology. When you scale up the topology, you add new managed servers to nodes that are already running one or more managed servers. When you scale out the topology, you add new managed servers to new nodes.

5.3.22.1 Scaling Up Oracle Identity Manager

In this case, you already have a node that runs a managed server configured with SOA components. The node contains a Middleware home, an Oracle HOME (SOA), and a domain directory for existing managed servers.

You can use the existing installations (Middleware home and domain directories) for creating new WLS_OIM and WLS_SOA servers. You do not need to install the OIM and SOA binaries in a new location or run pack and unpack.

To scale up the topology:

1. Using the Administration Console, clone either WLS_OIM1 or WLS_SOA1 into a new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.

   To clone a managed server:

   1. Select Environment -> Servers from the Administration Console.

   2. Select the managed server that you want to clone (WLS_OIM1 or WLS_SOA1).

   3. Select Clone.

   4. Name the new managed server WLS_OIMn or WLS_SOAn, where n is a number to identity the new managed server.

   The rest of the steps assume that you are adding a new server to OIMHOST1, which is already running WLS_SOA1 and WLS_OIM1.

2. For the listen address, assign the hostname or IP to use for this new managed server. If you are planning to use server migration as recommended for this server, this should be the VIP (also called a floating IP) to enable it to move to another node. The VIP should be different from the one used by the managed server that is already running.

3. Create JMS Servers for SOA, OIM, BPM, UMS, JRFWSAsync, and PS6SOA on the new managed server.

   1. Use the Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

   2. Create a new JMS Server for SOA, for example, SOAJMSServer_n. Use the SOAJMSFileStore_n for this JMSServer. Target the SOAJMSServer_n Server to the recently created Managed Server (WLS_SOAn).

   3. Create a new persistence store for the new UMSJMSServer, for example, UMSJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

      You can also assign SOAJMSFileStore_n as store for the new UMS JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Use the UMSJMSFileStore_n for this JMSServer. Target the UMSJMSServer_n Server to the recently created managed server (WLS_SOAn).

   5. Create a new persistence store for the new OIMJMSServer, for example, OIMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

      You can also assign SOAJMSFileStore_n as store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   6. Create a new JMS Server for OIM, for example, OIMJMSServer_n. Use the OIMJMSFileStore_n for this JMSServer. Target the OIMJMSServer_n Server to the recently created Managed Server (WLS_OIMn).

   7. Create a new persistence store for the new JRFWSAsyncJMSServer, for example, JRFWSAsyncJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
      

   8. Create a new JMS Server for JRFWSAsync, for example, JRFWSAsyncJMSServer_n. Use the JRFWSAsyncJMSFileStore_n for this JMSServer. Target the JRFWSAsyncJMSServer_n Server to the recently created Managed Server (WLS_OIMn).

      Note:

      This directory must exist before the managed server is started or the start operation fails.

      You can also assign SOAJMSFileStore_n as store for the new JRFWSAsync JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   9. Create a new persistence store for the new PS6JMSServer, for example, PS6JMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6JMSFileStore_n
      

   10. Create a new JMS Server for PS6, for example, PS6JMSServer_n. Use the PS6JMSFileStore_n for this JMSServer. Target the PS6JMSServer_n Server to the recently created Managed Server (WLS_OIMn).

       Note:

       This directory must exist before the managed server is started or the start operation fails.

       You can also assign SOAJMSFileStore_n as store for the new PS6 JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   11. Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment module for SOAJMS appears.

       Note:

       This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

   12. Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_n to this subdeployment. Click Save.

   13. Update the SubDeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for UMSJMS appears.

       Note:

       This subdeployment module name is a random name in the form of UMSJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

   14. Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_n to this subdeployment. Click Save.

   15. Update the SubDeployment targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.

       Note:

       This subdeployment module name is a random name in the form of OIMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).

   16. Click the OIMJMSServerXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_n to this subdeployment. Click Save.

   17. Update the SubDeployment targets for the JRFWSAsyncJMSSystemResource to include the recently created JRFWSAsync JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click JRFWSAsyncJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for JRFWSAsyncJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for JRFWSAsyncJMS appears.

       Note:

       This subdeployment module name is a random name in the form of JRFWSAsyncJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).

   18. Click the JRFWSAsyncJMSServerXXXXXX subdeployment. Add the new JMS Server for JRFWSAsync called JRFWSAsyncJMSServer_n to this subdeployment. Click Save.

   19. Update the SubDeployment targets for the PS6SOAJMSSystemResource to include the recently created PS6SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click PS6SOAJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for PS6SOAJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for PS6SOAJMS appears.

       Note:

       This subdeployment module name is a random name in the form of PS6SOAJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

   20. Click the PS6SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for PS6SOA called PS6SOAJMSServer_n to this subdeployment. Click Save.

4. Configure Oracle Coherence for deploying composites.

   Note:

   Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example:

   Dtangosol.coherence.localhost=SOAHOST1VHNn

5. Configure the transaction persistent store for the new server. This should be a shared storage location visible from other nodes.

   From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.

6. Disable hostname verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable hostname verification. You can re-enable it after you have configured server certificates for the communication between the Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).

   To disable hostname verification:

   1. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.

   2. Expand the Environment node in the Domain Structure window.

   3. Click Servers. Select WLS_SOAn in the Names column of the table.

   4. Click the SSL tab. Click Advanced.

   5. Set Hostname Verification to None. Click Save.

7. Start and test the new managed server from the Administration Console.

   1. Shut down the existing managed servers in the cluster.

   2. Ensure that the newly created managed server, WLS_SOAn, is up.

   3. Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional

8. Log in to the Administration Console. Select Services then the Foreign JNDI provider link. Select ForeignJNDIProvider-SOA then add the new server to the existing value.

9. Configure Server Migration for the new managed server.

   Note:

   Because this is a scale up operation, the node must already contain a Node Manager, an environment configured for server migration, and the floating IP for the new SOA managed server.

   To configure server migration:

   1. Log into the Administration Console.

   2. In the left pane, expand Environment and select Servers.

   3. Select the server (represented as a hyperlink) for which you want to configure migration. The Settings page for that server appears.

   4. Click the Migration tab.

   5. In the Available field, in the Migration Configuration section, select the machines to which to enable migration and click the right arrow. Select the same migration targets as for the servers that already exist on the node.

      For example, for new managed servers on SOAHOST1, which is already running WLS_SOA1, select SOAHOST2. For new managed servers on SOAHOST2, which is already running WLS_SOA2, select SOAHOST1.

      Make sure the appropriate resources are available to run the managed servers concurrently during migration.

   6. Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.

   7. Click Save.

   8. Restart the Administration Server, managed servers, and Node Manager.

   9. Repeat the steps in this list for configuring server migration for the newly created WLS_OIMn managed server.

10. To test server migration for this new server, follow these steps from the node where you added the new server:

    1. Stop the WLS_SOAn managed server.

       To do this, run kill -9 pid on the PID of the managed server. To identify the PID of the node, enter ps -ef | grep WLS_SOAn

    2. Watch the Node Manager Console for a message indicating that WLS_SOA1's floating IP is disabled.

    3. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.

    4. After Node Manager restarts the server, stop it again. Node Manager logs a message indicating that the server will not restart again locally.

5.3.22.2 Scaling Out Oracle Identity Manager

When you scale out the topology, you add new managed servers configured with SOA to new nodes.

Before performing the steps in this section, check that you meet these requirements:

• There must be existing nodes running managed servers configured with SOA within the topology.

• The new node can access the existing home directories for WebLogic Server and SOA. (Use the existing installations in shared storage for creating a new WLS_SOA or WLS_OIM managed server. You do not need to install WebLogic Server or SOA binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.)

  Note:

  If there is no existing installation in shared storage, you must install WebLogic Server and SOA in the new nodes.

  Note:

  When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, Oracle recommends keeping the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the user_home/bea/beahomelist file. See the following steps.

Follow these steps for scaling out the topology:

1. On the new node, mount the existing Middleware home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

2. To attach ORACLE_HOME in shared storage to the local Oracle Inventory, run the following commands:

   SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
   SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
   

   To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.

3. Log in to the Oracle WebLogic Administration Console.

4. Create a new machine for the new node that will be used, and add the machine to the domain.

5. Update the machine's Node Manager's address to map the IP of the node that is being used for scale out.

6. Use the Administration Console to clone WLS_SOA1 into a new managed server. Name it WLS_SOAn, where n is a number.

   Note:

   These steps assume that you are adding a new server to node n, where no managed server was running previously.

7. Assign the hostname or IP to use for the new managed server for the listen address of the managed server.

   If you are planning to use server migration for this server (which Oracle recommends), this should be the VIP (also called a floating IP) for the server. This VIP should be different from the one used for the existing managed server.

8. Create JMS servers for SOA, OIM (if applicable), UMS, BPM, JRFWSAsync, and PS6SOA on the new managed server.

   1. Use the Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

   2. Create a new JMS Server for SOA, for example, SOAJMSServer_n. Use the SOAJMSFileStore_n for this JMSServer. Target the SOAJMSServer_n Server to the recently created Managed Server (WLS_SOAn).

   3. Create a new persistence store for the new UMSJMSServer, for example, UMSJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

      You can also assign SOAJMSFileStore_n as store for the new UMS JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Use the UMSJMSFileStore_n for this JMSServer. Target the UMSJMSServer_n Server to the recently created managed server (WLS_SOAn).

   5. Create a new persistence store for the new OIMJMSServer, for example, OIMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

      You can also assign SOAJMSFileStore_n as store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   6. Create a new JMS Server for OIM, for example, OIMJMSServer_n. Use the OIMJMSFileStore_n for this JMSServer. Target the OIMJMSServer_n Server to the recently created Managed Server (WLS_OIMn).

   7. Create a new persistence store for the new BPMJMSServer, for example, BPMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

      You can also assign SOAJMSFileStore_n as store for the new BPM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   8. Create a new JMS Server for BPM, for example, BPMJMSServer_n. Use the BPMJMSFileStore_n for this JMSServer. Target the BPMJMSServer_n Server to the recently created managed server (WLS_SOAn).

   9. Create a new persistence store for the new JRFWSAsyncJMSServer, for example, JRFWSAsyncJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

      ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
      

      Note:

      This directory must exist before the managed server is started or the start operation fails.

      You can also assign SOAJMSFileStore_n as store for the new JRFWSAsync JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   10. Create a new JMS Server for JRFWSAsync, for example, JRFWSAsyncJMSServer_n. Use the JRFWSAsyncJMSFileStore_n for this JMSServer. Target the JRFWSAsyncJMSServer_n Server to the recently created managed server (WLS_SOAn).

   11. Create a new persistence store for the new PS6SOAJMSServer, for example, PS6SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.

       ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6SOAJMSFileStore_n
       

       Note:

       This directory must exist before the managed server is started or the start operation fails.

       You can also assign SOAJMSFileStore_n as store for the new PS6SOA JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

   12. Create a new JMS Server for PS6SOA, for example, PS6SOAJMSServer_n. Use the PS6SOAJMSFileStore_n for this JMSServer. Target the PS6SOAJMSServer_n Server to the recently created managed server (WLS_SOAn).

   13. Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment module for SOAJMS appears.

       Note:

       This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

   14. Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_n to this subdeployment. Click Save.

   15. Update the SubDeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for UMSJMS appears.

       Note:

       This subdeployment module name is a random name in the form of UMSJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

   16. Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_n to this subdeployment. Click Save.

   17. Update the SubDeployment targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.

       Note:

       This subdeployment module name is a random name in the form of OIMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).

   18. Click the OIMJMSServerXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_n to this subdeployment. Click Save.

9. Run the pack command on SOAHOST1 to create a template pack as follows:

   SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
   SOAHOST1> ./pack.sh -managed=true/
   -domain=MW_HOME/user_projects/domains/soadomain/
   -template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale
   

   Run the following command on SOAHOST1 to copy the template file created to SOAHOSTn:

   SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
   ORACLE_BASE/product/fmw/soa/common/bin
   

   Run the unpack command on SOAHOSTn to unpack the template in the managed server domain directory as follows:

   SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin
   SOAHOSTN> ./unpack.sh /
   -domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
   -template=soadomaintemplateScale.jar
   

10. Configure Oracle Coherence for deploying composites.

    Note:

    Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example:

    Dtangosol.coherence.localhost=SOAHOST1VHNn

11. Configure the transaction persistent store for the new server. This should be a shared storage location visible from other nodes.

    From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.

12. Disable hostname verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable hostname verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).

    To disable hostname verification:

    1. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.

    2. Expand the Environment node in the Domain Structure window.

    3. Click Servers. The Summary of Servers page appears.

    4. Select WLS_SOAn in the Names column of the table. The Settings page for the server appears.

    5. Click the SSL tab.

    6. Click Advanced.

    7. Set Hostname Verification to None.

    8. Click Save.

13. Start the Node Manager on the new node. To start the Node Manager, use the installation in shared storage from the existing nodes, and start Node Manager by passing the hostname of the new node as a parameter as follows:

    SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip
    

14. Start and test the new managed server from the Administration Console.

    1. Shut down the existing managed servers in the cluster.

    2. Ensure that the newly created managed server, WLS_SOAn, is up.

    3. Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional

15. Configure Server Migration for the new managed server.

    Note:

    Since this new node is using an existing shared storage installation, the node is already using a Node Manager and environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges. The floating IP for the new SOA managed server is already in the new node.

    Configure server migration by following these steps:

    1. Log into the Administration Console.

    2. In the left pane, expand Environment and select Servers.

    3. Select the server (represented as a hyperlink) for which you want to configure migration. The Settings page for that server appears.

    4. Click the Migration tab.

    5. In the Available field, in the Migration Configuration section, select the machines to which to enable migration and click the right arrow.

       Note:

       Specify the least-loaded machine as the migration target for the new server. The required capacity planning must be completed so that this node has enough available resources to sustain an additional managed server.

    6. Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.

    7. Click Save.

    8. Restart the Administration Server, managed servers, and Node Manager.

16. Test server migration for this new server. Follow these steps from the node where you added the new server:

    1. Stop the WLS_SOAn managed server.

       To do this, run kill -9 pid on the PID of the managed server. You can identify the PID of the node using ps -ef | grep WLS_SOAn.

    2. Watch the Node Manager Console: you should see a message indicating that WLS_SOA1's floating IP has been disabled.

    3. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.

    4. Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.