Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 1 (11.1.2) Part Number E21032-03 |
|
|
PDF · Mobi · ePub |
This chapter provides information about managing the Identity Management enterprise deployment you have set up.
This chapter includes the following topics:
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 19.1.2, "Starting and Stopping Oracle Virtual Directory"
Section 19.1.3, "Starting and Stopping Oracle Internet Directory"
Section 19.1.4, "Starting, Stopping, and Restarting Oracle HTTP Server"
Section 19.1.6, "Starting, Stopping, and Restarting WebLogic Administration Server"
Section 19.1.7, "Starting, Stopping, and Restarting Oracle Identity Manager"
Section 19.1.8, "Starting, Stopping, and Restarting Oracle Access Manager Managed Servers"
Section 19.1.9, "Starting and Stopping Oracle Identity Federation Managed Servers"
When starting up your entire infrastructure, start the components in the following order:
Database(s)
Database Listener(s)
Oracle Internet Directory
Oracle Virtual Directory
Oracle Access Manager Server(s)
WebLogic Administration Server
Oracle HTTP Server(s)
SOA Server(s)
Oracle Identity Manager Server(s)
Start and stop Oracle Virtual Directory as follows.
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
Start and stop Oracle Internet Directory as follows.
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
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
Start the Oracle web tier by issuing the command:
opmnctl startall
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.
Start and stop the Node Manager as follows:
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
To stop Node Manager, kill the process started in the previous section.
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.
Start and stop the WebLogic Administration Server as follows:
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
To stop the Administration Server, log in to the WebLogic console using the URL: http://admin.mycompany.com/console
.
Then proceed as follows:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select AdminServer(admin).
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you want to shut down the Administration Server.
Start and stop Oracle Identity Manager and Oracle SOA Suite servers as follows:
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:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
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.
Click the Start button.
Click Yes when asked to confirm that you want to start the server(s).
After WLS_SOA1 and/or WLS_SOA2 have started, select WLS_OIM1 and/or WLS_OIM2
Click Start.
Click Yes when asked to confirm that you want to start the server(s).
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:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OIM Servers (WLS_OIM1 and/or WLS_OIM2) and (WLS_SOA1 and/or WLS_SOA2).
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you want to shutdown the server(s).
Start and stop Oracle Access Manager Managed Servers as follows:
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:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).
Click the Start button.
Click Yes when asked to confirm that you want to start the server(s).
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:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you want to shut down the server(s).
Start and stop Oracle Identity Federation Managed Servers as follows:
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:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OIF Servers (WLS_OIF1 and/or WLS_OIF2).
Click Start.
Click Yes when asked to confirm that you want to start the server(s).
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:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OIF Servers (WLS_OIF1 and/or WLS_OIF2).
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you want to shut down the server(s).
Restart the server by following the previous Stop and Start procedures.
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
This section provides information about monitoring the Identity Management enterprise deployment described in this manual.
This section contains the following topics:
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Internet Directory, as follows:
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.
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.
The home page for an instance displays metrics for the instance such as performance, load, security, response, CPU utilization %, and memory utilization %.
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.
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Virtual Directory, as follows:
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.
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.
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.
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Directory Integration Platform, as follows:
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.
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.
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.
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".
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:
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 19.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.
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.
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:
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.
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.
Configure SSL server-authentication mode for the new instance as described in Section 7.4.3, "Configuring Oracle Internet Directory to Accept Server Authentication Mode SSL Connections."
Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.
If you have enabled Single Sign-on in the topology, you must update the WebTier configuration for Single Sign-on as described in Section 18.5, "Installing and Configuring WebGate."
Register the new Oracle HTTP Server instance as described in Section 6.10, "Registering Oracle HTTP Server with WebLogic Server."
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:
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.
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
.
Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.
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 19.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.
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.
Follow the steps in Section 8.2, "Expanding the Oracle Directory Integration Platform and ODSM Cluster".
Be sure to choose a port other than 7499, which is already in use.
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.
Scale up Oracle Access Manager as follows:
Log in to the Oracle WebLogic Server Administration Console at http://admin.mycompany.com/console
.
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.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAM1
.
Click Clone.
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.
Click OK.
Click the newly created server WLS_OAM3
Click Save.
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 OAMHOST
n
.
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:
In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None
.
Click Save.
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:
Log in to the OAM console at http://admin.mycompany.com/oamconsole
as the oamadmin
user.
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
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.
Click Coherence tab.
Set Local Port to a unique value on the host.
Click Apply.
Restart the WebLogic Administration Server as described in Section 19.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:
Log in as the Oracle Access Manager Admin User you created inSection 11.4.2, "Creating Users and Groups for Oracle Access Manager."
Click the System Configuration tab.
Expand Access Manager Settings - SSO Agents - OAM Agents.
Click the open folder icon, then click Search.
You should see the WebGate agent Webgate_IDM.
Click the agent Webgate_IDM.
Select Edit from the Actions menu.
Click +
in the Primary Server list (or the Secondary Server list if this is a secondary server).
Select the newly created managed server from the Server drop down list.
Set Max Connections to 4
.
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> <Location /fusion_apps> 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>
<Location /fusion_apps>
SetHandler weblogic-handler
WebLogicCluster idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100
</Location>
Save the file and restart the Oracle HTTP server, as described in Section 19.1, "Starting and Stopping Oracle Identity Management Components."
You can now start the new Managed Server, as described in Section 19.1, "Starting and Stopping Oracle Identity Management Components."
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:
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:
Select Environment -> Servers from the Administration Console.
From the Change Center menu, click Lock and Edit.
Select the Managed Server that you want to clone (for example, WLS_OIM1
or WLS_SOA1
).
Select Clone.
Name the new Managed Server WLS_OIM
n
or WLS_SOA
n
, 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
.
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.
Create JMS Servers for SOA, Oracle Identity Manager, UMS, and BPM on the new Managed Server.
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
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_SOA
n
).
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_SOA
n
.
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."
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.
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_SOA
n
).
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.
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_OIM
n
).
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 SOAJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1
and WLS_SOA2
).
Click the SOAJMSServer
XXXXXX
subdeployment. Add the new JMS Server for SOA called SOAJMSServer_
N
to this subdeployment. Click Save
.
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 UCMJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1
and WLS_SOA2
).
Click the UMSJMSServer
XXXXXX
subdeployment. Add the new JMS Server for UMS called UMSJMSServer_
N
to this subdeployment. Click Save.
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 BPMJMSServer
XXXXXX
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.
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 OIMJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1
and WLS_OIM2
).
Click the OIMJMSServer
XXXXXX
subdeployment. Add the new JMS Server for Oracle Identity Manager called OIMJMSServer_
N
to this subdeployment. Click Save.
Configure Oracle Coherence, as described in Section 13.6.1, "Updating the Coherence Configuration for the SOA Managed Server."
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.
Disable host name verification for the new Managed Server. Before starting and verifying the WLS_SOA
n
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 SOAHOST
n
. 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:
In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_SOAn
in the Names column of the table. The Settings page for the server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None
.
Click Save.
Repeat Steps 6a through 6h to disable host name verification for the WLS_OIM
n
Managed Servers. In Step d, select WLS_OIMn
in the Names column of the table.
Click Activate Changes from the Change Center menu.
Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:
Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at: http://admin.mycompany.com/em
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.
Navigate to Identity and Access, and then oim.
Right-click oim and navigate to System MBean Browser.
Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.
Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.
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
Restart the WebLogic Administration Server as described in Section 19.1, "Starting and Stopping Oracle Identity Management Components."
Start and test the new Managed Server from the Administration Console.
Shut down the existing Managed Servers in the cluster.
Ensure that the newly created Managed Server, WLS_SOA
n
, is up.
Access the application on the newly created Managed Server (http://vip:port/soa-infra
). The application should be functional.
Configure the newly created managed server for server migration. Follow the steps in Section 16.5, "Configuring Server Migration Targets" to configure server migration.
Test server migration for this new server. Follow these steps from the node where you added the new server:
Stop the WLS_SOA
n
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
Watch the Node Manager Console. You should see a message indicating that the floating IP address for WLS_SOA1
has been disabled.
Wait for the Node Manager to try a second restart of WLS_SOA
n
. Node Manager waits for a fence period of 30 seconds before trying this restart.
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.
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.
Follow the steps in Section 14.3, "Configuring Oracle Identity Federation on OIFHOST2" to scale up the topology for Oracle Identity Federation.
Be sure to choose a port other than 7499, which is already in use.
Follow the steps in Section 14.4, "Provisioning the Managed Servers on the Local Disk" to provision the new Oracle Identity Federation managed server on the local disk.
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.
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."
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."
Copy all files created in ORACLE_INSTANCE
/config/OHS/
component
/moduleconf
from the existing web tier configuration to the new one.
Register the new Oracle HTTP Server instance, as described in Section 6.10, "Registering Oracle HTTP Server with WebLogic Server."
Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.
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.
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.
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:
Follow the steps in Section 7.3.2, "Configuring an Additional Oracle Internet Directory Instance" to add a new node running Oracle Internet Directory.
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.
Configure SSL server authentication mode for the new instance, as described in Section 7.4.3, "Configuring Oracle Internet Directory to Accept Server Authentication Mode SSL Connections."
Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.
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:
Follow the steps in Section 9.3.2, "Configuring an Additional Oracle Virtual Directory" to add a new node running Oracle Virtual Directory.
Follow the steps in these sections to register the new Oracle Virtual Directory instance with the WebLogic domain.
Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.
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 19.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.
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:
Follow the steps in these sections to scale out the Oracle Identity Federation instances in the topology.
Follow the steps in Section 14.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.
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:
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.
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.
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.
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.
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.
Log in to the Oracle WebLogic Server Administration Console at http://admin.mycompany.com/console
.
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.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAM1
.
Click Clone.
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.
Click OK.
Click the newly created server WLS_OAM3.
Set the SSL listen port. This should be unique on the host that the Managed Server runs on.
Click Save.
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 IDMHOST
n
.
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:
In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure pane.
Click Servers. The Summary of Servers page appears.
Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Click Activate Configuration from the Change Center menu.
Restart the WebLogic Administration Server as described in Section 19.1, "Starting and Stopping Oracle Identity Management Components."
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/bi
n.
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
.
Start Node Manager and update the property file.
Start and stop Node Manager as described in Section 19.1, "Starting and Stopping Oracle Identity Management Components."
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
Start Node Manager once again as described in Section 19.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:
Log in to the OAM console at http://admin.mycompany.com/oamconsole as the oamadmin
user.
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
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.
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 11.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> <Location /fusion_apps> 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> <Location /fusion_apps> SetHandler weblogic-handler WebLogicCluster idmhost1.mycompany.com:14100,idmhost2.mycompany.com:14100,idmhost3.mycompany.com:14100 </Location>
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 13.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:
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.
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
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.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node to be used, and add the machine to the domain.
Update the machine's Node Manager's address to map the IP address of the node that is being used for scale out.
Use the Oracle WebLogic Server Administration Console to clone WLS_SOA1
into a new Managed Server. Name it WLS_SOA
n
, 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.
Assign the host name or IP address to use for the new Managed Server for the listen address of the Managed Server.
If you are planning to use server migration for this server (which Oracle recommends) this should be the VIP 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.
Create JMS servers for SOA, Oracle Identity Manager (if applicable), and UMS on the new Managed Server.
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.
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_SOA
n
).
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.
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_SOA
n
).
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.
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_SOA
n
).
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.
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_OIM
n
).
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 BPMJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1
and WLS_SOA2
).
Click the BPMJMSServer
XXXXXX
subdeployment. Add the new JMS Server for BPM called BPMJMSServer_
N
to this subdeployment. Click Save.
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 SOAJMSServer
XXXXXX
subdeployment. Add the new JMS Server for SOA called SOAJMSServer_
N
to this subdeployment. Click Save.
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 UMSJMSServer
XXXXXX
subdeployment. Add the new JMS Server for UMS called UMSJMSServer_
N
to this subdeployment. Click Save.
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 OIMJMSServer
XXXXXX
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.
Click Activate Configuration from the Change Center menu.
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
Configure Oracle Coherence, as described in Section 13.6.1, "Updating the Coherence Configuration for the SOA Managed Server."
Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:
Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at:
http://admin.mycompany.com/em
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.
Navigate to Identity and Access, and then oim.
Right-click oim and navigate to System MBean Browser.
Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.
Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.
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
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.
Disable host name verification for the new Managed Server. Before starting and verifying the WLS_SOA
n
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 SOAHOST
n
. 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:
Expand the Environment node in the Domain Structure window.
In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Click Servers. The Summary of Servers page appears.
Select WLS_SOAn
in the Names column of the table.
The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None
.
Click Save.
Click Activate Configuration from the Change Center menu.
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
Start and test the new Managed Server from the Oracle WebLogic Server Administration Console:
Shut down all the existing Managed Servers in the cluster.
Ensure that the newly created Managed Server, WLS_SOA
n
, is running.
Access the application on the newly created Managed Server (http://vip:port/soa-infra
). The application should be functional.
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:
Log in to the Administration Console.
In the left pane, expand Environment and select Servers.
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.
Click the Migration tab.
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.
Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
Click Save.
Restart the Administration Server, Managed Servers, and Node Manager.
Test server migration for this new server. Follow these steps from the node where you added the new server:
1. Abruptly stop the WLS_SOA
n
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_SOA
n
. 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.
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:
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.
Follow the steps in Chapter 5, "Configuring the Web Tier."
Copy all files created in ORACLE_INSTANCE
/config/OHS/
component
/moduleconf
from the existing web tier configuration to the new one.
If you have enabled Single Sign-on in the topology, you must update the WebTier configuration for Single Sign-on as described in Section 18.5, "Installing and Configuring WebGate."
Register the new Oracle HTTP Server instance as described in Section 6.10, "Registering Oracle HTTP Server with WebLogic Server."
Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.
Table 19-1 shows the static artifacts to back up in the 11g Oracle Identity Management enterprise deployment.
Table 19-1 Static Artifacts to Back Up in the Identity Management Enterprise Deployment
Type | Host | Location | Tier |
---|---|---|---|
Oracle Home (database) |
Oracle RAC database hosts:
|
User Defined |
Directory Tier |
|
|
Middleware home,
Identity Management Oracle home,
|
Directory Tier |
|
|
Middleware home,
Identity Management Oracle home,
|
Directory Tier |
|
|
Middleware Oracle home,
(Identity Management Oracle home DIP/ODSM,
(Admin server Oracle home,
|
Application Tier |
|
|
Middleware Oracle home,
Web Oracle Home,
Web Oracle Home,
|
Web Tier |
Install Related Files |
Each host |
OraInventory:
Windows registry: ( |
Not applicable. |
Table 19-2 shows the run-time artifacts to back up in the 11g Oracle Identity Management enterprise deployment:
Table 19-2 Run-Time Artifacts to Back Up in the Identity Management Enterprise Deployments
Type | Host | Location | Tier |
---|---|---|---|
Domain Home |
|
|
Application Tier |
Application Artifacts (ear and war files) |
|
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 |
OID Instance Home |
|
OID Instance Home on ORACLE_BASE/admin/oid_inst1
OID Instance Home on ORACLE_BASE/admin/oid_inst2 |
Directory Tier |
OVD Instance Home |
|
OVD Instance Home on
OVD Instance Home on
|
Directory Tier |
Oracle RAC Databases |
|
User defined |
Directory Tier |
OAM |
|
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.
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:
For information on patching an Oracle Fusion Middleware source file, see the Oracle Fusion Middleware Administrator's Guide.
To patch Oracle Identity Management components with minimal down time, it is recommended that you follow these guidelines:
Route the LDAP traffic from OIDHOST1 and OVDHOST1 to OIDHOST2 and OVDHOST2.
Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST1 or OVDHOST1).
Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.
Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.
Test the patch.
Route the traffic to OIDHOST1 or OVDHOST1 again.
Verify the applications are working properly.
Route the LDAP traffic on OIDHOST2 and OVDHOST2 to OIDHOST1 and OVDHOST1.
Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST2 or OVDHOST2).
Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.
Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.
Test the patch.
Route the traffic to both hosts on which the patch has been applied (OIDHOST1 and OIDHOST2, or OVDHOST1 and OVDHOST2).
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 19.6.3, "Troubleshooting Oracle Directory Integration Platform"
Section 19.6.4, "Troubleshooting Oracle Directory Services Manager"
Section 19.6.7, "Troubleshooting Oracle Identity Federation"
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.
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.
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.
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:
Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.
Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.
Make a connection to an Oracle Internet Directory server.
Work with the Oracle Internet Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.
Shut down one Managed Server at a time using the WebLogic Server Administration Console.
Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Internet 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:
In your web browser, exit the current Oracle Directory Services Manager page.
Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.
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:
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.
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>
Restart the Oracle HTTP Server, as described in Section 19.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:
Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.
Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.
Make a connection to an Oracle Virtual Directory server.
Work with the Oracle Virtual Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.
Shut down one Managed Server at a time using the WebLogic Server Administration Console.
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:
In your web browser, exit the current Oracle Directory Services Manager page.
Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.
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.
This section describes some common problems that can arise with Oracle Access Manager and the actions you can take to resolve the problem.
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:
Go to System Configuration -> Common Settings -> Session
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.
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.
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:
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
.
Verify that WebGate is installed.
Verify that OBAccessClient.xml
was copied from DOMAIN_HOME
/output
to the WebGate Lib directory and that OHS was restarted.
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.
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.
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:
Delete the file /tmp/oaconfigplan.xml
.
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.
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 19.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:
Oracle Identity Federation is up but the EM agent is down.
Check the EM agent status by running:
ORACLE_INSTANCE/EMAGENT/EMAGENT/bin/emctl status agent
Start the EM agent, if it is down, by running:
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=EMAGENT
Log in to Fusion Middleware Control again.
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.
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.
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'
Log in to Fusion Middleware Control again.
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.
If the issue still exists, restart the EM agent.
Stop the EM agent by running:
INST_HOME/bin/opmnctl stopproc ias-component=EMAGENT
Start the EM agent by running:
INST_HOME/bin/opmnctl startproc ias-component=EMAGENT
Log in to Oracle Enterprise Manager Fusion Middleware Control again.
This section describes some other recommendations for the Oracle Identity Management enterprise deployment.
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.