This section contains the following topics:
After having successfully completed the conditional common post-installation tasks review and perform the following conditional common high availability tasks.
Some components in the Oracle Fusion Applications environment are dependent on one another. Therefore, it is important to start and stop components in the proper order. In the course of normal IT operations, common operations include shutting down computers and starting them back up. Therefore, it is crucial to start and stop Oracle Fusion Applications in a sequential manner. See Start and Stop an Oracle Fusion Applications Environment in the Oracle Fusion Applications Administrator's Guide.
The Identity Management topology is highly scalable. It can be scaled up and/or scaled out. This section explains how to do so.
To scale up the topology, add a new component instance to a node already running one or more component instances.
To scale out the topology, add new component instances to new nodes.
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 how to create a new managed server or directory instance.
Scale out a topology by adding new components to new nodes. The components in all three tiers of the Oracle Identity Management topology described in this section can be scaled out by adding a new component instance to a new node.
The process of scaling out the Oracle Identity Management database involves installing new database instances, which is not described in this guide. The following steps assume that Real Application Clusters (RAC) is used and that the additional database instances have already been configured. For more information about RAC, see Install Oracle Database.
Oracle Identity Management components interface with the database using WebLogic Datasources. In systems that use Oracle RAC, Data sources are configured as Multi Datasources in Identity Management. A multi datasource is made up of several child datasources, one for each RAC database Instance. The Identity Management Applications interface with the RAC database by accessing the parent multi data source. If a new database instance is added, then create new datasources for each of the existing multi datasources and then add the new data source into the pre-existing multi data source. Because different applications use different datasources, add the database to each data source that is using the database.
To do this perform the following steps:
The Directory tier consists of two LDAP hosts, each running Oracle Internet Directory and Oracle Virtual Directory.
This section contains the following topics:
The Directory Tier has two Oracle Internet Directory nodes, LDAP_PROVISIONED_HOST and LDAP_SCALED_OUT_HOST, each running an Oracle Internet Directory instance.
When scaling up, use the existing Oracle Identity Management binaries on either node for creating the new Oracle Internet Directory instance.
To add a new Oracle Internet Directory instance to either Oracle Internet Directory node, or to scale out Oracle Internet Directory instances, perform the steps in the following subsections:
Assemble the following information before scaling Oracle Internet Directory.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host Name |
|
||
|
OID Port |
|
This value is available in the Oracle Fusion Applications Installation Workbook, Network - Ports tab, Identity Management Port Numbers table, OID row. |
|
|
OID SSL Port |
|
This value is available in the Oracle Fusion Applications Installation Workbook, Network - Ports tab, Identity Management Port Numbers table, OID SSL row. |
|
|
Oracle Instance Location |
|
||
|
Oracle Instance/component Name |
|
|
|
|
OID Admin Password |
|||
|
Password to protect the SSL wallet/keystore |
|
||
|
Password for the CA wallet |
|
||
|
WebLogic Admin Host |
ADMINVHN.mycompany.com |
||
|
WebLogic Admin Port |
|
7001 |
|
|
WebLogic Admin User |
weblogic_idm |
||
|
WebLogic Admin Password |
The schema database must be running before performing this task. Follow these steps to install Oracle Internet Directory on the host:
Before starting the configuration, determine the ports to be used for the new directory instance. For Scale out, these can be the same as the other existing instances. For Scale Up these ports must be unique to the new server instance.
Ensure that selected ports are not in use by any service on the computer by issuing these commands for the operating system that is being used.
For example, on Linux, enter:
netstat -an | grep "3060" netstat -an | grep "3131"
If a port is not in use, no output is returned from the command. If the ports are in use (that is, if the command returns output identifying either port), they must be free.
Remove the entries for the ports in the /etc/services file and restart the services, as described in Start and Stop Components, or restart the computer.
Create a file containing the ports used by Oracle Internet Directory. On Disk1 of the installation media, locate the file stage/Response/staticports.ini. Copy it to a file called oid_ports.ini. Delete all entries in oid_ports.ini except for Non-SSL Port for Oracle Internet Directory and SSL Port for Oracle Internet Directory. Change the values of those ports to the ports to be used, for example: 3060 and 3131.
If the port names in the file are slightly different from those listed in this step, use the names in the file.
Start the Oracle Identity Management 11g Configuration Wizard by running OID_ORACLE_HOME/bin/config.sh.
On the Welcome screen, click Next.
On the Select Domain screen, select Configure without a Domain.
Click Next.
On the Specify Installation Location screen, specify the following values:
Oracle Instance Location: OID_ORACLE_INSTANCE
Oracle Instance Name: oidn, where n is a sequential number for the instance. For example, if there are two instances already configured, n is3, so enter oid3.
Click Next.
On the Specify Email for Security Updates screen, specify these values:
Email Address: Provide the email address for the My Oracle Support account.
Oracle Support Password: Provide the password for the My Oracle Support account.
Check the check box next to the I wish to receive security updates via My Oracle Support field.
Click Next.
On the Configure Components screen, select Oracle Internet Directory, deselect all the other components, and click Next.
On the Configure Ports screen, use the oid_ports.ini file created in Step 2 to specify the ports to be used. This enables to bypass automatic port configuration.
Select Specify Ports using a Configuration File.
In the file name field specify oid_ports.ini.
Click Save, then click Next.
On the Specify Schema Database screen, select Use Existing Schema and specify the following values:
Connect String: This value is available in the Oracle Fusion Applications Installation Workbook, Database tab, IDM Database table, IDM DB Instances row.
The Oracle RAC database connect string information must be provided in the format:
host1:port1:instance1 ^host2:port2:instance2@servicename
During this installation, it is not required that all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.
Complete and accurate information must be provided. Specifically, the correct host, port, and instance name for each Oracle RAC instance must be provided, and the service name provided must be configured for all the specified Oracle RAC instances.
Any incorrect information entered in the Oracle RAC database connect string must be corrected manually after the installation.
User Name: ODS
Password: password. This is the password of the ODS schema in the database as specified when Oracle Identity Management RCU was run.
Click Next.
The ODS Schema in use message appears. The ODS schema chosen is already being used by the existing Oracle Internet Directory instance. Therefore, the new Oracle Internet Directory instance being configured would reuse the same schema.
Choose Yes to continue.
A popup window with this message appears:
"Please ensure that the system time on this Identity Management Node is in sync with the time on other Identity management Nodes that are part of the Oracle Application Server Cluster (Identity Management) configuration. Failure to ensure this may result in unwanted instance failovers, inconsistent operational attributes in directory entries and potential inconsistent behavior of password state policies."
Ensure that the system time is synchronized among all the IDM_PROVISIONED_HOSTs and IDM_SCALED_OUT_HOSTs. See Synchronize Oracle Internet Directory Nodes.
Click OK to continue.
On the Specify OID Admin Password screen, specify the Oracle Internet Directory administration password.
If a message saying that OID is not running is displayed, verify that the orcladmin account has not become locked and try again. Do not continue until this message is no longer displayed.
Click Next.
On the Installation Summary screen, review the selections to ensure that they are correct. If they are not, click Back to modify selections on previous screens. When they are correct, click Configure.
On the Configuration screen, multiple configuration assistants are launched in succession. This process can be lengthy. Wait for the configuration process to finish.
On the Installation Complete screen, click Finish to confirm the choice to exit.
To validate the installation of the Oracle Internet Directory instance on the new LDAP host, issue these commands:
ldapbind -h LDAPHOST.mycompany.com -p 3060 -D "cn=orcladmin" -q ldapbind -h LDAPHOST.mycompany.com -p 3131-D "cn=orcladmin" -q -U 1
where LDAPHOST is the host where the new instance is running.
Ensure that the following environment variables are set before using ldapbind:
ORACLE_HOME
ORACLE_INSTANCE
PATH - The following directory locations should be in the PATH:
IDM_ORACLE_HOME/bin
IDM_ORACLE_HOME/ldap/bin
IDM_ORACLE_HOME/ldap/admin
All the Oracle Fusion Middleware components deployed in this enterprise deployment are managed by using Oracle Enterprise Manager Fusion Middleware Control. To manage the Oracle Internet Directory component with this tool, register the component and the Oracle Fusion Middleware instance that contains it with an Oracle WebLogic Server domain. A component can be registered either at install time or post-install. A previously un-registered component can be registered with a WebLogic domain by using the opmnctl registerinstance command.
To register the Oracle Internet Directory instances installed on the host where the new server instance is running, follow these steps for each instance:
If SSL Authentication Mode is used, the following must be performed to ensure that the Oracle Internet Directory instances are capable of accepting requests using this mode. Each Oracle Internet Directory instance must be configured independently.
To enable Oracle Internet Directory to communicate using SSL Server Authentication Mode, perform the following steps on the host where the new server is running:
When this operation is performed, only the Oracle Internet Directory instance used should be running.
Sample output:
Server SSL Automation Script: Release 11.1.1.4.0 - Production Copyright (c) 2010 Oracle. All rights reserved. Downloading the CA wallet from the central LDAP location... >>>Enter the LDAP Hostname [SLC00DRA.mycompany.com]: POLICYSTORE.mycompany.com >>>Enter the LDAP port [3060]: 3060 >>>Enter an admin user DN [cn=orcladmin] >>>Enter password for cn=orcladmin: >>>Enter the sslDomain for the CA [idm]: IDMDomain >>>Enter a password to protect your SSL wallet/keystore: >>>Enter confirmed password for your SSL wallet/keystore: >>>Enter password for the CA wallet: >>>Searching the LDAP for the CA usercertificate ... Importing the CA certifcate into trust stores... >>>Searching the LDAP for the CA userpkcs12 ... Invoking OID SSL Server Configuration Script... Enter attribute values for your certificate DN >>>Country Name 2 letter code [US]: >>>State or Province Name [California]: >>>Locality Name(eg, city) []:Redwood >>>Organization Name (eg, company) [mycompany]: >>>Organizational Unit Name (eg, section) [oid-20110524015634]: >>>Common Name (eg, hostName.domainName.com) [SLC00XXX.mycompany.com]: The subject DN is cn=SLC00DRA.mycompany.com,ou=oid-20110524015634,l=Redwood,st=California,c=US Creating an Oracle SSL Wallet for oid instance... /u01/oracle/products/access/idm/../oracle_common/bin >>>Enter your OID component name: [oid1] >>>Enter the weblogic admin server host [SLC00XXX.mycompany.com] ADMINVHN >>>Enter the weblogic admin port: [7001] >>>Enter the weblogic admin user: [weblogic] >>>Enter weblogic password: >>>Enter your AS instance name:[asinst_1] oid1 >>>Enter an SSL wallet name for OID component [oid_wallet1] Checking the existence of oid_wallet1 in the OID server... Configuring the newly generated Oracle Wallet with your OID component... Do you want to restart your OID component?[y/n]y Do you want to test your SSL set up?[y/n]y >>>Please enter your OID ssl port:[3131] 3131 Please enter the OID hostname:[SLC00DRA.mycompany.com] LDAP_SCALED_OUT_HOST.mycompany.com >>>Invoking IDM_ORACLE_HOM/bin/ldapbind -h LDAP_SCALED_OUT_HOST.mycompany.com -p 3131-U 2 -D cn=orcladmin ... Bind successful Your oid1 SSL server has been set up successfully
Confirm that the script has been successful. Repeat all the steps in Configuring Oracle Internet Directory to Accept Server Authentication Mode SSL Connections. for each Oracle Internet Directory instance.
The Directory Tier has two nodes, LDAP_PROVISIONED_HOST and LDAP_SCALED_OUT_HOST, each running an Oracle Virtual Directory instance.
When scaling up, use existing Oracle Identity Management binaries on either node for creating the new Oracle Virtual Directory instance.
To add a new Oracle Virtual Directory instance to either Oracle Virtual Directory node, or to scale out Oracle Virtual Directory instances, perform the steps in the following subsections:
Assemble the following information before scaling Oracle Virtual Directory.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host Name |
NA |
|
NA |
|
OVD Listen Port |
|
NA |
This value is available in the Oracle Fusion Applications Installation Workbook, Network - Ports tab, Identity Management Port Numbers table, OVD. |
|
OVD SSL Port |
|
NA |
This value is available in the Oracle Fusion Applications Installation Workbook, Network - Ports tab, Identity Management Port Numbers table, OVD SSL. |
|
Oracle Virtual Directory Proxy Port |
|
NA |
This value is available in the Oracle Fusion Applications Installation Workbook Network - Ports tab, Identity Management Port Numbers table, OVD Admin. |
|
Oracle Instance Location |
|
|
NA |
|
OVD Existing Instance/Component Name |
|
|
NA |
|
Newly Created Instance/Component Name |
|
|
NA |
|
OVD Administrator Password |
NA |
NA |
NA |
|
WebLogic Admin Host |
|
|
NA |
|
WebLogic Admin Port |
|
7001 |
NA |
|
WebLogic Admin User |
|
weblogic_idm |
NA |
|
WebLogicAdmin Password |
NA |
NA |
NA |
|
Back end Identity Store host |
|
|
NA |
|
Back end Identity Store port |
|
NA |
This value is available in the Oracle Fusion Applications Installation Workbook Network - Ports tab ->Identity Management Port Numbers -> OID. |
|
Identity Store LDAP admin password |
NA |
NA |
NA |
|
Password to protect your SSL wallet/keystore |
|
NA |
NA |
|
Password for the CA wallet (created when you ran the Oracle Identity Management Provisioning Wizard) |
|
NA |
NA |
Follow these steps to configure the new Oracle Virtual Directory instance:
Ensure that ports used (OVD_PORT and OVD_SSL_PORT) are not in use by any service on the computer by issuing these commands for the operating system that is used.
On Linux:
netstat -an | grep "6501" netstat -an | grep "7501"
If a port is not in use, no output is returned from the command. If the ports are in use (that is, if the command returns output identifying either port), the port must be free.
On Linux:
Remove the entries for ports used by Oracle Virtual Directory in the /etc/services file and restart the services, as described in Start and Stop Components, or restart the computer.
Create a file containing the ports used by Oracle Virtual Directory. On Disk1 of the installation media, locate the file stage/Response/staticports.ini. Copy it to a file called ovd_ports.ini. Delete all entries in ovd_ports.ini except for Non-SSL Port for Oracle Virtual Directory and SSL Port for Oracle Virtual Directory. Change the values of those ports to the ports to be used, example: 3060 and 3131.
If the port names in the file are slightly different from those listed in this step, use the names in the file.
Start the Oracle Identity Management 11g Configuration Wizard by running OID_ORACLE_HOME/bin/config.sh.
On the Welcome screen, click Next.
On the Select Domain screen, select Configure without a Domain.
Click Next.
On the Specify Installation Location screen, specify the following values:
Oracle Instance Location: OVD_ORACLE_INSTANCE
Oracle Instance Name: ovdn, where n is a sequential number for the instance. For example, if there are two instances already configured, n will be 3, so enter ovd3.
Click Next.
On the Specify Email for Security Updates screen, specify these values:
Email Address: Provide the email address for the My Oracle Support account.
Oracle Support Password: Provide the password for the My Oracle Support account.
Check the checkbox next to the I wish to receive security updates via My Oracle Support field.
Click Next.
On the Configure Components screen, select Oracle Virtual Directory, deselect all the other components, and click Next.
On the Configure Ports screen, use the ovd_ports.ini file created in Step 2 to specify the ports to be used. This enables to bypass automatic port configuration.
Select Specify Ports using a Configuration File.
In the file name field specify ovd_ports.ini.
Click Save, then click Next.
On the Specify Virtual Directory screen: In the Client Listeners section, enter:
LDAP v3 Name Space: REALM_DN, for example: dc=mycompany,dc=com
In the OVD Administrator section, enter:
Administrator User Name: cn=orcladmin
Password: administrator_password
Confirm Password: administrator_password
Select Configure the Administrative Server in secure mode.
Click Next.
On the Installation Summary screen, review the selections to ensure that they are correct. If they are not, click Back to modify selections on previous screens. When they are correct, click Configure.
On the Configuration screen, multiple configuration assistants are launched in succession. This process can be lengthy. Wait for the configuration process to finish.
Click Next.
On the Installation Complete screen, click Finish to confirm the choice to exit.
To validate the installation of the Oracle Virtual Directory instance on the host, issue these commands:
ldapbind -h LDAPHOST.mycompany.com -p 6501 -D "cn=orcladmin" -q ldapbind -h LDAPHOST.mycompany.com -p 7501 -D "cn=orcladmin" -q -U 1
where LDAPHOST is the host where the new instance is running.
Ensure that the following environment variables are set before using ldapbind:
Set ORACLE_HOME to OID_ORACLE_HOME.
Set ORACLE_INSTANCE to OVD_ORACLE_INSTANCE.
PATH - The following directory locations should be in thePATH:
OID_ORACLE_HOME/bin
OID_ORACLE_HOME/ldap/bin
OID_ORACLE_HOME/ldap/admin
All the Oracle Fusion Middleware components deployed in this enterprise deployment are managed by using Oracle Enterprise Manager Fusion Middleware Control. To manage the Oracle Virtual Directory component with this tool, register the component and the Oracle Fusion Middleware instance that contains it with an Oracle WebLogic Server domain. A component can be registered either at install time or post-install. A previously un-registered component can be registered with a WebLogic domain by using the opmnctl registerinstance command.
To register the Oracle Virtual Directory instances, follow these steps on the host where the new instance is running:
Set the ORACLE_HOME to OID_ORACLE_HOME.
Set ORACLE_INSTANCE to OVD_ORACLE_INSTANCE1, where OVD_ORACLE_INSTANCE1 is the location of the newly-created instance.
Execute the opmnctl registerinstance command:
OVD_ORACLE_INSTANCE/bin/opmnctl registerinstance -adminHost WLSHostName -adminPort WLSPort -adminUsername adminUserName
For example:
OVD_ORACLE_INSTANCE/bin/opmnctl registerinstance \
-adminHost ADMINVHN.mycompany.com -adminPort 7001 -adminUsername weblogic
The command requires login to WebLogic Administration Server.
Username: weblogic
Password: password
For additional details on registering Oracle Virtual Directory components with a WebLogic Server domain, see Registering an Oracle Instance Using OPMNCTL in the Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.
In order to manage Oracle Virtual Directory by using Oracle Enterprise Manager Fusion Middleware Control, the Enterprise Manager Repository URL must be updated to point to the virtual IP address associated with the WebLogic Administration Server. Do this using the emctl utility with the switchOMS flag. This will enable the local emagent to communicate with the WebLogic Administration Server using the virtual IP address. The emctl utility is located under the OVD_ORACLE_INSTANCE/EMAGENT/EMAGENT/bin directory.
Syntax:
./emctl switchOMS ReposURL
For Example:
./emctl switchOMS http://ADMINVHN:7001/em/upload
Output:
./emctl switchOMS http://ADMINVHN.mycompany.com:7001/em/upload Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0. Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved. SwitchOMS succeeded.
Force the agent to reload its configuration by issuing the command:
./emctl reload
Check that the agent is using the correct Upload URL using the command:
./emctl status agent
Validate if the agents on the host where the new instance is running are configured properly to monitor their respective targets. Follow these steps to complete this task:
Use a web browser to access Oracle Enterprise Manager Fusion Middleware Control at http://ADMINVHN.mycompany.com:7001/em. Log in as the weblogic_idm user.
From the Domain Home Page navigate to the Agent-Monitored Targets page using the menu under Farm, thenAgent-Monitored Targets
Update the WebLogic monitoring user name and the WebLogic monitoring password.
Enter weblogic_idm as the WebLogic monitoring user name and the password for the weblogic user as the WebLogic monitoring password.
Click OK to save changes.
Before configuring Oracle Virtual Directory for SSL, set the ORACLE_HOME, ORACLE_INSTANCE and JAVA_HOME variables. For example, on the new LDAPHOST, set ORACLE_HOME to OID_ORACLE_HOME, set ORACLE_INSTANCE to OVD_ORACLE_INSTANCE, set JAVA_HOME to JAVA_HOME, and add JAVA_HOME to the PATH variable.
Start the SSL Configuration Tool by issuing the command SSLServerConfig command which is located in the directory ORACLE_COMMON_HOME/bin directory.
For example:
ORACLE_COMMON_HOME/bin/SSLServerConfig.sh -component ovd
When prompted, enter the following information:
LDAP Hostname: Central LDAP host, for example: POLICYSTORE.mycompany.com
It is recommended to use the Policy Store directory, not the Identity Store.
LDAP port: LDAP port, for example: 3060 (OID_LDAP_PORT)
Admin user DN: cn=orcladmin
Password: administrator_password
sslDomain for the CA: IDMDomain
Password to protect the SSL wallet/keystore: password_for_local_keystore
Enter confirmed password for the SSL wallet/keystore: password_for_local_keystore
Password for the CA wallet: certificate_password. This is the primary password crated when provisioning. Fixed was run as in OID Section
Country Name 2 letter code: Two letter country code, such as US
State or Province Name: State or province, for example: California
Locality Name: Enter the name of the city, for example: RedwoodCity
Organization Name: Company name, for example: mycompany
Organizational Unit Name: Leave at the default
Common Name: Name of this host, for example: LDAP_SCALED_OUT_HOST.mycompany.com
OVD Instance Name: for example, ovd1. To determine the OVD component name, execute the command:
OVD_ORACLE_INSTANCE/bin/opmnctl status
Oracle instance name: Name of the newly created Oracle instance, for example: ovd3Fixed as in OID Section
WebLogic admin host: Host running the WebLogic Administration Server, for example:. ADMINVHN.mycompany.com
WebLogic admin port: WebLogic Administration Server port, for example: 7001 (WLS_ADMIN_PORT)
WebLogic admin user: Name of the WebLogic administration user, for example: weblogic
WebLogic password: password.
SSL wallet name for OVD component [ovdks1.jks]: Accept the default
When asked to restart the Oracle Virtual Directory component, enter Yes.
When asked to test the OVD SSL connection, enter Yes. Ensure that the test is a success.
Before managing Oracle Virtual Directory, create connections from ODSM to each of the Oracle Virtual Directory instances. To do this, proceed as follows:
Access ODSM through the load balancer at: http://ADMIN.mycompany.com/odsm
Follow these steps to create connections to Oracle Virtual Directory:
To create connections to Oracle Virtual Directory, follow these steps. Create connections to each Oracle Virtual Directory node separately. Using the Oracle Virtual Directory load balancer virtual host from ODSM is not supported:
Create a direct connection to Oracle Virtual Directory on the new host providing the following information in ODSM:
Host: LDAPHOST.mycompany.com
Port: 8899 (The Oracle Virtual Directory proxy port, OVD_ADMIN_PORT)
Enable the SSL option.
User: cn=orcladmin
Password: password_to_connect_to_OVD
Create a direct connection to Oracle Virtual Directory on the host where the new instance is running, providing the following information in ODSM:
Host: LDAPHOST.mycompany.com
Port: 8899 (The Oracle Virtual Directory proxy port)
Enable the SSL option.
User: cn=orcladmin
Password: password_to_connect_to_OVD
Oracle Virtual Directory communicates with other directories through adapters.
The procedure is slightly different, depending on the directory connected to. The following sections show how to create and validate adapters for supported directories:
Creating Oracle Virtual Directory Adapters for Oracle Internet Directory and Active Directory
idmConfigTool can be used to create the Oracle Virtual Directory User and Changelog adapters for Oracle Internet Directory and Active Directory. Oracle Identity Manager requires adapters. It is highly recommended, though not mandatory, to use Oracle Virtual Directory to connect to Oracle Internet Directory.
To do this, perform the following tasks on IDM_PROVISIONED_HOST:
Set the environment variable ORACLE_HOME to IAM_ORACLE_HOME.
Create a properties file for the adapter that is configured called ovd1.props. The contents of this file depends on whether the Oracle Internet Directory adapter or the Active Directory Adapter are being configured.
Oracle Internet Directory adapter properties file:
ovd.host:LDAPHOST.mycompany.com
ovd.port:8899
ovd.binddn:cn=orcladmin
ovd.password:ovdpassword
ovd.oamenabled:true
ovd.ssl:true
ldap1.type:OID
ldap1.host:OIDIDSTORE.mycompany.com
ldap1.port:3060
ldap1.binddn:cn=oimLDAP,cn=systemids,dc=mycompany,dc=com
ldap1.password:oidpassword
ldap1.ssl:false
ldap1.base:dc=mycompany,dc=com
ldap1.ovd.base:dc=mycompany,dc=com
usecase.type: single
Active Directory adapter properties file:
ovd.host:LDAPHOST.mycompany.com
ovd.port:8899
ovd.binddn:cn=orcladmin
ovd.password:ovdpassword
ovd.oamenabled:true
ovd.ssl:true
ldap1.type:AD
ldap1.host:ADIDSTORE.mycompany.com
ldap1.port:636
ldap1.binddn:cn=adminuser
ldap1.password:adpassword
ldap1.ssl:true
ldap1.base:dc=mycompany,dc=com
ldap1.ovd.base:dc=mycompany,dc=com
usecase.type: single
The following list describes the parameters used in the properties file.
ovd.host is the host name of a server running Oracle Virtual Directory.
ovd.port is the https port used to access Oracle Virtual Directory (OVD_ADMIN_PORT).
ovd.binddn is the user DN used to connect to Oracle Virtual Directory.
ovd.password is the password for the DN used to connect to Oracle Virtual Directory.
ovd.oamenabled is always true in Oracle Fusion Applications deployments.
ovd.ssl is set to true, as an https port is being run.
ldap1.type is set to OID for the Oracle Internet Directory back end directory or set to AD for the Active Directory back end directory.
ldap1.host is the host on which back end directory is located. Use the load balancer name.
ldap1.port is the port used to communicate with the back end directory (OID_LDAP_PORT or OID_LDAP_SSL_PORT.
ldap1.binddn is the bind DN of the oimLDAP user.
ldap1.password is the password of the oimLDAP user
ldap1.ssl is set to true if the back end's SSL connection is used, and otherwise set to false. This should always be set to true when an adapter is being created for AD.
ldap1.base is the base location in the directory tree.
ldap1.ovd.base is the mapped location in Oracle Virtual Directory.
usecase.type is set to Single when using a single directory type.
Configure the adapter by using the idmConfigTool command, which is located at:
IAM_ORACLE_HOME/idmtools/bin
When the idmConfigTool is run, it creates or appends to the file idmDomainConfig.param. This file is generated in the same directory that the idmConfigTool is run from. To ensure that each time the tool is run, the same file is appended to, always run the idmConfigTool from the directory:
IAM_ORACLE_HOME/idmtools/bin
The syntax of the command is:
idmConfigTool.sh -configOVD input_file=configfile [log_file=logfile]
For example:
idmConfigTool.sh -configOVD input_file=ovd1.props
The command requires no input. The output looks like this:
The tool has completed its operation. Details have been logged to logfile
Run this command for the newly created Oracle Virtual Directory instance in the topology, with the appropriate value for ovd.host in the property file.
Validating the Oracle Virtual Directory Adapters
Perform the following tasks by using ODSM:
The Application Tier can be scaled out to multiple nodes. The following sections describe the details for scaling the Application Tier.
When scaling out a component of the Application Tier, perform these steps first:
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:
cd IAM_ORACLE_HOME/oui/bin ./attachHome.sh -jreLoc JAVA_HOME
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the IAM_MW_HOME/bea/beahomelist file and add IAM_MW_HOME/oui/bin to it.
Log in to the WebLogic Administration Console at: http://ADMIN.mycompany.com/console
Create a new machine for the new node to be used, and add the machine to the domain, as follows.
Select Environment, then select Machines from the Navigation menu.
Click Lock and Edit.
Click New on the Machine Summary screen.
Enter the following information:
Name: Name of the machine. This is usually the host name.
Machine OS: Select UNIX.
Click Next.
On the Node Manager Properties page, enter the following information:
Type: SSL.
Listen Address: Use the host name.
Click Finish.
Click Activate Changes.
Node Manager is used to start and stop WebLogic managed servers on the new host. In order to create a new node manager for the new host perform the following steps:
To scale up ODSM, use the existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) for creating a new Managed Server for the Oracle Directory Services Manager component.
To scale out, use the existing installations in shared storage for creating the new Managed Servers. It is not necessary to install WebLogic Server or Identity Management binaries in a new location but it is necessary to run pack and unpack to move files to MSERVER on the new node. This is described in Complete the Oracle Identity Manager Configuration Steps.
To scale ODSM instances, follow these steps:
Assemble the following information for scaling ODSM.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host name |
|
||
|
ODSM Port |
|
This value is available in the Oracle Fusion Applications Installation Workbook Network - Ports tab, Identity Management Port Numbers table, IDMDomain ODSM row. |
|
|
Oracle Instance Location/Name |
|
|
|
|
Oracle Middleware Home Location |
|
|
|
|
Oracle Home Directory |
|
||
|
WebLogic Admin host |
|
||
|
WebLogic Admin Port |
|
7001 |
|
|
WebLogic User Name |
weblogic_idm |
||
|
WebLogic Password |
|
||
|
WebLogic Server Directory |
|
Ensure that the system, patch, kernel and other requirements are met. See Verifying Certification, System Requirements, and Interoperability in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for a specific platform and version.
To provisioning the Instance Home or the Managed Server domain directory on shared storage, ensure that the appropriate shared storage volumes are mounted on the new host as described in Mounting Middleware Home and Creating a New Machine when Scaling Out.
For scaling out, use the default port (ODSM_PORT). For scaling up, choose a unique port for this instance. Ensure that port number used is not in use by any service on the computer by issuing this command for the operating system used. If a port is not in use, no output is returned from the command.
On Linux:
netstat -an | grep "7005"
If the port is in use (if the command returns output identifying the port), free it.
On Linux:
Remove the entries for port 7005 (ODSM_PORT) in the /etc/services file if the port is in use by a service and restart the services, as described in Start and Stop Components, or restart the computer.
Start the Oracle Identity Management 11g Configuration Wizard by running the config.sh script located under the IDM_ORACLE_HOME/bin directory on the new host. For example: IDM_ORACLE_HOME/bin
On the Welcome screen, click Next.
On the Select Domain screen, select the Expand Cluster option and specify these values:
Hostname: ADMINVHN.mycompany.com
Port: 7001 (WLS_ADMIN_PORT)
UserName: weblogic_idm
User Password: password for the webLogic user
Click Next.
A dialog box with the following message appears:
The selected domain is not a valid Identity Management domain or the installer cannot determine if it is a valid domain. If you created the domain using the Identity Management installer, you can ignore this message and continue. If you did not create the domain using the Identity Management installer, refer to the Identity Management documentation for information on how to verify the domain is valid.
Click YES to continue.
This is a benign warning that can be safely ignored.
A dialog box with the following message appears:
The selected domain is not a valid Identity Management domain or the installer cannot determine if it is a valid domain. If you created the domain using the Identity Management installer, you can ignore this message and continue. If you did not create the domain using the Identity Management installer, refer to the Identity Management documentation for information on how to verify the domain is valid.
Click YES to continue.
This is a benign warning that can be safely ignored.
On the Email for Security Updates screen, specify these values:
Email Address: Provide the email address for the My Oracle Support account.
Oracle Support Password: Provide the password for the My Oracle Support account.
Select the checkbox next to the I wish to receive security updates via My Oracle Support field.
Click Next.
On the Configure Components screen, de-select all the products except ODSM and then click Next.
On the Configure Ports screen, use the odsm_ports.ini file created in Step 4 to specify the ports to be used. This enables to bypass automatic port configuration.
Select Specify Ports using a Configuration File.
In the file name field specify odsm_ports.ini.
Click Save, then click Next.
On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Configure.
On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy. Wait until it completes.
On the Installation Complete screen, click Finish to confirm the choice to exit.
Add the newly added Managed Server host name and port to the list WebLogicCluster parameter, as described in Add New WebLogic Managed Server to Oracle HTTP Server Configuration Files.
To scale up, use the existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) for creating a new Managed Server for the Oracle Access Manager component.
Use the existing binaries in shared storage for creating the new Managed Servers. It is not necessary to install WebLogic Server or Identity Management binaries in a new location but it is necessary to run pack and unpack to bootstrap the domain configuration in the new node.
If shared storage is used, allow the new host access to that shared storage area.
Scale Oracle Access Manager by performing the steps in the following subsections:
Assemble the following information before scaling Oracle Access Manager.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host Name |
|
NA |
NA |
|
Existing OAM server |
NA |
|
NA |
|
New OAM server name |
|
|
NA |
|
Server Listen Address |
NA |
NA |
NA |
|
Server Listen Port |
|
NA |
This value is available in the Oracle Fusion Applications Installation Workbook, Network - Ports tab, Identity Management Port Numbers table, IDMDomain OAM row. |
|
WebLogic Admin Host |
NA |
ADMINVHN.mycompany.com |
NA |
|
WebLogic Admin Port |
|
7001 |
NA |
|
WebLogic Admin User |
NA |
weblogic_idm |
NA |
|
WebLogic Admin Password |
NA |
NA |
NA |
The following steps are necessary only in case of scaling out.
IAM_MW_HOME/bea/beahomelist file and add IAM_MW_HOME to it.Log in to the Oracle WebLogic 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 to be extended, 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.
In case of scaling out, use the default port, 14100 (OAM_PORT). In case of scaling up, choose a unique port.
Click OK.
Click the newly created server WLS_OAM3
Set Machine to be the machine created in Mount Middleware Home and Create a New Machine when Scaling Out.
Click Save.
Disable host name verification for the new Managed Server. Before starting and verifying the WLS_OAM3 Managed Server, disable host name verification. Re-enable it after having configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in IDMHOSTn.
If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name verification settings 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 Changes from the Change Center menu.
Run pack and unpack as described in Running Pack/Unpack.
Register the new Managed Server with Oracle Access Manager. Configure the new Managed Server now as an Oracle Access Manager server. Do this from the Oracle OAM console. Proceed as follows:
Add the newly created Oracle Access Manager server to all WebGate Profiles that might be using it, such as Webgate_IDM, Webgate_IDM_11g, 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:
Repeat Steps 5 to 10 for Webgate_IDM_11g, IAMSuiteAgent, and all other WebGates that might be in use.
Start now the new Managed Server, as described in Start and Stop Components.
Add the newly added Managed Server host name and port to the list WebLogicCluster parameter, as described in Add New WebLogic Managed Server to Oracle HTTP Server Configuration Files.
Save the file and restart the Oracle HTTP server, as described in Start and Stop Components.
A node that runs a Managed Server configured with Oracle SOA Suite and Oracle Identity Manager components already exists. The node contains a Middleware home, a SOA Oracle home, an Oracle Identity Manager Oracle home, and a domain directory for existing Managed Servers. Use the existing installations in shared storage for creating a new WLS_SOA and WLS_OIM managed server. There is no need to install the Oracle Identity and Access Management or Oracle SOA Suite binaries in a new location
When scaling up, add WLS_SOA and WLS_OIM managed servers to existing nodes.
In either case, run pack and unpack.
When scaling out the topology, add new Managed Servers configured with OIM and SOA to new nodes. First check that the new node can access the existing home directories for WebLogic Server, OIM, and SOA. It is not necessary to run pack and unpack to bootstrap the domain configuration in the new node.
Follow the steps in the following subsections to scale the topology:
Assemble the following information before scaling Oracle Identity Manager.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host name |
|
|
|
|
SOA virtual server name |
SOAHOSTxVHN |
||
|
OIM virtual server name |
OIMHOSTxVHN |
||
|
SOA managed server to clone |
|
|
|
|
OIM managed server to clone |
|
|
|
|
SOA managed server name |
|
|
|
|
OIM managed server name |
|
|
|
|
Numeric extension for new JMS servers |
|
3 |
|
|
WebLogic Admin Host |
ADMINVHN.mycompany.com |
||
|
WebLogic Admin Port |
|
7001 |
|
|
WebLogic Admin User |
weblogic_idm |
||
|
WebLogic Admin Password |
Follow this procedure twice, once to clone WLS_SOA_PROVISIONED_HOST and once again to clone WLS_OIM_PROVISIONED_HOST.
Log in to the Administration Console at: http://ADMIN.mycompany.com/console
Clone the WLS_OIM_PROVISIONED_HOST or the WLS_SOA_PROVISIONED_HOST into a new Managed Server. The source Managed Server to clone should be one that already exists on the node where the new Managed Server is run.
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 to clone (for example, WLS_OIM_PROVISIONED_HOST or WLS_SOA_PROVISIONED_HOST).
Select Clone.
Name the new Managed Server WLS_OIM_PROVISONED_HOSTn or WLS_SOA_PROVISIONED_HOSTn, where n is a number to identify the new Managed Server.
The rest of the steps assume that a new server is being added to IDM_PROVISIONED_HOST, which is already running WLS_SOA_PROVISIONED_HOST and WLS_OIM_PROVISIONED_HOST.
For the listen address, assign the host name or IP address to use for this new Managed Server. 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.
Mount the Middleware home, as described in Mount Middleware Home and Create a New Machine when Scaling Out.
Create JMS Servers for SOA, Oracle Identity Manager, UMS, and BPM on the new Managed Server. Do this as follows:
Log in to the WebLogic Administration Server and navigate to Services, Messaging, JMS Servers.
Click New.
Enter a value for Name, such as BPMJMSServer_auto_3.
Click Create New Store.
Select FileStore from the list
Click Next.
Enter a value for Name, such as BPMJMSFileStore_auto_3
Enter the following values:
Target: The new server that is being created.
Directory: ASERVER_HOME/jms/BPMJMSFileStore_auto_3
Click OK.
When returned to the JMS Server screen, select the newly created file store from the list.
Click Next.
On the next screen set the Target to the server that is being created.
Click Finish.
Create the following JMS Queues depending on the managed server that is being created:
| Server | JMS Server Name | File Store Name | Directory | Target |
|---|---|---|---|---|
|
WLS_SOAn |
BPMJMSServer_auto_n |
BPMJMSFileStore_auto_n |
|
WLS_SOAn |
|
WLS_SOAn |
SOAJMSServer_auto_n |
SOAJMSFileStore_auto_n |
|
WLS_SOAn |
|
WLS_SOAn |
UMSJMSServer_auto_n |
UMSJMSFileStore_auto_n |
|
WLS_SOAn |
|
wls_OIMn |
OIMJMSServer_auto_n |
OIMJMSFileStore_auto_n |
|
wls_OIMn |
|
wls_SOAn |
PS6SOAJMSServer_auto_n |
PS6SOAJMSFileStore_auto_n |
|
wls_SOAn |
Add the newly created JMS Queues to the existing JMS Modules by performing the following steps:
This section is necessary only when scaling out.
Run pack and unpack as described in Run Pack/Unpack.
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication in SOA enterprise deployments. Use unicast if multicast communication is disabled for security reasons.
Unicast communication does not enable nodes to discover other cluster members in this way. Consequently, specify the nodes that belong to the cluster. It is not necessary to specify all of the nodes of a cluster, however. Specify only enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as SOA enterprise deployments where multiple IPs are available in the same system, configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.
An incorrect configuration of the Oracle Coherence framework used for deployment may prevent the SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the configuration described in this section.
Specify the nodes using the tangosol.coherence.wkan system property, where n is a number between 1 and 9. Specify up to 9 nodes. Start the numbering at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost system property. This local host name should be the virtual host name used by the SOA server as the listener addresses, for example: SOAHOST3VHN. Set this property by adding the -Dtangosol.coherence.localhost parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab. The new server need also to be added to the existing entries.
Tip:
To guarantee high availability during deployments of SOA composites, specify enough nodes so that at least one of them is running at any given time.
SOA_SCALED_OUT_HOST2VHN is the virtual host name that maps to the virtual IP where WLS_SOA_SCALED_OUT_HOST2 is listening.
Use the Administration Console to specify a host name used by Oracle Coherence.
To add the host name used by Oracle Coherence:
Ensure that these variables are passed to the managed server correctly. They should be reflected in the server's output log. Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.
The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. SOA guarantees that composites are deployed to members of a single WebLogic Server cluster even though the communication protocol for the two entities (the WebLogic Server cluster and the groups to which composites are deployed) are different.
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 WebLogic Administration Console, select the Server_name, Services tab. Under Default Store, in Directory, enter the path to the folder used to store the data files from the default persistent store.
Disable host name verification for the new Managed Server. Before starting and verifying the WLS_SOAn Managed Server, disable host name verification. It can be re-enabled after configuring server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in IDMHOSTn. If the source server from which the new one 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_OIMn Managed Servers. In Step d, select WLS_OIMn in the Names column of the table.
Click Activate Changes from the Change Center menu.
Restart the WebLogic Administration Server as described in Start and Stop 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_SOAn, 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 Configure Server Migration Targets to configure server migration.
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 addresses for the new Managed Servers are already present in the new node.
Test server migration for this new server. Follow these steps from the node where the new server was added:
Stop the WLS_SOAn Managed Server.
To do this, run:
kill -9 pid
on the process ID (PID) of the Managed Server. Identify the PID of the node using
ps -ef | grep WLS_SOAn
Watch the Node Manager Console. A message indicating that the floating IP address for WLS_SOA_PROVISIONED_HOST has been disabled is displayed.
Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
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.
Repeat Steps a-d for WLS_OIMn.
The Oracle Identity Federation instances can be scaled out by adding a new node with a Managed Server to the existing cluster.
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.
The Oracle Identity Federation instances can be scaled out by adding a new node with a Managed Server to the existing cluster.
Perform the steps in the following sections to scale Oracle Identity Federation.
Assemble the following information before scaling Oracle Identity Federation.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host name |
|
||
|
OIF Port |
|
7499 |
This value is available in the Oracle Fusion Applications Installation Workbook, Network - Ports tab, Identity Management Port Numbers table, IDMDomain OIF row. |
|
Instance name |
|
|
|
|
WebLogic Admin Host |
|
||
|
WebLogic Admin Port |
|
7001 |
|
|
WebLogic Admin User |
weblogic_idm |
||
|
WebLogic Admin Password |
Ensure that the system, patch, kernel and other requirements are met. See Verifying Certification, System Requirements, and Interoperability in the in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version being used.
Create a file containing the ports used by Oracle Internet Directory. On Disk1 of the installation media, locate the file stage/Response/staticports.ini. Copy it to a file called oif_ports.ini. Delete all entries in oif_ports.ini except for Oracle Identity Federation Server Port. Change the value of that port to the port used for this instance.
If scaling out, use the default port, 7499 (OIF_PORT). If scaling up, choose a unique port for this instance.
If the port name in the file is slightly different from those listed in this step, use the name in the file.
Ensure that the appropriate shared storage volumes are mounted on the new IDMHOST, as described in Mount Middleware Home and Create a New Machine when Scaling Out.
Ensure that the to be used is not in use by any service on the computer by issuing these commands for the operating system used, specifying the port to be used. If a port is not in use, no output is returned from the command.
UNIX:
netstat -an | grep "7499"
If the port is in use (if the command returns output identifying the port), it must be free.
UNIX:
Remove the entries for port 7499 in the /etc/services file.
Start the Oracle Identity Management 11g Configuration Wizard located under the IDM_ORACLE_HOME/bin directory as follows:
Issue this command:
./config.sh
On the Welcome screen, click Next.
On the Select Domain screen, select the Expand Cluster option and specify these values:
HostName: ADMINVHN.mycompany.com
Port: 7001
UserName: weblogic_idm
User Password: weblogic_user_password
Click Next.
A dialog box with the following message appears:
The selected domain is not a valid Identity Management domain or the installer cannot determine if it is a valid domain. If you created the domain using the Identity Management installer, you can ignore this message and continue. If you did not create the domain using the Identity Management installer, refer to the Identity Management documentation for information on how to verify the domain is valid.
This is a benign warning that can be ignored.
Click Yes to continue.
On the Specify Installation Location screen, specify the following values:
Oracle Middleware Home Location: OIF_MW_HOME (This value is prefilled and cannot be updated.)
Oracle Home Directory: idm (This value is prefilled and cannot be updated.)
WebLogic Server Directory: OIF_MW_HOME/wlserver_10.3
Oracle Instance Location: OIF_ORACLE_INSTANCE
Instance Name: oifn, where n is a sequential number, for example oif3.
Click Next.
On the Specify Security Updates screen (if shown), specify the values shown in this example:
Email Address: Provide the email address for the My Oracle Support account.
Oracle Support Password: Provide the password for the My Oracle Support account.
Select I wish to receive security updates via My Oracle Support.
Click Next.
On the Configure Components screen, de-select all the components except Oracle Identity Federation components. Select only Oracle Identity Federation from the Oracle Identity Federation components. Do not select Oracle HTTP Server.
Click Next.
On the Configure Ports screen, use the oif_ports.ini file created in Step 2 to specify the ports to be used. This enables to bypass automatic port configuration.
Select Specify Ports using a Configuration File.
In the file name field specify oif_ports.ini.
Click Save, then click Next.
On the Installation Summary screen, review the selections to ensure that they are correct. If they are not correct, click Back to modify selections on previous screens. Then click Configure.
On the Configuration Progress screen, view the progress of the configuration.
On the Installation Complete screen, click Finish to confirm the choice to exit.
This section is necessary only when scaling out.
From IDM_PROVISIONED_HOST, copy the applications directory under the ASERVER_HOME/config/fmwconfig/servers/wls_oif1 directory to the ASERVER_HOME/config/fmwconfig/servers/wls_oifn directory, where wls_oifn is the new server being added, for example:
cp -rp ASERVER_HOME/config/fmwconfig/servers/wls_oif1/applications user@IDM_PROVISIONED_HOST:ASERVER_HOME/config/fmwconfig/servers/wls_oif3
Then run pack and unpack as described in Run Pack/Unpack.
Perform the steps in Validate Oracle Identity Federation and Configure the Enterprise Manager Agents to completed the configuration of your new server.
Add the newly added Managed Server host name and port to the list WebLogicCluster parameter, as described in Add New WebLogic Managed Server to Oracle HTTP Server Configuration Files.
Whenever a domain is extended to include a new managed server, extract the domain configuration needs from the ASERVER_HOME location to the MSERVER_HOME location. This applies for scaling up or out. To do this perform the following steps.
Pack the domain on IDM_PROVISIONED_HOST to create a template pack using the command:
pack.sh -domain=ASERVER_HOME -template =/templates/managedServer.jar -template_name="template_name" -managed=true
The pack.sh script is located in ORACLE_COMMON_HOME/common/bin.
Unpack the domain on the new host for scale out, or on the existing host for scale up, using the command:
unpack.sh -domain=MSERVER_HOME -template=/templates/managedServer.jar -app_dir=MSERVER_HOME/applications
The unpack.sh script is located in ORACLE_COMMON_HOME/common/bin.
In case of scaling out, start Node Manager and update the property file.
Start and stop Node Manager as described in Start and Stop 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 Start and Stop Components.
Scaling an Application Tier component typically requires to create a new WebLogic managed server. If a new managed server is added to the topology, after adding the managed server, update the Oracle HTTP Server configuration files (on all nodes) and add the new server to the existing WebLogic cluster directives.
In the Web tier, there are several configuration files under WEB_ORACLE_INSTANCE/config/OHS/componentname/moduleconf, including admin_vh.conf, sso_vh.conf and idminternal_vh.conf. Each contain a number of entries in location blocks. If a block references two server instances and add a third one is added, update that block with the new server.
For example if a new Oracle Access Manager server is added, update sso_vh.conf to include the new managed server. Add the new server to the WebLogicCluster directive in the file, for example, change:
<Location /oam> SetHandler weblogic-handler WebLogicCluster IDM_PROVISIONED_HOST.mycompany.com:14100,IDM_SCALED_OUT_HOST.mycompany.com:14100 </Location> <Location /fusion_apps> SetHandler weblogic-handler WebLogicCluster IDM_PROVISIONED_HOST.mycompany.com:14100,IDM_SCALED_OUT_HOST.mycompany.com:14100 </Location>
to:
<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDM_PROVISIONED_HOST.mycompany.com:14100,IDM_SCALED_OUT_HOST.mycompany.com:14100,IDM_PROVISIONED_HOST.mycompany.com:14101
</Location>
<Location /fusion_apps>
SetHandler weblogic-handler
WebLogicCluster IDM_PROVISIONED_HOST.mycompany.com:14100,IDM_SCALED_OUT_HOST.mycompany.com:14100,IDM_SCALED_OUT_HOST.mycompany.com:14100
</Location>
Similarly, if y a new ODSM server is added, update ODSM entries in the file admin_vh.conf.
Once the configuration file has been updated, restart the Oracle HTTP server(s) as described in Start and Stop Components. Oracle recommends to do this sequentially to prevent loss of service.
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 the Oracle HTTP Server, perform the steps in the following subsections:
Assemble the following information before scaling the Web Tier.
| Description | Variable | Documented Value | Customer Value |
|---|---|---|---|
|
Host name |
WEBHOST1.mycompany.com |
NA |
|
|
OHS port |
|
7777 |
NA |
|
Instance Name |
|
|
NA |
|
Component Name |
|
|
NA |
|
WebLogic Admin Host |
NA |
ADMINVHN.mycompany.com |
NA |
|
WebLogic Admin Port |
|
7001 |
NA |
|
WebLogic Admin User |
weblogic_idm |
NA |
|
|
WebLogic Admin Password |
NA |
NA |
NA |
ORACLE_INSTANCE/config/OHS/component/moduleconf from the existing Web Tier configuration to the new one.Perform these steps to configure the Oracle Web Tier:
Create a file containing the ports used by Oracle HTTP Server. On Disk1 of the installation media, locate the file stage/Response/staticports.ini. Copy it to a file called ohs_ports.ini. Delete all entries in ohs_ports.ini except for OHS PORT and OPMN Local Port. Change the value of OPMN Local Port to 6700. In case of scaling out, use the default value, 7777, for OHS PORT. In case of scaling up, choose a unique value for that instance on the machine.
If the port names in the file are slightly different from OHS PORT and OPMN Local Port, use the names in the file.
Change the directory to the location of the Oracle Fusion Middleware Configuration Wizard:
cd WEB_ORACLE_HOME/bin
Start the Configuration Wizard:
./config.sh
Enter the following information into the configuration wizard:
On the Welcome screen, click Next.
On the Configure Component screen, select: Oracle HTTP Server.
Ensure that Associate Selected Components with WebLogic Domain is selected.
Ensure Oracle Web Cache is NOT selected.
Click Next.
On the Specify WebLogic Domain Screen, enter
Domain Host Name: ADMINVHN.mycompany.com
Domain Port No: 7001, where 7001 is WLS_ADMIN_PORT.
User Name: Weblogic Administrator User (For example: weblogic)
Password: Password for the Weblogic Administrator User account
Click Next.
On the Specify Component Details screen, specify the following values:
Enter the following values for WEBHOSTn, where n is the number of the new host, for example, 3:
Instance Home Location: WEB_ORACLE_INSTANCE (/u02/local/oracle/config/instances/ohsn, for example, /u02/local/oracle/config/instances/ohs1)
Instance Name: webn
OHS Component Name: webn
Click Next.
On the Configure Ports screen, use the ohs_ports.ini file created in Step 1to specify the ports to be used. This enables to bypass automatic port configuration.
Select Specify Ports using a Configuration File.
In the file name field specify ohs_ports.ini.
Click Save, then click Next.
On the Specify Security Updates screen, specify these values:
Email Address: The email address for the My Oracle Support account.
Oracle Support Password: The password for the My Oracle Support account.
Select: I wish to receive security updates via My Oracle Support.
Click Next.
On the Installation Summary screen, review the selections to ensure that they are correct. If they are not, click Back to modify selections on previous screens.
Click Configure.
On the Configuration screen, the wizard launches multiple configuration assistants. This process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm the choice to exit.
Provisioning creates a set of scripts to start and stop managed servers defined in the domain. When a new managed server is created in the domain needed to update the domain configuration so that these start and stop scripts can also start the newly created managed server.
Configuring server migration allows SOA-managed and OIM-managed servers to be migrated from one host to another, so that if a node hosting one of the servers fails, the service can continue on another node. This section describes how to configure server migration for an Identity Management enterprise deployment.
Perform the steps in the following sections to configure server migration for the following Managed Servers:
WLS_OIM_PROVISIONED_HOST
WLS_SOA_PROVISIONED_HOST
WLS_OIM_SCALED_OUT_HOST
WLS_SOA_SCALED_OUT_HOST
The WLS_OIM_PROVISIONED_HOST and WLS_SOA_PROVISIONED_HOST Managed Server are configured to restart on IDM_SCALED_OUT_HOST should a failure occur.
The WLS_OIM_SCALED_OUT_HOST and WLS_SOA_SCALED_OUT_HOST Managed Servers are configured to restart on IDM_PROVISIONED_HOST should a failure occur.
The WLS_OIM_PROVISIONED_HOST, WLS_SOA_PROVISIONED_HOST, WLS_OIM_SCALED_OUT_HOST and WLS_SOA_SCALED_OUT_HOST servers listen on specific floating IPs that are failed over by WebLogic Server Migration.
In this section, a user and tablespace are setup for the server migration leasing table:
If other servers in the same domain have already been configured with server migration, the same tablespace and data sources can be used. In that case, the data sources and multi data source for database leasing do not need to be re-created, but they must be retargeted to the clusters being configured with server migration.
Create a tablespace called leasing. For example, log on to SQL*Plus as the sysdba user and run the following command:
create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;
Create a user named leasing and assign to it the leasing tablespace:
create user leasing identified by password;
grant create table to leasing;
grant create session to leasing;
alter user leasing default tablespace leasing;
alter user leasing quota unlimited on LEASING;
Create the leasing table using the leasing.ddl script:
Copy the leasing.ddl file located in either of the following directories to the database node:
WL_HOME/server/db/oracle/817 WL_HOME/server/db/oracle/920
Connect to the database as the leasing user.
Run the leasing.ddl script in SQL*Plus:
@Copy_Location/leasing.ddl;
The second step is to create a multi data source for the leasing table from the Oracle WebLogic Server Administration Console. Console URLs are provided in About Oracle Identity Management Console URLs. Create a data source to each of the Oracle RAC database instances during the process of setting up the multi data source, both for these data sources and the global leasing multi data source. When a data source is created:
Ensure that this is a non-XA data source.
The names of the multi data sources are in the format of MultiDS-rac0, MultiDS-rac1, and so on.
Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.
Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for the database.
Target these data sources to the oim_cluster and the soa_cluster.
Ensure the data source's connection pool initial capacity is set to 0 (zero). To do this, select Services, JDBC, and then Datasources. In the Datasources screen, click the Datasource Name, then click the Connection Pool tab, and enter 0 (zero) in the Initial Capacity field.
Creating a Multi Data Source
Perform these steps to create a multi data source:
From Domain Structure window in the Oracle WebLogic Server Administration Console, expand the Services node. The Summary of JDBC Data Source page appears.
Click Data Sources. The Summary of JDBC Multi Data Source page is displayed.
Click Lock and Edit.
Click New Multi Data Source. The Create a New JDBC Multi Data Source page is displayed.
Enter leasing as the name.
Enter jdbc/leasing as the JNDI name.
Select Failover as algorithm (default).
Click Next.
Select oim_cluster and soa_cluster as the targets.
Click Next.
Select non-XA driver (the default).
Click Next.
Click Create New Data Source.
Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for Oracle RAC Service-Instance connections, Versions:10 and later.
When creating the multi data sources for the leasing table, enter names in the format of MultiDS-rac0, MultiDS-rac1, and so on.
Click Next.
On JDBC Data Source Properties, select Database Driver: Oracle's Driver (Thin) for RAC Service-Instance connections.
Deselect Supports Global Transactions.
Click Next.
Enter the service name, database name, host port, and password for the leasing schema.
Click Next.
Click Test Configuration and verify that the connection works.
Click Next.
Target the data source to oim_cluster and SOA cluster.
Click Finish.
Select the data source that was just created, for example leasing-rac0, and add it to the right screen.
Click Create a New Data Source for the second instance of the Oracle RAC database, target it to the oim_cluster and soa_cluster, repeating the steps for the second instance of the Oracle RAC database.
Add the second data source to the multi data source.
Click Activate Changes.
In this section, Node Manager's properties file are edited. This must be done for the Node Managers on the nodes where the servers are running, IDM_PROVISIONED_HOST and IDM_SCALED_OUT_HOST.
The nodemanager.properties file is located in the directory
SHARED_CONFIG_DIR/nodemanager/hostname
where hostname is the name of the host where the node manager is running.
Add the following properties to enable server migration to work properly:
Interface:
Interface=eth0
This property specifies the interface name for the floating IP (for example, eth0).
Do not specify the sub-interface, such as eth0:1 or eth0:2. This interface is to be used without :0 or :1. Node Manager's scripts traverse the different :X-enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0, eth1, eth2, eth3, ethn, depending on the number of interfaces configured.
NetMask:
NetMask=255.255.255.0
This property specifies the net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface.
UseMACBroadcast:
UseMACBroadcast=true
This property specifies whether to use a node's MAC address when sending ARP packets, that is, whether to use the -b flag in the arping command.
Verify in Node Manager's output (shell where Node Manager is started) that these properties are being used, or problems may arise during migration. A similar message should be displayed in Node Manager's output:
StateCheckInterval=500 eth0=*,NetMask=255.255.255.0 UseMACBroadcast=true
LogToStderr must be set to true (in node.propertes), in order to see the properties in the output.
The following steps are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely.
If not done already, set the StartScriptEnabled property in the nodemanager.properties file to true. This is required to enable Node Manager to start the managed servers.
Start Node Manager on IDM_PROVISIONED_HOST and IDM_SCALED_OUT_HOST by running the startNodeManagerWrapper.sh script, which is located in the SHARED_CONFIG_DIR/nodemanager/hostname directory.
When running Node Manager from a shared storage installation, multiple nodes are started using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in HOSTn, use the Interface environment variable by setting JAVA_OPTIONS to: -DInterface=eth3.
Then start Node Manager.
On Linux, set environment and superuser privileges for the wlsifconfig.sh script:
Ensure that the PATH environment variable includes the files listed in Table 17-1.
Table 17-1 Files Required for the PATH Environment Variable
| File | Located in this directory |
|---|---|
|
|
|
|
|
|
|
|
|
For security reasons, sudo should be restricted to the subset of commands required to run the wlsifconfig.sh script. For example, perform the following steps to set the environment and superuser privileges for the wlsifconfig.sh script.
Ask the system administrator for the appropriate sudo and system rights to perform this step.
Grant sudo privilege to the WebLogic user oracle with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.
Make sure the script is executable by the WebLogic user ('oracle'). The following is an example of an entry inside /etc/sudoers granting sudo execution privilege for oracle and also over ifconfig and arping.
To grant sudo privilege to the WebLogic user ('oracle') with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries:
Defaults:oracle !requiretty oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
In this section, server migration targets are configured. Configuring Cluster Migration sets the DataSourceForAutomaticMigration property to true.
To configure migration in a cluster:
Log in to the Oracle WebLogic Server Administration Console at: http://ADMIN.mycompany.com/console.
In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page is displayed.
Click the cluster needed to configure migration (oim_cluster) in the Name column of the table.
Click the Migration tab.
Click Lock and Edit.
In the Candidate Machines for Migratetable Servers field, select the machine to which to allow migration and click the right arrow. In this case, select IDM_PROVISIONED_HOST and IDM_SCALED_OUT_HOST.
Select the data source to be used for automatic migration. In this case, select the leasing data source.
Click Save.
In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.
Select the server needed to configure migration.
Click the Migration tab.
Select Automatic Server Migration Enabled and click Save.
Click Activate Changes.
Repeat steps 2 to 13 for the SOA cluster.
Restart WebLogic Administration Server, Node Managers, and the servers for which server migration has been configured, as described in Start and Stop Components.
If migration is only going to be allowed to specific machines, do not specify candidates for the cluster, but rather specify candidates only on a server per server basis.
In this section, the server migration is tested. Perform these steps to verify that server migration is working properly:
To test from IDM_PROVISIONED_HOST:
Stop the WLS_OIM_PROVISIONED_HOST Managed Server. To do this, run this command:
kill -9 pid
where pid specifies the process ID of the Managed Server. The pid can be identified in the node by running this command:
ps -ef | grep WLS_OIM_PROVISIONED_HOST
Watch the Node Manager console. A message indicating that WLS_OIM_PROVISIONED_HOST's floating IP has been disabled should be displayed.
Wait for Node Manager to try a second restart of WLS_OIM_PROVISIONED_HOST. It waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.
To test from IDM_SCALED_OUT_HOST:
Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_OIM_PROVISIONED_HOST on IDM_PROVISIONED_HOST, Node Manager on IDM_SCALED_OUT_HOST should prompt that the floating IP for WLS_OIM_PROVISIONED_HOST is being brought up and that the server is being restarted in this node.
Access the OIM Console using the Virtual Host Name, for example: OIMVH1. Console URLs are provided in About Oracle Identity Management Console URLs.
Follow the previous steps to test server migration for the WLS_OIM_SCALED_OUT_HOST, WLS_SOA_PROVISIONED_HOST, and WLS_SOA_SCALED_OUT_HOST Managed Servers.
Table 17-2 shows the Managed Servers and the hosts they migrate to in case of a failure.
Table 17-2 Managed Server Migration
| Managed Server | Migrated From | Migrated To |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Verification From the Administration Console
Migration can also be verified in the Administration Console:
Log in to the Administration Console. Console URLs are provided in About Oracle Identity Management Console URLs.
Click IDMDomain on the left console.
Click the Monitoring tab and then the Migration sub tab.
The Migration Status table provides information on the status of the migration.
After a server is migrated, to fail it back to its original node/machine, stop the Managed Server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager starts the Managed Server on the machine to which it was originally assigned.
Back up the database and the WebLogic domain, as described in Perform Backups During Installation and Configuration.
This section discusses how to fail over the Administration Server to IDMHOST2 and how to fail it back to IDMHOST1.
This section contains the following topics:
If a node fails, the Administration Server can be failed over to another node. This section describes how to fail over the Administration Server from IDMHOST1 to IDMHOST2.
Assumptions:
The Administration Server is configured to listen on ADMINVHN.mycompany.com, and not on ANY address.
The Administration Server is failed over from IDMHOST1 to IDMHOST2, and the two nodes have these IP addresses:
IDMHOST1: 100.200.140.165
IDMHOST2: 100.200.140.205
ADMINVIP: 100.200.140.206
This is the Virtual IP address where the Administration Server is running, assigned to interface:index (for example, eth1:2), available in IDMHOST1 and IDMHOST2.
The domain directory where the Administration Server is running in IDMHOST1 is on a shared storage and is mounted also from IDMHOST2.
NM in IDMHOST2 does not control the domain at this point, since unpack/nmEnroll has not been run yet on IDMHOST2. But for the purpose of AdminServer failover and control of the AdminServer itself, Node Manager is fully functional
Oracle WebLogic Server and Oracle Fusion Middleware Components have been installed inIDMHOST2 as described in previous sections. That is, the same path for IDM_ORACLE_HOME and MW_HOME that exists in IDMHOST1 is available in IDMHOST2.
The following procedure shows how to fail over the Administration Server to a different node, IDMHOST2.
Step 1 and Step 2 are applicable ONLY for Linux.
Stop the Administration Server as described in Start and Stop Components.
Migrate the IP address to the second node.
Run the following command as root on IDMHOST1 (where x:y is the current interface used by ADMINVHN.mycompany.com):
Linux:
/sbin/ifconfig x:y down
For example:
/sbin/ifconfig eth0:1 down
Solaris:
/sbin/ifconfig x:y down
For example:
/sbin/ifconfig eth0:1 down
Run the following command on IDMHOST2:
Linux:
/sbin/ifconfig interface:index IP_Address netmask netmask
For example:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
Solaris:
/sbin/ifconfig interface:index IP_Address netmask netmask
For example:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
Ensure that the netmask and interface to be used match the available network configuration in IDMHOST2.
Update routing tables by using the following commands, for example:
Linux:
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
Solaris:
/usr/sbin/ping <ipaddress>
Perform the following steps to start Node Manager on IDMHOST2.
On IDMHOST2, mount the Administration Server domain directory if it is not already mounted. For example:
mount /u01/oracle
Start Node Manager by using the following commands:
cd WL_HOME/server/bin
./startNodeManager.sh
Stop the Node Manager by killing the Node Manager process.
Starting and stopping Node Manager at this point is only necessary the first time Node Manager is run. Starting and stopping it creates a property file from a predefined template. The next step adds properties to that property file.
Run the setNMProps.sh script to set the StartScriptEnabled property to true before starting Node Manager:
cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh
Use the StartScriptEnabled property to avoid class loading failures and other problems.
Start the Node Manager as described in Starting and Stopping Components.
Start the Administration Server on IDMHOST2.
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
Once in the WLST shell, execute the following commands:
nmConnect('admin','Admin_Password', 'IDMHOST2','5556', 'IDMDomain','/u1/oracle/config/domains/IDMDomain')
nmStart('AdminServer')
Test the access to the Administration Server on IDMHOST2 as follows:
Ensure the access to the Oracle WebLogic Server Administration Console at:
http://ADMINVHN.mycompany.com:7001/console.
Check that it is possible to access and verify the status of components in the Oracle Enterprise Manager at: http://ADMINVHN.mycompany.com:7001/em.
Perform the same steps as in Validate the Administration Server. This is to check that the Administration Server can be accessed when it is running on IDMHOST2.
This step checks that the Administration Server can be failed back, that is, it can be stopped on IDMHOST2 and run on IDMHOST1. To do this, migrate ADMINVHN back to IDMHOST1 node as described in the following steps.
Ensure that the Administration Server is not running. If it is, stop it from the WebLogic console, or by running the command stopWeblogic.sh from ASERVER_HOME/bin.
On IDMHOST2, unmount the Administration server domain directory. For example:
umount /u01/oracle
On IDMHOST1, mount the Administration server domain directory. For example:
mount /u01/oracle
Disable the ADMINVHN.mycompany.com virtual IP address on IDMHOST2 and run the following command as root on IDMHOST2:
/sbin/ifconfig x:y down
where x:y is the current interface used by ADMINVHN.mycompany.com.
Run the following command on IDMHOST1:
/sbin/ifconfig interface:index 100.200.140.206 netmask 255.255.255.0
Ensure that the netmask and interface to be used match the available network configuration in IDMHOST1
Update routing tables by using arping. Run the following command from IDMHOST1.
/sbin/arping -q -U -c 3 -I interface 100.200.140.206
If Node Manager is not already started on IDMHOST1, start it, as described in Start and Stop Components.
Start the Administration Server again on IDMHOST1.
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
Once in the WLST shell, execute
nmConnect(admin,'Admin_Pasword, IDMHOST1,'5556',
'IDMDomain','/u01/oracle/config/domains/IDMDomain'
nmStart('AdminServer')
Test the access to the Oracle WebLogic Server Administration Console at:
http://ADMINVHN.mycompany.com:7001/console
where 7001 is WLS_ADMIN_PORT
Check it is possible to access and verify the status of components in the Oracle Enterprise Manager at:
http://ADMINVHN.mycompany.com:7001/em
For more information regarding scale out and server migration for Oracle Fusion Applications, go to Complete Conditional Common High Availability Post-Installation Tasks for Oracle Fusion Applications. Otherwise, go to the section that corresponds to the product offering that is installed.