Skip Headers
Oracle® Enterprise Manager Cloud Control Administrator's Guide
12c Release 3 (12.1.0.3)

E24473-27
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

29 Enterprise Manager High Availability

This chapter discusses best practices for installation and configuration of each Cloud Control component and covers the following topics:

29.1 Agent High Availability

The following sections discuss best practices for installation and configuration of the Management Agent.

29.1.1 Configuring the Management Agent to Automatically Start on Boot and Restart on Failure

The Management Agent is started manually. It is important that the Management Agent be automatically started when the host is booted to insure monitoring of critical resources on the administered host. To that end, use any and all operating system mechanisms to automatically start the Management Agent. For example, on UNIX systems this is done by placing an entry in the UNIX /etc/init.d that calls the Management Agent on boot or by setting the Windows service to start automatically.

29.1.2 Configuring Restart for the Management Agent

Once the Management Agent is started, the watchdog process monitors the Management Agent and attempts to restart it in the event of a failure. The behavior of the watchdog is controlled by environment variables set before the Management Agent process starts. The environment variables that control this behavior follow. All testing discussed here was done with the default settings.

  • EM_MAX_RETRIES – This is the maximum number of times the watchdog will attempt to restart the Management Agent within the EM_RETRY_WINDOW. The default is to attempt restart of the Management Agent three times.

  • EM_RETRY_WINDOW - This is the time interval in seconds that is used together with the EM_MAX_RETRIES environmental variable to determine whether the Management Agent is to be restarted. The default is 600 seconds.

The watchdog will not restart the Management Agent if the watchdog detects that the Management Agent has required restart more than EM_MAX_RETRIES within the EM_RETRY_WINDOW time period.

29.1.3 Installing the Management Agent Software on Redundant Storage

The Management Agent persists its configuration, intermediate state and collected information using local files in the agent_inst directory.

In the event that these files are lost or corrupted before being uploaded to the Management Repository, a loss of monitoring data and any pending alerts not yet uploaded to the Management Repository occurs.

To protect from such losses, configure these sub-directories on striped redundant or mirrored storage. The Management Agent agent_inst directory is shown by entering the command 'emctl getemhome' on the command line, or from the Management Services and Repository > Agents tab in the Cloud Control console.

29.2 Repository High Availability

The following sections document best practices for repository configuration.

29.2.1 General Best Practice for Repository High Availability

Before installing Enterprise Manager, you should prepare the database, which will be used for setting up Management Repository. Install the database using Database Configuration Assistant (DBCA) to make sure that you inherit all Oracle install best practices.

  • Choose Automatic Storage Management (ASM) as the underlying storage technology.

  • Enable ARCHIVELOG Mode

  • Enable Block Checksums

  • Configure the Size of Redo Log Files and Groups Appropriately

  • Use a Flash Recovery Area

  • Enable Flashback Database

  • Use Fast-Start Fault Recovery to Control Instance Recovery Time

  • Enable Database Block Checking

  • Set DISK_ASYNCH_IO

The details of these settings are available in Oracle Database High Availability Best Practices.

Use the MAA Advisor for additional high availability recommendations that should be applied to the Management Repository. To access the MAA Advisor:

  1. On the Database Target Home page, locate the High Availability section.

  2. Click Details next to the Console item.

  3. In the Availability Summary section of the High Availability Console page, click Details located next to the MAA Advisor item.

29.2.2 Configuring RAC for the Management Repository

If the Management Repository is a Real Application Cluster (RAC) database, the Management Service processes need to be configured to communicate with each node of the RAC database in a redundant fashion.

Note that RAC nodes are referred to by their virtual IP (VIP) names. The service_name parameter is used instead of the system identifier (SID) in connect_data mode and failover is turned on. Refer to the Oracle Database Net Services Administrator's Guide for details.

Configure the repository connect descriptor by running the emctl command from Management Service. If you have multiple Management Services configured, this command must be run on each Management Service.

emctl config oms -store_repos_details -repos_conndesc '(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))' -repos_user sysman

After making the previous change, run the following command from any one OMS to make the same change to the monitoring configuration used for the Management Services and Repository target:

emctl config emrep -conn_desc <repository_connect descriptor as above>

29.3 Oracle Management Service High Availability

The following sections document the configuring the OMS for high availability.

29.3.1 Configuring the Cloud Control OMS in an Active/Passive Environment for High Availability Failover Using Virtual Host Names

This section provides a general reference for Cloud Control administrators who want to configure Enterprise Manager Cloud Control in Cold Failover Cluster (CFC) environments.

29.3.1.1 Overview and Requirements

The following conditions must be met for Cloud Control to fail over to a different host:

  • The installation must be done using a Virtual Host Name and an associated unique IP address.

  • Install on a shared disk/volume which holds the binaries and the gc_inst directory.

  • The Inventory location must failover to the surviving node.

  • The software owner and time zone parameters must be the same on all cluster member nodes that will host this Oracle Management Service (OMS).

29.3.1.2 Installation and Configuration

To override the physical host name of the cluster member with a virtual host name, software must be installed using the parameter ORACLE_HOSTNAME.

The software must be installed using the command line parameter -invPtrLoc to point to the shared inventory location file, which includes the path to the shared inventory location.

If you are using an NFS mounted volume for the installation, please ensure that you specify rsize and wsize in your mount command to prevent running into I/O issues.

For example:

oms.example.com:/u01/app/share1 /u01/app/share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0

Note:

Any reference to shared failover volumes could also be true for non-shared failover volumes which can be mounted on active hosts after failover.

29.3.1.3 Setting Up the Virtual Host Name/Virtual IP Address

You can set up the virtual host name and virtual IP address by either allowing the clusterware to set it up, or manually setting it up yourself before installation and startup of Oracle services. The virtual host name must be static and resolvable consistently on the network. All nodes participating in the setup must resolve the virtual IP address to the same host name. Standard TCP tools such as nslookup and traceroute can be used to verify the host name. Validate using the following commands:

nslookup <virtual hostname>

This command returns the virtual IP address and full qualified host name.

nslookup <virtual IP>

This command returns the virtual IP address and fully qualified host name.

Be sure to try these commands on every node of the cluster and verify that the correct information is returned.

29.3.1.4 Setting Up Shared Storage

Storage can be managed by the clusterware that is in use or you can use any shared file system (FS) volume, such as NFS, as long as it is not an unsupported type, such as OCFS V1.

Note:

Only OCFS V1 is not supported. All other versions of OCFS are supported.

If the OHS directory is on a shared storage, the LockFile directive in the httpd.conf file should be modified to point to a local disk, otherwise there is a potential for locking issues.

29.3.1.5 Setting Up the Environment

Some operating system versions require specific operating system patches be applied prior to installing 12c. The user installing and using the 12c software must also have sufficient kernel resources available. Refer to the operating system's installation guide for more details. Before you launch the installer, certain environment variables need to be verified. Each of these variables must be identically set for the account installing the software on ALL machines participating in the cluster:

  • OS variable TZ

    Time zone setting. You should unset this variable prior to installation.

  • PERL variables

    Variables such as PERL5LIB should also be unset to avoid association to the incorrect set of PERL libraries

29.3.1.6 Synchronizing Operating System IDs

The user and group of the software owner should be defined identically on all nodes of the cluster. This can be verified using the 'id' command:

$ id -a

uid=550(oracle) gid=50(oinstall) groups=501(dba)

29.3.1.7 Setting Up Shared Inventory

Use the following steps to set up shared inventory:

  1. Create your new ORACLE_HOME directory.

  2. Create the Oracle Inventory directory under the new ORACLE_HOME:

    $ cd <shared oracle home>

    $ mkdir oraInventory

  3. Create the oraInst.loc file. This file contains the Oracle Inventory directory path information needed by the Universal Installer.

    vi oraInst.loc

    Enter the path information to the Oracle Inventory directory and specify the group of the software owner as the oinstall user. For example:

    inventory_loc=/app/oracle/share1/oraInventory

    inst_group=oinstall

29.3.1.8 Installing the Software

Refer to the following steps when installing the software:

  1. Create the shared disk location on both the nodes for the software binaries.

  2. Point to the inventory location file oraInst.loc (under the ORACLE_BASE in this case), as well as specifying the host name of the virtual group. For example:

    $ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.example.com -debug

    You can also provide the ORACLE_HOSTNAME when prompted for this information from in Enterprise Manager runInstaller UI.

  3. Install Oracle Management Services on cluster member Host1.

  4. Continue the remainder of the installation normally.

  5. Once completed, copy the files oraInst.loc and oratab to /etc on all cluster member hosts (Host2, Host3, ...)

Windows Specific Configuration Steps

On Windows environments, an additional step is required to copy over service and keys required by the Oracle software. Note that these steps are required if your clustering software does not provide a shared windows registry.

  1. Using regedit on the first host, export each Oracle service from under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

  2. Using regedit on the first host, export HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE.

  3. Use regedit to import the files created in step 1 and 2 to the failover host.

29.3.1.9 Starting Up Services

Ensure that you start your services in the proper order. Use the order listed below:

  1. Establish the IP address on the active node.

  2. Start the TNS listener (if it is part of the same failover group).

  3. Start the database (if it is part of the same failover group).

  4. Start Cloud Control using emctl start oms

  5. Test functionality.

In case of failover, refer to "Performing Switchover and Failover Operations".

29.3.1.10 Repository Host Name Change

In general Enterprise Manager does not store IP address lookups. So if the IP address of the repository host changes but the hostname remains the same, no configuration change in required in Enterprise Manager. Ensure that the OMS(s) hosts can communicate with the repository host with the new IP address.

However if the Repository hostname changes, please use the following procedure to make appropriate configuration changes so that the OMS(s) can communicate with the repository with new hostname.

  1. Stop all OMS instances using the command

    $emctl stop oms -all

  2. Stop the Agent running on the database host.

    $emctl stop agent

  3. Perform host name change for the machine either by local resolution /etc/hosts or DNS based resolution or a combination of both.

  4. Follow Oracle Database Administrator guide to configure the database for hostname change.

  5. Correct the connect descriptor for the repository by running the following commands:

    On the first Oracle Management Service

    emctl start oms -admin-only

    On each Oracle Management Service

    $emctl config oms -store_repos_details -repos_conndesc <connect descriptor> -repos_user sysman

    Where <connect descriptor> is the repository connect descriptor using the new hostname.

    Note: If Single Client Access Name (SCAN) is configured on the Repository database, it may be possible to change the repository hostname without needing to change the connect descriptor of clients like OMS. Please consult Oracle Database Administrator Guide.

  6. Stop and Start OMS instances using the command:

    $emctl stop oms -all

    $emctl start oms

  7. The agent installed on the repository host using the old hostname can no longer be used. Install new agent on database host, if RAC database is configured then install new agent on each node. Follow below step to install new agent <include agent installation url for reference>

    1. Remove the agent_inst directory .

    2. Configure the agent using the agentDeploy.sh command:

    $<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

  8. Relocate the Repository database target to the new Management Agent configured using the following commands:

    <OMS_HOME>/bin/emcli login -username=sysman

    <OMS_HOME>/bin/emcli sync

    <OMS_HOME>/bin/emctl config repos -agent <new agent on host, e.g myNewReposHost.example.com:3872>

  9. Change the monitoring configuration for the OMS and Repository target: by running the following command from the OMS:

    $emctl config emrep -conn_desc

  10. Verify that the site is fully operational.

  11. Log in to Cloud Control. Navigate Setup, Manage Cloud Control and click on Health Overview.

  12. Delete old agent target entry.

  13. Verify that the site is fully operational.

29.3.1.11 Multiple OMS, SLB, First OMS Host Name Change

In this scenario, you have mulitple OMSs fronted by Server Load Balancer. OMS configuration backed up using the emctl exportconfig oms command on the primary OMS running the WebLogic AdminServer.

  1. Copy the emkey to the Management Repository by running the following command on the OMS:

    $<ORACLE_HOME>/bin/emctl config emkey -copy_to_repos

  2. Export the configuration from the OMS.

    $<ORACLE_HOME>/bin/emctl exportconfig oms -dir <location for the export file>

    After the configuration is exported, do not make any configuration changes to the OMS until hostname change is configured.

  3. Deconfigure and delete the OMS

    1. Stop the OMS $<ORACLE_HOME>/bin/emctl stop oms -all

    2. Stop the agent running $<AGENT_HOME>/bin/emctl stop agent

    3. Delete the OMS $<OMS_HOME>/bin/omsca delete -full

      For example:

      /u01/app/Oracle/Middleware/oms/bin/omsca delete -full

      Note : You are prompted to confirm your action, and furnish the AdminServer credentials and the repository database details such as the database host name, listener port, SID, and password. Once you provide the required details, the command automatically stops the OMS, Oracle WebLogic Server, and also Oracle WebTier.

  4. Delete following file from the Oracle Home

    Also, delete Instance home directory gc_inst, if it exists.

  5. Make sure no process running on the OMS host.

    ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9

    Note : Change Middleware|gc_inst to strings that match your own middleware and instance homes

  6. Perform hostname change for the machine either by local resolution /etc/hosts or DNS based resolution or a combination of both.

  7. Run omsca in recovery mode specifying the export file taken earlier to configure the OMS:

    <OMS_HOME>/bin/omsca recover -as -ms -nostart -backup_file <exportconfig file> -EM_INSTANCE_HOST <new hostname> -AS_HOST <new hostname>

    Note: The -backup_file to be passed must be the latest file generated from emctl exportconfig oms command in Step 2.

    Provide new hostname for -EM_INSTANCE_HOST and -AS_HOST

  8. Add the new hostname to the SLB virtual server pools and remove the old OMS entry.

  9. Start the OMS

    <OMS_HOME>/bin/emctl start oms

  10. Configure the Management Agent.

    1. Remove the agent_inst directory .

    2. Configure the agent using the agentDeploy.sh command:

      $<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

  11. The additional OMS must be re-enrolled so that they can communicate with the admin server running on the new host. Do the following on each additional management service.

    enroll oms -as_host <newhostname> -as_port <AdminServer_ssl_port>

    Note: You will be prompted to provided password for admin and node manager.

  12. Login to EM console. Navigate to Setup, Provisioning and Patching and click on Software library. If software library location is configured, verify it is accessible. If not accessible then follow software library configuration document to either migrate or configure new.

    <swlib configuration location>

  13. Verify that the site is fully operational.

29.3.1.12 Multiple OMS, SLB, Additional OMS Host Name Change

In this scenario, you have multiple OMS sites where the OMS instances are fronted by an SLB. OMS configuration backed up using the emctl exportconfig oms command on the first OMS. Hostname change is required on Additional OMS host.

  1. Stop the OMS using below command

    $<ORACLE_HOME>/bin/emctl stop oms

  2. Stop the agent running on the host

    $<AGENT_HOME>/bin/emctl stop agent

  3. Deconfigure and delete the OMS:

    Delete the OMS $<OMS_HOME>/bin/omsca delete -OMSNAME <Additional OMS Name>

    For example:

    /u01/app/Oracle/Middleware/oms/bin/omsca delete -OMSNAME EMGC_OMS2

    Note: You are prompted to confirm your action, and furnish the AdminServer credentials and the repository database details such as the database host name, listener port, SID, and password. Once you provide the required details, the command automatically stops the OMS, Oracle WebLogic Server, and also Oracle WebTier.

  4. Delete following file from the Oracle Home

    Delete the Instance home directory gc_inst, if it exists.

  5. Make sure no process running on the OMS host.

    ps -ef | grep -i -P "(Middleware|gc_inst)" | grep -v grep | awk '{print $2}' | xargs kill -9

    Note : Change Middleware|gc_inst to strings that match your own middleware and instance homes

  6. Perform hostname change for the machine either by local resolution /etc/hosts or DNS based resolution or a combination of both.

  7. Ensure that shared software library locations are accessible.

  8. Install an Management Agent on the required host using new hostname.

    1. Remove the agent_inst directory .

    2. Configure the agent using the agentDeploy.sh command:

      $<AGENT_HOME>/core/12.1.0.0.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<AGENT_BASE_DIR> AGENT_INSTANCE_HOME=<AGENT_INSTANCE_HOME> ORACLE_HOSTNAME=<AGENT_HOSTNAME> AGENT_PORT=<AGENT_PORT> -configOnly OMS_HOST=<oms host> EM_UPLOAD_PORT=<OMS_UPLOAD_PORT> AGENT_REGISTRATION_PASSWORD=<REG_PASSWORD>

  9. Use the Additional OMS deployment procedure to configure a new additional OMS. See the Oracle® Enterprise Manager Cloud Control Basic Installation Guide for more information.

  10. Verify that the site is fully operational.

29.3.2 Configuring the Cloud Control OMS for High Availability Failover

The following sections discuss how to configure the OMS for high availability failover in an Active/Active environment using a Server Load Balancer.

29.3.2.1 Configuring the Software Library

The software library location must be accessible by all active Management Services. If the software library is not configured during installation, it needs to be configured post-install using the Enterprise Manager console.:

  1. On the Enterprise Manager home page, from the Setup menu, select Provisioning and Patching, and then select Software Library.

  2. Click the Provisioning subtab.

  3. On the Provisioning page, click the Administration subtab.

  4. In the Software Library Configuration section, click Add to set the Software Library Directory Location to a shared storage that can be accessed by any host running the Management Service.

29.3.2.2 Configuring a Load Balancer

This section describes the guidelines for setting up a Server Load Balancer (SLB) to balance the agent and browser traffic to multiple Management Services.

Server Load Balancer Requirements

In order to configure your OMS's in an active/active configuration behind an SLB, your SLB must meet the following requirements:

  • The SLB must provide support for multiple virtual server ports.

    Enterprise Manager typically requires that up to 4 ports are configured on the SLB (Secure Upload, Agent Registration, Secure Console, Unsecure Console)

  • Support for persistence.

    HTTP and HTTPS traffic between the browser and the OMS requires persistence.

  • Support for application monitoring.

    The SLB must be capable of monitoring the health of the OMSs and detecting failures, so that requests will not be routed to OMSs that are not available.

SLB configuration is a two-step process:

  1. Configure the SLB.

  2. Make requisite changes on the Management Services.

29.3.2.2.1 SLB Setup

Use the following table as reference for setting up the SLB with Cloud Control Management Services.

Table 29-1 Management Service Ports

Cloud Control Service TCP Port Monitor Name Persistence Pool Name Load Balancing Virtual Server Name Virtual Server Port

Secure Upload

1159

mon_gcsu4900

None

pool_gcsu4900

Round Robin

vs_gcsu4900

1159

Agent Registration

4889

mon_gcar4889

Active Cookie Insert

pool_gcar4889

Round Robin

vs_gcar4889

4889

Secure Console

7799

mon_gcsc7799

Source IP

pool_gcsc7799

Round Robin

vs_gcsc443

443

Unsecure Console (optional)

7788

mon_gcuc7788

Source IP

pool_gcuc7788

Round Robin

vs_gcuc80

80


Use the administration tools that are packaged with your SLB. A sample configuration follows. This example assumes that you have two Management Services running on host A and host B using the default ports as listed in Table 33–1.

  1. Create Pools

    A pool is a set of servers grouped together to receive traffic on a specific TCP port using a load balancing method. Each pool can have its own unique characteristic for a persistence definition and the load-balancing algorithm used.

    Table 29-2 Pools

    Pool Name Usage Members Persistence Load Balancing

    pool_gcsu4900

    Secure upload

    HostA:4900 HostB:4900

    None

    Round Robin

    pool_gcar4889

    Agent registration

    HostA:4889 HostB:4889

    Active cookie insert; expiration 60 minutes

    Round Robin

    pool_gcsc7799

    Secured console access

    HostA:7799 HostB:7799

    Source IP; expiration 60 minutes

    Round Robin

    pool_gcuc7788 (optional)

    Unsecured console access

    HostA:7788 HostB:7788

    Source IP; expiration 60 minutes

    Round Robin


  2. Create Virtual Servers

    A virtual server, with its virtual IP Address and port number, is the client- addressable hostname or IP address through which members of a load balancing pool are made available to a client. After a virtual server receives a request, it directs the request to a member of the pool based on a chosen load balancing method.

    Table 29-3 Virtual Servers

    Virtual Server Name Usage Virtual Server Port Pool

    vs_gcsu4900

    Secure upload

    4900

    pool_gcsu4900

    vs_gcar4889

    Agent registration

    4889

    pool_gcar4889

    vs_gcsc443

    Secure console access

    443

    pool_gcsc7799

    vs_gcuc80 (optional)

    Unsecure console access

    80

    pool_gcuc7788


  3. Create Monitors

    Monitors are used to verify the operational state of pool members. Monitors verify connections and services on nodes that are members of load-balancing pools. A monitor is designed to check the status of a service on an ongoing basis, at a set interval. If the service being checked does not respond within a specified timeout period, the load balancer automatically takes it out of the pool and will choose the other members of the pool. When the node or service becomes available again, the monitor detects this and the member is automatically accessible to the pool and able to handle traffic.

    Table 29-4 Monitors

    Monitor Name Configuration Associate With

    mon_gcsu4900

    Type: https

    Interval: 5

    Timeout: 16

    Send String: GET /empbs/upload

    Receive String: Http Receiver Servlet active!

    HostA:4900 HostB:4900

    mon_gcar4889

    Type: http

    Interval: 5

    Timeout: 16

    Send String: GET /empbs/genwallet

    Receive String: GenWallet Servlet activated

    HostA:4889 HostB:4889

    mon_gcsc7799

    Type: https

    Interval: 5

    Timeout: 16

    Send String: GET /em/consoleStatus.jsp

    Receive String: Enterprise Manager Console is UP

    HostA:7799 HostB:7799

    mon_gcuc7788 (optional)

    Type: http

    Interval: 5

    Timeout: 16

    Send String: GET /em/consoleStatus.jsp

    Receive String: Enterprise Manager Console is UP

    HostA:7788 HostB:7788


    Note: Some Load Balancers require <CR><LF> characters to be added explicitly to the Send String using literal "\r\n". This is vendor-specific. Refer to your SLB documentation for details.

29.3.2.2.2 Enterprise Manager Side Setup

Perform the following steps:

  1. Resecure the Oracle Management Service

    By default, the service name on the Management Service-side certificate uses the name of the Management Service host. Management Agents do not accept this certificate when they communicate with the Oracle Management Service through a load balancer. You must run the following command to regenerate the certificate on each Management Service:

    emctl secure oms
      -host slb.example.com 
      -secure_port 4900 
      -slb_port 4900
      -slb_console_port 443  
      -console
      [-lock]  [-lock_console]
    
    

    Output:

    Oracle Enterprise Manager Cloud Control 12c Release 3
    Copyright (c) 1996, 2013 Oracle Corporation.  All rights reserved.
    Securing OMS... Started.
    Enter Enterprise Manager Root (SYSMAN) Password :
    Enter Agent Registration Password :
    Securing OMS... Successful
    Restart OMS
    
  2. Resecure all Management Agents

    Management Agents that were installed prior to SLB setup, including the Management Agent that comes with the Management Service install, would be uploading directly to the Management Service. These Management Agents will not be able to upload after SLB is setup. Resecure these Management Agents to upload to the SLB by running the following command on each Management Agent:

    emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em
    

29.3.2.3 Installing Additional Management Services

There are two ways to install additional Management Services: