20 Managing Enterprise Deployments

This chapter provides information about managing the Identity Management enterprise deployment you have set up.

This chapter includes the following topics:

• Section 20.1, "Starting and Stopping Oracle Identity Management Components"

• Section 20.2, "Monitoring Enterprise Deployments"

• Section 20.3, "Scaling Enterprise Deployments"

• Section 20.4, "Performing Backups and Recoveries"

• Section 20.5, "Patching Enterprise Deployments"

• Section 20.6, "Troubleshooting"

• Section 20.7, "Other Recommendations"

20.1 Starting and Stopping Oracle Identity Management Components

This section describes how to start, stop and restart the various components of the Oracle Enterprise Deployment for Identity Management.

This section contains the following topics:

• Section 20.1.1, "Startup Order"

• Section 20.1.2, "Starting and Stopping Oracle Virtual Directory"

• Section 20.1.3, "Starting and Stopping Oracle Internet Directory"

• Section 20.1.4, "Starting, Stopping, and Restarting Oracle HTTP Server"

• Section 20.1.5, "Starting and Stopping Node Manager"

• Section 20.1.6, "Starting, Stopping, and Restarting WebLogic Administration Server"

• Section 20.1.7, "Starting, Stopping, and Restarting Oracle Identity Manager"

• Section 20.1.8, "Starting, Stopping, and Restarting Oracle Access Manager Managed Servers"

• Section 20.1.9, "Starting, Stopping, and Restarting Oracle Adaptive Access Manager Managed Servers"

• Section 20.1.10, "Starting and Stopping Oracle Identity Federation Managed Servers"

20.1.1 Startup Order

When starting up your entire infrastructure, start the components in the following order:

1. Database(s)

2. Database Listener(s)

3. Oracle Internet Directory

4. Oracle Virtual Directory

5. Oracle Access Manager Server(s)

6. OAAM Servers

7. WebLogic Administration Server

8. Oracle HTTP Server(s)

9. SOA Server(s)

10. Oracle Identity Manager Server(s)

20.1.2 Starting and Stopping Oracle Virtual Directory

Start and stop Oracle Virtual Directory as follows.

20.1.2.1 Starting Oracle Virtual Directory

Start system components such as Oracle Virtual Directory by typing:

ORACLE_INSTANCE/bin/opmnctl startall

You can verify that the system components have started by executing:

ORACLE_INSTANCE/bin/opmnctl status -l

20.1.2.2 Stopping Oracle Virtual Directory

Stop system components such as Oracle Virtual Directory by executing the following command:

ORACLE_INSTANCE/bin/opmnctl stopall 

20.1.3 Starting and Stopping Oracle Internet Directory

Start and stop Oracle Internet Directory as follows.

20.1.3.1 Starting Oracle Internet Directory

Start system components such as Oracle Internet Directory by typing

ORACLE_INSTANCE/bin/opmnctl startall

You can verify that the system components have started by executing:

ORACLE_INSTANCE/bin/opmnctl status -l

20.1.3.2 Stopping Oracle Internet Directory

Stop system components such as Oracle Internet Directory by executing the following command:

ORACLE_INSTANCE/bin/opmnctl stopall 

20.1.4 Starting, Stopping, and Restarting Oracle HTTP Server

Prior to starting/stopping the Oracle HTTP server ensure that the environment variables WEB_ORACLE_HOME and ORACLE_INSTANCE are defined and that ORACLE_HOME/opmn/bin appears in the PATH. For example:

export ORACLE_HOME=WEB_ORACLE_HOME
export ORACLE_INSTANCE=/u01/app/oracle/admin/web[1-2]
export PATH=$ORACLE_HOME/opmn/bin:$PATH

20.1.4.1 Starting Oracle HTTP Server

Start the Oracle web tier by issuing the command:

opmnctl startall

20.1.4.2 Stopping Oracle HTTP Server

Stop the web tier by issuing the command

opmnctl stopall 

to stop the entire Web tier or

opmnctl stoproc process-type=OHS  

to stop Oracle HTTP Server only.

20.1.4.3 Restarting Oracle HTTP Server

You can restart the web tier by issuing a Stop followed by a Start as described in the previous sections.

To restart the Oracle HTTP server only, use the following command.

opmnctl restartproc process-type=OHS

20.1.5 Starting and Stopping Node Manager

Start and stop the Node Manager as follows:

20.1.5.1 Starting Node Manager

If the Node Manager being started is the one that controls the Administration Server (IDMHOST1 or IDMHOST2), then prior to starting the Node Manager issue the command:

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true 

To start Node Manager, issue the commands:

IDMHOST> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
IDMHOST> ./startNodeManager.sh

20.1.5.2 Stopping Node Manager

To stop Node Manager, kill the process started in the previous section.

20.1.5.3 Starting Node Manager for an Administration Server

IDMHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
IDMHOST1> export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
IDMHOST1> ./startNodeManager.sh

Note:

It is important to set -DDomainRegistrationEnabled=true whenever you start a Node Manager that manages the Administration Server.

20.1.6 Starting, Stopping, and Restarting WebLogic Administration Server

Start and stop the WebLogic Administration Server as follows:

20.1.6.1 Starting WebLogic Administration Server

The recommended way to start the Administration server is to use WLST and connect to Node Manager:

IDMHOST1> cd ORACLE_BASE/product/fmw/oracle_common/common/bin 
IDMHOST1> ./wlst.sh

Once in wlst shell, execute

wls:/offline> nmConnect('Admin_User','Admin_Password','ADMINHOST1','5556',
    'IDMDomain','/u01/app/oracle/admin/domain_name/aserver/IDMDomain')
wls:/nm/domain_name> nmStart('AdminServer')

Alternatively, you can start the Administration server by using the command:

DOMAIN_HOME/bin/startWeblogic.sh

20.1.6.2 Stopping WebLogic Administration Server

To stop the Administration Server, log in to the WebLogic console using the URL: http://admin.mycompany.com/console.

Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select AdminServer(admin).

4. Click Shutdown and select Force Shutdown now.

5. Click Yes when asked to confirm that you want to shut down the Administration Server.

20.1.6.3 Restarting WebLogic Administration Server

Restart the server by following the Stop and Start procedures in the previous sections.

20.1.7 Starting, Stopping, and Restarting Oracle Identity Manager

Start and stop Oracle Identity Manager and Oracle SOA Suite servers as follows:

20.1.7.1 Starting Oracle Identity Manager

To start the Oracle Identity Manager Managed Server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com/console.

Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select SOA Servers (WLS_SOA1 and/or WLS_SOA2).

   Note:

   You can start the Oracle Identity Manager and Oracle SOA Suite servers independently of each other. There is no dependency in their start order. However, the SOA server must be up and running for all of the Oracle Identity Manager functionality to be available.

4. Click the Start button.

5. Click Yes when asked to confirm that you want to start the server(s).

6. After WLS_SOA1 and/or WLS_SOA2 have started, select WLS_OIM1 and/or WLS_OIM2

7. Click Start.

8. Click Yes when asked to confirm that you want to start the server(s).

20.1.7.2 Stopping Oracle Identity Manager

To stop the Oracle Identity Manager Managed Server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com/console. Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select OIM Servers (WLS_OIM1 and/or WLS_OIM2) and (WLS_SOA1 and/or WLS_SOA2).

4. Click the Shutdown button and select Force Shutdown now.

5. Click Yes when asked to confirm that you want to shutdown the server(s).

20.1.7.3 Restarting Oracle Identity Manager

Restart the server by following the Stop and Start procedures in the previous sections.

20.1.8 Starting, Stopping, and Restarting Oracle Access Manager Managed Servers

Start and stop Oracle Access Manager Managed Servers as follows:

20.1.8.1 Starting Oracle Access Manager Managed Servers

To start the Oracle Access Manager Managed Server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com/console.

Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).

4. Click the Start button.

5. Click Yes when asked to confirm that you want to start the server(s).

20.1.8.2 Stopping Oracle Access Manager Managed Servers

To stop the Oracle Access Manager Managed Server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com/console. Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).

4. Click the Shutdown button and select Force Shutdown now.

5. Click Yes when asked to confirm that you want to shut down the server(s).

20.1.8.3 Restarting Oracle Access Manager Managed Servers

Restart the server by following the Stop and Start procedures in the previous sections.

20.1.9 Starting, Stopping, and Restarting Oracle Adaptive Access Manager Managed Servers

Start and stop Oracle Adaptive Access Manager as follows:

20.1.9.1 Starting Oracle Adaptive Access Manager Managed Servers

To start the OAAM Managed Server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com/console. Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select OAAM Servers (WLS_OAAM1 and/or WLS_OAAM2).

4. Click the Start button.

5. Click Yes when asked to confirm that you want to start the server(s).

20.1.9.2 Stopping Oracle Adaptive Access Manager Managed Servers

To stop the OAAM Managed Server(s), log in to the WebLogic console using the URL: http://admin.mycompany.com/console. Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select OAAM Servers (WLS_OAAM1 and/or WLS_OAAM2).

4. Click Shutdown and select Force Shutdown now.

5. Click Yes when asked to confirm that you want to shutdown the server(s).

20.1.9.3 Restarting Oracle Adaptive Access Manager Managed Servers

Restart the server by following the previous Stop and Start procedures.

20.1.10 Starting and Stopping Oracle Identity Federation Managed Servers

Start and stop Oracle Identity Federation Managed Servers as follows:

20.1.10.1 Starting Oracle Identity Federation

To start the Oracle Identity Federation Managed Server(s), log in to the WebLogic console at: http://admin.mycompany.com/console. Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select OIF Servers (WLS_OIF1 and/or WLS_OIF2).

4. Click Start.

5. Click Yes when asked to confirm that you want to start the server(s).

20.1.10.2 Stopping Oracle Identity Federation

To stop the Oracle Identity Federation Managed Server(s), log in to the WebLogic console at: http://admin.mycompany.com/console. Then proceed as follows:

1. Select Environment - Servers from the Domain Structure menu.

2. Click the Control tab.

3. Select OIF Servers (WLS_OIF1 and/or WLS_OIF2).

4. Click Shutdown and select Force Shutdown now.

5. Click Yes when asked to confirm that you want to shut down the server(s).

20.1.10.3 Restarting Oracle Identity Federation

Restart the server by following the previous Stop and Start procedures.

20.1.10.4 Starting the Oracle Identity Federation Instances and EMAgent

Start the Oracle Identity Federation Instance and EMAgent by executing the following command:

ORACLE_INSTANCE/bin/opmnctl startall

You can verify that the instance started successfully by executing:

ORACLE_INSTANCE/bin/opmnctl status -l

20.1.10.5 Stopping the Oracle Identity Federation Instances and EMAgent

Stop the Oracle Identity Federation Instance and EMAgent by executing the following command:

ORACLE_INSTANCE/bin/opmnctl stopall 

20.2 Monitoring Enterprise Deployments

This section provides information about monitoring the Identity Management enterprise deployment described in this manual.

This section contains the following topics:

• Section 20.2.1, "Monitoring Oracle Internet Directory"

• Section 20.2.2, "Monitoring Oracle Virtual Directory"

• Section 20.2.3, "Monitoring Oracle Directory Integration Platform"

• Section 20.2.4, "Monitoring WebLogic Managed Servers"

20.2.1 Monitoring Oracle Internet Directory

You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Internet Directory, as follows:

1. On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.

2. The Identity and Access section below the chart includes the name of each individual Oracle Internet Directory instance, for example, oid1, oid2), its status, host name, and CPU usage percentage. A green arrow in the Status column indicates that the instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Internet Directory instance to view the home page for that instance.

3. The home page for an instance displays metrics for the instance such as performance, load, security, response, CPU utilization %, and memory utilization %.

20.2.1.1 Oracle Internet Directory Component Names Assigned by Oracle Identity Manager Installer

When you perform an Oracle Internet Directory installation using Oracle Identity Management 11g Installer, the default component name that the installer assigns to the Oracle Internet Directory instance is oid1. You cannot change this component name.

The instance specific configuration entry for this Oracle Internet Directory instance is cn=oid1, cn=osdldapd, cn=subconfigsubentry.

If you perform a second Oracle Internet Directory installation on another computer and that Oracle Internet Directory instance uses the same database as the first instance, the installer detects the previously installed Oracle Internet Directory instance on the other computer using the same Oracle database, so it gives the second Oracle Internet Directory instance a component name of oid2.

The instance specific configuration entry for the second Oracle Internet Directory instance is cn=oid2, cn=osdldapd, cn=subconfigsubentry. A change of properties in the entry cn=oid2, cn=osdldapd, cn=subconfigsubentry does not affect the first instance (oid1).

If a third Oracle Internet Directory installation is performed on another computer and that instance uses the same database as the first two instances, the installer gives the third Oracle Internet Directory instance a component name of oid3, and so on for additional instances on different hosts that use the same database.

Note that the shared configuration for all Oracle Internet Directory instances is cn=dsaconfig, cn=configsets,cn=oracle internet directory. A change in this entry affects all the instances of Oracle Internet Directory.

This naming scheme helps alleviate confusion when you view your domain using Oracle Enterprise Manager by giving different component names to your Oracle Internet Directory instances.

20.2.2 Monitoring Oracle Virtual Directory

You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Virtual Directory, as follows:

1. On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.

2. The Identity and Access section below the chart includes the name of each instance of the Oracle Virtual Directory application (for example, ovd1, ovd2), its status, and host name. A green arrow in the Status column indicates that the Oracle Virtual Directory instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Virtual Directory instance to view the home page for that instance.

3. The home page for an instance displays metrics and configurations for the instance such as:

   • Oracle Virtual Directory status - A green arrow next to the Oracle Virtual Directory instance name at the top of the page indicates that the instance is up and running properly and a red arrow indicates that the instance is down.

   • Current Load - This indicates the current work load of this Oracle Virtual Directory instance. It includes three metrics: Open Connections, Distinct Connected Users, and Distinct Connected IP Addresses.

   • Average Response Time Metric - This displays the average time (in milliseconds) to complete an LDAP search request.

   • Operations Metric - This displays the average number of LDAP search requests finished per millisecond.

   • Listeners - This table lists the listeners configured for this Oracle Virtual Directory instance to provide services to clients.

   • Adapters - This table lists existing adapters configured with the Oracle Virtual Directory instance. Oracle Virtual Directory uses adapters to connect to different underlying data repositories.

   • Resource Usage - On the right hand side of the page, the CPU and memory utilization metrics are displayed to indicate the system resources consumed by the Oracle Virtual Directory instance.

20.2.3 Monitoring Oracle Directory Integration Platform

You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Directory Integration Platform, as follows:

1. On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.

2. The Identity and Access section below the chart includes the name of each instance of the Oracle Directory Integration Platform application (all have the name DIP (11.1.1.1.0)), its status, and host name. Each Oracle Directory Integration Platform instance is deployed in a different Managed Server). A green arrow in the Status column indicates that the Oracle Directory Integration Platform instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Directory Integration Platform instance to view the home page for that instance.

3. The home page for an instance displays metrics for the instance such as:

   • Oracle Directory Integration Platform status - A green arrow next to the Oracle Directory Integration Platform instance name at the top of the page indicates that the instance is up and running properly and a red arrow indicates that the instance is down.

   • DIP Component Status - This table includes these metrics:

     • Quartz Scheduler - This indicates whether tasks can be scheduled for synchronization or not. A green arrow indicates the scheduler is up and a red arrow indicates that the scheduler is down.

     • Mbeans - This indicates whether profile management is available to the user or not. A green arrow indicates profile management is available and a red arrow indicates profile management is unavailable.

   • Synchronization Profiles - This shows registered profiles and their execution status. In a high availability deployment, all the instances shows the same list of profiles.

   • Provisioning Profiles- This shows registered provisioning profiles and their execution status. In a high availability deployment, all the instances shows the same list of profiles.

   • Resource Usage - On the right hand side of the page, the CPU and memory utilization metrics are displayed to indicate the resource usage by the Oracle Directory Integration Platform instance.

20.2.4 Monitoring WebLogic Managed Servers

You can use Oracle Enterprise Manager Fusion Middleware Control to monitor Managed Servers and other Fusion Middleware components, such as Oracle Access Manager, Oracle Identity Manager, SOA, and Oracle Identity Federation. For more information, see the administrator guides listed in the Preface under "Related Documents".

20.3 Scaling Enterprise Deployments

The reference enterprise topology discussed in this manual is highly scalable. It can be scaled up and or scaled out. When the topology is scaled up, a new server instance is added to a node already running one or more server instances. When the topology is scaled out, new servers are added to new nodes.

This section contains the following topics:

• Section 20.3.1, "Scaling Up the Topology"

• Section 20.3.2, "Scaling Out the Topology"

20.3.1 Scaling Up the Topology

The Oracle Identity Management topology described in the guide has three tiers: the directory tier, application tier and web tier. The components in all the three tiers can be scaled up by adding a new server instance to a node that already has one or more server instances running.

The procedures described in this section show you how to create a new managed server or directory instance. If you add a new managed server, after adding the managed server you must update your Oracle HTTP Server configuration files (on all nodes) and add the new server to the existing WebLogic cluster directives.

For example if you add a new Oracle Access Manager server, you must update oam.conf to include the new managed server.

Update oam.conf as follows:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster
idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>

Once you have updated oam.conf, restart the Oracle HTTP server(s) as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.

20.3.1.1 Scaling Up the Directory Tier

The directory tier consists of the two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled up on one or both the nodes.

20.3.1.1.1 Scaling Up Oracle Internet Directory

The directory tier has two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Internet Directory instance.

To add a new Oracle Internet Directory instance to either Oracle Internet Directory node, follow the steps in Section 7.3.2, "Configuring an Additional Oracle Internet Directory Instance" with the following variations:

1. In step 2 and step 4, choose ports other than 389 and 636 since these ports are being used by the existing Oracle Internet Directory instance on the node.

2. Follow the steps in Section 7.4.1, "Registering Oracle Internet Directory with the WebLogic Server Domain" to register the new Oracle Internet Directory instance with the WebLogic domain. Use the location for the new Oracle Internet Directory instance as the value for ORACLE_INSTANCE.

3. Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.

4. If you have enabled Single Sign-on in the topology, you must update the WebTier configuration for Single Sign-on as described in Section 19.5, "Installing and Configuring WebGate."

5. Register the new Oracle HTTP Server instance as described in Section 6.10, "Registering Oracle HTTP Server with WebLogic Server."

20.3.1.1.2 Scaling Up Oracle Virtual Directory

The directory tier has two nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Virtual Directory instance.

To add a new Oracle Virtual Directory instance to either Oracle Virtual Directory node, follow the steps in Section 9.3.2, "Configuring an Additional Oracle Virtual Directory" with the following variations:

1. In step 2 and step 4, choose ports other than 6501 and 7501 since these ports are being used by the existing Oracle Virtual Directory instance on the node.

2. Follow the steps in these sections to register the new Oracle Virtual Directory instance with the WebLogic domain. Use the location for the new Oracle Virtual Directory instance as the value for ORACLE_INSTANCE.

   • Section 9.4, "Post-Configuration Steps"

   • Section 9.6, "Validating the Oracle Virtual Directory Instances"

   • Section 9.7, "Creating ODSM Connections to Oracle Virtual Directory"

   • Section 9.8, "Creating Adapters in Oracle Virtual Directory"

   • Section 10.4.9, "Updating Oracle Virtual Directory Adapters"

3. Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.

20.3.1.2 Scaling Up the Application Tier

The application tier consists of several nodes in pairs, depending on the products installed. These application servers run either Oracle Directory Services (OID/OVD), Oracle HTTP Servers or WebLogic Managed servers.

Some of the procedures described in this section show you how to create a new WebLogic managed server. If you add a new managed server to your topology, after adding the managed server you must update your Oracle HTTP Server configuration files (on all nodes) and add the new server to the existing WebLogic cluster directives.

For example if you add a new Oracle Access Manager server, you must update oam.conf to include the new managed server.

Update oam.conf as follows:

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>

Once you have updated oam.conf, restart the Oracle HTTP server(s) as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.

20.3.1.2.1 Scaling Up Oracle Directory Integration Platform and ODSM

The application tier already has a node (IDMHOST2) running a Managed Server configured with Oracle Directory Integration Platform and Oracle Directory Services Manager components. The node contains a WebLogic Server home and an Oracle Fusion Middleware Identity Management Home on the local disk.

The existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) can be used for creating a new Managed Server for the Oracle Oracle Directory Integration Platform and Oracle Directory Services Manager components.

1. Follow the steps in Section 8.2, "Expanding the Oracle Directory Integration Platform and ODSM Cluster".

2. Be sure to choose a port other than 7499, which is already in use.

3. Reconfigure the Oracle HTTP Server module with the new Managed Server. Follow the instructions in Chapter 5, "Configuring the Web Tier" to complete this task.

20.3.1.2.2 Scaling Up Oracle Access Manager 11g

Scale up Oracle Access Manager as follows:

Log in to the Oracle WebLogic Server Administration Console at http://admin.mycompany.com/console.

1. From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.

2. Click Lock & Edit from the Change Center menu.

3. Select an existing server on the host you want to extend, for example: WLS_OAM1.

4. Click Clone.

5. Enter the following information:

   • Server Name: A new name for the server, for example: WLS_OAM3.

   • Server Listen Address: The name of the host on which the Managed Server runs.

   • Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.

6. Click OK.

7. Click the newly created server WLS_OAM3

8. Click Save.

9. Disable host name verification for the new Managed Server. Before starting and verifying the WLS_OAM3 Managed Server, you must disable host name 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 OAMHOSTn.

   If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name verification settings were propagated to the cloned server. To disable host name verification:

   1. In Oracle Enterprise Manager Fusion Middleware Control, 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_OAM3 in the Names column of the table. The Settings page for server appears.

   5. Click the SSL tab.

   6. Click Advanced.

   7. Set Hostname Verification to None.

   8. Click Save.

10. Click Activate configuration from the Change Center menu.

Register the new Managed Server with Oracle Access Manager. You now must configure the new Managed Server now as an Oracle Access Manager server. You do this from the Oracle OAM console. Proceed as follows:

1. Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.

2. Click the System Configuration tab.

3. Click Server Instances.

4. Select Create from the Actions menu.

5. Enter the following information:

   • Server Name: WLS_OAM3

   • Host: Host that the server runs on

   • Port: Listen port that was assigned when the Managed Server was created

   • OAM Proxy Port: Port you want the Oracle Access Manager proxy to run on. This is unique for the host

   • Proxy Server ID: AccessServerConfigProxy

   • Mode: Set to Open or Simple, depending on the mode your existing Oracle Access Manager servers are operating in.

6. Click Coherence tab.

   Set Local Port to a unique value on the host.

7. Click Apply.

8. Restart the WebLogic Administration Server as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

Add the newly created Oracle Access Manager server to all WebGate Profiles that might be using it, such as Webgate_IDM and IAMSuiteAgent

For example, to add the Oracle Access Manager server to Webgate_IDM, access the OAM console at http://admin.mycompany.com/oamconsole, then proceed as follows:

1. Log in as the Oracle Access Manager Admin User you created inSection 10.4.2, "Creating Users and Groups for Oracle Access Manager."

2. Click the System Configuration tab.

3. Expand Access Manager Settings - SSO Agents - OAM Agents.

4. Click the open folder icon, then click Search.

   You should see the WebGate agent Webgate_IDM.

5. Click the agent Webgate_IDM.

6. Select Edit from the Actions menu.

7. Click + in the Primary Server list (or the Secondary Server list if this is a secondary server).

8. Select the newly created managed server from the Server drop down list.

9. Set Max Connections to 4.

10. Click Apply.

Repeat Steps 5 through 10 for IAMSuiteAgent and all other WebGates that might be in use.

Update the Web Tier. Once the new Managed Server has been created and started, the web tier starts to direct requests to it. Best practice, however, is to inform the web server that the new Managed Server has been created.

You do this by updating the file OAM.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component name/moduleconf.

Add the new server to the WebLogicCluster directive in the file, for example, change:

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100
</Location>

to:

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost1.mycompany.com:14101
</Location>

Save the file and restart the Oracle HTTP server, as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

You can now start the new Managed Server, as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

20.3.1.2.3 Scaling Up Oracle Adaptive Access Manager

To scale up OAAM, use the same procedure for both the OAAM server and the OAAM Administration Server.

Log in to the Oracle WebLogic Server console at: http://admin.mycompany.com/console. Then proceed as follows:

1. From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.

2. Click Lock & Edit from the Change Center menu.

3. Select an existing server on the host that you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.

4. Click Clone.

5. Enter the following information:

   • Server Name: A new name for the server, for example: WLS_OAAM3.

   • Server Listen Address: The name of the host on which the Managed Server runs.

   • Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.

6. Click OK.

7. Click the newly-created server WLS_OAAM3.

8. Set the SSL listen port. This should be unique on the host that the Managed Server is running on.

9. Click Save.

10. Disable host name verification for the new Managed Server. Before starting and verifying the WLS_OAAM3 Managed Server, you must disable host name 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 OAAMHOSTn.

    If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name verification settings were propagated to the cloned server. To disable host name verification:

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

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

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

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

    5. Click the SSL tab.

    6. Click Advanced.

    7. Set Hostname Verification to None.

    8. Click Save.

11. Click Activate configuration from the Change Center menu.

You must now configure the new Managed Server now as an Oracle Access Manager server. You do this from the Oracle OAM console. Proceed as follows:

1. Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.

2. Click the System Configuration tab.

3. Click Server Instances.

4. Select Create from the Actions Menu.

5. Enter the following information:

   • Server Name: WLS_OAM3

   • Host: Host that the server is running on

   • Port: Listen port that was assigned when the Managed Server was created.

   • OAM Proxy Port: Port you want the Oracle Access Manager proxy to run on. This is unique for each host.

   • Proxy Server ID: AccessServerConfigProxy.

   • Mode: Open

6. Click Apply.

7. Click Coherence tab.

   Set Local Port to a unique value on the host.

8. Click Apply.

You can now start the Oracle Access Manager server. In order for the server to be used, however, you must inform all WebGates of its existence. You do this as follows:

1. Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.

2. Click the System Configuration tab

3. Expand Agents -> OAM Agents -> 10g Agents.

4. Double click the WebGate you want to change.

5. Add the new server to either the Primary or Secondary server list by clicking +.

6. Select the server name from the list.

7. Click Apply.

20.3.1.2.4 Scaling Up Oracle Identity Manager (Adding Managed Servers to Existing Nodes)

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 (the Middleware home, and domain directories) for creating new WLS_OIM and WLS_SOA servers. There is no need to install the Oracle Identity Manager and Oracle SOA Suite binaries in a new location, or to run pack and unpack.

Follow these steps for scaling up the topology:

1. Using the Administration Console, clone either the WLS_OIM1 or the 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. From the Change Center menu, click Lock and Edit.

   3. Select the Managed Server that you want to clone (for example, WLS_OIM1 or WLS_SOA1).

   4. Select Clone.

   Name the new Managed Server WLS_OIMn or WLS_SOAn, where n is a number to identify 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 host name or IP address 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, Oracle Identity Manager, UMS, and BPM on the new Managed Server.

   1. Use the Oracle WebLogic Server 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, as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."

      Note:

      This directory must exist before the Managed Server is started or the start operation fails.

      ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/SOAJMSFileStore_N
      

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

   3. Create a new JMS server for BPM, for example, BPMJMSServer_auto_N. Use the BPMJMSServer_auto_N for this JMSServer. Target the BPMJMSServer_auto_N server to the recently created Managed Server WLS_SOAn.

   4. 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, as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."

   5. 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 as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."

      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.

   6. 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).

   7. 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 as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."

      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 Oracle Identity Manager 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 Oracle Identity Manager, for example, OIMJMSServer_N. Use the OIMJMSFileStore_N for this JMSServer. Target the OIMJMSServer_N server to the recently created Managed Server (WLS_OIMn).

   9. 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 Oracle WebLogic Server 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).

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

   10. 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 Oracle WebLogic Server 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 UCMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

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

   11. Update the SubDeployment targets for the BPMJMSSystemResource to include the recently created BPM 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 Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click BPMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for BPMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for BPMJMS appears.

       Note:

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

       Click the BPMJMSServerXXXXXX subdeployment. Add the new JMS Server for BPM called BPMJMSServer_N to this subdeployment. Click Save.

   12. Update the SubDeployment targets for OIMJMSModule to include the recently created Oracle Identity Manager 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 Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click OIMJMSModule (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).

       Click the OIMJMSServerXXXXXX subdeployment. Add the new JMS Server for Oracle Identity Manager called OIMJMSServer_N to this subdeployment. Click Save.

4. Configure Oracle Coherence, as described in Section 14.6.1, "Updating the Coherence Configuration for the SOA Managed Server."

5. Configure TX persistent store for the new server. This should be a location visible from other nodes as indicated in the recommendations about shared storage.

   From the Administration Console, select the 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 host name verification for the new Managed Server. Before starting and verifying the WLS_SOAn Managed Server, you must disable host name 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 host name verification, these steps are not required (the host name verification settings is propagated to the cloned server).

   To disable host name 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.

7. Repeat Steps 6a through 6h to disable host name verification for the WLS_OIMn Managed Servers. In Step d, select WLS_OIMn in the Names column of the table.

8. Click Activate Changes from the Change Center menu.

9. Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:

   1. Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at: http://admin.mycompany.com/em

   2. Log in to Oracle Enterprise Manager Fusion Middleware Control using the Admin user credentials.

      Note:

      At least one of the Oracle Identity Manager Managed Servers must be running for when these steps are executed.

   3. Navigate to Identity and Access, and then oim.

   4. Right-click oim and navigate to System MBean Browser.

   5. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.

   6. Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.

   7. The Rmiurl attribute is used for accessing SOA EJBs deployed on SOA Managed Servers. This is the application server URL. For a clustered deployment of Oracle Identity Manager, it is a comma-delimited list of all the SOA Managed Server URLs. The following are example values for this attribute:

      t3://oimhost1.mycompany.com:8001,oimhost2.mycompany.com:8001,oimhost3.mycompany.com:8001

10. Restart the WebLogic Administration Server as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

11. 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.

12. Configure the newly created managed server for server migration. Follow the steps in Section 17.5, "Configuring Server Migration Targets" to configure server migration.

13. 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 process ID (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 the floating IP address for WLS_SOA1 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.

20.3.1.3 Scaling Up Oracle Identity Federation

The application tier already has a node (OIFHOST2) running a Managed Server configured with Oracle Identity Federation. The node contains a WebLogic Server home and an Oracle Fusion Middleware Identity Management home on the local disk.

The existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) can be used for creating a new Managed Server for Oracle Identity Federation.

1. Follow the steps in Section 15.3, "Configuring Oracle Identity Federation on OIFHOST2" to scale up the topology for Oracle Identity Federation.

2. Be sure to choose a port other than 7499, which is already in use.

3. Follow the steps in Section 15.4, "Provisioning the Managed Servers on the Local Disk" to provision the new Oracle Identity Federation managed server on the local disk.

4. Reconfigure the Oracle HTTP Server module with the new Managed Server. Follow the instructions in Chapter 5, "Configuring the Web Tier," to complete this task.

20.3.1.4 Scaling Up the Web Tier

The web tier already has a node running an instance of the Oracle HTTP Server. The existing Oracle HTTP Server binaries can be used for creating the new Oracle HTTP Server instance. To scale up the Oracle HTTP Server, follow the steps in Chapter 5, "Configuring the Web Tier."

1. Use the Oracle Fusion Middleware 11g Web Tier Utilities Configuration Wizard to scale up the topology, as described in Chapter 5, "Configuring the Web Tier."

2. Copy all files created in ORACLE_INSTANCE/config/OHS/component/moduleconf from the existing web tier configuration to the new one.

3. Register the new Oracle HTTP Server instance, as described in Section 6.10, "Registering Oracle HTTP Server with WebLogic Server."

4. Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.

20.3.2 Scaling Out the Topology

In scaling out a topology, new servers are added to new nodes. The components in all three tiers of the Oracle Identity Management topology described in this manual can be scaled out by adding a new server instance to a new node.

20.3.2.1 Scaling Out the Directory Tier

The directory tier consists of the two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled out by adding new nodes to the directory tier.

20.3.2.1.1 Scaling Out Oracle Internet Directory

The directory tier has two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance. The Oracle Internet Directory instances can be scaled out by adding a new node to the existing Oracle Internet Directory cluster. To scale out Oracle Internet Directory instances, follow these steps:

1. Follow the steps in Section 7.3.2, "Configuring an Additional Oracle Internet Directory Instance" to add a new node running Oracle Internet Directory.

2. Follow the steps in Section 7.4.1, "Registering Oracle Internet Directory with the WebLogic Server Domain" to register the new Oracle Internet Directory instance with the WebLogic domain.

3. Configure SSL server authentication mode for the new instance, as described in

4. Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.

20.3.2.1.2 Scaling Out Oracle Virtual Directory

The directory tier has two nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. Oracle Virtual Directory can be scaled out by adding a new node configured to run Oracle Virtual Directory to the directory tier. To scale out Oracle Virtual Directory instances, follow these steps:

1. Follow the steps in Section 9.3.2, "Configuring an Additional Oracle Virtual Directory" to add a new node running Oracle Virtual Directory.

2. Follow the steps in these sections to register the new Oracle Virtual Directory instance with the WebLogic domain.

   • Section 9.4, "Post-Configuration Steps"

   • Section 9.6, "Validating the Oracle Virtual Directory Instances"

   • Section 9.7, "Creating ODSM Connections to Oracle Virtual Directory"

   • Section 9.8, "Creating Adapters in Oracle Virtual Directory"

   • Section 10.4.9, "Updating Oracle Virtual Directory Adapters"

3. Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.

20.3.2.2 Scaling Out the Application Tier

The application tier has two nodes (IDMHOST1 and IDMHOST2) running Managed Servers for Oracle Directory Integration Platform and Oracle Directory Services Manager, and two nodes (OAMHOST1 and OAMHOST2) running the Oracle Access Manager server.

Some of the procedures described in this section show you how to create a new WebLogic managed server. If you add a new managed server to your topology, after adding the managed server you must update your Oracle HTTP Server configuration files (on all nodes) and add the new server to the existing WebLogic cluster directives.

For example if you add a new Oracle Access Manager server, you must update oam.conf to include the new managed server.

Update oam.conf as follows:

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>

Once you have updated oam.conf, restart the Oracle HTTP server(s) as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.

20.3.2.2.1 Scaling Out Oracle Identity Federation

The application tier has two nodes (OIFHOST1 and OIFHOST2) running a Managed Server configured with Oracle Identity Federation. The Oracle Identity Federation instances can be scaled out by adding a new node with a Managed Server to the existing cluster.

Use the existing installations in shared storage for creating the new Managed Servers. You do not need to install WebLogic Server or Identity Management binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.

To scale out the Oracle Identity Federation instances, follow these steps:

1. Follow the steps in these sections to scale out the Oracle Identity Federation instances in the topology.

   • Section 15.3, "Configuring Oracle Identity Federation on OIFHOST2"

   • Section 15.4, "Provisioning the Managed Servers on the Local Disk"

   • Section 15.5, "Validating Oracle Identity Federation"

   • Section 15.6, "Configure the Enterprise Manager Agents"

2. Follow the steps in Section 15.8, "Configuring Oracle Identity Federation to work with the Oracle Web Tier" to add the newly added Managed Server host name and port to the list WebLogicCluster parameter.

20.3.2.2.2 Scaling Out Oracle Directory Integration Platform and ODSM

The application tier has two nodes (IDMHOST1 and IDMHOST2) running a Managed Server configured with Oracle Directory Integration Platform and Oracle Directory Services Manager. The Oracle Directory Integration Platform and Oracle Directory Services Manager instances can be scaled out by adding a new node with a Managed Server to the existing cluster.

Use the existing installations in shared storage for creating the new Managed Servers. You do not need to install WebLogic Server or Identity Management binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.

To scale out DIP and ODSM instances, follow these steps:

1. Follow the steps in Section 8.2, "Expanding the Oracle Directory Integration Platform and ODSM Cluster" to scale out the Oracle Directory Integration Platform and Oracle Directory Services Manager instances in the topology.

2. Reconfigure the Oracle HTTP Server module with the new Managed Server.

   Follow the steps in Section 8.4, "Configuring ODSM to work with the Oracle Web Tier." for the instructions to complete this task.

   Add the newly added Managed Server host name and port to the list WebLogicCluster Parameter.

20.3.2.2.3 Scaling Out Oracle Access Manager 11g

Scale out is very similar to scale up but first requires the software to be installed on the new node.

Use the existing installations in shared storage for creating the new Managed Servers. You do not need to install WebLogic Server or Identity Management 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 you are using shared storage, allow the new host access to that shared storage area.

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 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 Server Administration Console at http://admin.mycompany.com/console.

4. From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.

5. Click Lock & Edit from the Change Center menu.

6. Select an existing server on the host you want to extend, for example: WLS_OAM1.

7. Click Clone.

8. Enter the following information:

   • Server Name: A new name for the server, for example: WLS_OAM3.

   • Server Listen Address: The name of the host on which the Managed Server runs.

   • Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.

9. Click OK.

10. Click the newly created server WLS_OAM3.

11. Set the SSL listen port. This should be unique on the host that the Managed Server runs on.

12. Click Save.

13. Disable host name verification for the new Managed Server. Before starting and verifying the WLS_OAM3 Managed Server, you must disable host name 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 IDMHOSTn.

    If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name verification settings was propagated to the cloned server. To disable host name verification, proceed as follows:

    1. In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.

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

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

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

    5. Click the SSL tab.

    6. Click Advanced.

    7. Set Hostname Verification to None.

    8. Click Save.

14. Click Activate Configuration from the Change Center menu.

15. Restart the WebLogic Administration Server as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

16. Pack the domain on IDMHOST1 using the command:

    pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true
    

    The pack.sh script is located in MW_HOME/oracle_common/common/bin.

17. Unpack the domain on the new host using the command:

    unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
    

    The unpack.sh script is located in MW_HOME/oracle_common/common/bin.

18. Start Node Manager and update the property file.

    1. Start and stop Node Manager as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

    2. Run the script setNMProps.sh, which is located in ORACLE_COMMON_HOME/common/bin, to update the node manager properties file, for example:

       cd ORACLE_COMMON_HOME/common/bin
       ./setNMProps.sh
       

    3. Start Node Manager once again as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

Register the new Managed Server with Oracle Access Manager. The new Managed Server now must be configured as an Oracle Access Manager server. You do this from the Oracle OAM console, as follows:

1. Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin user.

2. Click the System Configuration tab.

3. Click Server Instances.

4. Select Create from the Actions menu.

5. Enter the following information:

   • Server Name: WLS_OAM3

   • Host: Host that the server is running on, IDMHOST3.

   • Port: Listen port that was assigned when the Managed Server was created.

   • OAM Proxy Port: Port you want the Oracle Access Manager proxy to run on. This is unique for the host.

   • Proxy Server ID: AccessServerConfigProxy

   • Mode: Set to Open or Simple, depending on the mode your existing Oracle Access Manager servers are operating in.

6. Click Apply.

Add the newly created Oracle Access Manager server to all WebGate profiles that might be using it, such as Webgate_IDM and IAMSuiteAgent.

For example, to add the Oracle Access Manager server to Webgate_IDM, access the OAM console at http://admin.mycompany.com/oamconsole and proceed as follows:

1. Log in as the Oracle Access Manager admin user you created in Section 10.4.2, "Creating Users and Groups for Oracle Access Manager."

2. Click the System Configuration tab

3. Expand Access Manager Settings - SSO Agents - OAM Agents.

4. Click the open folder icon, then click Search.

You should see the WebGate agent Webgate_IDM.

5. Click the agent Webgate_IDM.

6. Select Edit from the Actions menu.

7. Click + in the Primary Server list (or the secondary server list if this is a secondary server).

8. Select the newly created managed server from the Server drop down list.

9. Set Max Connections to 4.

10. Click Apply

Repeat Steps 5 through 10 for IAMSuiteAgent and other WebGates that are in use.

Update the Web Tier. Now that the new Managed Server has been created and started, the web tier starts to direct requests to it. Best practice, however, is to inform the web server that the new Managed Server has been created.

You do this by updating the file OAM.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component name/moduleconf.

Add the new server to the WebLogicCluster directive in the file, for example, change:

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100
</Location>

to:

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>

20.3.2.2.4 Scaling Out Oracle Adaptive Access Manager

Scale out is very similar to scale up, but first requires the software to be installed on the new node.

Use the existing installations in shared storage for creating the new Managed Servers. You do not need to install WebLogic Server or Identity Management binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.

Proceed as follows:

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 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 WebLogic console at http://admin.mycompany.com/console.

4. From the Domain Structure pane of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.

5. Click Lock & Edit from the Change Center menu.

6. Select an existing server on the host you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.

7. Click Clone.

8. Enter the following information:

   • Server Name: A new name for the server, for example: WLS_OAAM3

   • Server Listen Address: The name of the host on which the Managed Server runs.

   • Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.

9. Click OK.

10. Click the newly-created server WLS_OAAM3.

11. Set the SSL listen port. This should be unique on the host that the Managed Server is running on.

12. Click Save.

13. Disable host name verification for the new Managed Server. Before starting and verifying the WLS_OAAM3 Managed Server, you must disable host name 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 OAAMHOSTn.

    If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name verification settings were propagated to the cloned server. To disable host name verification:

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

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

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

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

    5. Click the SSL tab.

    6. Click Advanced.

    7. Set Hostname Verification to None.

    8. Click Save.

14. Click Activate configuration from the Change Center menu.

15. Pack the domain on IDMHOST1 using the command:

    pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAAM Domain" -managed=true
    

    The pack.sh script is located in MW_HOME/oracle_common/common/bin.

16. Unpack the domain on the new host using the command:

    unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
    

    The unpack.sh script is located in MW_HOME/oracle_common/common/bin.

17. Before you can start Managed Servers from the console, you must create a Node Manager properties file on OAAMHOST2 by running the script setNMProps.sh. The setNMProps.sh script is located in MW_HOME/oracle_common/common/bin. Type:

    cd MW_HOME/oracle_common/common/bin
    ./setNMProps.sh
    

18. Start Node Manager and the new Managed Server on the new host

19. Now that the new Managed Server has been created and started, the web tier starts to direct requests to it. Best practice, however, is to inform the web server that the new Managed Server has been created.

    You do this by updating the file oaam.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component_name/moduleconf.

    Add the new server to the WebLogicCluster directive in the file. For example, change:

         <Location /oaam_admin>
           SetHandler weblogic-handler
           WLProxySSL ON 
           WLProxySSLPassthrough ON
           WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
       </Location>
    

    to:

          <Location /oaam_admin>
            SetHandler weblogic-handler
            WLProxySSL ON 
            WLProxySSLPassthrough ON
            WebLogicCluster
     oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhsot3.mycompany.com:14300
       </Location>
    

20.3.2.2.5 Scaling Out Oracle Identity Manager (Adding Managed Servers to New Nodes)

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.

  Notes:

  • If there is no existing installation in shared storage, installing WebLogic Server and SOA in the new nodes is required as described in Section 14.6.1, "Updating the Coherence Configuration for the SOA Managed Server."

  • 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 Oracle Fusion Middleware 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 IAM_HOME in shared storage to the local Oracle Inventory, execute the following command:

   SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/oui/bin
   SOAHOSTn> ./attachHome.sh -jreLoc JAVA_HOME
   

3. 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.

4. Log in to the Oracle WebLogic Administration Console.

5. Create a new machine for the new node to be used, and add the machine to the domain.

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

7. Use the Oracle WebLogic Server 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.

8. Assign the host name or IP address to use for the new Managed Server for the listen address of the Managed Server.

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

10. Create JMS servers for SOA, Oracle Identity Manager (if applicable), and UMS on the new Managed Server.

    1. Use the Oracle WebLogic Server 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 as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure." For example:

       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_auto_N. Use the SOAJMSFileStore_N for this JMSServer. Target the SOAJMSServer_auto_N Server to the recently created Managed Server (WLS_SOAn).

    3. Create a new persistence store for the new UMSJMSServer, and name it, for example, UMSJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."

       ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N

       Notes:

       • This directory must exist before the Managed Server is started or the start operation fails.

       • It is also possible to assign SOAJMSFileStore_N as the 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 JMS server. Target the UMSJMSServer_N server to the recently created Managed Server (WLS_SOAn).

    5. Create a new persistence store for the new BPMJMSServer, and name it, for example, BPMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."

       ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N

       Notes:

       • This directory must exist before the Managed Server is started. Otherwise, the start operation fails.

       • It is also possible to assign SOAJMSFileStore_N as the store for the new BPM 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 BPM, for example, BPMJMSServer_N. Use the BPMJMSFileStore_N for this JMS server. Target the BPMJMSServer_N server to the recently created Managed Server (WLS_SOAn).

    7. Create a new persistence store for the new OIMJMSServer, and name it, for example, OIMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.4, "Shared Storage and Recommended Directory Structure."

       ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
       

       Notes:

       • This directory must exist before the Managed Server is started or the start operation fails.

       • It is also possible to assign SOAJMSFileStore_N as the store for the new Oracle Identity Manager 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 Oracle Identity Manager: for example, OIMJMSServer_N. Use the OIMJMSFileStore_N for this JMS Server. Target the OIMJMSServer_N Server to the recently created Managed Server (WLS_OIMn).

    9. Update the SubDeployment targets for the BPMJMSSystemResource to include the recently created BPM 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 Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click BPMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for BPMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for BPMJMS appears.

       Note:

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

       Click the BPMJMSServerXXXXXX subdeployment. Add the new JMS Server for BPM called BPMJMSServer_N to this subdeployment. Click Save.

    10. 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 Oracle WebLogic Server 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. Open the SubDeployments tab. The subdeployment module for SOAJMS appears.

        Note:

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

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

    11. Update the SubDeployment targets for 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 Oracle WebLogic Server 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. Open the SubDeployments tab. The subdeployment module for UMSJMS appears

        Note:

        This subdeployment module 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).

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

    12. Update the SubDeployment Targets for OIMJMSModule to include the recently created Oracle Identity Manager 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 Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click OIMJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSModule appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.

        Note:

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

        Click the OIMJMSXXXXXX subdeployment. Add the new JMS Server for Oracle Identity Manager called OIMJMSServer_N to this subdeployment. Click Save.

11. Click Activate Configuration from the Change Center menu.

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

    Prompt> cd ORACLE_COMMON_HOME/common/bin
    Prompt> ./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:

    Prompt> 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 -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
    

13. Configure Oracle Coherence, as described in Section 14.6.1, "Updating the Coherence Configuration for the SOA Managed Server."

14. Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:

    1. Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at:

       http://admin.mycompany.com/em

    2. Log in to Oracle Enterprise Manager Fusion Middleware Control using the admin user credentials.

       Note:

       At least one of the Oracle Identity Manager Managed Servers must be running for when these steps are executed.

    3. Navigate to Identity and Access, and then oim.

    4. Right-click oim and navigate to System MBean Browser.

    5. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.

    6. Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.

    7. The Rmiurl attribute is used for accessing SOA EJBs deployed on SOA Managed Servers. This is the application server URL. For a clustered deployment of Oracle Identity Manager, it is a comma-delimited list of all the SOA Managed Server URLs. The following are example values for this attribute:

       t3://oimhost1.mycompany.com:8001

       oimhost2.mycompany.com:8001

       oimhost3.mycompany.com:8001

15. Configure TX persistent store for the new server. This should be a location visible from other nodes as indicated in the recommendations about shared storage.

    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.

16. Disable host name verification for the new Managed Server. Before starting and verifying the WLS_SOAn Managed Server, you must disable host name 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 host name verification, these steps are not required (the host name verification setting is propagated to the cloned server).

    To disable host name verification:

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

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

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

    4. Select WLS_SOAn in the Names column of the table.

       The Settings page for server appears.

    5. Click the SSL tab.

    6. Click Advanced.

    7. Set Hostname Verification to None.

    8. Click Save.

17. Click Activate Configuration from the Change Center menu.

18. 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 host name of the new node as a parameter as follows:

    SOAHOSTN> WL_HOME/server/bin/startNodeManager new_node_ip
    

19. Start and test the new Managed Server from the Oracle WebLogic Server Administration Console:

    1. Shut down all the existing Managed Servers in the cluster.

    2. Ensure that the newly created Managed Server, WLS_SOAn, is running.

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

20. 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 an environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges. The floating IP address for the new SOA Managed Server is already present in the new node.

    Configure server migration following these steps:

    1. Log in to the Administration Console.

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

    3. Select the server (represented as hyperlink) for which you want to configure migration from the Names column of the table. The Setting 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.

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

       1. Abruptly stop the WLS_SOAn Managed Server.

       2. 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
       

       3. Watch the Node Manager Console. You should see a message indicating that floating IP address for WLS_SOA1 has been disabled.

       4. 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.

       5. 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.

20.3.2.3 Scaling Out the Web Tier

The web tier has two nodes each running an instance of the Oracle HTTP Server. The Oracle HTTP Server components can be scaled out by adding a new node configured to run Oracle HTTP Server to the web tier. To scale out Oracle HTTP Server, proceed as follows:

1. Follow the steps in Section 4.4, "Installing Oracle HTTP Server." Alternatively, on the new node, mount the existing Middleware home, if you are using shared storage.

2. Follow the steps in Chapter 5, "Configuring the Web Tier."

3. Copy all files created in ORACLE_INSTANCE/config/OHS/component/moduleconf from the existing web tier configuration to the new one.

4. If you have enabled Single Sign-on in the topology, you must update the WebTier configuration for Single Sign-on as described in Section 19.5, "Installing and Configuring WebGate."

5. Register the new Oracle HTTP Server instance as described in Section 6.10, "Registering Oracle HTTP Server with WebLogic Server."

6. Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.

20.4 Performing Backups and Recoveries

Table 20-1 shows the static artifacts to back up in the 11g Oracle Identity Management enterprise deployment.

Table 20-1 Static Artifacts to Back Up in the Identity Management Enterprise Deployment

Type	Host	Location	Tier
Oracle Home (database)	Oracle RAC database hosts: OIDDBHOST1 OIDDBHOST2	User Defined	Directory Tier
MW_HOME (OID)	OIDHOST1 OIDHOST2	Middleware home, MW_HOME: /u01/app/oracle/product/fmw Identity Management Oracle home, IDM_ORACLE_HOME: /u01/app/oracle/product/fmw/idm on both the OIDHOST1 and OIDHOST2	Directory Tier
MW_HOME (OVD)	OVDHOST1 OVDHOST2	Middleware home, MW_HOME: /u01/app/oracle/product/fmw Identity Management Oracle home, IDM_ORACLE_HOME: /u01/app/oracle/product/fmw/idm on both the OVDHOST1 and OVDHOST2	Directory Tier
MW_HOME (DIP, ODSM, OIM, OAAM, OAM11g, OIF and Admin Server)	IDMHOST1 IDMHOST2	Middleware Oracle home, MW_HOME: /u01/app/oracle/product/fmw (Identity Management Oracle home DIP/ODSM, IDM_ORACLE_HOME: /u01/app/oracle/product/fmw/idm on both IDMHOST1 and IDMHOST2 (Admin server Oracle home, IAM_ORACLE_HOME /u01/app/oracle/product/fmw/iam on both IDMHOST1 and IDMHOST2	Application Tier
MW_HOME (OHS)	WEBHOST1 WEBHOST2	Middleware Oracle home, MW_HOME: /u01/app/oracle/product/fmw Web Oracle Home, WEB_ORACLE_HOME: /u01/app/oracle/product/fmw/web on WEBHOST1 Web Oracle Home, WEB_ORACLE_HOME: /u01/app/oracle/product/fmw/web on WEBHOST2	Web Tier
Install Related Files	Each host	OraInventory: ORACLE_BASE/orainventory /etc/oratab, /etc/oraInst.loc user_home/bea/beahomelist (on hosts where WebLogic Server is installed) Windows registry: (HKEY_LOCAL/MACHINE/Oracle)	Not applicable.

Table 20-2 shows the run-time artifacts to back up in the 11g Oracle Identity Management enterprise deployment:

Table 20-2 Run-Time Artifacts to Back Up in the Identity Management Enterprise Deployments

Type	Host	Location	Tier
Domain Home	IDMHOST1 IDMHOST2	ORACLE_BASE/admin/IDMDomain/aserver on both IDMHOST1 and IDMHOST2	Application Tier
Application Artifacts (ear and war files)	IDMHOST1 IDMHOST2	Look at all the deployments, including Oracle Directory Integration Platform and Oracle Directory Services Manager, through the WebLogic Server Administration Console to identity all the application artifacts.	Application Tier
Instance Home (OHS)	WEBHOST1 WEBHOST2	OHS Instance Home on WEBHOST1: ORACLE_BASE/admin/ohs_inst1 OHS Instance Home on WEBHOST2: ORACLE_BASE/admin/ohs_inst2	Web Tier
OID Instance Home	OIDHOST1 OIDHOST2	OID Instance Home on OIDHOST1: ORACLE_BASE/admin/oid_inst1 OID Instance Home on OIDHOST2: ORACLE_BASE/admin/oid_inst2	Directory Tier
OVD Instance Home	OVDHOST1 OVDHOST2	OVD Instance Home on OVDHOST1: ORACLE_BASE/admin/ovd_inst1 OVD Instance Home on OVDHOST2: ORACLE_BASE/admin/ovd_inst2	Directory Tier
Oracle RAC Databases	OIDDBHOST1 OIDDBHOST2	User defined	Directory Tier
OAM	OAMHOST1 OAMHOST2	All the configurations are within the respective home directories described in this table. There are no instance homes.	Application Tier

For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.

20.5 Patching Enterprise Deployments

This section describes how to apply an Oracle Fusion Middleware patch file and how to patch Oracle Identity Management components with minimal down time.

This section contains the following topics:

• Section 20.5.1, "Patching an Oracle Fusion Middleware Source File"

• Section 20.5.2, "Patching Identity Management Components"

20.5.1 Patching an Oracle Fusion Middleware Source File

For information on patching an Oracle Fusion Middleware source file, see the Oracle Fusion Middleware Administrator's Guide.

20.5.2 Patching Identity Management Components

To patch Oracle Identity Management components with minimal down time, it is recommended that you follow these guidelines:

1. Route the LDAP traffic from OIDHOST1 and OVDHOST1 to OIDHOST2 and OVDHOST2.

2. Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST1 or OVDHOST1).

3. Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.

4. Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.

5. Test the patch.

6. Route the traffic to OIDHOST1 or OVDHOST1 again.

7. Verify the applications are working properly.

8. Route the LDAP traffic on OIDHOST2 and OVDHOST2 to OIDHOST1 and OVDHOST1.

9. Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST2 or OVDHOST2).

10. Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.

11. Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.

12. Test the patch.

13. Route the traffic to both hosts on which the patch has been applied (OIDHOST1 and OIDHOST2, or OVDHOST1 and OVDHOST2).

20.6 Troubleshooting

This section describes how to troubleshoot common issues that can arise with the Identity Management enterprise deployment described in this manual.

This section contains the following topics:

• Section 20.6.1, "Troubleshooting Oracle Internet Directory"

• Section 20.6.2, "Troubleshooting Oracle Virtual Directory"

• Section 20.6.3, "Troubleshooting Oracle Directory Integration Platform"

• Section 20.6.4, "Troubleshooting Oracle Directory Services Manager"

• Section 20.6.5, "Troubleshooting Oracle Access Manager 11g"

• Section 20.6.6, "Troubleshooting Oracle Identity Manager"

• Section 20.6.7, "Troubleshooting Oracle Identity Federation"

20.6.1 Troubleshooting Oracle Internet Directory

This section describes some common problems that can arise with Oracle Internet Directory and the actions you can take to resolve the problem.

Problem

The Oracle Internet Directory server is not responsive. When the load balancing router is configured to send an ICMP message to the LDAP SSL port for monitoring, the Oracle Internet Directory server starting SSL negotiation sometimes hangs, and thus it is required that the load balancing router not use ICMP messages for monitoring the LDAP SSL port.

Solution

Use an alternative such as TCP or the LDAP protocol itself.

Also, monitoring the LDAP non-SSL port is sufficient to detect LDAP availability.

Problem

The SSO/LDAP Application connection is lost to Oracle Internet Directory server

Solution

Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.

Problem

The LDAP application is receiving LDAP Error 53 (DSA Unwilling to Perform). When one of the database nodes goes down during the middle of the LDAP transaction, the Oracle Internet Directory server sends error 53 to the LDAP client

Solution

To see why the Oracle Internet Directory database node went down, see the Oracle Internet Directory logs in this location:

ORACLE_INSTANCE/diagnostics/logs/OID/oidldapd01s*.log

Problem

Issues involving TNSNAMES.ORA, TAF configuration, and related issues.

Solution

See the Oracle Database High Availability Overview manual.

20.6.2 Troubleshooting Oracle Virtual Directory

This section describes some common problems that can arise with Oracle Virtual Directory and the actions you can take to resolve the problem:

Problem

You get a command not found error when you run SSLServerConfig.sh, for example:

./SSLServerConfig.sh: line 169: 20110520125611: command not found 

Solution

Edit the file orapki.bat (on Windows) or orapki.sh (on Linux) and remove any blank lines at the end of the file. Save the file and run SSLServerConfig.sh again.

Problem

Oracle Virtual Directory is not responsive. When the load balancing router is configured to send an ICMP message to the LDAP SSL port for monitoring, the Oracle Virtual Directory server starting SSL negotiation sometimes hangs, and thus it is required that the load balancing router not use ICMP messages for monitoring the LDAP SSL port.

Solution

Use an alternative such as TCP or the LDAP protocol itself.

Also, monitoring the LDAP non-SSL port is sufficient to detect LDAP availability.

Problem

The SSO/LDAP Application connection is lost to the Oracle Virtual Directory server.

Solution

Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.

Problem

Issues involving TNSNAMES.ORA, TAF configuration, and related issues.

Solution

See the Oracle Database High Availability Overview manual.

Problem

When you run SSLServerConfig.sh for component OVD, sometime it fails with an error similar to this:

>>>Enter password for weblogic:
>>>Enter your keystore name [ovdks1.jks]:
Checking the existence of ovdks1.jks in the OVD...

>>>Failed to configure your SSL server wallet
>>>Please check /scratch/aime1/edgfa/idm//rootCA/keystores/ovd/ks_check.log for more information

In the log file, you see an error message like this:

Problem invoking WLST - Traceback (innermost last):
File "/scratch/aime1/edgfa/idm/rootCA/keystores/ovd/ovdssl-check.py", line 8, in ?
File "<iostream>", line 182, in cd
File "<iostream>", line 1848, in raiseWLSTExceptionWLSTException: Error occured while performing cd : Attributeoracle.as.ovd:type=component.listenersconfig.sslconfig,name=LDAP SSLEndpoint,instance=ovd_inst1,component=ovd1 not found. Use ls(a) to view theattributes

Solution

The problem is intermittent.To work around the issue, re-run the script.

20.6.3 Troubleshooting Oracle Directory Integration Platform

This section describes some common problems that can arise with Oracle Directory Integration Platform and the actions you can take to resolve the problem.

Problem

The instance is not working properly.

Solution

Check the respective log of the instance. For example, if the instance deployed in WLS_ODS1 is not running, then check the WLS_ODS1-diagnostic.log file.

Problem

Exceptions similar to the following are seen in Managed Server log files running the Oracle Directory Integration Platform application during an Oracle RAC failover:

RuntimeException:
[2008-11-21T00:11:10.915-08:00] [WLS_ODS] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection

AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [WLS_ODS] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]

Most of the exceptions are related to the scheduler or LDAP, for example:

1. Could not retrieve datasource via JNDI url 'jdbc/schedulerDS' java.sql.SQLException.

2. javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]

Solution

During an Oracle RAC failover, exceptions are seen in the Managed Server log files running the Oracle Directory Integration Platform application. These errors are thrown when the multi data sources configured on the WebLogic Server platform try to verify the health of the Oracle RAC database instances during failover. These are innocuous errors and can be ignored. The Oracle Directory Integration Platform application recovers and begin to operate normally after a lag of one or two minutes. For an Oracle RAC failover, there is no Oracle Directory Integration Platform down time if one instance is running at all times.

20.6.4 Troubleshooting Oracle Directory Services Manager

This section describes some common problems that can arise with Oracle Directory Services Manager and the actions you can take to resolve the problem.

After you have logged into Oracle Directory Services Manager, you can connect to multiple directory instances from the same browser window.

Avoid using multiple windows of the same browser program to connect to different directories at the same time. Doing so can cause a Target unreachable error.

You can log in to the same Oracle Directory Services Manager instance from different browser programs, such as Internet Explorer and Firefox, and connect each to a different directory instance.

If you change the browser language setting, you must update the session to use the new setting. To update the session, either disconnect the current server connection, refresh the browser page (either reenter the Oracle Directory Services Manager URL in the URL filed and press enter or press F5) and reconnect to the same server, or quit and restart the browser.

Problem

You attempt to invoke Oracle Directory Services Manager from Oracle Enterprise Manager Fusion Middleware Control by selecting Directory Services Manager from the Oracle Internet Directory menu in the Oracle Internet Directory target, then Data Browser, Schema, Security, or Advanced.

Oracle Directory Services Manager does not open. You might see an error message.

Solution

This is probably an installation problem. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

Problem

When you perform an Oracle Directory Services Manager failover using Oracle HTTP Server, the failover is not transparent. You see this behavior when you perform the following steps:

1. Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.

2. Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.

3. Make a connection to an Oracle Internet Directory server.

4. Work with the Oracle Internet Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.

5. Shut down one Managed Server at a time using the WebLogic Server Administration Console.

6. Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Internet Directory.

7. When you do, a message is displayed advising you to re-establish a new connection to the Oracle Directory Services Manager page.

Solution

If you encounter this problem, perform the following steps:

1. In your web browser, exit the current Oracle Directory Services Manager page.

2. Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.

3. Re-establish a new connection to the Oracle Internet Directory server you were working with earlier.

Problem

Oracle Directory Services Manager temporarily loses its connection to Oracle Internet Directory and displays the message LDAP Server is down.

Solution

In a High Availability configuration where Oracle Directory Services Manager is connected to Oracle Internet Directory through a load balancer, Oracle Directory Services Manager reports that the server is down during failover from one instance of Oracle Internet Directory to another. In other configurations, this message might indicate that Oracle Internet Directory has been shut down and restarted. In either case, the connection is reestablished in less than a minute, and you are able to continue without logging in again.

Problem

Oracle Directory Services Manager temporarily loses its connection to an Oracle Internet Directory instance that is using a Oracle RAC database. Oracle Directory Services Manager might display the message

LDAP error code 53 - Function not implemented.

Solution

This error can occur during failover of the Oracle Database that the Oracle Internet Directory instance is using. The connection is reestablished in less than a minute, and you are able to continue without logging in again.

Problem

You must perform the following steps to configure Oracle HTTP Server to route Oracle Directory Services Manager requests to multiple Oracle WebLogic Servers in a clustered Oracle WebLogic Server environment.

Solution

Perform these steps:

1. Create a backup copy of the Oracle HTTP Server's admin.conf file, which is located in ORACLE_INSTANCE/config. The backup copy provides a source to revert to if you encounter problems after performing this procedure.

2. Add the following text to the end of the Oracle HTTP Server's admin.conf file and replace the variable placeholder values with the host names and Managed Server port numbers specific to your environment. Be sure to use the <Location /odsm/ > as the first line in the entry. Using <Location /odsm/faces > or <Location /odsm/faces/odsm.jspx > can distort the appearance of the Oracle Directory Services Manager interface.

   <Location /odsm/ >
   SetHandler weblogic-handler
   WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
   </Location>
   

3. Restart the Oracle HTTP Server, as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components," to activate the configuration change.

   Note:

   Oracle Directory Services Manager loses its connection and displays a session time-out message if the Oracle WebLogic Server in the cluster that it is connected to fails. Oracle Directory Services Manager requests is routed to the secondary Oracle WebLogic Server in the cluster that you identified in the httpd.conf file after you log back in to Oracle Directory Services Manager.

Problem

Attempting to access Oracle Directory Services Manager using a web browser fails.

Solution

• Verify the Oracle Virtual Directory server is running. The Oracle Virtual Directory server must be running to connect to it from Oracle Directory Services Manager.

• Verify you entered the correct credentials in the Server, Port, User Name and Password fields. You can execute an ldapbind command against the target Oracle Virtual Directory server to verify the server, user name, and password credentials.

• Verify you are using a supported browser. Oracle Directory Services Manager supports the following browsers:

  • Internet Explorer 7

  • Firefox 2.0.0.2 and 3.0

  • Safari 3.1.2 (desktop)

  • Google Chrome 0.2.149.30

    Note:

    While Oracle Directory Services Manager supports all of the preceding browsers, only Internet Explorer 7 and Firefox 2.0.0.2 are certified.

Problem

Oracle Directory Services Manager does not open after you attempt to invoke it from Oracle Enterprise Manager Fusion Middleware Control by selecting one of the options from the Directory Services Manager entry in the Oracle Virtual Directory menu in the Oracle Virtual Directory target.

Solution

This is probably an installation problem. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

Problem

When you perform an Oracle Directory Services Manager failover using Oracle HTTP Server, the failover is not transparent. You see this behavior when you perform the following steps:

1. Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.

2. Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.

3. Make a connection to an Oracle Virtual Directory server.

4. Work with the Oracle Virtual Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.

5. Shut down one Managed Server at a time using the WebLogic Server Administration Console.

6. Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Virtual Directory. When you do, a message is displayed advising you to re-establish a new connection to the Oracle Directory Services Manager page.

Solution

If you encounter this problem, perform the following steps:

1. In your web browser, exit the current Oracle Directory Services Manager page.

2. Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.

3. Re-establish a new connection to the Oracle Virtual Directory server you were working with earlier.

Problem

Oracle Directory Services Manager temporarily loses its connection to an Oracle Virtual Directory instance that is using an Oracle RAC Database. Oracle Directory Services Manager might display the message LDAP error code 53 - Function not implemented.

Solution

This error can occur during failover of the Oracle Database that the Oracle Virtual Directory instance is using. The connection is reestablished in less than a minute, and you are able to continue without logging in again.

20.6.5 Troubleshooting Oracle Access Manager 11g

This section describes some common problems that can arise with Oracle Access Manager and the actions you can take to resolve the problem.

20.6.5.1 User Reaches the Maximum Allowed Number of Sessions

Problem

The Oracle Access Manager 11g server displays an error message similar to this:

The user has already reached the maximum allowed number of sessions. Please close one of the existing sessions before trying to login again.

Solution

If users log in multiple times without logging out, they might overshoot the maximum number of configured sessions. You can modify the maximum number of configured sessions by using the OAM Administration Console.

To modify the configuration by using the OAM Administration Console, proceed as follows:

1. Go to System Configuration -> Common Settings -> Session

2. Increase the value in the Maximum Number of Sessions per User field to cover all concurrent login sessions expected for any user. The range of values for this field is from 1 to any number.

20.6.5.2 Policies Do Not Get Created When Oracle Access Manager is First Installed

Problem

The Administration Server takes a long time to start after configuring Oracle Access Manager.

Solution

Tune the OAM database. When the Administration server first starts after configuring Oracle Access Manager, it creates a number of default policies in the database. If the database is distant or in need of tuning, this can take a significant amount of time.

Resources
Authentication Policies
   Protected Higher Level Policy
   Protected Lower Level Policy
   Publicl Policy
Authorization Policies
   Authorization Policies

If you do not see these items, the initial population has failed. Check the Administration Server log file for details.

20.6.5.3 You Are Not Prompted for Credentials After Accessing a Protected Resource

Problem

When you access a protected resource, Oracle Access Manager should prompt you for your user name and password. For example, after creating a simple HTML page and adding it as a resource, you should see credential entry screen.

Solution

If you do not see the credential entry screen, perform the following steps:

1. Verify that Host Aliases for IDMDomain have been set. You should have aliases for IDMDomain:80, IDMDomain:Null:, admin.mycompany.com:80, and sso.mycompany.com:443.

2. Verify that WebGate is installed.

3. Verify that OBAccessClient.xml was copied from DOMAIN_HOME/output to the WebGate Lib directory and that OHS was restarted.

4. When OBAccessClient.xml was first created, the file was not formatted. When the OHS is restarted, reexamine the file to ensure that it is now formatted. OHS gets a new version of the file from Oracle Access Manager when it first starts.

5. Shut down the Oracle Access Manager servers and try to access the protected resource. You should see an error saying Oracle Access Manager servers are not available. If you do not see this error, re-install WebGate.

20.6.6 Troubleshooting Oracle Identity Manager

This section describes some common problems that can arise with Oracle Identity Manager and the actions you can take to resolve the problem.

Problem

When you run Oracle Identity Manager configuration, the error java.io.FileNotFoundException: soaconfigplan.xml (Permission denied) may appear and Oracle Identity Manager configuration might fail.

Solution

To workaround this issue:

1. Delete the file /tmp/oaconfigplan.xml.

2. Start the configuration again (OH/bin/config.sh).

Problem

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)
         .
         .
         .

Solution

Despite this exception, the user is created correctly.

20.6.7 Troubleshooting Oracle Identity Federation

This section describes some common problems that can arise with Oracle Identity Federation and the actions you can take to resolve the problem.

Problem

On a Windows system, you cannot log in to the Oracle Identity Federation server even though it is running.

Solution

Make sure that the Oracle Identity Federation server is using IPv4, if everything else is using IPv4).

To verify this, look in the file DOMAIN_HOME/bin/setDomainEnv.cmd on OIFHOST1 and OIFHOST2.

Locate the line EXTRA_JAVA_PROPERTIES and add the following to the entry if it is not already present:

-Djava.net.preferIPv6Addresses -DuseIPv6Address=false
-Djava.net.preferIPv6Addresses=false

Save the file and restart the Oracle Identity Federation servers as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."

Problem

Extending the domain with Oracle Identity Federation fails when Oracle Identity Manager is installed at the Create Managed Server step.

Solution

Copy the file setDomainEnv.sh from DOMAIN_HOME/bin on IDMHOST1 to OIFHOST1.

Retry the operation.

Problem

You cannot change Oracle Identity Federation parameters by using Oracle Enterprise Manager Fusion Middleware Control. You see the message:

Configuration settings are unavailable because ..... OIF ...... is down

even though Oracle Identity Federation is up and running.

Solution

Here are the common causes and resolutions:

1. Oracle Identity Federation is up but the EM agent is down.

   1. Check the EM agent status by running:

      ORACLE_INSTANCE/EMAGENT/EMAGENT/bin/emctl status agent
      

   2. Start the EM agent, if it is down, by running:

      ORACLE_INSTANCE/bin/opmnctl startproc ias-component=EMAGENT
      

   3. Log in to Fusion Middleware Control again.

2. Oracle Identity Federation and EM agent are up, but the OIF home page and configuration pages in Fusion Middleware Control still show: OIF is down.

   1. Check if the EM agent points to the correct Fusion Middleware Control by running:

      ORACLE_INSTANCE/EMAGENT/EMAGENT/bin/emctl status agent
      

      Verify that the host and port for property Repository URL are the same as the Fusion Middleware Control's host and port.

   2. If the host and port are mismatched, change the Repository URL in EM agent to the correct Fusion Middleware Control by running:

      ORACLE_INSTANCE/EMAGENT/EMAGENT/bin/emctl switchOMS  http(s)://Host:Port/em/upload'
      

   3. Log in to Fusion Middleware Control again.

3. If the issue still exists, once logged in to Fusion Middleware Control, navigate to Farm->Agent-Monitored Targets (Top Left corner of the page) and click the Configure icon of the row that refers to Oracle Identity Federation. On the next page, ensure that all the information is correct and complete. Click OK to confirm.

   Check that the WebLogic user name and password are present.

   Check the host value. It might have been specified with an IPv6 address format.

4. If the issue still exists, restart the EM agent.

   1. Stop the EM agent by running:

      INST_HOME/bin/opmnctl stopproc ias-component=EMAGENT
      

   2. Start the EM agent by running:

      INST_HOME/bin/opmnctl startproc ias-component=EMAGENT
      

   3. Log in to Oracle Enterprise Manager Fusion Middleware Control again.

20.7 Other Recommendations

This section describes some other recommendations for the Oracle Identity Management enterprise deployment.

20.7.1 Preventing Timeouts for SQL*Net Connections

Most of the production deployment involves firewalls. Because database connections are made across firewalls, Oracle recommends that the firewall be configured so that the database connection is not timed out. For Oracle Real Application Clusters (Oracle RAC), the database connections are made on Oracle RAC VIPs and the database listener port. You must configure the firewall so it does not time out these connections. If such a configuration is not possible, set the SQLNET.EXPIRE_TIME=n parameter in the ORACLE_HOME/network/admin/sqlnet.ora file on the database server, where n is the time in minutes. Set this value to less than the known value of the timeout for the network device (that is, a firewall). For Oracle RAC, set this parameter in all of the Oracle home directories.