Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide, 12c Release 2 (12.1.0.2)

12c Release 2 (12.1.0.2)

E24089-17

Contents

Title and Copyright Information

Preface

- Intended Audience

- Purpose of the Document

- Documentation Accessibility

- Related Documents

- Conventions

Part I Getting Started

1 Procuring Software

- Releases Available for Enterprise Manager Cloud Control

- Procuring Enterprise Manager Cloud Control Software

- How Do You Access the Software from DVD?

- Accessing Software from DVD

- Setting Mount Point for DVD

- How Do You Procure the Software from Oracle Technology Network?

- Downloading Software

- Verifying File Size

- Extracting Contents

- Verifying Platform Information

- Procuring Oracle Management Agent Software

2 Understanding the Basics

- Understanding Installation Basics

- What Different Installation Modes Can You Use?

- What Is Enterprise Manager Cloud Control Installation Wizard?

- What Installation Types Are Offered by the Installation Wizard?

- Create a New Enterprise Manager System

- Upgrade an Existing Enterprise Manager System

- Install Software Only

- What is a Deployment Size?

- What Is Add Host Target Wizard?

- What Is Add Management Service Deployment Procedure?

- What Ports Are Used for Installation?

- What Default Ports Are Used?

- How Can You Customize Ports?

- What Precautions You Must Take While Customizing Port Numbers?

- What Data Files Are Created While Configuring Oracle Management Repository?

- How Do You Delete Data Files?

- Understanding Oracle WebLogic Server Requirement

- How Do I Verify Whether Oracle WebLogic Server Is Installed?

- Is Oracle WebLogic Server Cluster Supported?

- If Oracle WebLogic Server Already Exists, Is the Existing Domain Used?

- When and Why Do You Need Oracle WebLogic Server Credentials?

- When and Why Do You Need Node Manager Credentials?

- How Do You Find Admin Server Port After Installing Enterprise Manager?

- How Do You Verify Whether Admin Server Is Running?

- How Do You Start Admin Server?

- Understanding Installation Directories

- What Is Oracle Inventory Directory?

- What Is Oracle Middleware Home?

- What Is Oracle Management Service Instance Base Location?

- What Is Oracle Home?

- What Is Agent Base Directory?

- What is Agent Instance Directory?

- What Is /TMP C:\Temp Directory Used For?

- Understanding Additional Components Installed

- What Is Oracle Configuration Manager?

- Manually Collecting and Uploading Configuration Information

- Enabling Oracle Configuration Manager After Installing Enterprise Manager Cloud Control

- What Are Software Updates?

- How Can You Download the Software Updates?

- When Can You Apply the Software Updates?

- Understanding Configuration Assistants

- What Are Configuration Assistants?

- What Configuration Assistants Are Run by the Installation Wizard?

- Configuration Assistants Run While Installing a New Enterprise Manager

- Configuration Assistants Run While Upgrading an Existing Enterprise Manager

- Configuration Assistants Run While Upgrading an Additional Oracle Management Service

- What Do You Do When Configuration Assistants Fail?

- Understanding Prerequisite Checks

- What Prerequisite Checks Are Run by Default?

- How Can You Run Prerequisite Checks in Standalone Mode?

- Understanding Limitations of Enterprise Manager Cloud Control

- Can You Access Unlicensed Components?

- What Are the Limitations with DHCP-Enabled Machines?

- Understanding Other Miscellaneous Concepts

- What Is a Host List File?

- What Scripts Are Run During the Installation Process?

Part II Installing Enterprise Manager System

3 Installing Enterprise Manager System in Silent Mode

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- Installing Enterprise Manager

- Using Advanced Installer Options

- Understanding the Limitations

- Editing Response File for Installing Software

- After You Install

4 Installing Enterprise Manager Software Now and Configuring Later

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- Installing in Graphical Mode

- Installing Software

- Running Root Script

- Configure Software

- Performing Post-Configuration Tasks

- Installing in Silent Mode

- Installing Software

- Running Root Script

- Configuring Software

- Performing Post-Configuration Tasks

Part III Installing Additional Oracle Management Service

5 Installing Additional Oracle Management Service in Silent Mode

Part IV Installing Oracle Management Agent

6 Installing Oracle Management Agent in Silent Mode

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- Installing a Management Agent in Silent Mode

- Installing Using AgentPull Script

- Installing Using agentDeploy Script

- Installing Using RPM File

- Creating a Response File for Installing Using AgentPull Script

- Creating a Response File for Installing Using agentDeploy Script

- Creating a Response File for Installing Using an RPM File

- Understanding the Options Supported by the AgentPull Script

- Understanding the Options Supported by the agentDeploy Script

- Understanding the Contents of the Downloaded Management Agent Software

- Understanding the Contents of the Management Agent RPM File

- After You Install

7 Cloning Oracle Management Agent

- Overview

- Before You Begin

- Prerequisites

- Cloning Procedure

- Cloning in Graphical Mode

- Supported Additional Parameters

- Format of Host List File

- Cloning in Silent Mode

- Setting Environment Variables for Cloning Agent Using ZIP File

- After You Clone

8 Installing Shared Agent

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- Installing in Graphical Mode

- Supported Additional Parameters

- Installing in Silent Mode

- Creating a Response File

- After You Install

9 Installing Oracle Management Agent Software Now and Configuring Later

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- Configuration Procedure

- After You Install

Part V Advanced Installation and Configuration

10 Configuring Enterprise Manager for Firewalls

- Firewall Configuration Considerations

- Enabling ICMP Echo Requests on Firewalls

- Overview of Enterprise Manager Components and Ports

- Viewing a Summary of the Ports Assigned During Installation

- Default Port Assignments for Enterprise Manager Components

- Firewall Configurations for Enterprise Management Components

- Firewalls Between Your Browser and the Enterprise Manager Console

- Configuring the Management Agent on a Host Protected by a Firewall

- Configuring the Management Agent to Use a Proxy Server

- Configuring the Firewall to Allow Incoming Communication From the Management Service

- Configuring the OMS on a Host Protected by a Firewall

- Configuring the OMS to Use a Proxy Server to Communicate with Management Agents

- Configuring the Firewall to Allow Incoming Management Data From the Management Agents

- Enabling OMS to Access My Oracle Support

- About the dontProxyfor Property

- Firewalls Between the OMS and the Management Repository

- Firewalls Between Enterprise Manager and a Managed Database Target

- Firewalls Used with Multiple OMS Instances

- Configuring Firewalls to Allow ICMP and UDP Traffic for Beacons

11 Sizing Your Enterprise Manager Deployment

- Overview of Oracle Enterprise Manager Cloud Control Architecture

- Enterprise Manager Cloud Control Sizing

- Overview of Sizing Guidelines

- Hardware Information

- Sizing Specifications

- Sizing for Upgraded Installs

- Minimum Hardware Requirements

- Network Topology Considerations

- Software Configurations

- Small Configuration

- Medium Configuration

- Large Configuration

- Repository Tablespace Sizing

- Additional Configurations

- Large Concurrent UI Load

- BI Publisher Configuration

- Enterprise Manager Cloud Control Performance Methodology

- Step 1: Choosing a Starting Platform Cloud Control Deployment

- Step 2: Periodically Evaluating the Vital Signs of Your Site

- Step 3: Using DBA and Enterprise Manager Tasks To Eliminate Bottlenecks

- Offline Monthly Tasks

- Step 4: Eliminating Bottlenecks Through Tuning

- High CPU Utilization

- Loader Vital Signs

- Rollup Vital Signs

- Rollup Process

- Job, Notification, and Alert Vital Signs

- I/O Vital Signs

- About the Oracle Enterprise Manager Performance Page

- Determining the Optimum Number of Middle Tier OMS Servers

- Step 5: Extrapolating Linearly Into the Future for Sizing Requirements

- Using Returning Query Safeguards to Improve Performance

- Overview of Repository and Sizing Requirements for Fusion Middleware Monitoring

- ADP Monitoring

- JVMD Monitoring

12 Installing ADP with Advanced Installation Options

- Application Dependency and Performance Architecture

- Before you Begin

- Prerequisites

- Installation Procedure

- Deploying ADP Manager on a Previously Created Managed Server

- Deploying ADP Manager on an OMS Host

- Deploying ADP Manager on a Separate Host from OMS (Remote Deployment)

- Deploying ADP Agents (Remote Deployment)

- Performing Postinstallation Tasks

- Configuring Oracle SOA Suite for Secure Connectivity

- Configuring Oracle WebLogic Server or Oracle WebLogic Portal (WLP) for Secure Connectivity

- Importing a Certificate into the Manager's Keystore

- Configuring the ADP Agent When WebLogic Is Installed As a Windows Service

- After You Install

13 Installing JVMD with Advanced Install Options

- JVMD Architecture

- Before you Begin

- Prerequisites

- Installation Procedure

- Deploying JVMD Manager

- Deploying JVMD Manager on an OMS Host

- Deploying JVMD Manager on a Separate Host from OMS (Remote Deployment)

- Deploying JVMD Manager Manually

- Redeploying JVMD Manager

- Deploying JVMD Agents

- Deploying JVMD Agents Using Enterprise Manager Cloud Control

- Downloading and Deploying JVMD Agents

- Redeploying JVMD Agents on WebLogic Servers

- Deploying JVMD Database Agent

- Connecting JVMD Agent to the JVMD Manager Secure Port

- After You Install

14 Integrating BI Publisher with Enterprise Manager

- Overview

- Limitations

- Downloading Oracle BI Publisher

- BI Publisher Installation and Integration with Enterprise Manager 12c

- Enterprise Manager and BI Publisher Inventory

- Installing Enterprise Manager and Required Infrastructure

- Installing BI EE Using Software-only Install

- Integrating BI Publisher with Enterprise Manager using the configureBIP Script

- Verifying Integration of BI Publisher with Enterprise Manager

- Allowing Access to BI Publisher for Enterprise Manager Administrators

- Enterprise Manager Authentication Security Model

- BI Publisher security model

- BI Publisher Permissions

- BI Publisher OPSS Application Roles

- Authenticating and limiting access BI Publisher features

- Limiting access to BI Publisher features

- Granting BI Publisher OPSS Application Roles to Enterprise Manager Administrators in Repository-Based Authentication Mode Using wlst

- Propagation Time for Changes to OPSS

- Allowing Access to BI Publisher for Enterprise Manager Administrators in an underlying LDAP Authentication security model environment

- Mapping LDAP Groups to BI Publisher OPSS Application Roles

- Configuring BI Publisher with a Custom Trust Store

- BI Publisher Administration

- Post-Upgrade Steps to take after upgrading to BI Publisher to 11.1.1.6.0

- EMBIP* Roles: Granting Access to Folders and Catalog Objects

- Access to Enterprise Manager Repository

- Troubleshooting

- Rerunning configureBIP

- BI Publisher Log File Locations

- configureBIP Log Files

- Enterprise Manager BI Publisher Tree and EM CLI Log File Output

- BI Publisher Runtime

- Additional Troubleshooting

- Redeploying All Enterprise Manager-Supplied BI Publisher Reports

- Managing Enterprise Manager - BI Publisher Connection Credentials

- Managing the BI Publisher Server

- Configuring BI Publisher behind a Load-Balancer

Part VI Deinstallation

15 Deinstalling Enterprise Manager Cloud Control

- Prerequisites

- Deinstallation Procedure

- Deinstalling in Graphical Mode

- Deinstalling in Silent Mode

- After You Deinstall

16 Deinstalling Oracle Management Agent

- Prerequisites

- Deinstallation Procedure

- Deinstalling Oracle Management Agent in Graphical Mode

- Deinstalling Oracle Management Agent in Silent Mode

- Deinstaling in Slient Mode Using the Installer

- Deinstalling in Silent Mode Using AgentDeinstall.pl Script

- Deinstalling Shared Agent

- Deinstalling Oracle Management Agent Installed Using an RPM File

- After You Deinstall

17 Deinstalling ADP and JVMD

- Deinstallation Procedure for ADP

- Deinstalling ADP Manager

- Deinstalling ADP Agents

- Deinstallation Procedure for JVMD

- Deinstalling JVMD Managers

- Deinstalling JVMD Agents

Part VII Appendixes

A Understanding the Enterprise Manager Directory Structure

- Understanding the Enterprise Manager Directories Installed with Oracle Enterprise Manager Cloud Control 12c

- About the Oracle Management Service Home Directory

- About the Oracle Management Agent Home (AGENT_HOME) Directory

- About Business Intelligence Publisher Home Directory

- Summary of the Important Directories in the Oracle Management Service Home

- Understanding the Enterprise Manager Directories Installed with Management Service

- Understanding the Enterprise Manager Directories Installed with Management Agent

- Summary of the Important Directories in the Oracle Management Agent Home

- Understanding the Oracle Management Agent Directory Structure in Windows

- Identifying the Agent Instance Home When Using the emctl Command

B Installation and Configuration Log Files

- Enterprise Manager Cloud Control Installation Logs

- Installation Logs

- Configuration Logs

- General Configuration Logs

- Repository Configuration Logs

- Secure Logs

- Oracle Management Service Logs

- Add Host Log Files

- Initialization Logs

- Application Prerequisite Logs

- System Prerequisite Logs

- Agent Installation Logs

- Other Add Host Logs

C Redirecting Oracle Management Agent to Another Oracle Management Service

D Using RepManager Utility

- Overview

- Supported Actions and Commands

E Collecting OCM Data Using Oracle Harvester

- Oracle Harvester

- Supported Targets in Oracle Harvester

- Configuration Data Not Available in My Oracle Support

- Oracle Configuration Manager

- Additional Information

- Troubleshooting Configuration Data Collection Tools

- Oracle Harvester Collection Fails If the state/upload/external Directory Is Missing

- Oracle Configuration Manager Is Not Running

- Configuration Data Not Available in My Oracle Support

F Enabling Enterprise Manager Accessibility Features

- Enabling Enterprise Manager Accessibility Mode

- Setting uix-config.xml Flag

- Configuring web.xml File

- Verifying That Screen Reader Support Is Enabled

G Troubleshooting

- Troubleshooting Configuration Assistant Failures

- Plugins Prerequisites Check Configuration Assistant

- Repository Configuration Assistant

- Repository Out Of Box Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Oracle Configuration Manager Repeater Configuration Assistant

- OCM Configuration for OMS Configuration Assistant

- Agent Configuration Assistant

- Agent Upgrade Configuration Assistant

- Repository Upgrade Configuration Assistant

- Stopping APM Engines Configuration Assistant

- Stop Admin Server Configuration Assistant

- Troubleshooting ADP and JVMD Failures

- ADP Manager Name Conflict

- Failure to Deploy ADP Agent On a Target

- SSL Handshake Failure Agent Deployment Errors

- Copying ADP Agent Zip or Javadiagnosticagent Ear Step Failure

- Troubleshooting Package-Related Issues

- Troubleshooting Deinstallation Failures

Index

Oracle® Enterprise Manager

Cloud Control Advanced Installation and Configuration Guide

12c Release 2 (12.1.0.2)

E24089-17

October 2012

Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide, 12c Release 2 (12.1.0.2)

E24089-17

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Aravind Jayaraaman

Contributing Author:  Dennis Lee, Genevieve D'Souza, Namrata Bhakthavatsalam, Leo Cloutier, Jacqueline Gosselin, Pradeep Gopal

Contributor: Anu Vale, Smitha Vishwanathan, Abhishek Suresh Kumar, Srilatha Uravakonda, Shilpa Thergaonkar, Palem Naga Maheshwara Reddy, Smitha Nath, Prakash Jaganathan, Ariram Kandasamy, Raj Aggarwal, Daniel Tsao, Maria Kaval, James Emmond, Anand Kurumbur, Leslie Gloyd, Jerry Abramson, Ravi Pinnamaneni, Amitava Raha, Rajiv Kuriakose, Ashish Goel, Atif Jamil, Karthik Somasundaram, Devanand Patil, Sushma Vale, Abhishek Vaidya, Venkatesh BGS, Ashish Goel, Jing Ning, Akanksha Sheron, Bhavin Desai, David Eschliman, Glen Hawkins, James Kao, Andrew Gregory, Farouk Abushaban, Neelima Bawa, Courtney Llamas, Alvin Chyan, Suman Kumar Pramanik, Long Yang, Prasad Chebrolu, Bala Kuchibhotla, Daniel Tsao, Sanjay Ediga, Amitabh Khare, Mohammed Nazim, Rajesh Parasuraman, Maria Teresa Gil Lucientes, Asham Vohra.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Preface

Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide is an extension to Oracle Enterprise Manager Cloud Control Basic Installation Guide.

While the Oracle Enterprise Manager Cloud Control Basic Installation Guide covers basic installation procedures that help you get started with Enterprise Manager Cloud Control, the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide covers advanced installation procedures that help you install and configure the Enterprise Manager Cloud Control components in more complex environments.

This preface contains the following topics:

- Intended Audience

- Purpose of the Document

- Documentation Accessibility

- Related Documents

- Conventions

Intended Audience

Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide is meant for system administrators who want to install Enterprise Manager Cloud Control components in complex environments.

Purpose of the Document

Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide covers the following:

- Installing the following in graphical mode:

- Enterprise Manager Cloud Control software only so that you can configure it later

- Oracle Management Agent using a shared Oracle home

- Application Dependency and Performance (ADP) with advanced installation options

- JVM Diagnostics (JVMD) with advanced installation options

- Installing the following in silent mode:

- Enterprise Manager Cloud Control

- Enterprise Manager Cloud Control software only so that you can configure it later

- Additional Oracle Management Service

- Oracle Management Agent

- Oracle Management Agent software only so that you can configure it later

- Oracle Management Agent using a shared Oracle home

- Cloning Oracle Management Agent in graphical and silent mode

- Configuring advanced installation tasks such as configuring firewalls, sizing the Enterprise Manager deployment, and integrating BI publisher.

- Deinstalling Enterprise Manager Cloud Control and Oracle Management Agent in graphical and silent mode

Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide does NOT cover the following procedures. These procedures are documented in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- Installing Enterprise Manager Cloud Control in graphical mode

- Installing an additional Oracle Management Service in graphical mode

- Installing Oracle Management Agent in graphical mode

- Installing JVM Diagnostics and Application Dependency and Performance with default installation options

Also, Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide does NOT cover the procedure for upgrading your existing Enterprise Manager system. The upgrade procedure is documented in the Oracle Enterprise Manager Cloud Control Upgrade Guide.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

For more information, see the following books in the Enterprise Manager Cloud Control documentation library:

- Oracle Enterprise Manager Cloud Control Basic Installation Guide

- Oracle Enterprise Manager Cloud Control Upgrade Guide

- Oracle Enterprise Manager Cloud Control Administrator's Guide

For the latest releases of these and other Oracle documentation, check the Oracle Technology Network at the following URL:

http://www.oracle.com/technetwork/indexes/documentation/index.html

Enterprise Manager also provides extensive online Help. Click Help at the top-right corner of any Cloud Control page to display the online help window.

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Part I

Getting Started

This part describes how you can procure the Enterprise Manager Cloud Control software and the Oracle Management Agent software, and explains some key concepts you must know before you start using Enterprise Manager Cloud Control. In particular, this part contains the following chapters:

- Chapter 1, "Procuring Software"

- Chapter 2, "Understanding the Basics"

1 Procuring Software

This chapter describes how you can procure the Enterprise Manager Cloud Control software and the Oracle Management Agent software. In particular, this chapter covers the following:

- Releases Available for Enterprise Manager Cloud Control

- Procuring Enterprise Manager Cloud Control Software

- Procuring Oracle Management Agent Software

Releases Available for Enterprise Manager Cloud Control

Table 1-1 describes the releases Enterprise Manager Cloud Control has had so far.

Table 1-1 Enterprise Manager Cloud Control Releases

Release Numbers

Release Type

Release Date

Implementation Method

Description

Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2)

Patch Set 1 [PS1]

August 2012

- New installation of 12c Release 2 (12.1.0.2)

- Upgrade from 12c Release 1 (12.1.0.1), with or without BP1.

The first patch set containing several bug fixes, enhancements, and new features. Applied on the following:

- Base release, that is, Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) that was released in October 2011.

- Base release with BP1 applied, that is, Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1), which was released in October 2011, with BP1 applied on it.

- BP1 release, that is, Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) that was released in January 2012.

Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1)

Bundle Patch 1 [BP1]

January 2012

- New installation of 12c Release 1 (12.1.0.1) containing BP1.

- Patching of the base release, that is, 12c Release 1 (12.1.0.1)

A bundle patch containing several bug fixes and support for ported platforms. Applied on the base release, that is, Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) that was released in October 2011.

Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1)

Base Release

October 2011

- New installation of 12c Release 1 (12.1.0.1)

- Upgrade from 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1)

The first ever 12c release.

Note:
For more information on these releases and the platforms they support, access the Enterprise Manager Cloud Control Certification Matrix. For instructions to access this matrix, refer to the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Procuring Enterprise Manager Cloud Control Software

You can procure the Enterprise Manager Cloud Control software from either the product DVD or the Oracle Technology Network (OTN) Web site. This section describes these sources and covers the following:

- How Do You Access the Software from DVD?

- How Do You Procure the Software from Oracle Technology Network?

How Do You Access the Software from DVD?

You can obtain the Enterprise Manager Cloud Control software from the product DVD that is available through Oracle Service Delivery Managers or Oracle Sales Representatives. The software may be available either on a single DVD or on DVDs depending on the operating system.

This section covers the following:

- Accessing Software from DVD

- Setting Mount Point for DVD

Accessing Software from DVD

If the software is available on a single DVD, then insert the DVD into the DVD drive, and manually run the Enterprise Manager Cloud Control Installation Wizard.

If the software is available on DVDs, then copy the archived software from each of the DVDs to a location on your local disk. Extract the contents of each of the archived files to the same location. Then, invoke the Enterprise Manager Cloud Control Installation Wizard.

For example, Oracle delivers three DVDs for Linux x86 and x86_64, mainly these:

DVD1, containing a ZIP file with the name em12_linux_disk1of3.zip

DVD2, containing a ZIP file with the name em12_linux_disk2of3.zip

DVD3, containing a ZIP file with the name em12_linux_disk3of3.zip

In this case, copy the three ZIP files to a location on your disk, for example, /temp, and then extract their contents in the same location.

WARNING:

Extracting the contents to different locations will cause the installation to fail.

$ cp -r em12_linux_disk1of3.zip /temp

$ cp -r em12_linux_disk2of3.zip /temp

$ cp -r em12_linux_disk3of3.zip /temp

$ cd /temp

$ unzip em12_linux_disk1of3.zip

$ unzip em12_linux_disk2of3.zip

$ unzip em12_linux_disk3of3.zip

Once the contents are extracted, you can invoke the Enterprise Manager Cloud Control Installation Wizard. To do so, on UNIX platforms, invoke runInstaller, and on Microsoft Windows platforms, invoke setup.exe.

Note:
For information about the Enterprise Manager Cloud Control Installation Wizard, see What Is Enterprise Manager Cloud Control Installation Wizard?.

Setting Mount Point for DVD

If you want to access the DVD from a shared DVD drive, then set a mount point for the DVD drive.

On most Linux operating systems, the disk mounts automatically when you insert the DVD into the DVD drive. However, for some Linux operating systems, you might have to manually mount the disk. To verify whether the disk mounts automatically and to manually mount the disk if it does not mount itself automatically, follow these steps:

1. Insert the DVD into the disk drive.

2. To verify if the disk is automatically mounted, run the following command:

- On Red Hat Enterprise Linux:
# ls /mnt/cdrom

- On SUSE Linux Enterprise Server:
# ls /media/cdrom

3. If the command in Step (2) fails to display the contents of the disk, then run the following command:

- On Red Hat Enterprise Linux:
# mount -t nfs <host name>:/mnt/<full path to the dvdrom>

- On SUSE Linux Enterprise Server:
# mount -t nfs <host name>:/media/<full path to the dvdrom>

On most AIX operating systems, the disk mounts automatically when you insert the DVD into the DVD drive. However, for some AIX operating systems, you might have to manually mount the disk. To manually mount the disk if it does not mount itself automatically, follow these steps:

1. Switch the user to root user by running the following command:
$ su -root

2. Insert the disk into the drive.

Note:
If required, enter the following command to eject the currently mounted disk and to remove it from the drive:
# /usr/sbin/umount /<SD_DVD>

3. Enter the following command:
# /usr/sbin/mount -rv cdrfs /dev/cd0 /SD_DVD

In this example command, /SD_DVD is the disk mount point directory and /dev/cd0 is the device name for the disk device.

4. If you are prompted to specify the disk location, then specify the disk mount point directory path. For example, /SD_DVD

How Do You Procure the Software from Oracle Technology Network?

You can procure the Enterprise Manager Cloud Control software from OTN. The software available on OTN is archived using Info-ZIP's highly portable ZIP utility. The software is available in ZIP files. After downloading the software, you will need the UNZIP utility to extract the files.

This section covers the following:

- Downloading Software

- Verifying File Size

- Extracting Contents

- Verifying Platform Information

Downloading Software

To download the Enterprise Manager Cloud Control software from OTN, access the following URL:

http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html

The software is available in ZIP files. Download the ZIP files to a common location on your local disk.

Verifying File Size

After downloading the ZIP files, run the cksum command against the files and check if the file checksum of the downloaded software is the same as the file checksum displayed on OTN.

The following is the format of the ZIP files:

em12_<platform>_diskNofM.zip (<value> bytes) (cksum - <value>)

Here, <platform> refers to the operating system, N refers to the ZIP file number, and M refers to the total number of ZIP files available for download. For example, em12_linux_disk1of3.zip, em12_linux_disk2of3.zip, em12_linux_disk3of3.zip.

The value (cksum - <value>) is the file checksum that you need to check. To check the file checksum of the first ZIP file, run the following command:

$ cksum em12_<platform>_diskNofM.zip

For example,

$ cksum em12_linux_disk1of3.zip

Extracting Contents

You must unzip the archive on the platform for which it was intended. For example, if you download the software for the Linux x86 operating system, then you must unzip the file on a Linux x86 operating system only. If you unzip the file on a Microsoft Windows computer and then move the stage area to a Linux computer, then the staged area files will get corrupted. This is because Microsoft Windows does not preserve the case sensitivity or the permission bits of Linux file names.

If you have downloaded a single ZIP file, then extract the contents of it and manually run the Enterprise Manager Cloud Control Installation Wizard.

Note:
For information about the Enterprise Manager Cloud Control Installation Wizard, see What Is Enterprise Manager Cloud Control Installation Wizard?.

If you have downloaded ZIP files to a common location, then extract the contents of all the ZIP files in the same location, and then manually run the Enterprise Manager Cloud Control Installation Wizard.

WARNING:

Extracting the contents to different locations will cause the installation to fail.

Tip:
If you plan to store the files on a DVD, then first extract the contents of the ZIP file, and then copy those extracted files to the DVD. Do NOT copy the ZIP file itself; you need the unzipped contents of the ZIP file to install the product.

Verifying Platform Information

After extracting the contents of the ZIP file, access the following file to verify the platform information. Here, <Software_Location> can be either the DVD mount point or the location on your local disk where you have extracted the contents of the ZIP files.

<Software_Location>/stage/shiphomeproperties.xml

Note that a 32-bit Enterprise Manager Cloud Control software (both Enterprise Manager Cloud Control and Oracle Management Agent) can be installed only on a 32-bit operating system that is running on a 32-bit hardware. Similarly, a 64-bit Enterprise Manager software can be installed only on a 64-bit operating system that is running on a 64-bit hardware.

Do NOT try to install a 32-bit software on a 64-bit platform or vice versa; the installation may proceed, but will fail eventually. Therefore, ensure that you use the right software download for the right platform.

The shiphomeproperties.xml file provides the platform information as shown here:

<?xml version="1.0" standalone="yes" ?>
<ORACLEHOME_INFO>
<ARU_PLATFORM_INFO>
<ARU_ID>46</ARU_ID>
<ARU_ID_DESCRIPTION>Linux x86</ARU_ID_DESCRIPTION>
</ARU_PLATFORM_INFO>
</ORACLEHOME_INFO>

You can see the platform information in the <ARU_ID_DESCRIPTION> syntax. Table 1-2 lists the platform names that may be enclosed in this syntax, and describes whether the names represent a 32-bit or 64-bit software.

Table 1-2 Verifying Platform Information

Platform Name

Platform Specified in ARU_ID_DESCRIPTION

32-bit / 64-bit

Linux x86

Linux x86

32-bit

Microsoft Windows (32-bit)

Win 32

32-bit

Microsoft Windows (64-bit AMD64)

win 64

64-bit

Microsoft Windows (64-bit IA)

Windows Itanium

64-bit

Solaris Operating System (SPARC 64-bit)

Solaris

64-bit

HPUX PA-RISC(64-bit)

HPUNIX

64-Bit

AIX

AIX

64-bit

HP_IA64

HPI

64-bit

Linux x86-64

Linux AMD

64-bit

linux_ia64

Linux Itanium

64-bit

IBM Power Based Linux

Linux PPC

64-bit

linux_zseries64

zLinux

64-bit

HP Tru64 UNIX

Decunix

64-bit

Solaris Operating System (x86-64)

Solaris AMD64

64-bit

Solaris Operating System (x86)

Solaris AMD32

32-bit

Procuring Oracle Management Agent Software

Oracle Management Agent (Management Agent) is one of the core components of Enterprise Manager Cloud Control, and therefore, its software is part of the Enterprise Manager Cloud Control software. When you install Enterprise Manager Cloud Control, the installation wizard automatically installs a Management Agent.

You can install additional Management Agents using the Add Host Targets Wizard built into the Enterprise Manager Cloud Control console (Cloud Control console). The wizard uses the Management Agent software that is already present in the OMS home.

However, note that the Management Agent software present in the OMS home is always for the version and platform on which that OMS is running. For example, if the OMS is Oracle Management Service 12c and it is running on Linux platform, then the Management Agent software available there is also for Linux platform.

If you want to install a Management Agent for a platform that is different from the one on which the OMS is running, then ensure that you download that software using the Self Update Console, which is built into the Cloud Control console.

For information on Self Update and how you can use it to download the software, see the chapter on updating Cloud Control in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

Note:
The Management Agent software is not available on OTN, so the only way you can download the software is using the Self Update Console.

2 Understanding the Basics

This chapter introduces you to some key concepts of Enterprise Manager Cloud Control, and describes some important aspects of installation that you must know before you proceed any further.

In particular, this chapter covers the following:

- Understanding Installation Basics

- Understanding Oracle WebLogic Server Requirement

- Understanding Installation Directories

- Understanding Additional Components Installed

- Understanding Configuration Assistants

- Understanding Prerequisite Checks

- Understanding Limitations of Enterprise Manager Cloud Control

- Understanding Other Miscellaneous Concepts

Understanding Installation Basics

This section describes the fundamental aspects of the installation process. In particular, this section covers the following:

- What Different Installation Modes Can You Use?

- What Is Enterprise Manager Cloud Control Installation Wizard?

- What Installation Types Are Offered by the Installation Wizard?

- What is a Deployment Size?

- What Is Add Host Target Wizard?

- What Is Add Management Service Deployment Procedure?

- What Ports Are Used for Installation?

- What Data Files Are Created While Configuring Oracle Management Repository?

- How Do You Delete Data Files?

What Different Installation Modes Can You Use?

You can install Enterprise Manager Cloud Control or any of its core components either in an interactive, graphical mode or in a silent mode.

Graphical Mode

Graphical mode is the Graphical User Interface (GUI) method that involves usage of a Java-based installation wizard or a browser-based application that is built into and accessed from the Enterprise Manager Cloud Control console. This method is best suited for first-time installations because you are guided through the entire installation process and your installation details are captured using the interview screens.

Silent Mode

Silent method involves usage of Oracle-supplied response files or scripts that capture all the information required for installation. This method is simpler and faster, but requires you to have some knowledge on the installation process so that you can provide your installation details in the response files without having to see the interview screens of the installation wizard.

In both these modes, you can perform a software-only installation. A Software-Only installation is an approach that enables you to install only the software binaries of Enterprise Manager Cloud Control or a Management Agent, that is, without any configuration to the installation. This is best suited when you want to install the software at one point and configure it later.

What Is Enterprise Manager Cloud Control Installation Wizard?

Enterprise Manager Cloud Control Installation Wizard is a Java-based wizard that helps you install or upgrade to Enterprise Manager Cloud Control in graphical mode. If you are installing Enterprise Manager Cloud Control or any of its core components for the first time, then Oracle strongly recommends you to use this installation wizard.

Note:
To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

Figure 2-1 describes the key elements of the installation wizard.

Figure 2-1 Enterprise Manager Cloud Control Installation Wizard

What Installation Types Are Offered by the Installation Wizard?

The Enterprise Manager Cloud Control Installation Wizard offers the following installation types:

- Create a New Enterprise Manager System

- Upgrade an Existing Enterprise Manager System

- Install Software Only

Create a New Enterprise Manager System

This installation type enables you to install a new Enterprise Manager Cloud Control system with either simple or advanced configuration settings. For information about simple and advanced installation types, refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide.

For information about what is installed for both simple and advanced installation types, refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Upgrade an Existing Enterprise Manager System

This installation type enables you to upgrade the following to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2):

- Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1)

- Enterprise Manager 11g Grid Control Release 1 (11.1.0.1)

- Enterprise Manager 10g Grid Control Release 5 (10.2.0.5)

For upgrading Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) and Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), you can select one of the following approaches. However, for upgrading Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1), you can select only One System Upgrade approach.

- One System Upgrade, enables you to upgrade to Enterprise Manager Cloud Control on the same host where your earlier release of Enterprise Manager is running. This approach also upgrades the Management Repository in the existing Oracle Database itself. Since the upgrade happens on the same host, there is a reasonable downtime involved.

- Two System Upgrade, enables you to install Enterprise Manager Cloud Control on a host that is different from the host where your existing Enterprise Manager system is running. This approach does not upgrade the Management Repository in the existing Oracle Database, but upgrades the one in the backed up database, thus offering the scope for two Enterprise Manager systems to exist. Since a new Enterprise Manager system coexists with the old one, there is no or near zero downtime involved.

Note:
For more information on these upgrade options, see the Oracle Enterprise Manager Cloud Control Upgrade Guide.

Install Software Only

This installation type enables you to install only the software binaries of Enterprise Manager Cloud Control at one point, and configure it at a later point.

This approach helps you divide the installation process into two phases, mainly the installation phase and the configuration phase. Understandably, the installation phase takes less time compared to the configuration phase because the installation phase involves only copying of binaries.

For information about what is installed during the installation phase and what is configured during the configuration phase, refer to Overview.

What is a Deployment Size?

When you install Enterprise Manager Cloud Control with advanced configuration settings (Advanced installation type), you have an option of selecting the deployment size of your choice. This option is available in both graphical mode (Enterprise Manager Cloud Control Installation Wizard) and silent mode (response file).

The deployment size essentially indicates the number of targets you plan to monitor, the number Management Agents you plan to have, and the number of concurrent user sessions you plan have.

Table 2-1 describes each deployment size.

Table 2-1 Deployment Size

Deployment Size

Targets Count

Management Agents Count

Concurrent User Session Count

Small

Up to 999

Up to 99

Up to 10

Medium

Between 1000 and 9999

Between 100 and 999

Between 10 and 24

Large

10,000 or more

1000 or more

Between 25 and 50

The prerequisite checks are run regardless of the selection you make, but the values to be set for the various parameters checked depend on the selection you make. For more information about these deployment sizes, and the database parameters set for each of them, refer to Chapter 11.

After installing Enterprise Manager Cloud Control with a particular deployment size, you can choose to increase or decrease the count of targets, Management Agents, or concurrent user sessions. However, if you do increase the count to a level that is not appropriate for the selected deployment size, then the performance might suffer. Under such circumstances, Oracle recommends you to modify the database parameters according to the desired deployment size, as described in Chapter 11.

What Is Add Host Target Wizard?

The Add Host Targets Wizard (Figure 2-2) is a GUI-rich application accessible from within the Cloud Control console, and used for installing Management Agents on unmanaged hosts and converting them to managed hosts in the Enterprise Manager system.

Using the Add Host Targets Wizard, you can do the following:

- Install a fresh Management Agent

- Clone an existing well-tested, pre-patched, and running Management Agent

- Install a Management Agent from an existing, centrally shared Management Agent

Figure 2-2 Add Host Target Wizard

Although the Add Host Targets Wizard can be used for remotely installing one Management Agent, the wizard is best suited for mass-deployment of Management Agents, particularly while mass-deploying Management Agents of different releases on hosts of different platforms. The wizard gives you the flexibility to select hosts on which you want to install a Management Agent. This helps you when you want to install the Management Agent on several hosts, in one attempt.

What Is Add Management Service Deployment Procedure?

A deployment procedure is a procedure that contains a hierarchal sequence of provisioning or patching steps, where each step may contain a sequence of other steps. In other words, the workflow of all tasks that need to be performed for a particular life cycle management activity is encapsulated in a deployment procedure.

Enterprise Manager Cloud Control offers deployment procedures, and all of these can be accessed from within the Cloud Control console. One of the deployment procedures that falls within the context of Enterprise Manager Cloud Control installation is the Add Management Service deployment procedure.

The Add Management Service deployment procedure (Figure 2-3) helps you meet high-availability requirements by enabling you to install an additional OMS using an existing OMS that is running on an AdminServer host.

Figure 2-3 Add Management Service Deployment Procedure

In simple words, the Add Management Service deployment procedure enables you to install additional OMS instances in your environment. The deployment procedure clones an existing OMS and replicates its configuration to the destination host.

The earlier releases of Enterprise Manager offered this installation type from the Enterprise Manager Installation Wizard. However, for the Enterprise Manager Cloud Control release, this installation type is offered as a deployment procedure.

For more information about the deployment procedure, see the chapter on adding additional management service in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

What Ports Are Used for Installation?

This section describes the default ports that are honored while installing Enterprise Manager Cloud Control. In particular, this section covers the following:

- What Default Ports Are Used?

- How Can You Customize Ports?

- What Precautions You Must Take While Customizing Port Numbers?

What Default Ports Are Used?

The following are the default ports used for installation:

- Enterprise Manager Cloud Control

Upload Port

Console Port

HTTP Port

4889
If 4889 is not available, then the first available free port from the range 4889 to 4898 is selected.

The first available free port from the range 7788 - 7798 is selected.

HTTPS Port

1159
If 1159 is not available, then the first available free port from the range 4899 to 4908 is selected.

The first available free port from the range 7799 - 7809 is selected.

- Oracle Management Agent
The default upload port for Management Agent is 3872. The same port is used for both HTTP and HTTPS. If 3872 is not available, then the first available free port from the range 1830 to 1849 is selected.

- Admin Server
The default HTTPS port for Admin Server is 7101. If 7101 is not available, then the first available free port from the range 7101 to 7200 is selected.

- Node Manager
The default HTTPS port for Node Manager is 7401. If 7401 is not available, then the first available free port from the range 7401 to 7500 is selected.

- Managed Server
The default HTTP port for Managed Server is 7201. If 7201 is not available, then the first available free port from the range 7201 to 7300 is selected.

The default HTTPS port for Managed Server is 7301. If 7310 is not available, then the first available free port from the range 7301 to 7400 is selected.

How Can You Customize Ports?

Enterprise Manager Cloud Control offers you the flexibility to use custom ports instead of default ports.

Customizing Ports While Installing Enterprise Manager Cloud Control

- If you are installing Enterprise Manager Cloud Control in graphical mode, that is, using the Enterprise Manager Cloud Control Installation Wizard, then you can use the Port Configuration Details screen to enter custom ports. You can also import a staticports.ini file that already captures the custom ports.

- If you are installing Enterprise Manager Cloud Control in silent mode, that is, using the installation procedures described in Part II, then update the staticports.ini file with suitable custom ports.
The staticports.ini file is available at the following location of the software kit (DVD, downloaded software, and so on):

<software_kit>/response/staticports.ini

Customizing HTTP/HTTPS Console and Upload Ports After Installing Enterprise Manager Cloud Control

If you want to change the HTTP/HTTPS console ports and upload ports after installing Enterprise Manager Cloud Control, then follow these steps:

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

2. Update the emgc properties with HTTP and HTTPS ports as described in Table 2-2. Specify the values for parameters <http_upload_new>, <https_upload_new>, <http_console_new>, and <https_console_new>):

Table 2-2 Updating EMOMS Properties with HTTP and HTTPS Ports

Port/Property Type

Command to Run

HTTP Upload Port

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.ConsoleServerPort -value <http_upload_new>

HTTPS Upload Port

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.ConsoleServerHTTPSPort -value <https_upload_new>

HTTP Console Port

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.EMConsoleServerPort -value <http_console_new>

HTTPS Console Port

<OMS_Home>/bin/emctl set property -name oracle.sysman.emSDK.svlt.EMConsoleServerHTTPSPort -value <https_console_new>

3. Back up the following file:
$<OMS_INSTANCE_HOME>/emgc.properties

After backing up the file, open the original emgc.properties file, and specify the new port numbers for the following parameters:

EM_UPLOAD_HTTP_PORT=<http_upload_new>
EM_UPLOAD_HTTPS_PORT=<https_upload_new>
EM_CONSOLE_HTTP_PORT=<http_console_new>
EM_CONSOLE_HTTPS_PORT=<https_console_new>

4. Back up the files httpd.conf, ssl.conf, and httpd_em.conf from the following location:
$<WEBTIER_INSTANCE_HOME>/config/OHS/ohs#/

After backing up the files, open the original files, and specify the new port numbers:

- In httpd.conf file, in the Listen directive, replace <http_console_orig> with <http_console_new>.

- In ssl.conf file, in the Listen directive, replace <https_console_orig> with <https_console_new>.

- In httpd_em.conf file, in the Listen and VirtualHost directive, replace <http_upload_orig> with <http_upload_new>, and <https_upload_orig> with <https_upload_new>, respectively.

5. Start the OMS, and verify its status:
$<OMS_HOME>/bin/emctl start oms

$<OMS_HOME>/bin/emctl status oms -details

6. If the OMS is configured with any Server Load Balance (SLB), then update the ports in the SLB pools, monitors, and so on.

7. If the OMS is configured for SSO or OAM, then re-run the SSO or OAM configuration.

8. Back up the following file:
$<AGENT_INSTANCE_HOME>/sysman/config/emd.properties

Note:
Back up the emd.properties file from all Management Agents that are communicating with the OMS.

After backing up the file, open the original emd.properties file, and verify the URL mentioned in REPOSITORY_URL. If the URL is an HTTPS URL, then change the port number to <https_upload_new>. If the URL is an HTTP URL, then change the port number to <http_upload_new>.

9. If there are any EM CLI instances set up on the ports you have changed, then set up those instances again. To do so, from each EM CLI instance, run the command emcli setup or emcli status, and note the EM URL that appears.
If you have changed that port number, run the following command:

emcli setup -url=http(s)://<host>:<new_port#>/em -dir=<dir>....

What Precautions You Must Take While Customizing Port Numbers?

While updating the staticports.ini file, you must be extremely careful because an error in the file can cause the installation wizard to use default ports without displaying any warning. Therefore, before updating the staticports.ini file, check for these points:

- Always enter port numbers that are greater than 1024 and less than 65536.

- If a port is already being used by a component or any other application, do not enter that port (used port) in the staticports.ini file. If you do, then the related configuration assistant also fails.

- If you have entered the same port for more than one component, then the installation displays an error after the prerequisite checks phase. You must rectify this error before proceeding with the installation.

- If you have syntax errors in the staticports.ini file (for example, if you omitted the equal (=) character for a line), then the installation wizard ignores the line. For the components specified on such lines, the installation wizard assigns the default ports. The installation wizard does not display a warning for lines with syntax errors.

- If you misspell a component name, then the installation wizard assigns the default port for the component. Names of components in the file are case-sensitive. The installation wizard does not display a warning for lines with unrecognized names.

- If you enter a nonnumeric value for the port number, then the installation wizard ignores the line and assigns the default port number for the component. It does this without displaying any warning.

- If you misspell the parameter on the command line, then the installation wizard does not display a warning. It continues and assigns default ports to all components.

- If you enter a relative path to the staticports.ini file (for example, ./staticports.ini) in the command line, then the installation wizard does not find the file. It continues without displaying a warning and it assigns default ports to all components. You must enter a full path to the staticports.ini file.

What Data Files Are Created While Configuring Oracle Management Repository?

The following are the data files created while configuring Oracle Management Repository:

mgmt.dbf

Stores information about the monitored targets, their metrics, and so on.

mgmt_ecm_depot1.dbf

Stores configuration information collected from the monitored targets.

mgmt_ad4j.dbf

Stores monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).

How Do You Delete Data Files?

To delete the data files, you must drop the SYSMAN/MDS schema. To do so, run the following command from the OMS home.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_home> -oracleHome <oms_home>

Note:

- For Microsoft Windows, invoke RepManager.bat.

- If you are dropping the schemas that belong to a 10g Release 2 (10.2.x.x) Management Repository, then run previous command without these arguments:
-mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <OMS_HOME>

After dropping the schema, manually delete the database files mgmt.dbf and mgmt_ecm_depot1.dbf.

You can find these files by running the following command as SYS:

SELECT FILE_NAME FROM DBA_DATA_FILES WHERE UPPER (TABLESPACE_NAME) LIKE 'MGMT%';

Table 2-3 describes the -action options that are supported by the different versions of RepManager.

Table 2-3 RepManager Support for -action dropall Command

RepManager Version

Command Supported

RepManager 12.1

- -action dropall
Drops SYSMAN, SYSMAN_MDS, APM, OPSS, EMRUNTIME, and SYSMAN_RO.

- -action drop
Drops only SYSMAN.

RepManager 11.1

- -action dropall
Drops only SYSMAN and SYSMAN_MDS.

- -action drop
Drops only SYSMAN.

RepManager 10.2.0.5

-action drop

Drops only SYSMAN.

Understanding Oracle WebLogic Server Requirement

Enterprise Manager Cloud Control requires Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24+.

If Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24+ are NOT already installed in your environment, then the installation wizard automatically installs them for you while installing a new Enterprise Manager Cloud Control.

This section describes some important aspects related to Oracle WebLogic Server that you must know before you install Enterprise Manager Cloud Control.

In particular, this section covers the following:

- How Do I Verify Whether Oracle WebLogic Server Is Installed?

- Is Oracle WebLogic Server Cluster Supported?

- If Oracle WebLogic Server Already Exists, Is the Existing Domain Used?

- When and Why Do You Need Oracle WebLogic Server Credentials?

- When and Why Do You Need Node Manager Credentials?

- How Do You Find Admin Server Port After Installing Enterprise Manager?

- How Do You Verify Whether Admin Server Is Running?

- How Do You Start Admin Server?

How Do I Verify Whether Oracle WebLogic Server Is Installed?

To verify whether Oracle WebLogic Server is installed, check the following file in the Oracle WebLogic Server home:

$<WLS_HOME>/logs/log.txt

The following is the sample output of the log.txt file:

release  10.3.5.0 [Added]
|_____Common Infrastructure Engineering 7.1.0.0 [Added]
|    |_____Uninstall [Added]
|    |_____Patch Client [Added]
|    |_____Patch Attachment Facility [Added]
|    |_____Clone Facility [Added]
|_____WebLogic Server 10.3.5.0 [Added]
|    |_____Core Application Server [Added]
|    |_____Administration Console [Added]
|    |_____Configuration Wizard and Upgrade Framework [Added]
|    |_____Web 2.0 HTTP Pub-Sub Server [Added]
|    |_____WebLogic SCA [Added]
|    |_____WebLogic JDBC Drivers [Added]
|    |_____Third Party JDBC Drivers [Added]
|    |_____WebLogic Server Clients [Added]
|    |_____WebLogic Web Server Plugins [Added]
|    |_____UDDI and Xquery Support [Added]
|    |_____Server Examples [Added]
|    |_____Evaluation Database [Added]
|    |_____Workshop Code Completion Support [Added]
|_____Oracle Configuration Manager 10.3.3.1 [Added]
|    |_____Data Collector [Added]
|_____Oracle Coherence 3.6.0.3 [Not Installed]
|_____Coherence Product Files [Not Installed]
|_____Coherence Examples [Not Installed]

Is Oracle WebLogic Server Cluster Supported?

Oracle WebLogic Server cluster consists of Oracle WebLogic Servers running simultaneously and working together to provide increased scalability and reliability. A cluster appears to be a single Oracle WebLogic Server instance. The server instances that constitute a cluster can run on the same host, or be located on different hosts.

You can install Enterprise Manager Cloud Control on an Oracle WebLogic Server Cluster, however, you cannot take advantage of the cluster configurations.

If Oracle WebLogic Server Already Exists, Is the Existing Domain Used?

If Oracle WebLogic Server already exists, then the existing domain is NOT used. Instead, the Enterprise Manager Cloud Control Installation Wizard creates a new domain and deploys the Enterprise Manager Cloud Control software to it.

When and Why Do You Need Oracle WebLogic Server Credentials?

While installing or upgrading to Enterprise Manager Cloud Control, you are prompted to enter the Oracle WebLogic Server credentials (user name and password). The credentials are used for creating the WebLogic domain and other associated components such as the Admin Server, the managed server, and the node manager.

The WebLogic user name is the default user name that will be used as the administrative user for the WebLogic Domain. By default, the user name is weblogic. And the WebLogic password is the password for this default administrative user account.

When and Why Do You Need Node Manager Credentials?

While installing or upgrading to Enterprise Manager Cloud Control, you are prompted to enter the Node Manager password for the default Node Manager user account, which is nodemanager. The password is used for configuring the Node Manager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

How Do You Find Admin Server Port After Installing Enterprise Manager?

To find the Admin Server port, view the value set for the AS_HTTPS_PORT parameter in the emgc.properties file. This file is available in the Oracle Management Service Instance Base location.

For example,

/DATA/oracle/Middleware/gc_inst/em/EMGC_OMS1/emgc.properties

How Do You Verify Whether Admin Server Is Running?

To install an additional OMS, the Admin Server that is used by the first OMS must be up and running. To verify whether the Admin Server is running, access the Admin Server console using the following URL:

https://host:port/console

Here, host and port are values specified in the EM_INSTANCE_HOST and AS_HTTPS_PORT parameters, respectively, in the emgc.properties file. This properties file is available in the following location, that is, in the OMS home (first OMS) that was initially installed:

$<MIDDLEWARE_HOME>/gc_inst/em/EMGC_OMS1/emgc.properties

How Do You Start Admin Server?

You can start the Admin Server by running the following command. Although the command is used essentially to start the OMS, the command in turn starts the Admin Server on which that OMS is running. So run this command even if you know that the OMS is already running.

emctl start oms

Understanding Installation Directories

This section describes the installation directories that need to be entered while installing Enterprise Manager Cloud Control or any of its core components. In particular, this section covers the following:

- What Is Oracle Inventory Directory?

- What Is Oracle Middleware Home?

- What Is Oracle Management Service Instance Base Location?

- What Is Oracle Home?

- What Is Agent Base Directory?

- What is Agent Instance Directory?

- What Is /TMP C:\Temp Directory Used For?

What Is Oracle Inventory Directory?

If Enterprise Manager Cloud Control is the first Oracle product that you are installing, then the Enterprise Manager Cloud Control Installation Wizard prompts you to enter an inventory directory (also called the oraInventory directory).

This inventory directory is used by the installation wizard to place all the installer files and directories on the host. The installation wizard automatically sets up subdirectories for each Oracle product to contain the inventory data.

You can enter the oraInventory directory in two ways:

- While installing Enterprise Manager Cloud Control using the installation wizard, you can enter the oraInventory directory in the Oracle Inventory screen. When you enter it in this screen, you must also select the appropriate operating system group name that will own the oraInventory directories. The group you select must have write permission on the oraInventory directories.

- While installing Enterprise Manager Cloud Control in silent mode, that is, without using the installation wizard, you can enter the oraInventory directory using the -invPtrLoc parameter. This parameter considers the path to a location where the inventory pointer file (oraInst.loc) is available. However, this parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.
For example

./runInstaller -invPtrLoc /scratch/OracleHomes/oraInst.loc

Note:
Ensure that the oraInventory directory is not in a shared location. If it is, change it to a non-shared location.

If you already have an Oracle product installed on the host, then the installation wizard uses the existing oraInventory directory that was created while installing that Oracle product. Ensure that you have write permission on that directory. To do so, run the installer as the same operating system user as the one who installed the other Oracle product.

Note:
The oraInventory directory is different from Installation Directory. For information about Installation Directory, see What Is Oracle Middleware Home?.

What Is Oracle Middleware Home?

While installing or upgrading to Enterprise Manager Cloud Control, you are required to enter the Oracle Middleware home.

Oracle Middleware home (Middleware home) is the parent directory that has the Oracle WebLogic Server home, the Java Development Kit, the Web tier instance files, one or more Oracle homes, the OMS instance base directory, and other relevant files. This is where the OMS and the plug-ins are deployed.

For example,

/u01/app/Oracle/Middleware

If you are installing or upgrading to Enterprise Manager Cloud Control, then:

- If Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24+ are already installed in your environment, then the installation wizard automatically detects them and displays the absolute path to the Middleware home where they are installed.
In this case, validate the Middleware home that is detected and displayed by default. If the location is incorrect, then enter the path to the correct location. Ensure that the Middleware home you select or enter is a Middleware home that does not have any Oracle homes for the OMS and the Management Agent.

- If Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24+ are NOT already installed in your environment, then the installation wizard automatically installs them for you while installing Enterprise Manager Cloud Control.
In this case, enter the absolute path to a directory where you want to have them installed. Ensure that the directory you enter does not contain any files or subdirectories.

For example,

/u01/app/Oracle/Middleware/

Note:
Oracle Middleware home is different from Oracle Home of OMS or Management Agent. For information about Oracle Home, see What Is Oracle Home?.

What Is Oracle Management Service Instance Base Location?

While installing Enterprise Manager Cloud Control, you are required to enter the Oracle Management Service Instance Base Location.

Oracle Management Service Instance Base Location is a directory (gc_inst) inside the Middleware home where the configuration files of the OMS are stored.

The installation wizard uses its built-in algorithm to identify this location, and displays it for you to validate. If the Middleware home is /u01/app/Oracle/Middleware/, then by default, the following is the Oracle Management Service Instance Base Location:

/u01/app/Oracle/Middleware/gc_inst

You can either accept the default location or specify another location that has write permission.

Note:
For information about Oracle Middleware home, see What Is Oracle Middleware Home?.

What Is Oracle Home?

Oracle Home or Oracle home is the directory where the OMS, the Management Agent, and the plug-ins are installed. Table 2-4 lists the default Oracle homes are created.

Table 2-4 Oracle Homes of OMS, Management Management Plug-Ins

Component

Default Oracle Home

Sample Location

Oracle Management Service

$<MIDDLEWARE_HOME>/oms

/u01/app/Oracle/Middleware/oms

Oracle Management Agent

$<AGENT_BASE_DIR>/core/12.1.0.2.0

/u01/app/Oracle/agent/core/12.1.0.2.0

Plug-In (OMS-specific plug-ins)

$<MIDDLEWARE_HOME>/plugins/<pluginID_Version>

/u01/app/Oracle/software/plugins/oracle.sysman.db.agent.plugin_12.1.0.2.0

Plug-In (agent-specific plug-ins)

$<AGENT_BASE_DIR>/plugins

/u01/app/Oracle/agent/plugins

Note:
Oracle Home is different from OraInventory. For information about OraInventory directory, see What Is Oracle Inventory Directory?.

What Is Agent Base Directory?

While installing Enterprise Manager Cloud Control and a standalone Management Agent using the Add Host Targets Wizard, you are required to enter an installation base directory, which is essentially the agent base directory.

Agent Base Directory is a directory outside the Oracle Mdidleware Home, where the Management Agent home is created.

For example, if the agent base directory is /u01/app/Oracle/agent, then the Management Agent home is created as /u01/app/Oracle/agent/core/12.1.0.2.0.

What is Agent Instance Directory?

Agent Instance Directory is a directory (agent_inst) created for storing all Management Agent-related configuration files.

Agent Instance Directory is created inside the agent base directory.

For example, if the agent base directory is /u01/app/Oracle/agent, then by default, the following is the agent instance directory:

/u01/app/Oracle/agent/agent_inst

What Is /TMP C:\Temp Directory Used For?

When you invoke the Enterprise Manager Cloud Control Installation Wizard, it automatically copies some executable files and link files to a temporary directory on the host.

For example, the default /tmp directory on UNIX hosts, and C:\Temp on Microsoft Windows hosts.

If the host is set to run cron jobs along with many other processes that may be running periodically, then these jobs attempt to clean up the default temporary directory, thereby deleting some files and causing the installation wizard to fail.

If there are any cron jobs or processes that are automatically run on the hosts to clean up the temporary directories, then ensure that you set the TMP or TEMP environment variable to a location that is different from the default location. Ensure that the non-default location you set is secure on the hard drive, that is, the non-default location is a location where cleanup jobs are not run. Also ensure that you have write permissions on this alternative directory.

This must be done before you run the installer to invoke the Enterprise Manager Cloud Control Installation Wizard. (For UNIX operating systems, you invoke runInstaller, and for Microsoft Windows, you invoke setup.exe).

Note:
Specifying an alternative temporary directory location is not mandatory, and is required only if any cron jobs are set on the computers to clean up the /tmp directory.

Understanding Additional Components Installed

This section describes the additional components that are installed along with the core components of Enterprise Manager Cloud Control. In particular, this section covers the following:

- What Is Oracle Configuration Manager?

- What Are Software Updates?

What Is Oracle Configuration Manager?

With Enterprise Manager Cloud Control, you can choose to enable Oracle Configuration Manager. Alternatively, you can enable it after installing Enterprise Manager Cloud Control.

Oracle Configuration Manager automatically collects configuration information from your environment at regular intervals and uploads it to Oracle repository. This helps Oracle maintain up-to-date information about your environment, identify security vulnerabilities, quickly diagnose support issues, and offer better solutions consistently.

However, no business or personal information is collected and uploaded, except for local contact name in the event of transmission problems. Oracle guarantees that all the information collected will be kept strictly confidential and under no circumstances will this information be shared with any other party.

Oracle recommends that the host from where you are running the installation wizard have a connection to the Internet so that the configuration information can be automatically collected and uploaded to My Oracle Support.

If the host from where you are running the installation wizard has a connection to the Internet, then on the Oracle Configuration Manager screen of the installation wizard, enter the My Oracle Support user name (or e-mail address) and password.

Otherwise, enter only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information.

If you want to enable it after installing Enterprise Manager Cloud Control, then see Enabling Oracle Configuration Manager After Installing Enterprise Manager Cloud Control.

Manually Collecting and Uploading Configuration Information

To manually collect the configuration information, follow these steps:

1. Navigate to the OMS home and run the following command:
$<OMS_HOME>/ccr/bin/emCCR collect

For Oracle Configuration Manager 10.2.7 and higher, the collected configuration information is stored in the /ccr/hosts/state/upload/ocmconfig.jar file. For lower versions of Oracle Configuration Manager, the collected configuration information is stored in the /ccr/state/upload/ocmconfig.jar file. When you run the same command next time, the ocmconfig.jar file gets overwritten with fresh data. Therefore, at any point, you will see only one ocmconfig.jar file.

2. Upload the ocmconfig.jar file to a Service Request on My Oracle Support.

3. Repeat Step (1) and Step (2) from the Management Agent home.

Enabling Oracle Configuration Manager After Installing Enterprise Manager Cloud Control

To enable Oracle Configuration Manager at a later point, do the folllowing:

1. Set the environment variable ORACLE_CONFIG_HOME to the Oracle Management Service instance base directory. Oracle Management Service instance base is the directory where the configuration files of the OMS are created.

- In bash terminal, run the following command:
export ORACLE_CONFIG_HOME=<absolute_path_to_gc_inst>

- In other terminals, run the following command:
setenv ORACLE_CONFIG_HOME <absolute_path_to_gc_inst>

Note:
For information about Oracle Management Service instance base directory, refer to What Is Oracle Management Service Instance Base Location?.

2. From the OMS home, run the following command:
$<OMS_HOME>/ccr/bin/setupCCR

What Are Software Updates?

While installing or upgrading Enterprise Manager Cloud Control, you can choose to install software updates.

Software updates include interim patches, critical patch updates, prerequisite updates, install updates, and so on released by Oracle periodically.

How Can You Download the Software Updates?

You can either manually download the software updates or have the Enterprise Manager Cloud Control Installation Wizard automatically download them for you.

- Manual Download by User: If you choose to manually download the software updates yourself, then invoke the Enterprise Manager Cloud Control Installation Wizard with the -downloadUpdates argument in the following way. This argument ensures that the installation wizard is invoked only for downloading the software updates.
./runInstaller -downloadUpdates

On the Software Updates screen, enter the My Oracle Support account user name and password, and click Search for Updates. The installation wizard downloads the software updates to scratchPath/updates directory.

Manual download option is best suited when you are installing Enterprise Manager Cloud Control in silent mode. Oracle recommends you to use this option even while installing in graphical mode.

- Automatic Download by Installation Wizard: If you choose to have the Enterprise Manager Cloud Control Installation Wizard automatically download the software updates, then on the Software Updates screen of the installation wizard, enter the My Oracle Support account user name and password. The installation wizard will connect to My Oracle Support and automatically download the updates from there.

When Can You Apply the Software Updates?

You can apply the software updates in one of the following ways depending on the download mechanism:

- Manual Download by User: If you have manually downloaded the software updates, then:

- In Graphical Mode: On the Software Updates screen of the installation wizard, select Search for Updates, and then, select Local Directory. Enter the location where the updates are available, and click Search for Updates. To search the computer and select the location, click Browse.

- In Silent Mode: Before you invoke the installer using the response file, edit the response file to set the INSTALL_UPDATES_SELECTION parameter to "staged". Then, for the STAGE_LOCATION parameter, enter the absolute path to the location where the updates are available.

- Automatic Download by Installation Wizard: If you want to automatically download and apply the software updates from My Oracle Supoprt, then:

- In Graphical Mode: On the Software Updates screen of the installation wizard, select Search for Updates, then select My Oracle Support. Enter the My Oracle Support account user name and password, and click Search for Updates. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch.

- In Silent Mode: Before you invoke the installer using the response file, edit the response file to set the INSTALL_UPDATES_SELECTION parameter to "download". Then, enter your My Oracle Support credentials in the MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES and the MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES parameters.

Oracle strongly recommends you to apply them while the installation is in progress for the following reasons:

- Keeping track of the availability of software updates at the time of installation is difficult

- Keeping track of the patch numbers, and manually downloading them and applying them after installation is a cumbersome process

Automatically downloading and applying the software updates during installation saves time and effort, and ensures that you do not miss out on important software updates.

Understanding Configuration Assistants

This section describes the postinstallation activities that are performed by the installation wizard. In particular, this section covers the following:

- What Are Configuration Assistants?

- What Configuration Assistants Are Run by the Installation Wizard?

- What Do You Do When Configuration Assistants Fail?

What Are Configuration Assistants?

While installing or upgrading to Enterprise Manager Cloud Control in either GUI mode (using the installation wizard) or silent mode (using a response file), a set of configuration assistants are run at the end of the installation process to configure the installed or upgraded components. Your installation or upgrade process is complete only after all the components are configured using these configuration assistants.

Note:
Even when you perform a software-only installation of Enterprise Manager, when you run the ConfigureGC.sh script to configure the installation, the configuration assistants are internally run. (On Microsoft Windows, run the ConfigureGC.bat script.)

What Configuration Assistants Are Run by the Installation Wizard?

This section lists the configuration assistants run by the installation wizard for the different installation types.

- Configuration Assistants Run While Installing a New Enterprise Manager

- Configuration Assistants Run While Upgrading an Existing Enterprise Manager

- Configuration Assistants Run While Upgrading an Additional Oracle Management Service

Configuration Assistants Run While Installing a New Enterprise Manager

The following are the configuration assistants that are run while installing a new Enterprise Manager, that is, when you select Create a new Enterprise Manager System in the installation wizard.

- Plugins Prerequisites Check Configuration Assistant

- Repository Configuration Assistant

Note:
If you use a database instance that was created with a preconfigured Management Repository using the database templates offered by Oracle, then Repository Out-of-Box Configuration Assistant is run instead of Repository Configuration Assistant.

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Agent Configuration Assistant

Configuration Assistants Run While Upgrading an Existing Enterprise Manager

The following are the configuration assistants that are run while upgrading an existing Enterprise Manager, that is, when you select Upgrade an existing Enterprise Manager System in the installation wizard.

1-System Upgrade Approach

- Plugins Prerequisites Check Configuration Assistant

- Repository Upgrade Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

In addition, while upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), the following are run:

- Stopping APM Engines Configuration Assistant

- Stop Admin Server Configuration Assistant

Note:
Agent Configuration Assistant is not run because the Management Agent is not upgraded as it is either predeployed by the Enterprise Manager 12c Upgrade Console (for 10.2.0.5 or 11.1 Management Agents) or upgraded using the Upgrade Agents Console (for 12.1.0.1 Management Agents).

2-System Upgrade Approach

- Plugins Prerequisites Check Configuration Assistant

- Repository Upgrade Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Agent Configuration Assistant

1-System Upgrade Approach on a Different Host

- Plugins Prerequisites Check Configuration Assistant

- Repository Upgrade Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Agent Configuration Assistant

Configuration Assistants Run While Upgrading an Additional Oracle Management Service

The following are the configuration assistants that are run while upgrading an additional OMS, that is, when you select Upgrade an existing Enterprise Manager System, then select an additional OMS in the installation wizard.

1-System Upgrade Approach

- Plugins Prerequisites Check Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

In addition, while upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), the following are run:

- Stopping APM Engines Configuration Assistant

- Stop Admin Server Configuration Assistant

Note:
The Agent Configuration Assistant is not run because the Management Agent is not upgraded as it is either predeployed by the Enterprise Manager 12c Upgrade Console (for 10.2.0.5 or 11.1 Management Agents) or upgraded using the Upgrade Agents Console (for 12.1.0.1 Management Agents).

1-System Upgrade Approach on a Different Host

- Plugins Prerequisites Check Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

What Do You Do When Configuration Assistants Fail?

If an optional configuration assistant fails, then the installation wizard ignores the failure and runs to the next configuration assistant automatically. However, if a mandatory configuration assistant fails, then the installation wizard stops the installation process. In this case, you are expected to resolve the issue and rerun the configuration assistant.

For information about the log files to review when a configuration assistant fails, and the actions to be taken to resolve the issue, see Appendix G.

Understanding Prerequisite Checks

Every time you install Enterprise Manager Cloud Control using the installation wizard, a set of prerequisite checks are run to verify if the environment meets the minimum requirements for a successful installation. The installation wizard checks for a variety of things including required operating system patches, operating system packages, kernel parameters, and so on.

The following sections describe these prerequisite checks. In particular, this section covers the following:

- What Prerequisite Checks Are Run by Default?

- How Can You Run Prerequisite Checks in Standalone Mode?

What Prerequisite Checks Are Run by Default?

The following are the default prerequisite checks that are run for different installation types—Creating a New Enterprise Manager System and Upgrading an Existing Enterprise Manager System:

- Prerequisite check for verifying whether the installation is being done on a certified operating system.

- Prerequisite check for verifying whether all the certified packages and libraries have been installed.

- Prerequisite check for verifying whether the glibc package has been installed. (Not applicable for Management Agent installation)

- Prerequisite check for verifying whether there is sufficient disk space in the temp directory. (Not applicable for Management Agent installation)

- Prerequisite check for verifying whether there is sufficient disk space in the inventory directory.

- Prerequisite check for verifying whether there is write permission in the inventory directory.(Not applicable for OMS installation)

- Prerequisite check for verifying whether the software is compatible with the current operating system.

- Prerequisite check for verifying whether there is sufficient physical memory.

- Prerequisite check for verifying the required ulimit value. (Not applicable for Management Agent installation)

- Prerequisite check for verifying the host name.

- Prerequisite check for verifying whether the LD_ASSUME_KERNEL environment variable is set. (Not applicable for Management Agent installation)

- Prerequisite check for verifying whether proper timezone is set.

- Prerequisite check for verifying whether there is 4 GB of swap space. (Not applicable for Management Agent installation)

How Can You Run Prerequisite Checks in Standalone Mode?

You can run the prerequisite checks in standalone mode before invoking the installation wizard. This helps you identify and resolve issues that might otherwise cause the installation to fail.

Table 2-5 shows the commands you need to run to run the prerequisite checks in standalone mode:

Table 2-5 Running Prerequisite Checks in Standalone Mode

Installation Type

Command

- Create a New Enterprise Manager System

- Upgrade an Existing Enterprise Manager System

- Install Software Only

<Software_Location>/install/runInstaller -prereqchecker PREREQ_CONFIG_LOCATION=<Software_Location>/stage/prereq -entryPoint "oracle.sysman.top.oms_Core" -prereqLogLoc <absolute_path_to_log_location> -silent -waitForCompletion

Note:
On Microsoft Windows, replace /runInstaller with setup.exe. Also, <Software_Location> mentioned in the commands in Table 2-5 refer to the location where the Enterprise Manager software is available. For example, DVD. If you have downloaded the software from Oracle Technology Network (OTN), then enter the absolute path to that downloaded location.

Understanding Limitations of Enterprise Manager Cloud Control

This section describes the limitations you might face while using Enterprise Manager Cloud Control. In particular, this section covers the following:

- Can You Access Unlicensed Components?

- What Are the Limitations with DHCP-Enabled Machines?

Can You Access Unlicensed Components?

Although the installation media in your media pack contain many Oracle components, you are permitted to use only those components for which you have purchased licenses. Oracle Support Service does not provide support for components for which licenses have not been purchased.

For more information, access the Enterprise Manager documentation library at the following URL and view the Oracle Enterprise Manager Licensing Information Guide:

http://www.oracle.com/technetwork/indexes/documentation/index.html

What Are the Limitations with DHCP-Enabled Machines?

Do NOT run the OMS on a computer that is DHCP enabled. Oracle strongly suggests that you use a static host name or IP address assigned on the network for Enterprise Manager Cloud Control components to function properly.

For more information, refer to My Oracle Support Note 428665.1 at:

https://support.oracle.com/

Understanding Other Miscellaneous Concepts

This section covers miscellaneous concepts related to the installation of Enterprise Manager Cloud Control. In particular, this section covers the following:

- What Is a Host List File?

- What Scripts Are Run During the Installation Process?

What Is a Host List File?

While using the Add Host Targets Wizard, you can enter the hosts on which you want to install Oracle Management Agent, in two ways — you can either enter the host name or the IP address, or select an external file that contains a list of hosts mentioned.

If you choose to select an external file, then ensure that the file contains only the host name (Example 2-1), or the host name followed by the platform name (Example 2-2).

Example 2-1 External File with Only the Host Names

host1.example.com
host2.example.com

Example 2-2 External File with the Host Names and Platform Names

host1.example.com linux
host2.example.com aix

What Scripts Are Run During the Installation Process?

At least once during or after the installation of Enterprise Manager Cloud Control or Management Agent, you are prompted to log in as a root user and run oraInstRoot.sh, allroot.sh, or root.sh. You must log in as a root user because the scripts edit files in the /etc directory and create files in the local bin directory (/usr/local/bin, by default).

After every installation, a check is performed to identify the Central Inventory (oraInventory) directory. The Central Inventory directory is a directory that is automatically created by the installation wizard when an Oracle product is installed on a host for the very first time.

Note:
Ensure that the central inventory location you specify must NOT be on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system.

- If you have NOT installed an Oracle product before on the host, then run the oraInstRoot.sh script from the Central Inventory:
$Home/oraInventory/oraInstRoot.sh

The oraInstRoot.sh script is run to create the oraInst.loc file. The oraInst.loc file contains the Central Inventory location.

- However, if you already have an Oracle product on the host, then run allroot.sh script from the OMS home:
<OMS_HOME>/allroot.sh

Part II

Installing Enterprise Manager System

This part describes the different ways of installing Enterprise Manager Cloud Control. In particular, this part contains the following chapters:

- Chapter 3, "Installing Enterprise Manager System in Silent Mode"

- Chapter 4, "Installing Enterprise Manager Software Now and Configuring Later"

3 Installing Enterprise Manager System in Silent Mode

This chapter describes how you can install Enterprise Manager Cloud Control while utilizing an existing, certified Oracle Database, in silent mode. In particular, this section covers the following:

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- After You Install

Note:
All general purpose file systems, including OCFS2 and ACFS, are acceptable for storing Enterprise Manager Cloud Control 12c software binaries and OMS instance home files (configuration files in gc_inst). However, OCFS is not considered a general purpose file system, and therefore is not considered acceptable for this use.

Overview

If you are familiar with the way Enterprise Manager is installed, and if you want to install it without facing any interview screens of the installation wizard, then the best option is to install it in silent mode.

In silent mode, you use a response file that captures all the information you need to successfully complete an installation. This saves time and effort in one way because the installation details are captured just once, and in a single file that can be circulated and reused for installation on other hosts.

However, whether you install Enterprise Manager in graphical mode or silent mode, the installation process, the installed components, and the configuration process remain the same. Therefore, silent mode of installing Enterprise Manager is only an option offered to you.

To understand what components are installed, what configuration assistants are run, and how the directory structure will look after installation, see the chapter on installing Enterprise Manager system in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Before You Begin

Before you begin, keep these points in mind:

- You must ensure that you have the latest Enterprise Manager Cloud Control software.
To download the latest software, access the following URL:

http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html

For information about downloading the latest software, refer to How Do You Procure the Software from Oracle Technology Network?.

- Ensure that there are no white spaces in the name of the directory where you download and run the Enterprise Manager Cloud Control software from. For example, do not download and run the software from a directory titled EM Software because there is a white space between the two words of the directory name.

- You can install Enterprise Manager Cloud Control only on a single host—locally on the server where you invoke the installation wizard with a response file. You cannot install on or remote hosts.

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- Oracle Management Service 12c Release 2 (12.1.0.2) can communicate only with Oracle Management Agent 12c Release 2 (12.1.0.2) and Oracle Management Agent 12c Release 1 (12.1.0.1), and not with any earlier release of the Management Agent.
And Oracle Management Service 12c Release 1 (12.1.0.1) can communicate only with Oracle Management Agent 12c Release 1 (12.1.0.1), and not with any earlier release or higher release of the Management Agent.

- You must not set the ORACLE_HOME and ORACLE_SID environment variables. You must ensure that the Oracle directories do NOT appear in the PATH.

- The Enterprise Manager Cloud Control Installation Wizard installs Java Development Kit (JDK) 1.6 v24 and Oracle WebLogic Server 11g Release 1 (10.3.5), but only if they do not exist in your environment.

- If Oracle WebLogic Server 11g Release 1 (10.3.5) does not exist and if you choose to manually install it, then ensure that you install it using JDK 1.6 v24+ (64-bit version for 64-bit platforms and 32-bit version for 32-bit platforms).

- Download JDK 1.6 v24+ for your platform from the platform vendor's Web site.
For example, download SUN JDK 1.6 v24+ for Linux platforms from the following Oracle Web site URL:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

- If you already have JDK, then verify its version by navigating to the <JDK_Location>/bin directory and running the following command:
"./java -fullversion"

To verify whether it is a 32-bit or a 64-bit JDK, run the following command:

"file *"

- JROCKIT is not supported.

- If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.5) on Linux 64-bit platforms, first install the 64-bit JDK for your platform, and then download and use the wls1035_generic.jar file to install Oracle WebLogic Server.
For example,

<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1035_generic.jar>

- If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.5) on Linux 32-bit platforms, then download and use either the wls1035_linux32.bin file or the wls1035_generic.jar file.
For example,

<JDK home>/bin/java -jar <absolute_path _to_wls1035_generic.jar>

- You must follow the instructions outlined in the Oracle® Fusion Middleware Installation Guide for Oracle WebLogic Server to install Oracle WebLogic Server. The guide is available in the Fusion Middleware documentation library available at:
http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html

- You must ensure that the Oracle WebLogic Server installation is a typical installation, and even if you choose to perform a custom installation, ensure that components chosen for custom installation are the same as the ones associated with a typical installation.

- You must ensure that the user installing the WebLogic Server is the same as the one installing Enterprise Manager Cloud Control.

- If you are installing Enterprise Manager Cloud Control in a Middleware home that is on an NFS-mounted drive, then ensure that you maintain the lock file in a local file system and not in that NFS-mounted location. To do so, after you install, modify the lock file location in the httpd.conf file to map to a location on a local file system. For instructions, refer to After You Install.

- You must ensure that the Oracle WebLogic Server 11g Release 1 (10.3.5) installed by the Enterprise Manager Cloud Control Installation Wizard or by you is dedicated for Enterprise Manager Cloud Control. You must not have any other Oracle Fusion Middleware product installed in that Middleware home.
Enterprise Manager Cloud Control cannot coexist with any Oracle Fusion Middleware product in the same Middleware home because the ORACLE_COMMON property is used by both the products.

- Do not install on a symlink. If you do, then you will not be able to clone this OMS later.

- You can optionally use the database templates offered by Oracle to create a database instance with a preconfigured Management Repository. To do so, refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide.
However, note that the database templates are essentially designed for simple installation, although they can be used for advanced installation. Therefore, while performing an advanced installation (possibly with small, medium, or large deployment size selection), when you provide the details of such a database, you will be prompted that the database parameters need to be modified to suit the deployment size you selected. You can confirm the message to proceed further. The installation wizard will automatically set the database parameters to the required values.

- If you want to optionally follow the configuration guidelines for deploying the Management Repository so that your management data is secure, reliable, and always available, refer to the Oracle Enterprise Manager Cloud Control Administrator's Guide.

- By default, the software updates cannot be applied during installation because the INSTALL_UPDATES_SELECTION variable in the response file is set to "skip". However, if you want to apply them during installation, then you can modify this variable as described in Table 3-2.

- Oracle offers bug fixes for a product based on the Oracle Lifetime Support Policy. When the license period expires for a particular product, the support for bug fixes offered by Oracle also ends. For more information, see the Oracle Lifetime Support Policy available at:
http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

When determining supportability and certification combinations for an Enterprise Manager Cloud Control installation, you must consider Enterprise Manager Cloud Control's framework components as well as the targets monitored by Enterprise Manager Cloud Control. Oracle recommends keeping your Cloud Control components and targets updated to the latest certified versions in order to receive code fixes without having to purchase an Extended Support license.

- You can find the OMS and Management Agent entries in the /etc/oragchomelist file for all UNIX platforms except HPUNIX, HPia64, Solaris Sparc.
On HPUNIX, HPia64, Solaris Sparc platforms, the entries are present in /var/opt/oracle/oragchomelist.

- As a prerequisite, you must have an existing Oracle Database to configure the Management Repository. This database can also have the Automatic Memory Management (AMM) feature enabled.

Prerequisites

Meet the prerequisites described in the chapter on installing Enterprise Manager system that is available in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Installation Procedure

This section covers the following:

- Installing Enterprise Manager

- Using Advanced Installer Options

- Understanding the Limitations

- Editing Response File for Installing Software

Installing Enterprise Manager

To install a complete Enterprise Manager system in silent mode, follow these steps:

Note:
Oracle recommends you to run the EM Prerequisite Kit before invoking the installer to ensure that you meet all the repository requirements beforehand. Even if you do not run it manually, the installer anyway runs it in the background while installing the product. However, running it manually beforehand sets up your Management Repository even before you can start the installation or upgrade process. For information on the kit, to understand how to run it, and to know about the prerequisite checks it runs, see Oracle Enterprise Manager Cloud Control Basic Installation Guide.

1. Copy the following response file to an accessible location on your local host:
<Software_Location>/response/new_install.rsp

In this command, <Software_Location> is either the DVD location or the location where you have downloaded the software kit.

2. Edit the response file and enter appropriate values for the variables described in Table 3-2.

3. Invoke the installer as a user who belongs to the oinstall group you created. For information about creating operating system groups and users, see the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If this is the first Oracle product you are installing on the host, then run the following command:
./runInstaller -silent -responseFile <absolute_path>/new_install.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:
The central inventory location you enter must NOT be on a shared file system. The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- Otherwise, run the following command:
./runInstaller -silent -responseFile <absolute_path>/new_install.rsp

Note:
To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

Note:
For information about the additional, advanced options you can pass while invoking the installer, refer to Using Advanced Installer Options.

Note:

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- Ensure that there are no white spaces in the name of the directory where you download and run the Enterprise Manager Cloud Control software from. For example, do not download and run the software from a directory titled EM Software because there is a white space between the two words of the directory name.

- When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have read and write access to the /stage subdirectory, which a subdirectory in the Disk1 directory of the Enterprise Manager software.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have read and write permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have read and write access to the /stage directory. If you do not have, then set the TEMP variable to a location where the install user has access to, and then relaunch the installation wizard.

- If you connect to a database instance that was created using the database template offered by Oracle, then you will be prompted that the database parameters need to be modified to suit the deployment size you selected. This is because the templates are essentially designed for simple installation, and the database parameters are set as required for simple installation. Since it is used for advanced installation, the parameters must be set to different values. You can confirm the message to proceed further. The installation wizard will automatically set the parameters to the required values.

Note:

- If any repository-related prerequisite check fails, then run the check manually. For instructions, see the appendix on EM Prerequisite Kit in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If a configuration assistant fails, the installer stops and none of the subsequent configuration assistants are run. Resolve the issue and retry the configuration assistant. For more information, see Appendix G.

Using Advanced Installer Options

The following are some additional, advanced options you can pass while invoking the installer:

- By default, a Provisioning Advisor Framework (PAF) staging directory is created for copying the Software Library entities related to the deployment procedures. By default, this location is the scratch path location (/tmp). The location is used only for provisioning activities—entities are copied for a deployment procedure, and then, deleted once the deployment procedure ends.
If you want to override this location with a custom location, then invoke the installer with the EM_STAGE_DIR option, and enter a unique custom location.

For example,

./runInstaller EM_STAGE_DIR=/home/john/software/oracle/pafdir -silent -responseFile <absolute_path>/new_install.rsp

- After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer with START_OMS and b_startAgent options, and set them to true or false depending on what you want to control.
For example, if you do not want the Management Agent to start automatically, then run the following command:

./runInstaller START_OMS=true b_startAgent=false -silent -responseFile <absolute_path>/new_install.rsp

To understand the limitations involved with this advanced option, see Understanding the Limitations.

Understanding the Limitations

When you use START_OMS and b_startAgent as advanced options to control the way the OMS and the Management Agent start up automatically, sometimes the Management Agent and the host on which it was installed do not appear as targets in the Cloud Control console.

Table 3-1 lists the different combinations of these advanced options, and describes the workaround to be followed for each combination:

Table 3-1 Advanced Options and Workarounds

Advanced Option

Workaround

START_OMS=false

b_startAgent=false

1. Start the OMS:
$<OMS_HOME>/bin/emctl start oms

2. Secure the Management Agent:
$<AGENT_HOME>/bin/emctl secure agent

3. Start the Management Agent:
$<AGENT_HOME>/bin/emctl start agent

4. Add the targets:
$<AGENT_HOME>/bin/emctl config agent addinternaltargets

5. Upload the targets:
$<AGENT_HOME>/bin/emctl upload agent

START_OMS=true

b_startAgent=false

Start the Management Agent:

$<AGENT_HOME>/bin/emctl start agent

START_OMS=false

b_startAgent=true

1. Start the OMS:
$<OMS_HOME>/bin/emctl start oms

2. Secure the Management Agent:
$<AGENT_HOME>/bin/emctl secure agent

3. Add the targets:
$<AGENT_HOME>/bin/emctl config agent addinternaltargets

4. Upload the targets:
$<AGENT_HOME>/bin/emctl upload agent

Editing Response File for Installing Software

Table 3-2 describes what variables you must edit and how you must edit them in the new_install.rsp response file for installing Enterprise Manager Cloud Control in silent mode.

Table 3-2 Editing Response File for Installing Enterprise Manager System

Parameter

Description

UNIX_GROUP_NAME

(Required only when central inventory does not exist) Enter the name of the UNIX group you belong to.

For example, "dba"

Note: This parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

INVENTORY_LOCATION

(Required only when central inventory does not exist) Enter the absolute path to the Central Inventory.

For example, /scratch/oracle/oraInventory

Note: This parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

SECURITY_UPDATES_VIA_MYORACLESUPPORT

- Enter TRUE if you want to download and install security updates. Then, enter the credentials for the following variables:
MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

- Enter FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

- Enter TRUE if you want to decline the security updates. In this case, you should have entered False for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

- Enter FALSE if you do not want to decline the security updates. In this case, you should have entered TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

INSTALL_UPDATES_SELECTION

By default, this variable is set to "skip" indicating that the software updates will not be installed during installation.

- If you want to install the software updates from My Oracle Support, then set this variable to "download". Then, enter the credentials for the following parameters:
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- If you want to install the software updates from a staged location, then set this variable to "staged". Then, for the STAGE_LOCATION parameter, enter the absolute path, which leads to the Updates directory, where the software updates are available.

PROXY_USER

Enter the user name that can be used to access the proxy server.

Note: Applies only if you have set the SECURITY_UPDATES_VIA_MYORACLESUPPORT variable to TRUE and/or the INSTALL_UPDATES_SELECTION variable to "download", and only if your connection to the Internet requires you to connect through a proxy.

PROXY_PWD

Enter the password that can be used to access the proxy server.

Note: Applies only if you have set the SECURITY_UPDATES_VIA_MYORACLESUPPORT variable to TRUE and/or the INSTALL_UPDATES_SELECTION parameter to "download", and only if your connection to the Internet requires you to connect through a proxy.

PROXY_HOST

Enter the name of the proxy host.

Note: Applies only if you have set the SECURITY_UPDATES_VIA_MYORACLESUPPORT variable to TRUE and/or the INSTALL_UPDATES_SELECTION parameter to "download", and only if your connection to the Internet requires you to connect through a proxy.

PROXY_PORT

Enter the port used by the proxy server.

Note: Applies only if you have set the SECURITY_UPDATES_VIA_MYORACLESUPPORT variable to TRUE and/or the INSTALL_UPDATES_SELECTION parameter to "download", and only if your connection to the Internet requires you to connect through a proxy.

ORACLE_MIDDLEWARE_HOME_LOCATION

Enter the location where you want the installer to install Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24.

For example, /u01/app/Oracle/Middleware.

Ensure that the middleware location has write permission. And that this is not an NFS-mounted location.

If you have already installed them manually, then enter the location where you have installed them.

For more information about this location, see What Is Oracle Middleware Home?.

Note: Ensure that the Middleware home you enter here is used only for Enterprise Manager Cloud Control. Ensure that no other Oracle Fusion Middleware products or components are installed in the same Middleware home.

Note: (Only for Microsoft Windows) Ensure that the number of characters in the middleware home path does not exceed 25 characters. For example, the middleware home path C:\Oracle\MW\EM containing only 15 characters is acceptable. However, C:\Oracle\MW\new\EM\dir\a123 containing more than 25 characters is not acceptable.

AGENT_BASE_DIR

Enter the absolute path to the agent base directory, a location outside the Oracle Middleware home where the Management Agent can be installed.

For example, /oracle/agent.

Ensure that this location is empty and has write permission. Also ensure that it is always maintained outside the Oracle Middleware home.

Note: (Only for Microsoft Windows) Ensure that the number of characters in the agent base directory path does not exceed 25 characters. For example, the agent base directory path C:\Oracle\Agent\ containing only 16 characters is acceptable. However, C:\Oracle\ManagementAgent\12c\new containing more than 25 characters is not acceptable.

ORACLE_HOSTNAME

Enter the fully qualified name of the host where you want to configure the OMS. The host name can also be a virtual host name if your host is configured with virtual machine. Ensure that the host name you enter is accessible from other hosts in the network (other hosts must be able to ping this host).

If you do not mention the host name, the installation wizard will proceed further, honoring the host name it automatically detects for that host.

WLS_ADMIN_SERVER_USERNAME

By default, weblogic is the name assigned to the default user account that is created for the Oracle WebLogic Domain. If you want to accept the default name, then skip this variable. However, if you want to have a custom name, then enter the name of your choice.

WLS_ADMIN_SERVER_PASSWORD

Enter a password for the WebLogic user account.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

Confirm the password for the WebLogic user account.

NODE_MANAGER_PASSWORD

By default, nodemanager is the name assigned to the default user account that is created for the node manager. Enter a password for this node manager user account.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

NODE_MANAGER_CONFIRM_PASSWORD

Confirm the password for the node manager user account.

ORACLE_INSTANCE_HOME_LOCATION

By default, gc_inst is considered as the OMS Instance Base directory for storing all OMS-related configuration files, and it is created in the Middleware home. If you want to accept the default location and the directory name, then skip this variable. However, if you want to have a custom location and a custom directory name, then enter the absolute path to the custom location leading up to the custom directory name.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

Note: If you have entered an NFS-mounted drive for the ORACLE_MIDDLEWARE_HOME_LOCATION parameter, then ensure that the location you enter for this parameter is a non-NFS-mounted location.

DATABASE_HOSTNAME

Enter the fully qualified name of the host where the existing database resides. Ensure that the host name does not have underscores.

For example, example.com

If you have already created a database instance with a preconfigured Management Repository using the database templates offered by Oracle, then provide details about that database instance.

If you are connecting to an Oracle RAC Database, and if the nodes have virtual host names, then enter the virtual host name of one of its nodes.

The connection to the database is established with a connect string that is formed using only this virtual host name, and the installation ends successfully.

However, if you want to update the connect string with other nodes of the cluster, then after the installation, run the following command:

$<OMS_HOME>/bin/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

If your Oracle RAC database is configured with Single Client Access Name (SCAN) listener, then you can enter a connection string using the SCAN listener.

Note: If you connect to a database instance that was created using the database template offered by Oracle, then note that the password assigned to the user accounts SYSMAN_MDS, SYSMAN_APM, and SYSMAN_OPSS, which were created while preconfiguring the Management Repository, are automatically reset with the SYSMAN password you enter for the SYSMAN_PASSWORD parameter.

LISTENER_PORT

Enter the listener port to connect to the existing database.

For example, 1521

SERVICENAME_OR_SID

Enter the service name or the system ID (SID) of the existing database.

For example, orcl

SYS_PASSWORD

Enter the SYS user account's password.

DEPLOYMENT_SIZE

Set one of the following values to indicate the number of targets you plan to monitor, the number Management Agents you plan to have, and the number of concurrent user sessions you plan have.

- Small, to monitor up to 999 targets, with up to 99 Management Agents and up to 10 concurrent user sessions

- Medium, to monitor about 1000 to 9999 targets, with about 100 to 999 Management Agents and about 10 to 24 concurrent user sessions

- Large, to monitor 10,000 or more targets, with 1000 or more Management Agents, and with about 25 to 50 concurrent user sessions

The prerequisite checks are run regardless of the selection you make, but the values to be set for the various parameters checked depend on the selection you make.

You can also modify the deployment size after the installation.

For more information on deployment sizes, the prerequisite checks that are run, the database parameters that are set, and how you can modify the deployment size after installation, refer to What is a Deployment Size?.

SYSMAN_PASSWORD

Enter a password for creating a SYSMAN user account. This password is used to create the SYSMAN user, which is the primary owner of the Management Repository schema.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

If you connect to a database instance that was created using the database template offered by Oracle, then note that the password assigned to the user accounts SYSMAN_MDS, SYSMAN_APM, and SYSMAN_OPSS, which were created while preconfiguring the Management Repository, are automatically reset with the SYSMAN password you enter for this parameter.

SYSMAN_CONFIRM_PASSWORD

Confirm the SYSMAN user account's password.

MANAGEMENT_TABLESPACE_LOCATION

Enter the absolute path to the location where the data file (mgmt.dbf) for management tablespace can be stored. Ensure that the specified path leads up to the file name.

For example:

- If the database is on a file system, then the path must look like /u01/oracle/prod/oradata/mgmt.dbf

- If the database is on Automatic Storage Management (ASM), then the path must look like +<disk_group1>/prod/oradata/mgmt.dbf, where disk_group1 is a diskgroup created on ASM and prod is the Service ID (SID).

- If the database is on a raw device, then the path must look like </dev/raw1>/prod/oradata/mgmt.dbf, where /dev/raw1 is the raw device and prod is the SID.

Enterprise Manager Cloud Control requires this data file to store information about the monitored targets, their metrics, and so on. Essentially, everything else other than configuration data, software library data, and audit data.

CONFIGURATION_DATA_TABLESPACE_LOCATION

Enter the absolute path to the location where the data file (mgmt_ecm_depot1.dbf) for configuration data tablespace can be stored. Ensure that the specified path leads up to the file name.

For example, /home/john/oradata/mgmt_ecm_depot1.dbf

Enterprise Manager Cloud Control requires this data file to store configuration information collected from the monitored targets.

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

Enter the absolute path to a location where the data file (mgmt_ad4j.dbf) for JVM Diagnostics data tablespace can be stored. Ensure that the specified path leads up to the file name.

For example, /home/john/oradata/mgmt_ad4j.dbf

Enterprise Manager Cloud Control requires this data file to store monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).

AGENT_REGISTRATION_PASSWORD

Enter a password to secure the communication between the OMS and the Management Agents. Note that you have to provide the same registration password for securing your Management Agents.

AGENT_REGISTRATION_CONFIRM_PASSWORD

Confirm the agent registration password.

STATIC_PORTS_FILE

By default, ports described in What Ports Are Used for Installation? are honored. If you want to accept the default ports, then leave this field blank.

If you want to use custom ports, then enter the absolute path to the staticports.ini file that lists the custom ports to be used for the installation.

PLUGIN_SELECTION

By default, mandatory plug-ins such as Oracle Database Management Plug-In, Oracle Fusion Middleware Management Plug-In, Oracle My Oracle Support Management Plug-In, and Oracle Exadata Management Plug-In get automatically installed with the Enterprise Manager system.

However, if you want to install any of the other optional plug-ins that are available in the software kit (DVD or downloaded software), then enter the names of those plug-ins for this variable.

For example,

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

If you want to install any plug-in that is not available in the software kit, then do the following:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location:
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Update this variable (PLUGIN_SELECTION) to the names of those plug-ins you downloaded.

3. Invoke the installer with the following option, and pass the location where you downloaded the plug-ins:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

After You Install

Perform the post-install steps as described in the chapter on installing Enterprise Manager system that is available in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

4 Installing Enterprise Manager Software Now and Configuring Later

This chapter explains how you can install only the software binaries of Enterprise Manager Cloud Control at one point, and configure the installation at a later point. In particular, this chapter covers the following:

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

Note:
All general purpose file systems, including OCFS2 and ACFS, are acceptable for storing Enterprise Manager Cloud Control 12c software binaries and OMS instance home files (configuration files in gc_inst). However, OCFS is not considered a general purpose file system, and therefore is not considered acceptable for this use.

Overview

You can choose to install only the software binaries of Enterprise Manager Cloud Control at one point and configure it at a later point in time to work with an existing, certified Oracle Database. This approach enables you to divide the installation process into two phases, mainly the installation phase and the configuration phase. Understandably, the installation phase takes less time compared to the configuration phase because the installation phase involves only copying of binaries. This approach helps you plan your installation according to the time and priorities you have.

During the installation phase, you invoke the installer to create Oracle homes and install the following components in the Middleware home:

- Java Development Kit (JDK) 1.6 v24

- Oracle WebLogic Server 11g Release 1 (10.3.5)

- Oracle Management Service 12c

- Oracle Management Agent 12c

- Oracle JRF 11g Release (11.1.1.6.0), which includes oracle_common directory

- Oracle Web Tier 11g Release (11.1.1.6.0), which includes Oracle_WT directory

Note:

- Java Development Kit (JDK) 1.6 v24 and Oracle WebLogic Server 11g Release 1 (10.3.5) are installed only if they do not exist in your environment.

- If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.5), then follow the guidelines outlined in Before You Begin.

During the configuration phase, you invoke a configuration script to do the following:

- Create an Oracle WebLogic domain called GCDomain. For this WebLogic Domain, a default user account, weblogic, is used as the administrative user. You can choose to change this, if you want, in the installer.

- Create a Node Manager user account called nodemanager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

- Configure an Oracle Management Service Instance Base location (gc_inst) in the Middleware home, for storing all configuration details related to Oracle Management Service 12c.
For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the instance base location is /u01/app/Oracle/Middleware/gc_inst.

- Configures Oracle Management Repository in the existing, certified Oracle Database.

- Deploys and configures the following plug-ins:

- Oracle Database Management Plug-In

- Oracle Fusion Middleware Management Plug-In

- Oracle My Oracle Support Management Plug-In

- Oracle Exadata Management Plug-In

Note:
In addition to the mandatory plug-ins listed above, you can optionally install other plug-ins available in the software kit. The installer offers a screen where you can select the optional plug-ins and install them. However, if you want to install some plug-ins that are not available in the software kit, then refer to the point about installing additional plug-ins in Using Advanced Script Options.

- Runs the following configuration assistants to configure the installed or upgraded components:

- Plugins Prerequisites Check Configuration Assistant

- Repository Configuration Assistant

Note:
If you use a database instance that was created with a preconfigured Management Repository using the database templates offered by Oracle, then Repository Out-of-Box Configuration Assistant is run instead of Repository Configuration Assistant.

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Agent Configuration Assistant

Before You Begin

Before you begin, keep these points in mind:

- You must ensure that you have the latest Enterprise Manager Cloud Control software.
To download the latest software, access the following URL:

http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html

For information about downloading the latest software, refer to How Do You Procure the Software from Oracle Technology Network?.

- Ensure that there are no white spaces in the name of the directory where you download and run the Enterprise Manager Cloud Control software from. For example, do not download and run the software from a directory titled EM Software because there is a white space between the two words of the directory name.

- You can install Enterprise Manager Cloud Control using the installation wizard only on a single host, that is, locally on the server where the wizard is invoked. You cannot install on or remote hosts.

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- Oracle Management Service 12c Release 2 (12.1.0.2) can communicate only with Oracle Management Agent 12c Release 2 (12.1.0.2) and Oracle Management Agent 12c Release 1 (12.1.0.1), and not with any earlier release of the Management Agent.
And Oracle Management Service 12c Release 1 (12.1.0.1) can communicate only with Oracle Management Agent 12c Release 1 (12.1.0.1), and not with any earlier release or higher release of the Management Agent.

- You must not set the ORACLE_HOME and ORACLE_SID environment variables. You must ensure that the Oracle directories do NOT appear in the PATH.

- Do not install on a symlink. If you do, then you will not be able to clone this OMS later.

- The Enterprise Manager Cloud Control Installation Wizard installs Java Development Kit (JDK) 1.6 v24 and Oracle WebLogic Server 11g Release 1 (10.3.5), but only if they do not exist in your environment.

- (Only for Graphical Mode) You must set the DISPLAY environment variable.

- In bash terminal, run the following command:
export DISPLAY=<hostname>:<vnc port>.0

For example, export DISPLAY=example.com:1.0

- In other terminals, run the following command:
setenv DISPLAY <hostname>:1.0

For example, setenv DISPLAY example.com:1.0

- If Oracle WebLogic Server 11g Release 1 (10.3.5) does not exist and if you choose to manually install it, then ensure that you install it using JDK 1.6 v24+ (64-bit version for 64-bit platforms and 32-bit version for 32-bit platforms).

- Download JDK 1.6 v24+ for your platform from the platform vendor's Web site.
For example, download SUN JDK 1.6 v24+ for Linux platforms from the following Oracle Web site URL:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

- If you already have JDK, then verify its version by navigating to the <JDK_Location>/bin directory and running the following command:
"./java -fullversion"

To verify whether it is a 32-bit or a 64-bit JDK, run the following command:

"file *"

- JROCKIT is not supported.

- If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.5) on Linux 64-bit platforms, first install the 64-bit JDK for your platform, and then download and use the wls1035_generic.jar file to install Oracle WebLogic Server.
For example,

<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1035_generic.jar>

- If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.5) on Linux 32-bit platforms, then download and use either the wls1035_linux32.bin file or the wls1035_generic.jar file.
For example,

<JDK home>/bin/java -jar <absolute_path _to_wls1035_generic.jar>

- You must follow the instructions outlined in the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server to install Oracle WebLogic Server. The guide is available in the Fusion Middleware documentation library available at:
http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html

- You must ensure that the Oracle WebLogic Server installation is a typical installation, and even if you choose to perform a custom installation, ensure that components chosen for custom installation are the same as the ones associated with a typical installation.

- You must ensure that the user installing the WebLogic Server is the same as the one installing Enterprise Manager Cloud Control.

- If you are installing Enterprise Manager Cloud Control in a Middleware home that is on an NFS-mounted drive, then ensure that you maintain the lock file in a local file system and not in that NFS-mounted location. To do so, after you install, modify the lock file location in the httpd.conf file to map to a location on a local file system. For instructions, refer to Performing Post-Configuration Tasks or Performing Post-Configuration Tasks depending on the installation method you choose for installing Enterprise Manager Cloud Control.

- You must ensure that the Oracle WebLogic Server 11g Release 1 (10.3.5) installed by the Enterprise Manager Cloud Control Installation Wizard or by you is dedicated for Enterprise Manager Cloud Control. You must not have any other Oracle Fusion Middleware product installed in that Middleware home.
Enterprise Manager Cloud Control cannot coexist with any Oracle Fusion Middleware product in the same Middleware home because the ORACLE_COMMON property is used by both the products.

- You can optionally use the database templates offered by Oracle to create a database instance with a preconfigured Management Repository. To do so, refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide.
However, note that the database templates are essentially designed for simple installation, although they can be used for advanced installation. Therefore, while performing an advanced installation (possibly with small, medium, or large deployment size selection), when you provide the details of such a database, you will be prompted that the database parameters need to be modified to suit the deployment size you selected. You can confirm the message to proceed further. The installation wizard will automatically set the database parameters to the required values.

- If you want to optionally follow the configuration guidelines for deploying the Management Repository so that your management data is secure, reliable, and always available, refer to the Oracle Enterprise Manager Cloud Control Administrator's Guide.

- (Only for Silent Mode) By default, the software updates cannot be applied during installation because the INSTALL_UPDATES_SELECTION variable in the response file is set to "skip". However, if you want to apply them during installation, then you can modify this variable as described in Editing Response File for Installing Software.

- By default, the upload ports and console ports as described in What Ports Are Used for Installation? are used.

- Oracle offers bug fixes for a product based on the Oracle Lifetime Support Policy. When the license period expires for a particular product, the support for bug fixes offered by Oracle also ends. For more information, see the Oracle Lifetime Support Policy available at:
http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

When determining supportability and certification combinations for an Enterprise Manager Cloud Control installation, you must consider Enterprise Manager Cloud Control's framework components as well as the targets monitored by Enterprise Manager Cloud Control. Oracle recommends keeping your Cloud Control components and targets updated to the latest certified versions in order to receive code fixes without having to purchase an Extended Support license.

- You can find the OMS and Management Agent entries in the /etc/oragchomelist file for all UNIX platforms except HPUNIX, HPia64, Solaris Sparc.
On HPUNIX, HPia64, Solaris Sparc platforms, the entries are present in /var/opt/oracle/oragchomelist.

- As a prerequisite, you must have an existing Oracle Database to configure the Management Repository. This database can also have the Automatic Memory Management (AMM) feature enabled.

Prerequisites

Meet the prerequisites described in the chapter on installing Enterprise Manager system that is available in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Installation Procedure

This section describes the following:

- Installing in Graphical Mode

- Installing in Silent Mode

Installing in Graphical Mode

This section explains how you can install only the software binaries of Enterprise Manager Cloud Control at one point in graphical mode, and configure the installation at a later point. In particular, this section covers the following:

- Installing Software

- Running Root Script

- Configure Software

- Performing Post-Configuration Tasks

Installing Software

To install only the software binaries of Enterprise Manager Cloud Control in graphical mode, follow these steps:

Note:
Oracle recommends you to run the EM Prerequisite Kit before invoking the installer to ensure that you meet all the repository requirements beforehand. Even if you do not run it manually, the installer anyway runs it in the background while installing the product. However, running it manually beforehand sets up your Management Repository even before you can start the installation or upgrade process. For information on the kit, to understand how to run it, and to know about the prerequisite checks it runs, see Oracle Enterprise Manager Basic Installation Guide.

1. Invoke the Enterprise Manager Cloud Control Installation Wizard
Invoke the installer as a user who belongs to the oinstall group you created. For information about creating operating system groups and users, see the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

<Software_Location>/runInstaller [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- In this command, <Software_Location> refers to either the DVD or the location where you have downloaded software kit.

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- For information about the additional, advanced options you can pass while invoking the installer, refer to Using Advanced Installer Options.

- The central inventory location you enter must NOT be on a shared file system.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

Note:
When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have read and write access to the /stage subdirectory, which a subdirectory in the Disk1 directory of the Enterprise Manager software.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have read and write permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have read and write access to the /stage directory. If you do not have, then set the TEMP variable to a location where the install user has access to, and then relaunch the installation wizard.

2. Enter My Oracle Support Details

On the My Oracle Support Details screen, enter your My Oracle Support credentials to enable Oracle Configuration Manager. If you do not want to enable Oracle Configuration Manager now, go to Step (3).

If the host from where you are running the installation wizard does not have a connection to the Internet, then enter only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support.

Note:
For information about manually collecting the configuration information and uploading it to My Oracle Support, see Manually Collecting and Uploading Configuration Information.

3. Click Next.

4. Install Software Updates

On the Software Updates screen, select one of the following sources from where the software updates can be installed while the installation of the Enterprise Manager system is in progress. If you do not want to apply them now, then select Skip.

- (Recommended) Select Search for Updates, then select Local Directory if you have already manually downloaded the software updates to an accessible local or remote location.

Note:
For instructions to manually download the software updates, refer to How Can You Download the Software Updates?.

Enter the location where the updates are available, and click Search for Updates. To search the computer and select the location, click Browse. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch.

- If the updates have been downloaded to the default location, then select or enter the full path to the scratch path location. For example, if the scratch path location is /scratch/OracleHomes and if the software updates are available in /scratch/OracleHomes/Updates, then enter /scratch/OracleHomes/Updates.

- If the software updates have been downloaded to a custom location, then select or enter the full path to the custom location. For example, if the custom location is /scratch/john and if the software updates are available in /scratch/john/Updates, then enter /scratch/john/Updates.

- Select Search for Updates, and then, select My Oracle Support if you want the installer to connect to My Oracle Support and automatically download the updates from there.
Enter the My Oracle Support account user name and password, and click Search for Updates. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch

Note:
If you choose to skip installing the software updates during installation by not providing the My Oracle Support credentials, you can always register the credentials later using the Enterprise Manager Cloud Control console and view the recommended security patches. To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, click Set MOS Credentials and register the credentials.

5. Click Next.
If Enterprise Manager Cloud Control is the first Oracle product you are installing on the host that is running on UNIX operating system, then the Oracle Inventory screen appears. For details, see step (6). Otherwise, the Check Prerequisites screen appears. For details, see step (8).

If Enterprise Manager Cloud Control is the first Oracle product you are installing on the host that is running on Microsoft Windows operating system, then the Oracle Inventory screen does not appear. On Microsoft Windows, the following is the default inventory directory:

<system drive>\Program Files\Oracle\Inventory

6. Enter Oracle Inventory Details
On the Oracle Inventory screen, do the following. You will see this screen only if this turns out to be your first ever installation of an Oracle product on the host.

1. Enter the full path to a directory where the inventory files and directories can be placed.

Note:

- The central inventory location you enter must NOT be on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1

- If this is the first Oracle product on the host, then the default central inventory location is /home/<user_name>/oraInventory. However, if you already have some Oracle products on the host, then the central inventory location can be found in the oraInst.loc file. The oraInst.loc file is located in the /etc directory for Linux and AIX, and in the /var/opt/oracle directory for Solaris, HP-UX, and Tru64.

2. Select the appropriate operating system group name that will own the Oracle inventory directories. The group that you select must have write permissions on the Oracle Inventory directories.

7. Click Next.

8. Check Prerequisites

On the Prerequisite Checks screen, check the status of the prerequisite checks run by the installation wizard, and verify whether your environment meets all the minimum requirements for a successful installation.

The installation wizard runs the prerequisite checks automatically when you come to this screen. It checks for the required operating system patches, operating system packages, and so on.

The status of the prerequisite check can be either Warning, Failed, or Succeeded.

- If some checks result in Warning or Failed status, then investigate and correct the problems before you proceed with the installation. The screen provides details on why the prerequisites failed and how you can resolve them. After you correct the problems, return to this screen and click Rerun to check the prerequisites again.

- However, all package requirements must be met or fixed before proceeding any further. Otherwise, the installation might fail.

9. Click Next.

10. Select Installation Type

On the Installation Types screen, select Install software only.

11. Click Next.

12. Enter Installation Details
On the Installation Details screen, do the following:

1. Enter or validate or enter the Middleware home where you want to install the OMS and other core components.

Note:

- If Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 are already installed in your environment, then the installer automatically detects them and displays the absolute path to the Middleware home where they are installed. In this case, validate the Middleware home location that is detected and displayed by default. If the location is incorrect, then enter the path to the correct location. Ensure that the Middleware home location you select or enter is a Middleware home location that does not have any Oracle homes for Oracle Management Service and Oracle Management Agent.

- If Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 are NOT already installed in your environment, then the installer automatically installs them for you while installing the Enterprise Manager system. In this case, enter the absolute path to a directory where you want to have them installed. For example, /oracle/software/. Ensure that the directory you enter does not contain any files or subdirectories.

- (Only for Microsoft Windows) Ensure that the number of characters in the middleware home path does not exceed 25 characters.
For example, the middleware home path C:\Oracle\MW\EM containing only 15 characters is acceptable. However, C:\Oracle\MW\new\EM\dir\a123 containing more than 25 characters is not acceptable.

2. Enter the absolute path to the agent base directory, a location outside the Oracle Middleware home where the Management Agent can be installed. For example, /oracle/agent. Ensure that this location is empty and has write permission. Also ensure that it is always maintained outside the Oracle Middleware home.

Note:
(Only for Microsoft Windows) Ensure that the number of characters in the agent base directory path does not exceed 25 characters.
For example, the agent base directory path C:\Oracle\Agent\ containing only 16 characters is acceptable. However, C:\Oracle\ManagementAgent\12c\new containing more than 25 characters is not acceptable.

3. Validate the name of the host where you want to configure the OMS.
The host name appears as a fully qualified name. The host name can also appear as a virtual host name if your host is configured with virtual machine.

You can choose to accept the default host name and proceed with the installation. Alternatively, you can change the name if it is incorrect, or enter another host name for this host. Ensure that the host name you enter is accessible from other hosts in the network (other hosts must be able to ping this host).

13. Click Next.

14. Review and Install
On the Review screen, review the details you provided for the selected installation type.

- If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

- After you verify the details, if you are satisfied, click Install to begin the installation process.

15. Track the Progress
On the Install Progress screen, view the overall progress (in percentage) of the installation.

16. End the Installation
On the Finish screen, you should see information pertaining to the installation of Enterprise Manager. Review the information and click Close to exit the installation wizard.

Using Advanced Installer Options

The following are some additional, advanced options you can pass while invoking the installer:

- By default, GCDomain is the default name used for creating the WebLogic Domain. To override this and use a custom WebLogic Domain name, invoke the installation wizard with the WLS_DOMAIN_NAME option, and enter a unique custom name.

Note:
Ensure that the WLS_DOMAIN_NAME option is used even when the ConfigureGC.sh is invoked to configure the software binaries as described in Configure Software.

For example, if you want to use the custom name EMDomain, then run the following command:

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh WLS_DOMAIN_NAME=EMDomain

- If you want to set the Central Inventory, then pass the -invPtrLoc parameter. This parameter considers the path to a location where the inventory pointer file (oraInst.loc) is available. However, this parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.
For example,

./runInstaller -invPtrLoc /scratch/OracleHomes/oraInst.loc -silent -responseFile <absolute_path_response_file>

- After you install the software binaries, you will configure the binaries. And after the configuration ends successfully, by default, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installation wizard with START_OMS and b_startAgent options, and set them to true or false depending on what you want to control.

Note:
Ensure that the START_OMS and b_startAgent options are used even when the ConfigureGC.sh is invoked to configure the software binaries as described in Configure Software.

For example, if you do not want the Management Agent to start automatically, then run the following command:

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh START_OMS=true b_startAgent=false

To understand the limitations involved with this advanced option, see Understanding the Limitations.

Running Root Script

(For UNIX Only) After you install the software binaries of Enterprise Manager Cloud Control, log in as a root user in a new terminal and run the following scripts:

- If this is the first Oracle product you just installed on the host, then run the oraInstroot.sh script from the inventory location specified in the oraInst.loc file that is available in the Management Agent home.
For example, if the inventory location specified in the oraInst.loc file is $HOME/oraInventory, then run the following command:

$HOME/oraInventory/oraInstRoot.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/local/bin/sudo $HOME/oraInventory/oraInstRoot.sh

- Run the allroot.sh script from the OMS home:
$<OMS_HOME>/allroot.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/local/bin/sudo $<OMS_HOME>/allroot.sh

Configure Software

To configure Enterprise Manager Cloud Control, follow these steps:

1. Invoke the Enterprise Manager Cloud Control Installation Wizard
Invoke the installation wizard as a user who belongs to the oinstall group you created. For information about creating operating system groups and users, see the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- While installing the software binaries as described in Installing Software, if you had passed the argument -invPtrLoc, then pass the same argument here as well.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- For information about the additional, advanced options you can pass while invoking the script, refer to Using Advanced Script Options.

- The only way to configure a software-only installation is to run the ConfigureGC.sh (or ConfigureGC.bat on Microsoft Windows) script. DO NOT run the individual configuration assistants to configure a software-only installation. If you want to run the individual configuration assistants to configure the installation for some reason, then contact Oracle Support.

- If you have already configured a software-only installation (the Oracle home) using the ConfigureGC.sh script (or ConfigureGC.bat on Microsoft Windows, then DO NOT try to reconfigure it—either using the script or using the individual configuration assistants.

2. Select Installation Type

In the installation wizard, on the Installation Types screen, select Create a New Enterprise Manager System.

3. Click Next.

4. Deploy Plug-Ins

On the Plug-In Deployment screen, select the optional plug-ins you want to install from the software kit (DVD, downloaded software) while installing the Enterprise Manager system.

The pre-selected rows are mandatory plug-ins that will be installed by default. Select the optional ones you want to install.

Note:
During installation, if you want to install a plug-in that is not available in the software kit, then refer to the point about installing additional plug-ins in Using Advanced Installer Options.

5. Click Next.

6. Enter WebLogic Server Configuration Details

On the WebLogic Server Configuration Details screen, enter the credentials for the WebLogic Server user account and the Node Manager user account, and validate the path to the Oracle Management Service instance base location.

Note:
Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

By default, the WebLogic Domain name is GCDomain, and the Node Manager name is nodemanager. These are non-editable fields. The installer uses this information for creating Oracle WebLogic Domain and other associated components such as the admin server, the managed server, and the node manager.

A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

By default, the Oracle Management Service instance base location is gc_inst, which is created in the Middleware home for storing all configuration details related to the OMS.

7. Click Next.

8. Enter Database Connection Details

On the Database Connection Details screen, do the following:

1. Provide details of the existing, certified database where the Management Repository needs to be created. If you have already created a database instance with a preconfigured Management Repository using the database templates offered by Oracle, then provide details about that database instance.
The installer uses this information to connect to the existing database for creating the SYSMAN schema and plug-in schemas. If you provide details of a database that already has a preconfigured Management Repository, then the installer only creates plug-in schemas.

Note:

- For information about creating a database instance with a preconfigured Management Repository using the database templates offered by Oracle, refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If you connect to a database instance that was created using the database template offered by Oracle, then note that the password assigned to the user accounts SYSMAN_MDS, SYSMAN_APM, and SYSMAN_OPSS, which were created while preconfiguring the Management Repository, are automatically reset with the SYSMAN password you enter on the Repository Configuration Details screen (as described in Step (10)).

- To identify whether your database is a certified database listed in the certification matrix, access the certification matrix as described in Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If any repository-related prerequisite check fails, then run the check manually. For instructions, see the appendix on EM Prerequisite Kit in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- Oracle Real Application Cluster (Oracle 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. For more information, refer to Oracle Database Net Services Administrator's Guide.

2. Select the deployment size from the Deployment Size list to indicate the number of targets you plan to monitor, the number Management Agents you plan to have, and the number of concurrent user sessions you plan have.
The prerequisite checks are run regardless of the selection you make, but the values to be set for the various parameters checked depend on the selection you make.

For more information on deployment sizes, the prerequisite checks that are run, the database parameters that are set, and how you can modify the deployment size after installation, refer to What is a Deployment Size?.

Table 4-1 describes each deployment size.

Table 4-1 Deployment Size

Deployment Size

Targets Count

Management Agents Count

Concurrent User Session Count

Small

Up to 999

Up to 99

Up to 10

Medium

Between 1000 and 9999

Between 100 and 999

Between 10 and 24

Large

10,000 or more

1000 or more

Between 25 and 50

9. Click Next.

Note:
If you connect to a database instance that was created using the database template offered by Oracle, then you will be prompted that the database parameters need to be modified to suit the deployment size you selected. This is because the templates are essentially designed for simple installation, and the database parameters are set as required for simple installation. Since it is used for advanced installation, the parameters must be set to different values. You can confirm the message to proceed further. The installation wizard will automatically set the parameters to the required values.
If you are connecting to an Oracle RAC database, and if you have entered the virtual host name of one of its nodes, then the installation wizard prompts you with a Connection String dialog and requests you to update the connect string with information about the other nodes that are part of the cluster. Update the connect string and click OK. If you want to test the connection, click Test Connection.

If your Oracle RAC database is configured with Single Client Access Name (SCAN) listener, then you can enter a connection string using the SCAN listener.

Oracle Real Application Cluster (Oracle 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. For more information, refer to Oracle Database Net Services Administrator's Guide.

10. Enter Repository Configuration Details

On the Repository Configuration Details screen, do the following:

1. For SYSMAN Password, enter a password for creating the SYSMAN user account. The SYSMAN user account is used for creating the SYSMAN schema, which holds most of the relational data used in managing Enterprise Manager Cloud Control. SYSMAN is also the super administrator for Enterprise Manager Cloud Control.

Note:

- Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

- If you connect to a database instance that was created using the database template offered by Oracle, then note that the password assigned to the user accounts SYSMAN_MDS, SYSMAN_APM, and SYSMAN_OPSS, which were created while preconfiguring the Management Repository, are automatically reset with the SYSMAN password you enter on this screen.

2. For Registration Password, enter a password for registering the new Management Agents that join the Enterprise Manager system.

Note:
Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

3. For Management Tablespace, enter the absolute path to the location where the data file for management tablespace (mgmt.dbf) can be stored. The installer uses this information for storing data about the monitored targets, their metrics, and so on. Ensure that the specified path leads up to the file name.
For example, /u01/oracle/prod/oradata/mgmt.dbf

4. For Configuration Data Tablespace, enter the absolute path to the location where the data file for configuration data tablespace (mgmt_ecm_depot1.dbf) can be stored. This is required for storing configuration information collected from the monitored targets. Ensure that the specified path leads up to the file name.
For example, /u01/oracle/prod/oradata/mgmt_ecm_depot1.dbf

5. For JVM Diagnostics Data Tablespace, enter the absolute path to a location where the data file for JVM Diagnostics data tablespace (mgmt_ad4j.dbf) can be stored. Ensure that the specified path leads up to the file name. Enterprise Manager Cloud Control requires this data file to store monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).
For example, /u01/oracle/prod/oradata/mgmt_ad4j.dbf

Note:
If you are configuring the Management Repository on a database that uses Oracle Automatic Storage Management (Oracle ASM) for storage, then when you enter the data file location, only the disk group is used for creating the tablespaces. For example, if you specify +DATA/a.dbf, then only +DATA is used for creating the tablespaces on Oracle ASM, and the exact location of the data file on the disk group is decided by Oracle Managed Files.

11. Click Next.

12. Customize Ports

On the Port Configuration Details screen, customize the ports to be used for various components.

You can enter a free custom port that is either within or outside the port range recommended by Oracle.

To verify if a port is free, run the following command:

- On Unix:
netstat -anp | grep <port no>

- On Microsoft Windows:
netstat -an|findstr <port_no>

However, the custom port must be greater than 1024 and lesser than 65535. Alternatively, if you already have the ports predefined in a staticports.ini file and if you want to use those ports, then click Import staticports.ini file and select the file.

Note:
If the staticports.ini file is passed during installation, then by default, the ports defined in the staticports.ini file are displayed. Otherwise, the first available port from the recommended range is displayed.
The staticports.ini file is available in the following location:

<Software_Extracted_Location>/response

13. Click Next.

14. Review and Configure
On the Review screen, review the details you provided for the selected installation type.

- If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

- After you verify the details, if you are satisfied, click Configure to begin the installation process.

15. Track the Progress
On the Install Progress screen, view the overall progress (in percentage) of the installation.

Note:

- If a configuration assistant fails, the installer stops and none of the subsequent configuration assistants are run. Resolve the issue and retry the configuration assistant. For more information, see Appendix G.

- If you accidently exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the OMS home to rerun the Configuration Assistant in silent mode. For Microsoft Windows platforms, invoke runConfig.bat script.
$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

16. End the Installation
On the Finish screen, you should see information pertaining to the installation of Enterprise Manager. Review the information and click Close to exit the installation wizard.

Using Advanced Script Options

The following are some additional, advanced options you can pass while invoking the configureGC.sh script (or configureGC.bat on Microsoft Windows):

- By default, GCDomain is the default name used for creating the WebLogic Domain. To override this and use a custom WebLogic Domain name, invoke the script with the WLS_DOMAIN_NAME option, and enter a unique custom name.

Note:
Ensure that the WLS_DOMAIN_NAME option was used even when the installation wizard was invoked to install the software binaries as described in Installing Software.

For example, if you want to use the custom name EMDomain, then run the following command:

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh WLS_DOMAIN_NAME=EMDomain

- If you want to install some plug-ins that are not in the software kit, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager Download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the ConfigureGC.sh script (or ConfigureGC.bat on Microsoft Windows) with the following option, and pass the location where the plug-ins you want to install are available:
./ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

The Plug-In Deployment screen of the installation wizard displays a list of plug-ins available in the software kit as well as the plug-ins available in this custom location. You can choose the ones you want to install.

- After the configuration ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the script with START_OMS and b_startAgent options, and set them to true or false depending on what you want to control.

Note:
Ensure that the START_OMS and b_startAgent options are used even when the installation wizard was invoked to install the software binaries as described in Installing Software.

For example, if you do not want the Management Agent to start automatically, then run the following command:

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh START_OMS=true b_startAgent=false

To understand the limitations involved with this advanced option, see Understanding the Limitations.

Performing Post-Configuration Tasks

Perform the post-install steps as described in the chapter on installing Enterprise Manager system that is available in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Installing in Silent Mode

This section explains how you can install only the software binaries of Enterprise Manager Cloud Control at one point in silent mode, and configure the installation at a later point. In particular, this section covers the following:

- Installing Software

- Running Root Script

- Configuring Software

- Performing Post-Configuration Tasks

Installing Software

To install only the software binaries of Enterprise Manager Cloud Control in silent mode, follow these steps:

Note:
Oracle recommends you to run the EM Prerequisite Kit before invoking the installer to ensure that you meet all the repository requirements beforehand. Even if you do not run it manually, the installer anyway runs it in the background while installing the product. However, running it manually beforehand sets up your Management Repository even before you can start the installation or upgrade process. For information on the kit, to understand how to run it, and to know about the prerequisite checks it runs, see Oracle Enterprise Manager Basic Installation Guide.

1. Copy the following response file to an accessible location on your local host:
<Software_Location>/response/software_only.rsp

In this command, <Software_Location> refers to either the DVD or the location where you have downloaded software kit.

2. Edit the response file and enter appropriate values for the variables described in Table 4-2.

3. Invoke the installer as a user who belongs to the oinstall group you created. For information about creating operating system groups and users, see the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If this is the first Oracle product you are installing on the host, then run the following command:
./runInstaller -silent -responseFile <absolute_path>/software_only.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

- Otherwise, run the following command:
./runInstaller -silent -responseFile <absolute_path>/software_only.rsp

Note:

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- The central inventory location you enter must NOT be on a shared file system. The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- For information about the additional, advanced options you can pass while invoking the installer, refer to Using Advanced Installer Options. The central inventory location you enter must NOT be on a shared file system.

Note:
When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have read and write access to the /stage subdirectory, which a subdirectory in the Disk1 directory of the Enterprise Manager software.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have read and write permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have read and write access to the /stage directory. If you do not have, then set the TEMP variable to a location where the install user has access to, and then relaunch the installation wizard.

Editing Response File for Installing Software

Table 4-2 describes what variables you must edit and how you must edit them in the software_only.rsp response file for installing the software binaries.

Table 4-2 Editing Response File for Installing Enterprise Manager Software

Parameter

Description

UNIX_GROUP_NAME

(Required only when central inventory does not exist) Enter the name of the UNIX group you belong to.

For example, "dba"

Note: This parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

INVENTORY_LOCATION

(Required only when central inventory does not exist) Enter the absolute path to the Central Inventory.

For example, /scratch/oracle/oraInventory

Note: This parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

SECURITY_UPDATES_VIA_MYORACLESUPPORT

- Enter TRUE if you want to download and install security updates. Then, enter the credentials for the following variables:
MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

- Enter FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

- Enter TRUE if you want to decline the security updates. In this case, you should have entered False for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

- Enter FALSE if you do not want to decline the security updates. In this case, you should have entered TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

INSTALL_UPDATES_SELECTION

By default, this variable is set to "skip" indicating that the software updates will not be installed during installation.

- If you want to install the software updates from My Oracle Support, then set this variable to "download". Then, enter the credentials for the following parameters:
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- If you want to install the software updates from a staged location, then set this variable to "staged". Then, for the STAGE_LOCATION parameter, enter the absolute path, which leads to the Updates directory, where the software updates are available.

ORACLE_MIDDLEWARE_HOME_LOCATION

Enter the location where you want the installer to install Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24.

For example, /u01/app/Oracle/Middleware.

Ensure that the middleware location has write permission to create the OMS home.

If you have already installed them manually, then enter the location where you have installed them.

For more information about this location, see What Is Oracle Middleware Home?.

Note: Ensure that the Middleware home you enter here is used only for Enterprise Manager Cloud Control. Ensure that no other Oracle Fusion Middleware products or components are installed in the same Middleware home.

Note: (Only for Microsoft Windows) Ensure that the number of characters in the middleware home path does not exceed 25 characters. For example, the middleware home path C:\Oracle\MW\EM containing only 15 characters is acceptable. However, C:\Oracle\MW\new\EM\dir\a123 containing more than 25 characters is not acceptable.

AGENT_BASE_DIR

Enter the absolute path to the agent base directory, a location outside the Oracle Middleware home where the Management Agent can be installed.

For example, /oracle/agent.

Ensure that this location is empty and has write permission. Also ensure that it is always maintained outside the Oracle Middleware home.

Note: (Only for Microsoft Windows) Ensure that the number of characters in the agent base directory path does not exceed 25 characters. For example, the agent base directory path C:\Oracle\Agent\ containing only 16 characters is acceptable. However, C:\Oracle\ManagementAgent\12c\new containing more than 25 characters is not acceptable.

ORACLE_HOSTNAME

Enter the fully qualified name of the host where you want to configure the OMS. The host name can also be a virtual host name if your host is configured with virtual machine. Ensure that the host name you enter is accessible from other hosts in the network (other hosts must be able to ping this host).

If you do not mention the host name, the installation wizard will proceed further, honoring the host name it automatically detects for that host.

Running Root Script

(For UNIX Only) After you install the software binaries of Enterprise Manager Cloud Control, log in as a root user in a new terminal and run the following scripts:

- If this is the first Oracle product you just installed on the host, then run the oraInstroot.sh script from the inventory location specified in the oraInst.loc file that is available in the Management Agent home.
For example, if the inventory location specified in the oraInst.loc file is $HOME/oraInventory, then run the following command:

$HOME/oraInventory/oraInstRoot.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/local/bin/sudo $HOME/oraInventory/oraInstRoot.sh

- Run the allroot.sh script from the OMS home:
$<OMS_HOME>/allroot.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/local/bin/sudo $<OMS_HOME>/allroot.sh

Configuring Software

To configure the software binaries of Enterprise Manager Cloud Control, follow these steps:

1. Copy the following response file to an accessible location on the host where you copied the software binaries of Enterprise Manager Cloud Control:
<Software_Location>/response/new_install.rsp

In this command, <Software_Location> refers to either the DVD or the location where you have downloaded software kit.

2. Edit the response file and enter appropriate values for the variables described in Table 4-3.

3. Configure the software binaries by invoking the ConfigureGC.sh script (or ConfigureGC.bat on Microsoft Windows) passing the response you edited in the previous step:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -silent -responseFile <absolute_path>/new_install.rsp [-invPtrLoc <absolute_path_to_inventory_directory>]

Note:

- While installing the software binaries as described in Installing Software, if you had passed the argument -invPtrLoc, then pass the same argument here as well.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- For information about the additional, advanced options you can pass while invoking the script, refer to Using Advanced Script Options.

- The only way to configure a software-only installation is to run the ConfigureGC.sh script (or ConfigureGC.bat on Microsoft Windows). DO NOT run the individual configuration assistants to configure a software-only installation. If you want to run the individual configuration assistants to configure the installation for some reason, then contact Oracle Support.

- If you have already configured a software-only installation (the Oracle home) using the ConfigureGC.sh script (or ConfigureGC.bat on Microsoft Windows), then DO NOT try to reconfigure it—either using the script or using the individual configuration assistants.

- If you connect to a database instance that was created using the database template offered by Oracle, then you will be prompted that the database parameters need to be modified to suit the deployment size you selected. This is because the templates are essentially designed for simple installation, and the database parameters are set as required for simple installation. Since it is used for advanced installation, the parameters must be set to different values. You can confirm the message to proceed further. The installation wizard will automatically set the parameters to the required values.

Note:

- If any repository-related prerequisite check fails, then run the check manually. For instructions, see the appendix on EM Prerequisite Kit in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If a configuration assistant fails, the installer stops and none of the subsequent configuration assistants are run. Resolve the issue and rerun the configuration assistant. For more information, see Appendix G.

Editing Response File for Configuring Software

Table 4-3 describes what variables you must edit and how you must edit them in the new_install.rsp file for configuring the software binaries.

Table 4-3 Editing Response File for Configuring Enterprise Manager Software

Parameter

Description

PLUGIN_SELECTION

By default, mandatory plug-ins such as Oracle Database Management Plug-In, Oracle Fusion Middleware Management Plug-In, Oracle My Oracle Support Management Plug-In, and Oracle Exadata Management Plug-In get automatically installed with the Enterprise Manager system.

However, if you want to install any of the other optional plug-ins that are available in the software kit (DVD or downloaded software), then enter the names of those plug-ins for this variable.

For example,

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

If you want to install any plug-in that is not available in the software kit, then do the following:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location:
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Update this variable (PLUGIN_SELECTION) to the names of those plug-ins you downloaded.

3. Invoke the installer with the following option, and pass the location where you downloaded the plug-ins:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

WLS_ADMIN_SERVER_USERNAME

By default, weblogic is the name assigned to the default user account that is created for the Oracle WebLogic Domain. If you want to accept the default name, then blank. However, if you want to have a custom name, then enter the name of your choice.

WLS_ADMIN_SERVER_PASSWORD

Enter a password for the WebLogic user account.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

Confirm the password for the WebLogic user account.

NODE_MANAGER_PASSWORD

By default, nodemanager is the name assigned to the default user account that is created for the node manager. Enter a password for this node manager user account.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

NODE_MANAGER_CONFIRM_PASSWORD

Confirm the password for the node manager user account.

ORACLE_INSTANCE_HOME_LOCATION

By default, gc_inst is considered as the OMS Instance Base directory for storing all OMS-related configuration files. If you want to accept the default directory, then blank. However, if you want to have a custom directory, then enter the name of the custom directory.

Whether you accept the default directory or enter a custom one, by default, the directory is created under the parent directory of the Middleware home.

For example, if the Middleware home is /u01/app/Oracle/Middleware, then the directory is /u01/app/Oracle/gc_inst.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

DATABASE_HOSTNAME

Enter the fully qualified name of the host where the existing database resides. Ensure that the host name does not have underscores.

For example, example.com

If you have already created a database instance with a preconfigured Management Repository using the database templates offered by Oracle, then provide details about that database instance.

If you are connecting to an Oracle RAC Database, and if the nodes have virtual host names, then enter the virtual host name of one of its nodes.

The connection to the database is established with a connect string that is formed using only this virtual host name, and the installation ends successfully.

However, if you want to update the connect string with other nodes of the cluster, then after the installation, run the following command:

$<OMS_HOME>/bin/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

If your Oracle RAC database is configured with Single Client Access Name (SCAN) listener, then you can enter a connection string using the SCAN listener.

Note: If you connect to a database instance that was created using the database template offered by Oracle, then note that the password assigned to the user accounts SYSMAN_MDS, SYSMAN_APM, and SYSMAN_OPSS, which were created while preconfiguring the Management Repository, are automatically reset with the SYSMAN password you enter for the SYSMAN_PASSWORD parameter.

LISTENER_PORT

Enter the listener port to connect to the existing database.

For example, 1521

SERVICENAME_OR_SID

Enter the service name or the system ID (SID) of the existing database.

For example, orcl

SYS_PASSWORD

Enter the SYS user account's password.

DEPLOYMENT_SIZE

Set one of the following values to indicate the number of targets you plan to monitor, the number Management Agents you plan to have, and the number of concurrent user sessions you plan have.

- Small, to monitor up to 999 targets, with up to 99 Management Agents and up to 10 concurrent user sessions

- Medium, to monitor about 1000 to 9999 targets, with about 100 to 999 Management Agents and about 10 to 24 concurrent user sessions

- Large, to monitor 10,000 or more targets, with 1000 or more Management Agents, and with about 25 to 50 concurrent user sessions

The prerequisite checks are run regardless of the selection you make, but the values to be set for the various parameters checked depend on the selection you make.

For more information on deployment sizes, the prerequisite checks that are run, the database parameters that are set, and how you can modify the deployment size after installation, refer to What is a Deployment Size?.

SYSMAN_PASSWORD

Enter a password for creating a SYSMAN user account. This password is used to create the SYSMAN user, which is the primary owner of the Management Repository schema.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

Note: If you connect to a database instance that was created using the database template offered by Oracle, then note that the password assigned to the user accounts SYSMAN_MDS, SYSMAN_APM, and SYSMAN_OPSS, which were created while preconfiguring the Management Repository, are automatically reset with the SYSMAN password you enter for this parameter.

SYSMAN_CONFIRM_PASSWORD

Confirm the SYSMAN user account's password.

MANAGEMENT_TABLESPACE_LOCATION

Enter the absolute path to the location where the data file for management tablespace (mgmt.dbf) can be stored. Ensure that the specified path leads up to the file name.

For example:

- If the database is on a file system, then the path must look like /u01/oracle/prod/oradata/mgmt.dbf

- If the database is on Automatic Storage Management (ASM), then the path must look like +<disk_group1>/prod/oradata/mgmt.dbf, where disk_group1 is a diskgroup created on ASM and prod is the Service ID (SID).

- If the database is on a raw device, then the path must look like </dev/raw1>/prod/oradata/mgmt.dbf, where /dev/raw1 is the raw device and prod is the SID.

Enterprise Manager Cloud Control requires this data file to store information about the monitored targets, their metrics, and so on. Essentially, everything else other than configuration data, software library data, and audit data.

CONFIGURATION_DATA_TABLESPACE_LOCATION

Enter the absolute path to the location where the data file for configuration data tablespace (mgmt_ecm_depot1.dbf) can be stored. Ensure that the specified path leads up to the file name.

For example, /home/john/oradata/mgmt_ecm_depot1.dbf

Enterprise Manager Cloud Control requires this data file to store configuration information collected from the monitored targets.

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

Enter the absolute path to a location where the data file for JVM Diagnostics data tablespace (mgmt_ad4j.dbf) can be stored. Ensure that the specified path leads up to the file name.

For example, /home/john/oradata/mgmt_ad4j.dbf

Enterprise Manager Cloud Control requires this data file to store monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).

AGENT_REGISTRATION_PASSWORD

Enter a password to secure the communication between the OMS and the Management Agents. Note that you have to provide the same registration password for securing your Management Agents.

AGENT_REGISTRATION_CONFIRM_PASSWORD

Confirm the agent registration password.

STATIC_PORTS_FILE

By default, ports described in What Ports Are Used for Installation? are honored. If you want to accept the default ports, then leave this field blank.

If you want to use custom ports, then enter the absolute path to the staticports.ini file that lists the custom ports to be used for the installation.

Performing Post-Configuration Tasks

Perform the post-install steps as described in the chapter on installing Enterprise Manager system that is available in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Part III

Installing Additional Oracle Management Service

This part contains the following chapters:

- Chapter 5, "Installing Additional Oracle Management Service in Silent Mode"

5 Installing Additional Oracle Management Service in Silent Mode

Oracle recommends you to use the Add Management Service deployment procedure to install an additional Oracle Management Service (OMS). The Add Management Service deployment procedure offers a GUI-rich, interactive way of installing an additional OMS. For instructions, refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide.

However, if you have any security restrictions or audit demands in your environment, or if you are not permitted to use Oracle credentials to log in over the network for installation, then follow these steps to manually install an additional OMS in silent, non-interactive mode.

1. If Oracle Software Library (Software Library) is configured on the main OMS, which comes with Enterprise Manager Cloud Control, then ensure that Software Library is accessible from the remote host where you plan to install the additional OMS.
In this procedure, for easy understanding, the OMS that comes with Enterprise Manager Cloud Control is referred to as the first OMS, and the additional OMS you install is referred to as the additional OMS.

2. On the remote host, perform a software-only installation of the additional OMS as described in Installing in Graphical Mode.

Note:

- Ensure that you install the software binaries in the same middleware location as that of the first OMS.

- At the end of the software-only installation, do NOT run the ConfigureGC.sh or ConfigureGC.bat script as prompted by the installer. That file must be run only when you are performing a fresh installation.

3. Deploy the plug-ins:
$<OMS_HOME>/sysman/install/PluginInstall.sh

On the Plug-In Deployment screen, select the optional plug-ins you want to install.

The screen displays only those plug-ins that were available in the software kit (DVD, downloaded software) you used in the previous step for installing the software binaries.

The pre-selected rows on this screen are mandatory plug-ins that will be installed by default. Select the optional ones you want to install.

Note:

- On Microsoft Windows, run PluginInstall.bat.

- Ensure that you select the same set of plug-ins as the ones on the source OMS (or first OMS).
To identify the plug-ins installed on the source OMS (or first OMS), follow these steps:

1. Connect to the Management Repository and run the following SQL query to retrieve a list of plug-ins installed:
SELECT epv.plugin_id, epv.version, epv.rev_version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id

2. Make a note of the additional plug-ins you installed.

- To install the additional plug-ins that are installed on the source OMS (or first OMS), or to install any additional plug-ins that are not in the software kit you used for installing the binaries, follow these steps:

1. Manually download the plug-ins from the Enterprise Manager Download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the script with the following option, and pass the location where the plug-ins you want to install are available:
$<OMS_HOME>/sysman/install/PluginInstall.sh -pluginLocation <absolute_path_to_plugin_software_location>

The Plug-In Deployment screen displays a list of plug-ins that were available in the software kit as well as the downloaded plug-ins available in this custom location. You can choose the ones you want to install.

4. On the additional OMS, apply all the patches you applied on the first OMS so that both OMS instances are identical and are in sync.
To identify the patches you applied on the first OMS, run the following commands from its Oracle home:

$<OMS_HOME>/OPatch/opatch lsinventory

5. Export the configuration details from the first OMS. To do so, run the following command from the Oracle home of the first OMS and pass the location where you want to configuration details can be exported as a file.
$<OMS_HOME>/bin/emctl exportconfig oms -dir <absolute_path_to_directory>

6. Copy the exported configuration details file from the first OMS host to the additional OMS host.

7. Copy the configuration details onto the additional OMS. To do so, run the following command from the Oracle home of the additional OMS:
$<OMS_HOME>/bin/omsca recover -ms -backup_file <absolute_path_to_the_file_copied_in_step4> [-AS_HTTPS_PORT <port> -MSPORT <port> -MS_HTTPS_PORT <port> -EM_NODEMGR_PORT <port> -EM_UPLOAD_PORT <port> -EM_UPLOAD_HTTPS_PORT <port> -EM_CONSOLE_PORT <port> -EM_CONSOLE_HTTPS_PORT <port> -config_home <absolute_path_to_instance_dir> -EM_INSTANCE_HOST <second_oms_host_name>]

For example,

$<OMS_HOME>/bin/omsca recover -ms -backup_file /opt/oracle/product/backup/opf_ADMIN_20120504_031016.bka -AS_HTTPS_PORT 7101 -MSPORT 7202 -MS_HTTPS_PORT 7301 -EM_NODEMGR_PORT 7403 -EM_UPLOAD_PORT 4889 -EM_UPLOAD_HTTPS_PORT 4900 -EM_CONSOLE_PORT 7788 -EM_CONSOLE_HTTPS_PORT 7799 -config_home /opt/oracle/product/omsmdw/gc_inst -EM_INSTANCE_HOST example.com

8. (Applicable only if you do not already have a Management Agent on the host) Configure the Management Agent on the additional OMS host by running the following command from the OMS home:
$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<middleware_home>/agent OMS_HOST=<second_oms_host_name> EM_UPLOAD_PORT=<second_oms_port> AGENT_REGISTRATION_PASSWORD=<password> -configOnly

Note:
If you have Server Load Balancer (SLB) configured, then directly enter the host name and port number of the SLB. If SLB is not configured, then enter the secure upload port of the first OMS.

9. Deploy the required plug-ins on the Management Agent.
For information about deploying plug-ins, refer to the section Deploying and Updating Plug-ins in the chapter Updating Cloud Control, in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

10. Import the trusted certificate on the additional OMS host, where you configured the Management Agent as described in Step (7). When prompted for a password, enter welcome.
$<AGENT_HOME>/bin/emctl secure add_trust_cert_to_jks

11. Manually discover the Oracle WebLogic Server target.

1. Ensure that both the first and the additional OMS instances are up and running.

2. In the Cloud Control console, from the Targets menu, select Middleware.

3. On the Middleware page, click EMGC_DOMAIN.

4. On the EMGC_DOMAIN home page, from the Farm menu, select Refresh WebLogic Domain.

5. On the Refresh WebLogic Domain page, click Continue.
Enterprise Manager Cloud Control refreshes the WebLogic Domain and discovers the second managed server on the additional OMS host.

For information about discovering the other targets, refer to the chapter Adding Targets in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

For configuring the shared Oracle Software Library location and the Server Load Balancer, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

Part IV

Installing Oracle Management Agent

This part describes the different ways of installing Oracle Management Agent. In particular, this part contains the following chapters:

- Chapter 6, "Installing Oracle Management Agent in Silent Mode"

- Chapter 7, "Cloning Oracle Management Agent"

- Chapter 8, "Installing Shared Agent"

- Chapter 9, "Installing Oracle Management Agent Software Now and Configuring Later"

6 Installing Oracle Management Agent in Silent Mode

This chapter describes how you can install Oracle Management Agent (Management Agent) in silent mode. In particular, this chapter covers the following:

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- After You Install

Overview

Installing a Management Agent in silent mode is only an alternative to installing it using the Add Host Targets Wizard. While the Add Host Targets Wizard requires you to use its GUI-rich interview screens for providing all installation details, the silent mode requires you to use a response file for providing installation details and deployment scripts to install Management Agents on hosts.

Installing in silent mode is useful when you want to install an additional Management Agent on a destination host from the destination host itself, without using the Add Host Targets Wizard.

You can install Management Agents in silent mode using the following methods:

Using the AgentPull Script

To install a Management Agent using the AgentPull.sh (AgentPull.bat for Microsoft Windows) script, you must do the following:

1. Download the AgentPull.sh (AgentPull.bat for Microsoft Windows) script onto the destination host where the Management Agent needs to be installed, using a web browser or a data transfer tool.

2. Execute the script on the destination host to install a Management Agent.

In this method, you do not need to download the Management Agent software onto the destination host before executing the script.

Using the agentDeploy Script

To install a Management Agent using the agentDeploy.sh (agentDeploy.bat for Microsoft Windows) script, you must do the following:

1. Download the Management Agent software for the required platform onto the Oracle Management Service (OMS) host, using EMCLI.

2. Transfer the Management Agent software to the destination host where you want to install the Management Agent. Unzip the software.

3. Execute the agentDeploy.sh (agentDeploy.bat for Microsoft Windows) script on the destination host to install a Management Agent.

Using the RPM File

To install a Management Agent using the .rpm file, you must do the following:

1. Download the .rpm file onto the Oracle Management Service (OMS) host using EMCLI.

2. Transfer the .rpm file to the destination host where you want to install the Management Agent.

3. Install the .rpm file on the destination host to install a Management Agent.

Note:

- The Management Agent .rpm file is available only for Linux x86 and Linux x86-64 platforms.

- From Enterprise Manager 12c Release 1 (12.1.0.1), installing a Management Agent by downloading the Management Agent .rpm file from Oracle Technology Network (OTN) is not supported.

Once the installation is complete, you will see the following default contents in the agent base directory:

<agent_base_directory>
|_____core
|_____12.1.0.2.0
|_____plugins
|_____plugins.txt
|_____plugins.txt.status
|_____agent_inst
|_____sbin
|_____agentimage.properties

Note:

- Using the .rpm file, you can also choose to install a Management Agent while provisioning an operating system on a bare metal host. For more information, see the Oracle Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching. This guide is available in the Enterprise Manager documentation library at:
http://www.oracle.com/technetwork/indexes/documentation/index.html

- If you want to repoint your existing Management Agents to a new Oracle Management Service (OMS), then you must first deinstall those Management Agents and plug-ins, and then redeploy those Management Agents and plug-ins using the new OMS. This is typically done when you want to move from an Enterprise Manager Cloud Control system in a test environment to an Enterprise Manager Cloud Control system in a production environment.
When you repoint your existing Management Agents to a new OMS, you cannot move the targets monitored by the Management Agents, the target history, and the Management Agent history. The monitored targets and the history data is lost.

- If you upgrade a 12c Release 1 (12.1.0.1) Management Agent installed on a host to 12c Release 2 (12.1.0.2), and you want to install another Management Agent on the same host, reporting to a different OMS, ensure that you install the Management Agent after downloading the Management Agent software, and specifying the s_agentSrvcName parameter, as described in Installing Using agentDeploy Script.

Before You Begin

Before you begin installing a Management Agent in silent mode, keep these points in mind:

- You can install a Management Agent on only one host at a time by using the silent methods. Therefore, use this approach when you want to install a Management Agent on only a few hosts.

- The Management Agent software, for the platform on which the destination host is running, must be present on the OMS host. The Management Agent software contains the core binaries required for installation, the response file to be edited and passed, the agentDeploy.sh script (agentDeploy.bat for Microsoft Windows), and the oracle-agt script.
By default, the OMS host contains the Management Agent software for the platform on which the OMS host is running. For example, if the OMS host runs on the Linux x86-64 platform, then the Management Agent software available by default on the OMS host is for the Linux x86-64 platform only.

If you want to install a Management Agent on a platform that is different from the platform on which the OMS is running, you must download and apply the Management Agent software for the required platform, using the Self Update console.

For information on Self Update and how you can use it to download and apply the Management Agent software, see the chapter on Self Update in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

- By default, the OMS host contains the Management Agent software for the platform on which the OMS is running. For example, if the OMS host is Linux x86-64, then the Management Agent software available by default is only for Linux x86-64.
If you want to install the Management Agent on a platform that is different from the one on which the OMS is running, then download and apply the software for the desired platform using the Self Update console.

For information on Self Update and how you can use it to download and apply the software, see the chapter on Self Update in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

- You must run the agentDeploy.sh (agentDeploy.bat for Microsoft Windows) and AgentPull.sh (AgentPull.bat for Microsoft Windows) scripts only from the destination host.

- You cannot run any preinstallation or postinstallation scripts as part of the installation process. Of course, you can run them manually after the installation ends.

- By default, the agentDeploy.sh script (agentDeploy.bat on Windows), AgentPull.sh script (AgentPull.bat for Microsoft Windows), and the .rpm file configures only the following types of plug-ins:

- All discovery plug-ins that were configured with the OMS from where the Management Agent software is being deployed.

- Oracle Home discovery plug-in

- Oracle Home monitoring plug-in

Prerequisites

Before installing a Management Agent in silent mode, ensure that you meet the following prerequisites:

Table 6-1 Prerequisites for Installing Oracle Management Agent in Silent Mode

Requirement

Description

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements. For more information, see the chapter on hardware requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Operating System Requirements

Ensure that you install the Management Agent only on certified operating systems as mentioned in the Enterprise Manager certification matrix available on My Oracle Support.

To access the Enterprise Manager certification matrix, follow the steps outlined in Oracle Enterprise Manager Cloud Control Basic Installation Guide.

For information about platforms receiving future support, refer to My Oracle Support note 793512.1.

Package Requirements

Ensure that you install all the operating system-specific packages. For more information, see the chapter on package requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

If you choose to install a Management Agent using a .rpm file, ensure that the rpm-build package is installed on the host. To verify this, run the following command:

rpm -qa | grep rpm-build

cURL Utility

(For installing using the AgentPull script only)

Ensure that you install the cURL utility on the destination host.

You can download the cURL utility from the following URL:

http://curl.haxx.se/dlwiz/?type=bin

Note: The zip and unzip utilities must be present on the destination host, and must be of version 6.0 or higher. Also, for destination hosts running on Microsoft Windows, Oracle recommends that you install cURL in c:\.

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For more information, see the chapter on creating operating system groups and users in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

/etc/hosts File Requirements

Ensure that the /etc/hosts file on the host has the IP address, the fully qualified name, and the short name in the following format:

172.16.0.0 example.com mypc

Time Zone Requirements

Ensure that the host time zone has been set correctly. To verify the host time zone, run the following command:

echo $TZ

If the time zone displayed is incorrect, run the following commands, before running the agentDeploy.sh or agentDeploy.bat scripts, to set the correct time zone:

- For Korn shell:
TZ=<value>

export TZ

- For Bourne shell or Bash shell:
export TZ=<value>

- For C shell:
setenv TZ <value>

For example, in the Bash shell, run the following command to set the time zone to America/New_York:

export TZ='America/New_York'

The time zones you can use are listed in <AGENT_HOME>/sysman/admin/supportedtzs.lst.

Note: If you had ignored a prerequisite check warning about wrong time zone settings during the Management Agent install, you must set the correct time zone on the host after installing the Management Agent. For information on setting time zones post install, refer After You Install.

PATH Environment Variable Requirements

(For installing using the AgentPull script only)

(For Microsoft Windows) Ensure that the location of zip.exe and unzip.exe is part of the PATH environment variable.

For example, if zip.exe and unzip.exe are present in c:\Program Files\bin, then c:\Program Files\bin must be part of the PATH environment variable.

Path Validation Requirements

Validate the path to all command locations. For more information, refer to the appendix on validating command locations in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

CLASSPATH Environment Variable Requirements

Unset the CLASSPATH environment variable. You can always reset the variable to the original value after the installation is complete.

Port Requirements

Ensure that the default ports described in What Default Ports Are Used? are free.

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied.

By default, the temporary directory location set to the environment variable TMP or TEMP is honored. If both are set, then TEMP is honored. If none of them are set, then the following default values are honored: /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

/var/tmp Requirements

(For installing using the .rpm file only)

Ensure that the /var/tmp directory has at least 700 MB of free space.

/usr/lib/oracle Requirements

(For installing using the .rpm file only)

Ensure that the /usr/lib/oracle directory has at least 2 GB of free space.

Agent Base Directory Requirements

Ensure that the agent base directory is empty and has at least 1 GB of free space.

Ensure that the directory name does not contain any spaces.

Ensure that the installing user owns the installation base directory. Ensure that the installer user or the root user owns all the parent directories. Ensure that the root user owns the root directory.

For example, if the installation base directory is /scratch/OracleHomes/agent, and oracle is the installing user, then the /scratch/OracleHomes/agent directory must be owned by oracle, directories scratch and OracleHomes must be owned by either oracle or root user, and the root directory (/) must be owned by root user.

If the agent base directory is mounted, then ensure that it is mounted with the setuid turned on.

Agent Instance Home Requirements

(For installing using the agentDeploy script only)

Ensure that the agent instance home location you specify in the response file is empty.

Permission Requirements

- Ensure that you have write permission in the agent instance home.

- Ensure that you have write permission in the temporary directory.

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is abc and the user installing the Management Agent is xyz, then ensure that abc and xyz belong to the same group, and they have read and write access to the inventory.

Central Inventory (oraInventory) Requirements

- Ensure that you allocate 100 MB of space for the Central Inventory.

- Ensure that the central inventory directory is not in a shared file system. If it is already in a shared file system, then create a new inventory in a non-shared file system. You can optionally migrate the products that were previously installed in the shared file system to this new inventory in the non-shared file system.

- Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts.
If you do not have these permissions on the default inventory (typically in the location mentioned in the /etc/oraInst.loc file) on any remote host, then ensure that you enter the path to an alternative inventory location using the INVENTORY_LOCATION or -invPtrLoc arguments as described in Table 6-6. Note that these parameters are supported only on UNIX platforms, and not on Microsoft Windows platforms.

Agent User Account Permissions and Rights

(For installing using the AgentPull or agentDeploy scripts only)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based operating system, then ensure that the agent user account has permissions and rights to perform the following:

- Act as part of the operating system.

- Adjust memory quotas for a process.

- Replace process level token.

- Log in as a batch job.

To verify whether the agent user has these rights, follow these steps:

1. Launch the Local Security Policy.
From the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Policy.

2. In the Local Security Policy window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permissions for cmd.exe

(For installing using the AgentPull or agentDeploy scripts only)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based operating system, then ensure that you grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. This is a restriction from Microsoft.

For more information on this restriction and to understand how you can grant these permissions, access the following URL to Microsoft Web site:

http://support.microsoft.com/kb/867466/en-us

Installation Procedure

This section describes the actions involved in installing a Management Agent in silent mode. It consists of the following:

- Installing a Management Agent in Silent Mode

- Creating a Response File for Installing Using AgentPull Script

- Creating a Response File for Installing Using agentDeploy Script

- Creating a Response File for Installing Using an RPM File

- Understanding the Options Supported by the AgentPull Script

- Understanding the Options Supported by the agentDeploy Script

- Understanding the Contents of the Downloaded Management Agent Software

Installing a Management Agent in Silent Mode

This section explains the methods of installing a Management Agent in silent mode. It consists of the following:

- Installing Using AgentPull Script

- Installing Using agentDeploy Script

- Installing Using RPM File

Installing Using AgentPull Script

To install a Management Agent using the AgentPull script, follow these steps:

Download the AgentPull Script onto the Destination Host

1. If the destination host runs on UNIX, access the following URL from the host:
https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage

If the destination host runs on Microsoft Windows, access the following URL from the host:

https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage?script=bat

Save the file as AgentPull.sh (AgentPull.bat for Microsoft Windows) to a temporary directory, say /tmp (c:\temp for Microsoft Windows).

Note:
You can also use the following command to obtain the AgentPull.sh script:
curl "https://<OMS_HOST>:<OMS_PORT>/em/install/getAgentImage" --insecure -o AgentPull.sh

To use this command, ensure that you have the cURL utility installed, as described in Table 6-1.

2. (Only for UNIX Operating Systems) Provide the execute permission to the AgentPull.sh script by running the following command:
chmod +x <absolute_path_to_AgentPull.sh>

For example, run the command chmod +x /tmp/AgentPull.sh.

Install the Management Agent Using the AgentPull Script

1. Identify the platforms for which the Management Agent software is available on the OMS host. Run the AgentPull.sh script (AgentPull.bat for Microsoft Windows) specifying the -showPlatforms option to display the platforms for which the Management Agent software is available on the OMS host.
<absolute_path_to_AgentPull.sh> -showPlatforms

Example 6-1 shows a sample output of the command.

Example 6-1 Output of Running AgentPull.sh Using -showPlatforms

Platforms Version
Linux x86-64 12.1.0.2.0
Microsoft Windows x64 (64-bit) 12.1.0.2.0
IBM AIX on POWER Systems (64-bit) 12.1.0.2.0

2. If the destination host runs on UNIX, and the OMS host runs on Microsoft Windows, run the following command:
dos2unix <absolute_path_to_AgentPull.sh>

For example, run the command dos2unix /tmp/AgentPull.sh.

3. Create a response file agent.rsp (in any location on the destination host) specifying the parameters described in Table 6-2.
Example 6-2 shows the contents of a sample response file.

Example 6-2 Response File Contents

LOGIN_USER=sysman
LOGIN_PASSWORD=welcome
PLATFORM="Linux x86-64"
VERSION=12.1.0.2.0
AGENT_REGISTRATION_PASSWORD=wel246come

4. Run the AgentPull.sh script (AgentPull.bat for Microsoft Windows) specifying the RSPFILE_LOC and AGENT_BASE_DIR parameters.
<absolute_path_to_AgentPull.sh> RSPFILE_LOC=<absolute_path_to_responsefile> AGENT_BASE_DIR=<absolute_path_to_agentbasedir>

For example, run the following command:

/tmp/AgentPull.sh RSPFILE_LOC=/tmp/agent.rsp AGENT_BASE_DIR=/scratch/agent

The AgentPull.sh script supports certain options, such as -download_only, which downloads the Management Agent software, but does not deploy the Management Agent. These supported options are described in Table 6-5.

Installing Using agentDeploy Script

To install a Management Agent using the agentDeploy script, follow these steps:

Download the Management Agent Software onto the OMS Host Using EMCLI

1. On the OMS host, from the OMS home, log in to the EMCLI client. EMCLI Client is available by default with every OMS installation, so you need not install the client separately.
$<OMS_HOME>/bin/emcli login -username=sysman -password=<password>

For example,

$<OMS_HOME>/bin/emcli login -username=sysman -password=2benot2be

Note:

- The user name must always be sysman. Do not enter any other user name.

- If you have configured a load balancer for a multiple OMS setup, ensure that you run the EMCLI commands on one of the local OMS hosts, and not on the load balancer hosts.

- If you have configured a load balancer for a multiple OMS setup, and you choose to use the EMCLI setup command, ensure that you pass the OMS host and port as parameters, and not the load balancer host and port.
For example, emcli setup -url=https://<OMS_HOST>:<OMS_PORT>/em -user=sysman -password=sysman

2. Synchronize EMCLI:
$<OMS_HOME>/bin/emcli sync

3. Identify the platforms for which the Management Agent software is available on the OMS host:
$<OMS_HOME>/bin/emcli get_supported_platforms

This command lists all the platforms for which the Management Agent software is available on the OMS host. Example 6-3 shows a sample output of the command.

Example 6-3 Output Showing Software Availability for Different Platforms

---------------------------------------------------
Version = 12.1.0.2.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 12.1.0.2.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 12.1.0.2.0
Platform Name = HP-UX PA-RISC (64-bit)
---------------------------------------------------

If the output lists the platform on which you want to install the Management Agent, then proceed to the next step. Otherwise, download and apply the software for the required platform using the Self Update console.

For information on Self Update and how you can use it to download and apply the software, refer to the chapter on Self Update in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

4. Download the Management Agent software from Oracle Software Library to a temporary directory on the OMS host:
$<OMS_HOME>/bin/emcli get_agentimage -destination=<download_directory> -platform="<platform>" -version=<version>

For example,

./emcli get_agentimage -destination=/tmp -platform="Linux x86-64" -version=12.1.0.2.0

Ensure that you run the EMCLI get_agentimage command only on the OMS host. This command fails if you run it on any other host.

Note:
In the command, note the following:

- -destination is a directory on the OMS host where you want the Management Agent software to be downloaded. Ensure that you have write permission on this location.
If the destination directory is titled with two or more words separated by a space, then enclose the directory name with double quotes.

For example, if the destination directory is titled /tmp/linux agentimage, then enter the value as -destination="/tmp/linux agentimage"

- -platform is the platform for which you want to download the software; this must match one of the platforms listed in the previous step for which the software is available on the OMS host.

- -version is the version of the Management Agent software that you want to download; this is an optional argument. If you do not pass this argument, then the version is defaulted to the OMS version.

The command downloads the core Management Agent software to the destination directory you entered. For example, for Linux x86-64, you will see the file 12.1.0.2.0_AgentCore_226.zip. For information on the contents of this core software, see Understanding the Contents of the Downloaded Management Agent Software.

Transfer the Management Agent Software to the Destination Host

1. Transfer the downloaded ZIP file to a temporary directory (/tmp) on the destination host where you want to install the Management Agent. You can use any FTP software to transfer the file. For example, FileZilla.

Install the Management Agent Using the agentDeploy Script

1. On the destination host, extract the contents of the ZIP file using the unzip utility:
unzip /tmp/<software_zip_file> -d <software_extract_location>

For example,

unzip /tmp/12.1.0.2.0_AgentCore_46.zip -d /tmp/agtImg

2. Edit the response file agent.rsp as described in Table 6-3.
<software_extract_location>/agent.rsp

3. Invoke the deployment script and pass the response file:
<software_extract_location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile>

Note:

- Instead of creating a response file, you can choose to pass response file parameters explicitly while invoking the deployment script.
The mandatory response file parameters are OMS_HOST, EM_UPLOAD_PORT, and AGENT_REGISTRATION_PASSWORD.

For example,

/tmp/agtImg/agentDeploy.sh AGENT_BASE_DIR=/scratch/agent12c OMS_HOST=example.com EM_UPLOAD_PORT=14511 AGENT_REGISTRATION_PASSWORD=2bornot2b

- When you pass the arguments while invoking the deployment script, these values need not be given with double quotes. However, when you provide them in a response file, the values need to be in double quotes (except for the argument b_startAgent).

- In addition to passing the agent base directory and a response file (or individual mandatory arguments with installation details), you can also pass other options that are supported by the deployment script. For more information, see Understanding the Options Supported by the agentDeploy Script.

4. Run the root scripts when you are prompted. For more information, see After You Install.

Installing Using RPM File

To install a Management Agent using a .rpm file, follow these steps:

Download the RPM File onto the OMS Host

1. On the OMS host, from the OMS home, log in to the EMCLI client. EMCLI Client is available by default with every OMS installation, so you need not install the client separately.
$<OMS_HOME>/bin/emcli login -username=<username> -password=<password>

For example,

$<OMS_HOME>/bin/emcli login -username=sysman -password=2benot2be

2. Synchronize EMCLI:
$<OMS_HOME>/bin/emcli sync

3. Identify the platforms for which the Management Agent software is available on the OMS host:
$<OMS_HOME>/bin/emcli get_supported_platforms

This command lists all the platforms for which the Management Agent software is available on the OMS host. Example 6-4 shows a sample output of the command.

Example 6-4 Output Showing Software Availability for Different Platforms

---------------------------------------------------
Version = 12.1.0.2.0
Platform Name = Linux x86-64
---------------------------------------------------
Version = 12.1.0.2.0
Platform Name = Oracle Solaris on x86-64 (64-bit)
---------------------------------------------------
Version = 12.1.0.2.0
Platform Name = HP-UX PA-RISC (64-bit)
---------------------------------------------------

If the output lists the platform on which you want to install the Management Agent, then proceed to the next step. Otherwise, download and apply the software for the required platform using the Self Update console.

For information on Self Update and how you can use it to download and apply the software, see the chapter on Self Update in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

4. Download the .rpm file of the Management Agent from Oracle Software Library to a temporary directory on the OMS host
$<OMS_HOME>/bin/emcli get_agentimage_rpm -destination=<download_directory> -platform="<platform>" -version=<version>

For example,

./emcli get_agentimage_rpm -destination=/tmp -platform="Linux x86-64" -version=12.1.0.2.0

Note:
In the command, note the following:

- -destination is a directory on the OMS host where you want the .rpm file to be downloaded. Ensure that you have write permission on this location.
If the destination directory is titled with two or more words separated by a space, then enclose the directory name with double quotes.

For example, if the destination directory is titled /tmp/linux agentimage, then enter the value as -destination="/tmp/linux agentimage"

- -platform is the platform for which you want to download the .rpm file; this must match one of the platforms listed in the previous step for which the software is available on the OMS host.

- -version is the version of the Management Agent for which you want to download the .rpm file; this is an optional argument. If you do not pass this argument, then the version is defaulted to the OMS version.

The command downloads the .rpm file of the core Management Agent to the destination directory you entered. For example, oracle-agt-12.1.0.2.0-1.0.i386.rpm

Transfer the RPM File to the Destination Host

1. Transfer the downloaded .rpm file to a temporary directory (/tmp) on the destination host where you want to install the Management Agent. You can use any FTP software to transfer the file. For example, FileZilla.

Install the Management Agent Using the RPM File

1. On the destination host, install the .rpm file as a root user to install the Management Agent:
rpm -ivh <download_directory>/<rpm_file>

For example,

rpm -ivh /tmp/oracle-agt-12.1.0.2.0-1.0.i386.rpm

Note:
The following is the output of the command:

Preparing... ########################################### [100%]
Running the prereq
1:oracle-agt ########################################### [100%]
Follow the below steps to complete the agent rpm installation:
1. Edit the properties file: /usr/lib/oracle/agent/agent.properties with the correct values
2. Execute the command /etc/init.d/oracle-agt RESPONSE_FILE=<location_to_agent.properties>

2. Edit the agent.properties file as described in Table 6-4. The file is available in the following location:
/usr/lib/oracle/agent/agent.properties

3. Run the following command to complete the installation:
/etc/init.d/oracle-agt RESPONSE_FILE=<location_to_agent.properties>

Creating a Response File for Installing Using AgentPull Script

Table 6-2 describes the various parameters you can include in the response file while installing a Management Agent using the AgentPull script.

Table 6-2 Creating a Response File for Installing Oracle Management Agent Using AgentPull Script

Parameter

Description

LOGIN_USER

(Mandatory) Enter the Enterprise Manager console login user name.

For example, LOGIN_USER=sysman

LOGIN_PASSWORD

(Mandatory) Enter the Enterprise Manager console login password.

For example, LOGIN_PASSWORD=welcome1

PLATFORM

(Mandatory) Enter the platform for which you want to download the Management Agent software.

For example, PLATFORM="Linux x86-64"

Note: The value of this parameter must be in " ".

VERSION

(Optional) Enter the version of the Management Agent software you want to download.

For example, VERSION=12.1.0.2.0

If you do not specify this parameter, it is assigned the OMS version.

AGENT_REGISTRATION_PASSWORD

(Mandatory) Enter a password for registering new Management Agents that join the Enterprise Manager system.

By default, the communication between the OMS and the Management Agents is secured and locked. Any new Management Agents that join the Enterprise Manager system must be authenticated before they become part of the system. The password you enter here will be used for authenticating those new Management Agents.

For example, AGENT_REGISTRATION_PASSWORD=Wel456come

CURL_PATH

(For Microsoft Windows destination hosts only)

(Optional) Enter the absolute path of the installed cURL utility.

For example, CURL_PATH=c:\Program Files\curl

If you do not include this parameter, it is assigned the value c:\.

Creating a Response File for Installing Using agentDeploy Script

Table 6-3 describes the various parameters you must include in the response file while installing a Management Agent using the agentDeploy script.

Table 6-3 Creating a Response File for Installing Oracle Management Agent Using agentDeploy Script

Parameter

Description

OMS_HOST

(Mandatory) Enter the OMS host name.

For example, OMS_HOST=example.com

EM_UPLOAD_PORT

(Mandatory) Enter the upload port (HTTP or HTTPS) for communicating with the OMS.

For example, EM_UPLOAD_PORT=14511

AGENT_REGISTRATION_PASSWORD

(Mandatory) Enter a password for registering new Management Agents that join the Enterprise Manager system.

By default, the communication between the OMS and the Management Agents is secured and locked. Any new Management Agents that join the Enterprise Manager system must be authenticated before they become part of the system. The password you enter here will be used for authenticating those new Management Agents.

For example, AGENT_REGISTRATION_PASSWORD=Wel456come

AGENT_INSTANCE_HOME

(Optional) Enter a directory location on the destination host where all Management Agent-related configuration files can be stored. For this parameter, you can do one of the following:

- Leave it blank.
In this case, by default, an instance directory titled agent_inst is created in the agent installation base directory.

For example, if the installation base directory is /john/oracle/, then the instance directory is defaulted to /john/oracle/agent_inst

- Enter the absolute path to a custom directory.
Although you can enter any location as a custom location, Oracle recommends you to maintain the instance directory inside the installation base directory.

For example, AGENT_INSTANCE_HOME=/john/oracle/instance_dir/inst_mydir

AGENT_PORT

(Optional) Enter a free port on which the Management Agent process should be started. The same port is used for both HTTP and HTTPS.

For example, AGENT_PORT=1832

If you do not enter any value, then either 3872 or any free port between 1830 and 1849 is honored.

b_startAgent

(Optional) Enter TRUE if you want the Management Agent to start automatically once it is installed and configured. Otherwise, enter FALSE.

For example, b_startAgent=TRUE

If you do not include this parameter, it defaults to TRUE.

ORACLE_HOSTNAME

(Optional) Enter the fully qualified domain name of the host where you want to install the agent.

For example, ORACLE_HOSTNAME=example.com

If you do not include this parameter, it defaults to the physical host name.

s_agentHomeName

(Optional) Enter the name of the Oracle home you want to see created for the Management Agent.

For example, s_agentHomeName=agent12cR2

If you do not include this parameter, it defaults to agent12cn, where n is 1 for the first Management Agent installed on the host, 2 for the second Management Agent installed on the host, and so on.

s_agentSrvcName

(Optional) Enter the customized Management Agent service name.

For example, s_agentSrvcName=agentsrvc1

If you do not include this parameter, it defaults to Oracle+<oracle_home_name>+Agent.

Note: If you upgrade a 12c Release 1 (12.1.0.1) Management Agent installed on a host to 12c Release 2 (12.1.0.2), and you want to install another Management Agent on the same host, ensure that you install the Management Agent after downloading the Management Agent software, and specifying the s_agentSrvcName parameter.

Creating a Response File for Installing Using an RPM File

Table 6-4 describes the various parameters you can include in the agent.properties response file while installing a Management Agent using a .rpm file.

Table 6-4 Creating a Response File for Installing Oracle Management Agent Using an RPM File

Parameter

Description

OMS_HOST

(Mandatory) Enter the host name of the OMS to which you want to connect.

For example, OMS_HOST=example.com

OMS_PORT

(Mandatory) Enter the upload port (HTTP or HTTPS) to communicate with the OMS.

For example, OMS_PORT=1835

AGENT_REGISTRATION_PASSWORD

(Mandatory) Enter a password for registering new Management Agents that join the Enterprise Manager system.

By default, the communication between the OMS and the Management Agents is secured and locked. Any new Management Agents that join the Enterprise Manager system must be authenticated before they become part of the system. The password you enter here will be used for authenticating those new Management Agents.

For example, AGENT_REGISTRATION_PASSWORD=Wel456come

AGENT_USERNAME

(Mandatory) Enter the user name with which you want to install the Management Agent.

For example, AGENT_USERNAME=sysman

AGENT_GROUP

(Mandatory) Enter the group to which the Management Agent user should belong.

For example, AGENT_GROUP=group1

AGENT_PORT

(Optional) Enter the port used for the Management Agent process.

For example, AGENT_PORT=1832

If you do not enter any value, then either 3872 or any free port between 1830 and 1849 is honored.

ORACLE_HOSTNAME

(Only for Virtual Hosts) Enter the virtual host name where you want to install the Management Agent.

For example, ORACLE_HOSTNAME=example.com

Understanding the Options Supported by the AgentPull Script

Table 6-5 lists the options supported by the AgentPull.sh script. On Microsoft Windows, these options apply to the AgentPull.bat file.

Table 6-5 Understanding the Options Supported by AgentPull.sh/AgentPull.bat

Option

Description

-download_only

Only downloads the Management Agent software. Does not deploy the Management Agent.

-showPlatforms

Displays the platforms for which the Management Agent software is available on the OMS host. Does not install the Management Agent.

-help

Displays command line help and describes the usage of the AgentPull.sh script.

Understanding the Options Supported by the agentDeploy Script

Table 6-6 lists the options supported by the agentDeploy.sh script. On Microsoft Windows, these options apply to the agentDeploy.bat file.

Table 6-6 Understanding the Options Supported by agentDeploy.sh/agentDeploy.bat

Option

Description

-prereqOnly

Runs only the prerequisite checks. Does NOT actually install the Management Agent.

This option is useful when you want to verify whether your environment meets all the prerequisites for a successful Management Agent installation.

-ignorePrereqs

Skips running the prerequisite checks. Use this when you have already used the -prereqOnly option and verified the prerequisites, and only want to install the software binaries.

-invPtrLoc

Considers the Oracle Inventory directory for storing inventory details. Enter the absolute path to the oraInst.loc file that contains the location of the OraInventory directory.

Important: If you enter a value for this option, do NOT use the INVENTORY_LOCATION option. Also note that this parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

INVENTORY_LOCATION

Considers the Oracle Inventory directory for storing inventory details. Enter the absolute path to the OraInventory directory.

Important:

- If you enter a value for this option, do NOT use the -invPtrLoc option.

- Do NOT use this option if you already have the /var/opt/oracle/oraInst.loc on HP and Solaris platforms, and /etc/oraInst.loc file on all other UNIX platforms.

- This parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

-help

Displays command line help and describes the usage of the deployment script.

-debug

Logs more debug messages useful for debugging and resolving errors.

-ignoreUnzip

Skips extracting the software binaries of the Management Agent software. Use this when you do not want to copy the binaries again, but only want to configure the available binaries.

-softwareOnly

Installs only the software binaries, and does NOT configure the installation. Use this when you want to perform a software-only installation of the Management Agent. For more information, see Chapter 9.

Note: This option does not apply if you are cloning using a ZIP file.

-configOnly

Configures the software binaries, and does not install any software binaries. Use this when you have performed a software-only installation using the -softwareOnly option, so that only the configuration is done to the copied software binaries. For more information, see Chapter 9.

Note: This option does not apply if you are cloning using a ZIP file.

-forceConfigure

Forcefully configures the Management Agent even when the OMS is unreachable. Use this option only when you are installing the Management Agent before installing the OMS, and when you know for sure that you will install the OMS later on the same host and port mentioned for the parameters OMS_HOST and EM_UPLOAD_PORT, respectively, in the response file you pass.

If you pass this option, then do not pass -configOnly, -softwareOnly, and -prereqOnly.

Note: When you pass this option, the Management Agent is configured to use HTTP (non-secure) communication. To establish a secure HTTPS communication between the Management Agent and the OMS, you must manually secure the Management Agent after the OMS is available.

Understanding the Contents of the Downloaded Management Agent Software

Table 6-7 describes the contents of the core Management Agent software you download before installing the Management Agent using the agentDeploy script.

Table 6-7 Contents of the Downloaded Management Agent Software

Files

Description

12.1.0.2.0_PluginsOneoffs_<platform id>.zip

Plug-in ZIP file containing all the discovering plug-ins, which were installed with the OMS, Oracle Home discovery plug-in, and Oracle Home monitoring plug-in.

agentcoreimage.zip

Archived ZIP file containing the core agent bits and agent set-uid binaries.

agentDeploy.sh/agentDeploy.bat

Script used for deploying the Management Agent.

unzip

Utility used for unarchiving the ZIP files.

agentimage.properties

Properties file used for getting the version, platform ID, and so on.

agent.rsp

Response file to be edited and passed for installing the Management Agent.

Understanding the Contents of the Management Agent RPM File

If you choose to install a Management Agent using the .rpm file, the .rpm file you download contains an agent base directory. Table 6-8 describes the contents of this agent base directory:

Table 6-8 Contents of the Agent Base Directory Present in RPM File

Element

Description

core/12.1.0.2.0

Contains the Management Agent software.

sbin

Contains the Management Agent binaries.

plugins.txt

Response file specifying the plug-ins deployed on the Management Agent.

plugins

Contains the plug-in software.

agentimage.properties

Properties file used for getting the version, platform ID, and so on.

agent.properties

Response file to be edited and passed for installing the Management Agent.

oracle-agt

Management Agent configuration script.

After You Install

After you install the Management Agent, follow these steps:

1. (Only for UNIX Operating Systems) Manually run the following scripts as a root user. If you do not have SUDO privileges, then request your Administrator who has the privileges to run these scripts.

- If this is the first Oracle product you just installed on the host, then run the oraInstroot.sh script from the inventory location specified in the oraInst.loc file that is available in the Management Agent home.
For example, if the inventory location specified in the oraInst.loc file is $HOME/oraInventory, then run the following command:

$HOME/oraInventory/oraInstRoot.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/bin/sudo $HOME/oraInventory/oraInstRoot.sh

- Run the root.sh script from the Management Agent home:
$<AGENT_HOME>/root.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/bin/sudo $<AGENT_HOME>/root.sh

Note:
You do not need to run the oraInstroot.sh and root.sh scripts if you are installing a Management Agent using a .rpm file.

2. Verify the installation:

1. Navigate to the Management Agent home and run the following command to see a message that confirms that the Management Agent is up and running:
$<AGENT_INSTANCE_HOME>/bin/emctl status agent

Note:
If the status of the Management Agent is down for some reason, then manually start the Management Agent by running the following command from its Oracle home:
$<AGENT_INSTANCE_HOME>/bin/emctl start agent

2. Navigate to the Management Agent home and run the following command to see a message that confirms that EMD upload completed successfully:
$<AGENT_INSTANCE_HOME>/bin/emctl upload

3. Verify if all the plug-ins were installed successfully. To do so, access the following log file from the Management Agent home, and search for the sentence WARN:Plugin configuration has failed.
$<AGENT_HOME>/cfgtoollogs/cfgfw/CfmLogger-<timestamp>.log

For example,

$/u01/agent/core/12.1.0.2.0/cfgtoollogs/cfgfw/CfmLogger-<timestamp>.log

If you find the sentence, resolve the issue by running the AgentPluginDeploy.pl script from the Management Agent home.

$<AGENT_BASE_DIR>/agent/core/12.1.0.2.0/perl/bin/perl <AGENT_BASE_DIR>/agent/core/12.1.0.2.0/bin/AgentPluginDeploy.pl -oracleHome <AGENT_BASE_DIR>/agent/core/12.1.0.2.0 -agentDir <AGENT_BASE_DIR> -pluginIdsInfoFile <AGENT_BASE_DIR>/plugins.txt -action configure -emStateDir <AGENT_INSTANCE_HOME>

For example,

/u01/agent/core/12.1.0.2.0/perl/bin/perl /u01/agent/core/12.1.0.2.0/bin/AgentPluginDeploy.pl -oracleHome /u01/agent/core/12.1.0.2.0/ -agentDir /u01/agent -pluginIdsInfoFile /u01/agent/plugins.txt -action configure -emStateDir /u01/agent/agent_inst

4. If you had ignored a prerequisite check warning about wrong time zone settings, follow these steps:

1. Set the correct time zone on the required host.
For information on how to set the time zone on a host, refer Time Zone Requirements in Table 6-1.

2. Deinstall the Management Agent present on the host.
For information on how to deinstall a Management Agent, refer to Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

3. Install a Management Agent on the host.

5. By default, the host and the Management Agent get automatically added to the Enterprise Manager Cloud Control console for monitoring. None of the targets running on that host get automatically discovered and monitored.
To monitor the other targets, you must add them to Enterprise Manager Cloud Control either using the Auto Discovery Results page, the Add Targets Manually page, or the discovery wizards offered for the targets you want to monitor.

For information about discovering targets in Enterprise Manager Cloud Control, refer to the chapter on adding targets in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

Note:
If you want to repoint your existing Management Agents to a new Oracle Management Service (OMS), then you must first deinstall those Management Agents and plug-ins, and then redeploy those Management Agents and plug-ins using the new OMS. This is typically done when you want to move from an Enterprise Manager Cloud Control system in a test environment to an Enterprise Manager Cloud Control system in a production environment.
When you repoint your existing Management Agents to a new OMS, you cannot move the targets monitored by the Management Agents, the target history, and the Management Agent history. The monitored targets and the history data is lost.

7 Cloning Oracle Management Agent

This chapter explains how you can clone an existing Oracle Management Agent (Management Agent). In particular, this section covers the following:

- Overview

- Before You Begin

- Prerequisites

- Cloning Procedure

- After You Clone

Overview

Oracle Management Agent (Management Agent) is one of the core components of Enterprise Manager Cloud Control that enables you to convert an unmanaged host to a managed host in the Enterprise Manager system. The Management Agent works in conjunction with the plug-ins to monitor the targets running on that managed host.

Therefore, if you want to monitor a target running on a host, you must first convert that unmanaged host to a managed host by installing an Oracle Management Agent, and then manually discover the targets running on it to start monitoring them.

However, the Management Agent you install using other installation types is always a fresh installation without any customized configuration that you had done or interim one-off patches that you had applied to other running Management Agents.

If you want to install an additional Management Agent that is identical to the existing well-tested, pre-patched, and running Management Agent, then the best option is to clone the existing instance. This saves time and effort in patching a fresh installation all over again and bringing it to the current state.

You can clone an existing Management Agent in graphical or silent mode.

- In graphical mode, you use the Add Host Targets Wizard that is accessible from within the Enterprise Manager Cloud Control console. The wizard enables you to select a source Management Agent, which you want to clone, and identify one or more remote hosts on which you want to clone it.
The wizard first copies the source Management Agent image to the host on which Oracle Management Service (OMS) is running, and then, it transfers that copied image to the destination hosts. Although the wizard can be used for remotely cloning one, single Management Agent, it is best suited for mass-deployment of Management Agents, particularly while mass-deploying Management Agents of different releases on hosts of different platforms.

- In silent mode, you use a compressed file (ZIP), which you transfer. Understandably, this is a much easier method because you compress the Oracle home of an existing Management Agent and transfer it to the destination host without having to specify any parameters or values in an interview screen, but still retaining all its configuration settings and applied one-off patches.
However, in silent mode, you can install only on one destination host at any given time. Once you are done with cloning of a Management Agent on a host, you must redo the procedure to clone on another host. Therefore, you cannot clone on multiple hosts simultaneously, and as a result, this approach is best suited when you want to clone only on a few hosts, one host after the other.

Understandably, as a prerequisite, you need to have at least one Management Agent in your environment, and its software binaries must be accessible from all the hosts where you want to clone an additional Management Agent. Therefore, note that this installation type must be used for installing only additional Management Agents in your environment.

After installing a Management Agent, to monitor a target, add the target to Enterprise Manager Cloud Control either using the Auto Discovery Results page, the Add Targets Manually page, or the discovery wizards offered for the targets you want to monitor.

For information about discovering targets in Enterprise Manager Cloud Control, refer to the chapter on adding targets in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

Once the installation is complete, you will see the following default contents in the agent base directory:

<agent_base_directory>
|_____core
|_____12.1.0.2.0
|_____plugins
|_____plugins.txt
|_____agent_inst
|_____sbin
|_____agentimage.properties

Note:
If you want to repoint your existing Management Agents to a new Oracle Management Service (OMS), then you must first deinstall those Management Agents and plug-ins, and then redeploy those Management Agents and plug-ins using the new OMS. This is typically done when you want to move from an Enterprise Manager Cloud Control system in a test environment to an Enterprise Manager Cloud Control system in a production environment.
When you repoint your existing Management Agents to a new OMS, you cannot move the targets monitored by the Management Agents, the target history, and the Management Agent history. The monitored targets and the history data is lost.

Before You Begin

Before you begin installing an Oracle Management Agent, keep these points in mind:

- (Only for Graphical Mode) The Add Host Targets Wizard converts an unmanaged host to a managed host in the Enterprise Manager system by cloning an existing Oracle Management Agent.

- Oracle Management Agent 12c communicates only with Oracle Management Service 12c and not with any earlier release of Enterprise Manager.

- (Only for Graphical Mode) Using the Add Host Targets Wizard, you can clone only when the source host (from where you are cloning the Management Agent) and the destination host are running on the same operating system. Therefore, if you have hosts running on different platforms, then you must have one deployment session per platform.

- While cloning, the source Management Agent is not shut down.

- (Only for Graphical Mode) If you have multiple hosts, sharing a common mounted drive, then install the Management Agents in two different phases:

1. First, clone the Management Agent to the host where the drive is shared by selecting the deployment type Clone Existing Agent in the Add Host Targets Wizard. Follow the instructions outlined in this chapter.

2. Then, install a Management Agent on all other hosts that access the shared, mounted drive by selecting the deployment type Add Host to Shared Agent in the Add Host Targets Wizard. (Here, you will select the Management Agent you installed in the previous step.) For more information, follow the instructions outlined in Chapter 8.

- Cloning on shared clusters is NOT supported. If you have an Oracle RAC Cluster with multiple nodes, then you must clone the Management Agent on each of the nodes separately. In other words, in the Add Host Targets Wizard, you must add each node explicitly as a destination host.

- (Only for Graphical Mode) The Add Host Targets Wizard uses SSH to establish connectivity between Oracle Management Service (OMS) and the remote hosts where you want to install the Management Agents

- (Only for Graphical Mode) Only SSH1 (SSH version 1) and SSH2 (SSH version 2) protocols offered by OpenSSH are supported for deploying a Management Agent.

- (Only for Graphical Mode) SSH public key authentication and password-based authentication are supported. So you can use an existing SSH public key authentication without exposing your passwords. You can provide a dummy password in the wizard, and the wizard will internally use the underlying public key infrastructure to perform the installation.
To set up SSH public key authentication, follow these steps:

1. Navigate to the following location in the OMS home:
$<OMS_HOME>/oui/prov/resources/scripts

For example,

/home/software/em/middleware/oms/oui/prov/resources/scripts

2. Run the following script on the OMS host as the OMS user, and pass the Management Agent install user name and the fully qualified name of the target hosts:
sshUserSetup.sh -setup -user <agent_install_1user_name> -hosts <target_hosts>

3. Access the Add Host Targets Wizard, and provide the dummy password and install the Management Agent.

The wizard ignores the dummy password, and honors the keys present in the following location on the OMS host to perform the installation. Here, $HOME refers to the home directory of the OMS install user.

- $HOME/.ssh/id_rsa

- $HOME/.ssh/id_dsa

- $HOME/.ssh/identity

If you want to provide additional keys, specify them as values for the oracle.sysman.prov.remoteinterfaces.identitylist property present in the $<OMS_HOME>/sysman/prov/agentpush/agentpush.properties file, using a comma separated list.

- (Only for Graphical Mode) The Add Host Targets Wizard supports Named Credentials that enable you to use a set of credentials registered with a particular name specifically for this operation, by your administrator. This ensures an additional layer of security for your passwords because as an operator, you can only select the named credential, which is saved and stored by an administrator, and not know the actual user name and password associated with it.
In case the named credential you select does not have the privileges to clone, then you can set the named credential to run as another user (locked user account). In this case, the wizard logs in to the hosts using the named credential you select, but clones using the locked user account you set.

For example, you can create a named credential titled User_A, and set it to run as User_X that has the required privileges. In this case, the wizard logs in to the hosts as User_A, but installs as User_X, using the privilege delegation setting (sudo or PowerBroker) specified in the named credential.

- By default, the Add Host Targets Wizard configures all the plug-ins that were configured with the Management Agent you are cloning.

- You must have read privileges on the Oracle WebLogic Server's alert log directories for the Support Workbench (Incident) metrics to work properly. You must also ensure that the Management Agent that is monitoring this Oracle WebLogic Server target is running on the same host as the Oracle WebLogic Server.

Prerequisites

Before cloning the Management Agent, ensure that you meet the following prerequisites.

Table 7-1 Prerequisites for Cloning Oracle Management Agent

Requirement

Description

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements. For more information, see the chapter on hardware requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Software Requirements

(Only for Graphical Mode)

(For Microsoft Windows) Ensure that you have installed Cygwin 1.7 on the destination host. For more information, see the chapter on installing Cygwin in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Note: While running cygwin.bat in Microsoft Windows Server 2008 and Microsoft Windows Vista, ensure that you invoke it in administrator mode. To do this, right-click the cygwin.bat file and select Run as administrator.

Operating System Requirements

Ensure that you install the Management Agent only on certified operating systems as mentioned in the Enterprise Manager certification matrix available on My Oracle Support.

To access the Enterprise Manager certification matrix, follow the steps outlined in Oracle Enterprise Manager Cloud Control Basic Installation Guide.

For information about platforms receiving future support, refer to My Oracle Support note 793512.1.

Note: If you use Oracle Solaris 10, then ensure that you have update 9 or higher installed. To verify whether it is installed, run the following command:

cat /etc/release

You should see the output similar to the following. Here, s10s_u6 indicates that update 6, which is not a supported update level for installation, is installed.

Solaris 10 10/08 s10s_u6wos_07b SPARC

Package Requirements

Ensure that you install all the operating system-specific packages. For more information, see the chapter on package requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For more information, see the chapter on creating operating system groups and users in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

/etc/hosts File Requirements

Ensure that the /etc/hosts file on the host has the IP address, the fully qualified name, and the short name in the following format:

172.16.0.0 example.com mypc

Destination Host Requirements

Ensure that the destination hosts are accessible from the host where the OMS is running.

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is example.com and the short name is mypc, then add the following line in the /etc/hosts file:

172.16.0.0 example.com mypc

Destination Host Credential Requirements

(Only for Graphical Mode)

Ensure that all the destination hosts running on the same operating system have the same set of credentials. For example, all the destination hosts running on Linux operating system must have the same set of credentials.

The wizard installs the Management Agent using the same user account. If you have hosts running on the same operating system but with different credentials, then have two different deployment sessions.

Destination Host Time Zone Requirements

(Only for Graphical Mode)

Ensure that the time zones of the destination hosts have been set correctly. To verify the time zone of a destination host, log in to the OMS host, and run the following command:

ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

If the time zone displayed is incorrect, log in to the destination host, and follow these steps:

1. Run the following commands to set the time zone on the destination host:

- For Korn shell:
TZ=<value>

export TZ

- For Bourne shell or Bash shell:
export TZ=<value>

- For C shell:
setenv TZ <value>

For example, in the Bash shell, run the following command to set the time zone to America/New_York:

export TZ='America/New_York'

The time zones you can use are listed in <AGENT_HOME>/sysman/admin/supportedtzs.lst.

2. Restart the SSH daemon.
If the destination host runs on a UNIX based operating system, run the following command:

sudo /etc/init.d/sshd restart

If the destination host runs on a Microsoft Windows operating system, run the following commands:

cygrunsrv -E sshd

cygrunsrv -S sshd

3. Verify whether the SSH server can access the TZ environment variable by logging in to the OMS host, and running the following command:
ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

Note: If you had ignored a prerequisite check warning about wrong time zone settings during the cloning procedure, you must set the correct time zone on the destination hosts after cloning the Management Agent. For information on setting time zones post cloning, refer After You Clone.

Time Zone Requirements

(Only for Silent Mode)

Ensure that the host time zone has been set correctly. To verify the host time zone, run the following command:

echo $TZ

If the time zone displayed is incorrect, run the following commands, before running the agentDeploy.sh or agentDeploy.bat scripts, to set the correct time zone:

- For Korn shell:
TZ=<value>

export TZ

- For Bourne shell or Bash shell:
export TZ=<value>

- For C shell:
setenv TZ <value>

For example, in the Bash shell, run the following command to set the time zone to America/New_York:

export TZ='America/New_York'

The time zones you can use are listed in <AGENT_HOME>/sysman/admin/supportedtzs.lst.

Note: If you had ignored a prerequisite check warning about wrong time zone settings during the cloning procedure, you must set the correct time zone on the host after cloning the Management Agent. For information on setting time zones post cloning, refer After You Clone.

sudo/pbrun/sesu/su SSH Requirements

(Only for Graphical Mode)

(Only for UNIX)

Ensure that you set the oracle.sysman.prov.agentpush.enablePty property to true in the $<OMS_HOME>/sysman/prov/agentpush/agentpush.properties file, if the privilege delegation tool you are using requires a pseudo terminal for remote command execution via SSH. Most privilege delegation tools such as pbrun, sesu, and su require a pseudo terminal for remote command execution, by default.

Note: If you are using sudo as your privilege delegation tool, and you do not want to set the oracle.sysman.prov.agentpush.enablePty property to true, do one of the following:

- Include Defaults visiblepw in the /etc/sudoers file, or enter the sudo command with the -S option for Privileged Delegation Setting on the Installation Details page.
For information on how to access the Installation Details page, see Cloning in Graphical Mode.

- Comment out Defaults requiretty in the /etc/sudoers file.

sudo/pbrun/sesu/su Requirements (for Root User)

(Only for Graphical Mode)

(Only for UNIX)

- Ensure that the installing user has the privileges to invoke the id command and the agentdeployroot.sh script as root. Grant the privileges in the configuration file of your privilege delegation tool.
For example, if you are using sudo as your privilege delegation tool, include the following in the /etc/sudoers file to grant the required privileges:

oracle ALL=(root) /usr/bin/id, /home/oracle/agentibd/*/agentdeployroot.sh

Here, oracle is the installing user, and /home/oracle/agentibd is the agent base directory.

- You do not require the following entry in the /etc/sudoers file for installing a Management Agent. However, the entry is required for performing provisioning and patching operations in Enterprise Manager. Therefore, if you are removing this entry before installing a Management Agent, then ensure that you bring back the entry after installing the Management Agent.
(root)/oracle/product/oms12c/agent/agent_inst/bin/nmosudo

sudo/pbrun/sesu/su Requirements (for Locked Account User)

(Only for Graphical Mode)

(Only for UNIX)

- Ensure that the installing user has the privileges to invoke /bin/sh as the locked account user. Grant the privileges in the configuration file of your privilege delegation tool.
For example, if you are using sudo as your privilege delegation tool, include the following in the /etc/sudoers file to grant the required privileges:

login_user1 ALL=(oracle) /bin/sh

Here, login_user1 is the SSH log in user, and oracle is the locked account and install user.

If you do not want to grant privileges to the installing user to invoke /bin/sh as the locked account user, set the oracle.sysman.prov.agentpush.pdpShellOutEnabled property to false, and ensure that the installing user has the privileges to invoke id, chmod, cp, mkdir, rm, tar, emctl, agentDeploy.sh, runInstaller, and unzip as the locked account user. Grant the privileges in the configuration file of your privilege delegation tool.

For example, if you are using sudo as your privilege delegation tool, include the following in the /etc/sudoers file to grant the required privileges:

login_user1 ALL=(oracle) /usr/bin/id, /bin/chmod, /bin/cp, /bin/mkdir, /bin/rm, /bin/tar, /home/oracle/agentibd/agent_inst/bin/emctl, /home/oracle/agentibd/*/agentDeploy.sh, /home/oracle/agentibd/*/prereq_stage/core/12.1.0.2.0/oui/bin/runInstaller, /home/oracle/agentibd/*/unzip, /home/oracle/agentibd/*/unzipTmp/unzip

Here, login_user1 is the SSH log in user, oracle is the locked account and install user, and /home/oracle/agentibd is the agent base directory.

- You do not require the following entry in the /etc/sudoers file for installing a Management Agent. However, the entry is required for performing provisioning and patching operations in Enterprise Manager. Therefore, if you are removing this entry before installing a Management Agent, then ensure that you bring back the entry after installing the Management Agent.
(root)/oracle/product/oms12c/agent/agent_inst/bin/nmosudo

Permission Requirements

- Ensure that the agent base directory you specify is empty and has write permission.

- Ensure that the instance directory is empty and has write permission.

PATH Environment Variable Requirements

(Only for Graphical Mode)

On the destination host, ensure the following:

- (For Microsoft Windows) Ensure that the Cygwin software location appears before other software locations in the PATH environment variable. After making it the first entry, restart the SSH daemon (sshd).

- (For UNIX) On the destination host, ensure that the SCP binaries (for example, /usr/bin/scp) are in the PATH environment variable:

Path Validation Requirements

Validate the path to all command locations. For more information, see the appendix on validating command locations in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

CLASSPATH Environment Variable Requirements

Unset the CLASSPATH environment variable. You can always reset the variable to the original value after the installation is complete.

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied.

By default, the temporary directory location set to the environment variable TMP or TEMP is honored. If both are set, then TEMP is honored. If none of them are set, then the following default values are honored: /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Agent Base Directory Requirements

Ensure that the agent base directory is empty and has at least 1 GB of free space.

Ensure that the directory name does not contain any spaces.

Ensure that the installing user owns the agent base directory. Ensure that the installer user or the root user owns all the parent directories. Ensure that the root user owns the root directory.

For example, if the agent base directory is /scratch/OracleHomes/agent, and oracle is the installing user, then the /scratch/OracleHomes/agent directory must be owned by oracle, directories scratch and OracleHomes must be owned by either oracle or root user, and the root directory (/) must be owned by root user.

If the agent base directory is mounted, then ensure that it is mounted with the setuid turned on.

Default SSH Port Requirements

(Only for Graphical Mode)

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts. To verify the port, run the following command:

netstat -anp | grep <port_no>

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file that is present in the OMS home:

$<OMS_HOME>/oui/prov/resources/Paths.properties

Software Availability Requirements

(Only for Graphical Mode)

For Cloning an Existing Management Agent

Ensure that you already have Oracle Management Agent 12c running in your environment. Ensure that the platform on which it is running is the same as the platform of the destination hosts on which you want to clone.

For Installing a Management Agent Using Shared Oracle Home

Ensure that you already have Oracle Management Agent 12c installed as a Master Agent in a shared, mounted location

Installation Base Directory Requirements

(Only for Graphical Mode)

Ensure that the agent base directory you specify in the Installation Base Directory field is empty and has write permission.

plugins.txt File Update Requirements

(Only for Silent Mode)

(Only if you installed additional plug-ins to the Management Agent later)

By default, when you install a Management Agent, it is automatically configured with the Oracle Home discovery plug-in, the Oracle Home monitoring plug-in, and all the discovery plug-ins that were configured with the OMS from where the Management Agent is being deployed. However, if you install any additional plug-ins later, then follow these steps:

1. Edit the plugins.txt file from the installation base directory.

2. Add entries in the following format for every additional plug-in you installed:
<plug-in_name>|<plug-in_version>|<plug-in_type>

For example, oracle.sysman.oh|12.1.0.2.0||discovery

Note: To find the plug-in name, plug-in version, and plug-in type, see the plugins directory in the installation base directory. For each plug-in, you should see a subdirectory titled based on the plug-in name, type, and version.

For example, oracle.sysman.db.discovery.plugin_12.1.0.2.0

Here, oracle.sysman.db is the plug-in name, discovery is the plug-in type, and 12.1.0.2.0 is the plug-in version.

3. Save the plugins.txt file.

Job System Requirements

Ensure that the job system is enabled on the source Management Agent you want to clone.

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is abc and the user installing the Management Agent is xyz, then ensure that abc and xyz belong to the same group, and they have read and write access to the inventory.

Central Inventory (oraInventory) Requirements

- Ensure that you allocate 100 MB of space for the Central Inventory.

- Ensure that the central inventory directory is not in a shared file system. If it is already in a shared file system, then create a new inventory in a non-shared file system. You can optionally migrate the products that were previously installed in the shared file system to this new inventory in the non-shared file system.

- Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then ensure that you specify the path to an alternative inventory location by using one of the following options in the Additional Parameters field of the Add Host Targets Wizard. However, these parameters are supported only on UNIX platforms, and not on Microsoft Windows platforms.
INVENTORY_LOCATION=<absolute_path_to_inventory_directory>

-invPtrLoc <absolute_path_to_oraInst.loc>

Port Requirements

Ensure that the default ports described in What Default Ports Are Used? are free.

Agent User Account Permissions and Rights

(Only for Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based operating system, then ensure that the agent user account has permissions and rights to perform the following:

- Act as part of the operating system.

- Adjust memory quotas for a process.

- Replace process level token.

- Log in as a batch job.

To verify whether the agent user has these rights, follow these steps:

1. Launch the Local Security Policy.
From the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Policy.

2. In the Local Security Policy window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permissions for cmd.exe

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based operating system, then ensure that you grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. This is a restriction from Microsoft.

For more information on this restriction and to understand how you can grant these permissions, access the following URL to Microsoft Web site:

http://support.microsoft.com/kb/867466/en-us

Preinstallation/Postinstallation Scripts Requirements

(Only for Graphical Mode)

Ensure that the preinstallation and postinstallation scripts that you want to run along with the installation are available either on the OMS host, destination hosts, or on a shared location accessible to the destination hosts.

Browser Requirements

(Only for Graphical Mode)

- Ensure that you use a certified browser as mentioned in the Enterprise Manager certification matrix available on My Oracle Support.
To access the Enterprise Manager certification matrix, follow the steps outlined in Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If you use Microsoft Internet Explorer 8 or 9, do the following:

- Turn off the compatibility view mode. To do so, in Microsoft Internet Explorer, from the Tools menu, click Compatibility View to disable it if it is enabled. Also, click Compatibility View Settings and deregister the Enterprise Manager Cloud Control console URL.

- Enable XMLHTTP. To do so, from the Tools menu, click Internet Options. Click the Advanced tab, and under the Security heading, select Enable native XMLHTTP support to enable it.

Cloning Procedure

This section describes the following:

- Cloning in Graphical Mode

- Cloning in Silent Mode

Cloning in Graphical Mode

To clone a Management Agent in graphical mode, follow these steps:

1. In Cloud Control, do one of the following:

- From the Setup menu, select Add Target, and then, click Auto Discovery Results. On the Auto Discovery Results page, select a host you want to monitor in Enterprise Manager Cloud Control, and click Promote.
Enterprise Manager Cloud Control displays the Add Host Wizard, where you can select the option to clone an existing Management Agent.

- From the Setup menu, select Add Target, and then, click Add Targets Manually. On the Add Targets Manually page, select Add Host Targets and click Add Host.
Enterprise Manager Cloud Control displays the Add Host Wizard, where you can select the option to clone an existing Management Agent.

2. On the Host and Platform page, do the following:

1. Accept the default name assigned for this session or enter a unique name of your choice. The custom name you enter can be any intuitive name, and need not necessarily be in the same format as the default name. For example, add_host_operation_1
A unique deployment activity name enables you to save the cloning details specified in this deployment session and reuse them in the future without having to enter all the details all over again in the new session.

2. Click Add to enter the fully qualified name and select the platform of the host on which you want to clone the Management Agent.

Note:

- Oracle recommends you to enter the fully qualified domain name of the host. For monitoring purpose, Enterprise Manager Cloud Control adds that host and the Management Agent with the exact name you enter here.

- You must enter only one host name per row. Entering multiple host names separated by a comma is not supported.

- You must ensure that the host name you enter does not have underscores.

Alternatively, you can click either Load from File to add host names stored in a file, or Add Discovered Hosts to add host names from a list of hosts discovered by Enterprise Manager. For information on how the host name entries must appear in the host file, see Format of Host List File.

Note:
When you click Add Discovered Hosts and add hosts from a list of discovered hosts, the host's platform is automatically detected and displayed. The platform name is detected using a combination of factors, including hints received from automated discovery and the platform of the OMS host. This default platform name is a suggestion, so Oracle strongly recommends you to verify the platform details before proceeding to the next step.

As you can clone only if the source host and destination host are running on the same platform, set the platform for the first host in the first row of the table and from the Platform list, select Same for All Hosts. This will ensure that the platform name you selected for the first host is also set for the rest of the hosts in the table.

Note:
If you are cloning a Management Agent on a platform that is different from the platform on which the OMS is running, then ensure that you have the software for that platform. If you do not have that software, then access the Self Update Console within Enterprise Manager Cloud Control, download the software, then apply it.
To access the Self Update Console, from the Setup menu, select Extensibility, then select Self Update. To download the latest Management Agent software, click Agent Software, select the required software, then click Download.

For more information on using the Self Update Console to download and apply the latest software, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

3. Click Next.

3. On the Installation Details page, do the following:

1. In the Deployment Type section, select Clone Existing Agent. Then, for Select Target, click the torch icon and select the Management Agent you want to clone.

Note:
If you have multiple hosts sharing a common mounted drive, then install the Management Agents in two different phases:

1. In the Add Host Targets Wizard, select the deployment type Clone Existing Agent, and clone the Management Agent to the host where the drive is shared.

2. In the Add Host Targets Wizard, select the deployment type Add Host to Shared Agent, and install a Management Agent on all other hosts that access the shared, mounted drive. (Here, you will select the Management Agent you cloned in the previous step as the master agent or shared agent.)

Figure 7-1 describes this step.

Figure 7-1 Cloning a Management Agent

Description of "Figure 7-1 Cloning a Management Agent"

2. From the table, select the first row that indicates the hosts grouped by their common platform name.

3. In the Installation Details section, provide the installation details common to the hosts selected in Step 3 (b). For Installation Base Directory, enter the absolute path to the agent base directory where you want the software binaries, security files, and inventory files of the Management Agent to be copied.
For example, /usr/home/software/oracle/agentHome

If the path you enter does not exist, the application creates a directory at the specified path, and copies the Management Agent software binaries, security files, and inventory files there.

Note:
The Installation Base Directory is essentially the agent base directory. Ensure that the directory you provide is empty. If a previously run deployment session had failed for some reason, then you might see an ADATMP_<timestamp> subdirectory in the installation base directory. In this case, either delete the subdirectory and start a new deployment session, or retry the failed session from the Add Host Status page.

4. For Instance Directory, accept the default instance directory location or enter the absolute path to a directory of your choice where all Management Agent-related configuration files can be stored.
For example, /usr/home/software/oracle/agentHome/agent_inst

If you are entering a custom location, then ensure that the directory has write permission. Oracle recommends you to maintain the instance directory inside the installation base directory.

If the path you enter does not exist, the application creates a directory at the specified path, and stores all the Management Agent-related configuration files there.

5. From Named Credential list, select an appropriate profile whose credentials can be used for setting up the SSH connectivity between the OMS and the remote hosts, and for installing a Management Agent on each of the remote hosts.

Note:

- If you do not have a credential profile, or if you have one but do not see it in the Named Credential list, then click the plus icon against this list. In the Create New Named Credential window, enter the credentials and store them with an appropriate profile name so that it can be selected and used for installing the Management Agents. Also set the run privilege if you want to switch over from the Named Credential you are creating, to another user who has the privileges to perform the installation.

- If the plus icon is disabled against this list, then you do not have the privileges to create a profile with credentials. In this case, contact your administrator and either request him/her to grant you the privileges to create a new profile or request him/her to create a profile and grant you the access to view it in the Named Credential list.

- If you have manually set up SSH public key authentication between the OMS and the remote hosts, then you may not have a password for your user account. In this case, create a named credential with a dummy password. Do NOT leave the password field blank.

6. For Privileged Delegation Setting, validate the Privilege Delegation setting to be used for running the root scripts. By default, it is set to the Privilege Delegation setting configured in Enterprise Manager Cloud Control.
For example, you can specify one of the following for the Privileged Delegation Setting field:

/usr/bin/sudo -u %RUNAS% %COMMAND%
/usr/bin/sesu - %RUNAS% -c "%COMMAND%"
/usr/bin/pbrun %PROFILE% -u %RUNAS% %COMMAND%
/usr/bin/su - %RUNAS% -c "%COMMAND%"

If you leave the Privileged Delegation Setting field blank, the root scripts will not be run by the wizard; you will have to run them manually after the installation. For information about running them manually, see After You Clone.

This setting will also be used for performing the installation as the user set in the Run As attribute of the selected Named Credential if you had set the user while creating that Named Credential.

Note:
In the Privilege Delegation setting, the %RUNAS% is honored as the root user for running the root scripts and as the user set in the Run As attribute of the Named Credential for performing the installation.

7. For Port, accept the default port (3872) that is assigned for the Management Agent to communicate, or enter a port of your choice.
The custom port you enter must not be busy. If you are not sure, you can leave this field blank. Enterprise Manager Cloud Control automatically assigns the first available free port within the range of 1830 - 1849.

8. (Optional) In the Optional Details section, enter the absolute path to an accessible location where the preinstallation and postinstallation scripts you want to run are available. Note that only one preinstallation or one postinstallation script can be specified.
If you want to run the script as root, then select Run as Root. If the script is on the host where OMS is running and is not on the host where you want to install the Management Agent, then select Script on OMS. In this case, the script will be copied from the OMS host to the destination hosts, and then run on the destination hosts.

9. (Optional) For Additional Parameters, enter a whitespace-separate list of additional parameters that you want to pass during the installation. For a complete list of supported additional parameters, see Table 7-2.
For example, if you want to provide the inventory pointer location file, then enter -invPtrLoc followed by the absolute path to the file location. Note that this parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

10. Repeat Step 3 (b) to Step 3 (i) for every other row you have in the table.

11. Click Next.

4. On the Review page, review the details you have provided and if you are satisfied with the details, then click Deploy Agent to clone the Management Agent.
If you want to modify the details, then click Back repeatedly to reach the page where you want to make the changes.

When you click Deploy Agent and submit the deployment session, you are automatically taken to the Add Host Status page that enables you to monitor the progress of the deployment session.

Note:
On the Add Host Status page, if you see the error message Copying Source Agent Image Failed, then refer to the following log file in the OMS home:
$<OMS_HOME>/sysman/prov/agentpush/<timestampdir>/applogs/deployfwk.log

This error usually occurs when the job system is not enabled on the source Management Agent you are cloning. Ensure that the job system is enabled.

Supported Additional Parameters

Table 7-2 lists the additional parameters supported for cloning a Management Agent in graphical mode.

Table 7-2 Supported Additional Parameters

Parameter

Description

INVENTORY_LOCATION

Enter the absolute path to the Central Inventory (oraInventory).

For example, INVENTORY_LOCATION=$HOME/oraInventory

Note: This parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

This parameter will be used only when the Central Inventory pointer /etc/oraInst.loc (or /var/opt/oracle/oraInst.loc) does not exist.

-invPtrLoc

Enter the absolute path to the inventory file that has the location of the Central Inventory (oraInventory).

For example, -invPtrLoc /tmp/oraInst.loc

Note: This parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

s_agentSrvcName

(Only for Microsoft Windows) Enter a custom name for the Management Agent service.

Every Management Agent appears as a service in Microsoft Windows, and every Management Agent has a default service name. If you want to assign a custom name to identify it, then use this parameter.

For example, s_agentSrvcName=agentsrvc1

Note: If you upgrade a 12c Release 1 (12.1.0.1) Management Agent installed on a Microsoft Windows host to 12c Release 2 (12.1.0.2), and you want to install another Management Agent on the same host, reporting to a different OMS, ensure that you specify the s_agentSrvcName parameter.

EM_STAGE_DIR

Enter the absolute path to a custom location that can be created as a temporary Provisioning Advisor Framework (PAF) staging directory.

By default, every time you install a Management Agent, a PAF staging directory is created for copying the Software Library entities related to the deployment procedures. By default, this location is the scratch path location (/tmp). The location is used only for provisioning activities—entities are copied for a deployment procedure, and then, deleted once the deployment procedure ends.

If you want to override this location with a custom location, you can pass this option and enter a custom location.

For example,

EM_STAGE_DIR=/home/john/software/oracle/pafdir

b_startAgent=false

Specify this parameter if you do not want the Management Agent to start automatically once it is installed and configured.

If you do not specify this parameter, the Management Agent starts automatically once it is installed and configured.

b_secureAgent=false

Specify this parameter if you do not want the Management Agent to be secured after the install.

If you specify this parameter, ensure that you also specify the OMS HTTP port, using the EM_UPLOAD_PORT parameter.

For example, b_secureAgent=false EM_UPLOAD_PORT=4899

If you do not specify this parameter, the Management Agent is secured automatically after the install.

Format of Host List File

In the Add Host Targets Wizard, you can click Load from File to add the hosts listed in a file. However, ensure that the file you select has one of the following formats:

- Only the host name.
For Example,

host1.example.com

host2.example.com

- The host name followed by the platform name.
For Example,

host1.example.com linux_x64

host2.example.com aix

The supported platform names are linux_x64, linux, solaris, hpunix, hpi, linux64_zseries, aix, linux_ppc64, windows_x64, solaris_x64, win32.

Cloning in Silent Mode

To clone a Management Agent manually, follow these steps:

1. Set the environment variables described in Table 7-3.

2. Navigate to the agent base directory:
cd $AGENT_BASE_DIR

3. Compress the directories and files present in the agent base directory, and a create a ZIP file in the temporary directory:
zip -r $T_WORK/agentcoreimage.zip core sbin plugins plugins.txt agentimage.properties

4. Navigate to the temporary directory:
cd $T_WORK

5. Copy the agentDeploy.sh to the temporary directory:
cp $AGENT_HOME/sysman/install/agentDeploy.sh .

6. Copy the UNZIP utility to the temporary directory:
cp $AGENT_HOME/bin/unzip .

7. Copy the agentimage.properties to the temporary directory:
cp $AGENT_BASE_DIR/agentimage.properties .

8. Create the final ZIP file with all the contents to be transferred, in the temporary directory:
zip -r agent.zip $T_WORK/*

9. Transfer the ZIP file to the installation base directory of the destination host using a file transfer utility (for example, FTP).

10. Extract the contents of the ZIP file.

11. Create a response file titled agent.rsp (in the same directory) as described in Table 6-3.

Note:
The response file you create can have any name, and not necessarily agent.rsp. For easy understanding, this chapter uses the name agent.rsp. Also, instead of creating a response file, you can choose to pass the values in separate arguments while invoking the deployment script. However, Oracle recommends that you create a response file and capture the information there.

12. Invoke the deployment script and pass the response file:
<Agent_Base_Directory>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile>

Note:

- Instead of creating a response file, if you choose to pass the values in separate arguments, then invoke the deployment script with some mandatory arguments in the following way:
<Agent_Base_Directory>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> OMS_HOST=<oms_hostname> EM_UPLOAD_PORT=<em_upload_port> AGENT_REGISTRATION_PASSWORD=<password>

- In addition to passing the agent base directory and a response file (or individual mandatory arguments with installation details), you can also pass other options that are supported by the deployment script. For more information, see Understanding the Options Supported by the agentDeploy Script.

Setting Environment Variables for Cloning Agent Using ZIP File

Table 7-3 lists the environment variables you need to set and describes how you can set them.

Table 7-3 Setting Environment Variables for Cloning Agent Using ZIP File

AGENT_BASE_DIR

Set it to the installation base directory of the Management Agent you want to clone.

- In bash terminal, run the following command:
export AGENT_BASE_DIR=<absolute_path_to_agent_install_base_dir>

For example,

export AGENT_BASE_DIR=/u01/app/Oracle/software/agent

- In other terminals, run the following command:
setenv AGENT_BASE_DIR <absolute_path_to_agent_install_base_dir>

For example,

setenv AGENT_BASE_DIR /u01/app/Oracle/software/agent

AGENT_HOME

Set it to the Oracle home of the Management Agent.

For example,

/u01/app/Oracle/software/agent/core/12.1.0.2.0

- In bash terminal, run the following command:
export AGENT_HOME=<absolute_path_to_agent_home>

For example,

export AGENT_HOME=/u01/app/Oracle/software/agent/core/12.1.0.2.0

- In other terminals, run the following command:
setenv AGENT_HOME <absolute_path_to_agent_home>

For example,

setenv AGENT_HOME /u01/app/Oracle/software/agent/core/12.1.0.2.0

T_WORK

Set it to /tmp/clone_work.

- In bash terminal, run the following command:
export T_WORK=/tmp/clone_work

- In other terminals, run the following command:
setenv T_WORK /tmp/clone_work

After You Clone

After you clone the Management Agent, follow these steps:

1. (Only for Graphical Mode) Verify the installation on the Add Host Status page. Review the progress made on each of the phases of the deployment operation — Initialization, Remote Prerequisite Check, and Agent Deployment.

Note:
In the Add Host Targets Wizard, after you click Deploy Agent to install one or more Management Agents, you are automatically taken to the Add Host Status page.
If you want to view the details or track the progress of all the deployment sessions, then from the Setup menu, select Add Target, and then, click Add Targets Manually. On the Add Targets Manually page, select Add Host Targets and click Add Host Results.

If a particular phase fails or ends up with a warning, then review the details provided for each phase in the Agent Deployment Details section, and do one of the following:

- Ignore the warning or failure, and continue with the session if you prefer.

- You can choose to proceed with the deployment of Management Agents only on those remote hosts that have successfully cleared the checks, and you can ignore the ones that have Warning or Failed status. To do so, click Continue and select Continue, Ignoring Failed Hosts.

- You can choose to proceed with the deployment of Management Agents on all the hosts, including the ones that have Warning or Failed status. To do so, click Continue and select Continue, All Hosts.

- Fix the problem by reviewing the error description carefully, understanding its cause, and taking action as recommended by Oracle.

- You can choose to retry the deployment of Management Agents with the same installation details. To do so, click Retry and select Retry Using Same Inputs.

- You can retry the deployment of Management Agents with modified installation details. To do so, click Retry and select Update Inputs and Retry.

Note:
If you see the error message Copying Source Agent Image Failed, then refer to the following log file in the OMS home:
$<OMS_HOME>/sysman/prov/agentpush/<timestampdir>/applogs/deployfwk.log

This error usually occurs when the job system is not enabled on the source Management Agent you are cloning. Ensure that the job system is enabled.

2. Verify the installation as described in After You Install.

Note:
If you want to repoint your existing Management Agents to a new Oracle Management Service (OMS), then you must first deinstall those Management Agents and plug-ins, and then redeploy those Management Agents and plug-ins using the new OMS. This is typically done when you want to move from an Enterprise Manager Cloud Control system in a test environment to an Enterprise Manager Cloud Control system in a production environment.
When you repoint your existing Management Agents to a new OMS, you cannot move the targets monitored by the Management Agents, the target history, and the Management Agent history. The monitored targets and the history data is lost.

8 Installing Shared Agent

This chapter describes how you can install a Shared Agent with the help of a central, shared Oracle home location of an existing Oracle Management Agent (Management Agent) that is installed on an NFS-mounted drive.

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- After You Install

Overview

If you want to install additional Management Agents on hosts that share a mounted drive where a Management Agent is already installed, then the best option is to use the software binaries of the shared Oracle home from the mounted drive and configure the remote hosts to be managed by that Management Agent, thus capitalizing on the NFS visibility and saving hard disk space on the remote hosts.

The Management Agent that shares its software binaries, in this context, is called the Master Agent, and the one that is configured with an instance directory on the remote host is called the Shared Agents or NFS Agents.

You can install a Shared Agent in graphical or silent mode. In graphical mode, you use the Add Host Targets Wizard that is accessible from within the Enterprise Manager Cloud Control console. In silent mode, you use the AgentNFS.pl script.

The wizard and the script use the software binaries from the shared Oracle home and configure an instance directory on each of the destination hosts for storing configuration files such as emd.properties, targets.xml, log files, and so on.

Note:

- Installing a Shared Agent on a host running on Microsoft Windows is not supported.

- Unlike the Add Host Target Wizard, the AgentNFS.pl script must be run only from a destination host, and at a given time, only one Management Agent can be installed at a given time. Therefore, if you want to install only a few Management Agents, then use the AgentNFS.pl script.

Before You Begin

Before you begin, keep these points in mind:

- When you install a Shared Agent, you only configure an instance directory on the destination host to store configuration files; you do not actually install a Management Agent.

- The Shared Agent can communicate only with Oracle Management Service 12c and not with any earlier release of Enterprise Manager.

- Only the destination host and the Shared Agent installed on it get automatically discovered and monitored in the Enterprise Manager system. The targets running on that destination host do not get automatically discovered and added to the Enterprise Manager system.

- The source host (where the Master Agent is running) and the destination host must be running on the same operating system. Therefore, if you have hosts running on different platforms, then you must have one deployment session per platform.

- The Master Agent and the Shared Agent must be installed with the same user account.

- (Only for Graphical Mode) The Add Host Targets Wizard uses SSH to establish connectivity between Oracle Management Service (OMS) and the remote hosts where you want to install the Management Agents.

- (Only for Graphical Mode) Only SSH1 (SSH version 1) and SSH2 (SSH version 2) protocols offered by OpenSSH are supported for deploying a Management Agent.

- (Only for Graphical Mode) SSH public key authentication and password-based authentication are supported. So you can use an existing SSH public key authentication without exposing your passwords. You can provide a dummy password in the wizard, and the wizard will internally use the underlying public key infrastructure to perform the installation.
To set up SSH public key authentication, follow these steps:

1. Navigate to the following location in the OMS home:
$<OMS_HOME>/oui/prov/resources/scripts

For example,

/home/software/em/middleware/oms/oui/prov/resources/scripts

2. Run the following script on the OMS host as the OMS user, and pass the Management Agent install user name and the fully qualified name of the target hosts:
sshUserSetup.sh -setup -user <agent_install_1user_name> -hosts <target_hosts>

3. Access the Add Host Targets Wizard, and provide the dummy password and install the Management Agent.

The wizard ignores the dummy password, and honors the keys present in the following location on the OMS host to perform the installation. Here, $HOME refers to the home directory of the OMS install user.

- $HOME/.ssh/id_rsa

- $HOME/.ssh/id_dsa

- $HOME/.ssh/identity

If you want to provide additional keys, specify them as values for the oracle.sysman.prov.remoteinterfaces.identitylist property present in the $<OMS_HOME>/sysman/prov/agentpush/agentpush.properties file, using a comma separated list.

- (Only for Graphical Mode) The Add Host Targets Wizard supports Named Credentials that enable you to use a set of credentials registered with a particular name specifically for this operation, by your administrator. This ensures an additional layer of security for your passwords because as an operator, you can only select the named credential, which is saved and stored by an administrator, and not know the actual user name and password associated with it.
In case the named credential you select does not have the privileges to perform the installation, then you can set the named credential to run as another user (locked user account). In this case, the wizard logs in to the hosts using the named credential you select, but performs the installation using the locked user account you set.

For example, you can create a named credential titled User_A, and set it to run as User_X that has the required privileges. In this case, the wizard logs in to the hosts as User_A, but installs as User_X, using the privilege delegation setting (sudo or PowerBroker) specified in the named credential.

- By default, the Add Host Targets Wizard configures only the following types of plug-ins:

- All discovery plug-ins that were configured with the OMS from where the Management Agent software is being deployed.

- Oracle Home discovery plug-in

- Oracle Home monitoring plug-in

Prerequisites

Before installing a Shared Agent, ensure that you meet the following prerequisites:

Table 8-1 Prerequisites for Installing Shared Agent

Requirement

Description

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements. For more information, see the chapter on hardware requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Destination Host Disk Space Requirements

Ensure that the Master Agent host has a minimum of 1 GB free hard disk space, and the Shared Agent host has a minimum of 1 MB free hard disk space.

Software Requirements

(Only for Graphical Mode)

(For Microsoft Windows) Ensure that you have installed Cygwin 1.7 on the destination host. For more information, see the chapter on installing Cygwin in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Note: While running cygwin.bat in Microsoft Windows Server 2008 and Microsoft Windows Vista, ensure that you invoke it in administrator mode. To do this, right-click the cygwin.bat file and select Run as administrator.

Operating System Requirements

Ensure that you install the Management Agent only on certified operating systems as mentioned in the Enterprise Manager certification matrix available on My Oracle Support.

To access the Enterprise Manager certification matrix, follow the steps outlined in Oracle Enterprise Manager Cloud Control Basic Installation Guide.

For information about platforms receiving future support, refer to My Oracle Support note 793512.1.

Note: If you use Oracle Solaris 10, then ensure that you have update 9 or higher installed. To verify whether it is installed, run the following command:

cat /etc/release

You should see the output similar to the following. Here, s10s_u6 indicates that update 6, which is not a supported update level for installation, is installed.

Solaris 10 10/08 s10s_u6wos_07b SPARC

Package Requirements

Ensure that you install all the operating system-specific packages. For more information, see the chapter on package requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For more information, see the chapter on creating operating system groups and users in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Software Availability Requirements

Ensure that you already have Oracle Management Agent 12c installed as a Master Agent in a shared, mounted location.

Software Mount Requirements

Ensure that you mount the Master Agent software by running the following command on the Shared Agent host:

mount -t nfs -o ro <master_agent_host_name>:<agent_base_dir_of_master_agent> <agent_base_dir_of_shared_agent>

For example, run the following command:

mount -t nfs -o ro abc.oracle.com:/scratch/masterAgent /scratch/sharedAgent

Also, ensure that the Management Agent user has only read permissions on the mount location, that is, the agent base directory of the Master Agent.

/etc/hosts File Requirements

Ensure that the /etc/hosts file on the host has the IP address, the fully qualified name, and the short name in the following format:

172.16.0.0 example.com mypc

Destination Host Access Requirements

Ensure that the destination hosts are accessible from the host where the OMS is running.

Ensure that the destination host has read-only access to the software binaries of this Master Agent.

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is example.com and the short name is mypc, then add the following line in the /etc/hosts file:

172.16.0.0 example.com mypc

Destination Host Credential Requirements

(Only for Graphical Mode)

Ensure that all the destination hosts running on the same operating system have the same set of credentials. For example, all the destination hosts running on Linux operating system must have the same set of credentials.

The wizard installs the Management Agent using the same user account. If you have hosts running on the same operating system but with different credentials, then have two different deployment sessions.

Destination Host Time Zone Requirements

(Only for Graphical Mode)

Ensure that the time zones of the destination hosts have been set correctly. To verify the time zone of a destination host, log in to the OMS host, and run the following command:

ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

If the time zone displayed is incorrect, log in to the destination host, and follow these steps:

1. Run the following commands to set the time zone on the destination host:

- For Korn shell:
TZ=<value>

export TZ

- For Bourne shell or Bash shell:
export TZ=<value>

- For C shell:
setenv TZ <value>

For example, in the Bash shell, run the following command to set the time zone to America/New_York:

export TZ='America/New_York'

The time zones you can use are listed in <AGENT_HOME>/sysman/admin/supportedtzs.lst.

2. Restart the SSH daemon.
If the destination host runs on a UNIX based operating system, run the following command:

sudo /etc/init.d/sshd restart

If the destination host runs on a Microsoft Windows operating system, run the following commands:

cygrunsrv -E sshd

cygrunsrv -S sshd

3. Verify whether the SSH server can access the TZ environment variable by logging in to the OMS host, and running the following command:
ssh -l <install_user> <destination_host_name> /bin/sh -c 'echo $TZ'

Note: If you had ignored a prerequisite check warning about wrong time zone settings during the Management Agent install, you must set the correct time zone on the destination hosts after installing the Management Agents. For information on setting time zones post install, refer After You Install.

Time Zone Requirements

(Only for Silent Mode)

Ensure that the host time zone has been set correctly. To verify the host time zone, run the following command:

echo $TZ

If the time zone displayed is incorrect, run the following commands, before running the agentDeploy.sh or agentDeploy.bat scripts, to set the correct time zone:

- For Korn shell:
TZ=<value>

export TZ

- For Bourne shell or Bash shell:
export TZ=<value>

- For C shell:
setenv TZ <value>

For example, in the Bash shell, run the following command to set the time zone to America/New_York:

export TZ='America/New_York'

The time zones you can use are listed in <AGENT_HOME>/sysman/admin/supportedtzs.lst.

Note: If you had ignored a prerequisite check warning about wrong time zone settings during the Management Agent install, you must set the correct time zone on the host after installing the Management Agent. For information on setting time zones post install, refer After You Install.

sudo/pbrun/sesu/su SSH Requirements

(Only for Graphical Mode)

(Only for UNIX)

Ensure that you set the oracle.sysman.prov.agentpush.enablePty property to true in the $<OMS_HOME>/sysman/prov/agentpush/agentpush.properties file, if the privilege delegation tool you are using requires a pseudo terminal for remote command execution via SSH. Most privilege delegation tools such as pbrun, sesu, and su require a pseudo terminal for remote command execution, by default.

Note: If you are using sudo as your privilege delegation tool, and you do not want to set the oracle.sysman.prov.agentpush.enablePty property to true, do one of the following:

- Include Defaults visiblepw in the /etc/sudoers file, or enter the sudo command with the -S option for Privileged Delegation Setting on the Installation Details page.
For information on how to access the Installation Details page, see Installing in Graphical Mode.

- Comment out Defaults requiretty in the /etc/sudoers file.

sudo/pbrun/sesu/su Requirements (for Root User)

(Only for Graphical Mode)

(Only for UNIX)

- Ensure that the installing user has the privileges to invoke the id command and the agentdeployroot.sh script as root. Grant the privileges in the configuration file of your privilege delegation tool.
For example, if you are using sudo as your privilege delegation tool, include the following in the /etc/sudoers file to grant the required privileges:

oracle ALL=(root) /usr/bin/id, /home/oracle/agentinst/*/agentdeployroot.sh

Here, oracle is the installing user, and /home/oracle/agentinst is the agent instance directory of the Shared Agent.

- You do not require the following entry in the /etc/sudoers file for installing a Management Agent. However, the entry is required for performing provisioning and patching operations in Enterprise Manager. Therefore, if you are removing this entry before installing a Management Agent, then ensure that you bring back the entry after installing the Management Agent.
(root)/oracle/product/oms12c/agent/agent_inst/bin/nmosudo

sudo/pbrun/sesu/su Requirements (for Locked Account User)

(Only for Graphical Mode)

(Only for UNIX)

- Ensure that the installing user has the privileges to invoke /bin/sh as the locked account user. Grant the privileges in the configuration file of your privilege delegation tool.
For example, if you are using sudo as your privilege delegation tool, include the following in the /etc/sudoers file to grant the required privileges:

login_user1 ALL=(oracle) /bin/sh

Here, login_user1 is the SSH log in user, and oracle is the locked account and install user.

If you do not want to grant privileges to the installing user to invoke /bin/sh as the locked account user, set the oracle.sysman.prov.agentpush.pdpShellOutEnabled property to false, and ensure that the installing user has the privileges to invoke id, chmod, cp, mkdir, rm, tar, emctl, perl, runInstaller, and unzip as the locked account user. Grant the privileges in the configuration file of your privilege delegation tool.

For example, if you are using sudo as your privilege delegation tool, include the following in the /etc/sudoers file to grant the required privileges:

login_user1 ALL=(oracle) /usr/bin/id, /bin/chmod, /bin/cp, /bin/mkdir, /bin/rm, /bin/tar, /home/oracle/agentinst/bin/emctl, /home/oracle/agentibd/core/12.1.0.2.0/perl/bin/perl, /home/oracle/agentibd/core/12.1.0.2.0/oui/bin/runInstaller, /home/oracle/agentibd/core/12.1.0.2.0/bin/unzip

Here, login_user1 is the SSH log in user, oracle is the locked account and install user, /home/oracle/agentinst is the agent instance directory of the Shared Agent, and /home/oracle/agentibd is the agent base directory.

- You do not require the following entry in the /etc/sudoers file for installing a Management Agent. However, the entry is required for performing provisioning and patching operations in Enterprise Manager. Therefore, if you are removing this entry before installing a Management Agent, then ensure that you bring back the entry after installing the Management Agent.
(root)/oracle/product/oms12c/agent/agent_inst/bin/nmosudo

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied.

By default, the temporary directory location set to the environment variable TMP or TEMP is honored. If both are set, then TEMP is honored. If none of them are set, then the following default values are honored: /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Instance Directory Requirements

Ensure that the instance directory you enter is empty and has write permission.

Shared Oracle Home Requirements

Ensure that the Master Agent home is accessible from the destination host where you want to install the Shared Agent. Ensure that the Master Agent home is mounted with the setuid turned on.

Ensure that the Shared Agent has read-only access to the software binaries of this Master Agent.

PATH Environment Variable Requirements

(Only for Graphical Mode)

On the destination host, ensure the following:

- (For Microsoft Windows) Ensure that the Cygwin software location appears before other software locations in the PATH environment variable. After making it the first entry, restart the SSH daemon (sshd).

- (For UNIX) On the destination host, ensure that the SCP binaries (for example, /usr/bin/scp) are in the PATH environment variable:

Path Validation Requirements

(Only for Graphical Mode)

Validate the path to all command locations. For more information, see the appendix on validating command locations in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

CLASSPATH Environment Variable Requirements

If the value assigned to the CLASSPATH environment variable has white spaces in it, then ensure that you unset it. You can always reset the environment variable to the original value after the installation is complete.

Default SSH Port Requirements

(Only for Graphical Mode)

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts. To verify the port, run the following command:

netstat -anp | grep <port_no>

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file that is present in the OMS home:

$<OMS_HOME>/oui/prov/resources/Paths.properties

Port Requirements

Ensure that the default ports described in What Default Ports Are Used? are free.

Installing User Requirements

- Ensure that the user installing the Shared Agent is the same as the user who installed the Master Agent.

- If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

- Ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.
For example, if the inventory owner is abc and the user installing the Management Agent is xyz, then ensure that abc and xyz belong to the same group, and they have read and write access to the inventory.

Central Inventory (oraInventory) Requirements

- Ensure that you allocate 100 MB of space for the Central Inventory.

- Ensure that the inventory directory is not in a shared file system.

- The Shared Agent uses the inventory location mentioned in the oraInst.loc file, which is present in the <MASTER_AGENT_BASE DIR>/core/12.1.0.2.0/ directory. Ensure that the Shared Agent user has read and write permissions on this directory.

Agent User Account Permissions and Rights

(Only for Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based operating system, then ensure that the agent user account has permissions and rights to perform the following:

- Act as part of the operating system.

- Adjust memory quotas for a process.

- Replace process level token.

- Log in as a batch job.

To verify whether the agent user has these rights, follow these steps:

1. Launch the Local Security Policy.
From the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Policy.

2. In the Local Security Policy window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permissions for cmd.exe

(Only for Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based operating system, then ensure that you grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. This is a restriction from Microsoft.

For more information on this restriction and to understand how you can grant these permissions, access the following URL to Microsoft Web site:

http://support.microsoft.com/kb/867466/en-us

Preinstallation/Postinstallation Scripts Requirements

(Only for Graphical Mode)

Ensure that the preinstallation and postinstallation scripts that you want to run along with the installation are available either on the OMS host, destination hosts, or on a shared location accessible to the destination hosts.

Browser Requirements

(Only for Graphical Mode)

- Ensure that you use a certified browser as mentioned in the Enterprise Manager certification matrix available on My Oracle Support.
To access the Enterprise Manager certification matrix, follow the steps outlined in Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If you use Microsoft Internet Explorer 8 or 9, do the following:

- Turn off the compatibility view mode. To do so, in Microsoft Internet Explorer, from the Tools menu, click Compatibility View to disable it if it is enabled. Also, click Compatibility View Settings and deregister the Enterprise Manager Cloud Control console URL.

- Enable XMLHTTP. To do so, from the Tools menu, click Internet Options. Click the Advanced tab, and under the Security heading, select Enable native XMLHTTP support to enable it.

Installation Procedure

This section describes the following:

- Installing in Graphical Mode

- Installing in Silent Mode

Installing in Graphical Mode

To install a Shared Agent in graphical mode, follow these steps:

1. In Cloud Control, do one of the following:

- From the Setup menu, select Add Targets, and then, click Auto Discovery Results. On the Auto Discovery Results page, select a host you want to monitor in Enterprise Manager Cloud Control, and click Promote.

- From the Setup menu, select Add Target, and then, click Add Targets Manually. On the Add Targets Manually page, select Add Host Targets and click Add Host.

2. On the Host and Platform page, do the following:

1. Accept the default name assigned for this session or enter a unique name of your choice. The custom name you enter can be any intuitive name, and need not necessarily be in the same format as the default name. For example, add_host_operation_1
A unique deployment activity name enables you to save the installation details specified in this deployment session and reuse them in the future without having to enter all the details all over again in the new session.

2. Click Add to enter the fully qualified name and select the platform of the host on which you want to install the Management Agent.

Note:

- Oracle recommends you to enter the fully qualified domain name of the host. For monitoring purpose, Enterprise Manager Cloud Control adds that host and the Management Agent with the exact name you enter here.

- You must enter only one host name per row. Entering multiple host names separated by a comma is not supported.

- You must ensure that the host name you enter does not have underscores.

Alternatively, you can click either Load from File to add host names stored in a file, or Add Discovered Hosts to add host names from a list of hosts discovered by Enterprise Manager. For information on how the host name entries must appear in the host file, see Format of Host List File

Note:
When you click Add Discovered Hosts and add hosts from a list of discovered hosts, the host's platform is automatically detected and displayed. The platform name is detected using a combination of factors, including hints received from automated discovery and the platform of the OMS host. This default platform name is a suggestion, so Oracle strongly recommends you to verify the platform details before proceeding to the next step.

As the Shared Agent can be installed only if the source host and the destination host are running on the same platform, set the platform for the first host in the first row of the table and from the Platform list, select Same for All Hosts. This will ensure that the platform name you selected for the first host is also set for the rest of the hosts in the table.

Note:
If you are installing a Management Agent on a platform that is different from the platform on which the OMS is running, then ensure that you have the software for that platform. If you do not have that software, then access the Self Update Console within Enterprise Manager Cloud Control, download the software, then apply it.
To access the Self Update Console, from the Setup menu, select Extensibility, then select Self Update. To download the latest Management Agent software, click Agent Software, select the required software, then click Download.

For more information on using the Self Update Console to download and apply the latest software, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

3. Click Next.

3. On the Installation Details page, do the following:

1. In the Deployment Type section, select Add Host to Shared Agent. Then, for Select Target, click the torch icon and select the Management Agent that is shared and mounted. This location must be visible on all remote hosts.
Figure 8-1 describes this step.

Figure 8-1 Installing a Shared Agent

Description of "Figure 8-1 Installing a Shared Agent"

2. From the table, select the first row that indicates the hosts grouped by their common platform name.

3. In the Installation Details section, provide the installation details common to the hosts selected in Step 3 (b). For Oracle Home, validate or enter the location of the shared Management Agent home. Ensure that this location is accessible from all the destination hosts.

4. For Instance Directory, enter the absolute path to a directory where all Management Agent-related configuration files can be stored. Ensure that the directory has write permission.
For example, /usr/home/software/oracle/agentHome/agent_inst

If the path you enter does not exist, the application creates a directory at the specified path, and stores all the Management Agent-related configuration files there.

5. From Named Credential list, select an appropriate profile whose credentials can be used for setting up the SSH connectivity between the OMS and the remote hosts, and for installing a Management Agent on each of the remote hosts.

Note:

- If you do not have a credential profile, or if you have one but do not see it in the Named Credential list, then click the plus icon against this list. In the Create New Named Credential window, enter the credentials and store them with an appropriate profile name so that it can be selected and used for installing the Management Agents. Also set the run privilege if you want to switch over from the Named Credential you are creating, to another user who has the privileges to perform the installation.

- If the plus icon is disabled against this list, then you do not have the privileges to create a profile with credentials. In this case, contact your administrator and either request him/her to grant you the privileges to create a new profile or request him/her to create a profile and grant you the access to view it in the Named Credential list.

- If you have manually set up SSH public key authentication between the OMS and the remote hosts, then you may not have a password for your user account. In this case, create a named credential with a dummy password. Do NOT leave the password field blank.

6. For Privileged Delegation Setting, validate the Privilege Delegation setting to be used for running the root scripts. By default, it is set to the Privilege Delegation setting configured in Enterprise Manager Cloud Control.
For example, you can specify one of the following for the Privileged Delegation Setting field:

/usr/bin/sudo -u %RUNAS% %COMMAND%
/usr/bin/sesu - %RUNAS% -c "%COMMAND%"
/usr/bin/pbrun %PROFILE% -u %RUNAS% %COMMAND%
/usr/bin/su - %RUNAS% -c "%COMMAND%"

If you leave the Privileged Delegation Setting field blank, the root scripts will not be run by the wizard; you will have to run them manually after the installation. For information about running them manually, see After You Install.

This setting will also be used for performing the installation as the user set in the Run As attribute of the selected Named Credential if you had set the user while creating that Named Credential.

Note:
In the Privilege Delegation setting, the %RUNAS% is honored as the root user for running the root scripts and as the user set in the Run As attribute of the Named Credential for performing the installation.

7. For Port, accept the default port (3872) that is assigned for the Management Agent to communicate, or enter a port of your choice.
The custom port you enter must not be busy. If you are not sure, you can leave it blank. Enterprise Manager Cloud Control automatically assigns the first available free port within the range of 1830 - 1849.

8. (Optional) In the Optional Details section, enter the absolute path to an accessible location where the preinstallation and postinstallation scripts you want to run are available. Note that only one preinstallation or one postinstallation script can be specified.
If you want to run the script as root, then select Run as Root. If the script is on the host where OMS is running and is not on the host where you want to install the Management Agent, then select Script on OMS. In this case, the script will be copied from the OMS host to the destination hosts, and then run on the destination hosts.

9. (Optional) For Additional Parameters, enter a whitespace-separate list of additional parameters that you want to pass during the installation. For a complete list of supported additional parameters, see Table 8-2.
For example, if you want to provide the inventory pointer location file, then enter -invPtrLoc followed by the absolute path to the file location. However, this parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

10. Repeat Step 3 (b) to Step 3 (h) for every other row you have in the table.

11. Click Next.

4. On the Review page, review the details you have provided and if you are satisfied with the details, then click Deploy Agent to install the Management Agent.
If you want to modify the details, then click Back repeatedly to reach the page where you want to make the changes.

When you click Deploy Agent and submit the deployment session, you are automatically taken to the Add Host Status page that enables you to monitor the progress of the deployment session.

Note:
If you restart the destination host after installing a Shared Agent, and the Shared Agent does not start up automatically, restore the mount, and start the Shared Agent manually by running the following commands on the host:

mount -t nfs -o ro <master_agent_host_name>:<agent_base_dir_of_master_agent> <agent_base_dir_of_shared_agent>
$<INSTANCE_HOME>/bin/emctl start agent

Supported Additional Parameters

Table 8-2 lists the additional parameters supported for installing a Shared Agent in graphical mode.

Table 8-2 Supported Additional Parameters

Parameter

Description

EM_STAGE_DIR

Enter the absolute path to a custom location that can be created as a temporary Provisioning Advisor Framework (PAF) staging directory.

By default, every time you install a Management Agent, a PAF staging directory is created for copying the Software Library entities related to the deployment procedures. By default, this location is the scratch path location (/tmp). The location is used only for provisioning activities—entities are copied for a deployment procedure, and then, deleted once the deployment procedure ends.

If you want to override this location with a custom location, you can pass this option and enter a custom location.

For example,

EM_STAGE_DIR=/home/john/software/oracle/pafdir

b_startAgent=false

Specify this parameter if you do not want the Management Agent to start automatically once it is installed and configured.

If you do not specify this parameter, the Management Agent starts automatically once it is installed and configured.

b_secureAgent=false

Specify this parameter if you do not want the Management Agent to be secured after the install.

If you specify this parameter, ensure that you also specify the OMS HTTP port, using the EM_UPLOAD_PORT parameter.

For example, b_secureAgent=false EM_UPLOAD_PORT=4899

If you do not specify this parameter, the Management Agent is secured automatically after the install.

Installing in Silent Mode

To install a Shared Agent in silent mode, follow these steps:

1. Create a response file titled AgentNFS.rsp as described in Table 8-3.

Note:
The response file you create can have any name, and not necessarily AgentNFS.rsp. For easy understanding, this chapter uses the name AgentNFS.rsp. Also, instead of creating a response file, you can choose to pass the arguments explicitly while invoking the script. However, Oracle recommends that you create a response file and capture the information there.

2. Invoke the script from the Master Agent home, which is visible as a shared location, and pass the response file.
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/AgentNFS.pl -responseFile=<absolute_path_to_response_file>

For example,

/scratch/agent_base_dir/core/12.1.0.2.0/perl/bin/perl /scratch/agent_base_dir/core/12.1.0.2.0/sysman/install/AgentNFS.pl -responseFile=/home/john/AgentNFS.rsp

Note:

- Instead of creating a response file, you can choose to pass all the arguments explicitly while invoking the script. In this case, invoke the script in the following way:
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/AgentNFS.pl AGENT_INSTANCE_HOME=<absolute_path_to_instance_dir> ORACLE_HOME=<absolute_path_to_master_agent_oracle_home> <parameter1>=<value1> <parameter2>=<value2> <parameter3>=<value3>...

For example,

/scratch/agent_base_dir/core/12.1.0.2.0/perl/bin/perl /scratch/agent_base_dir/core/12.1.0.2.0/sysman/install/AgentNFS.pl AGENT_INSTANCE_HOME=/home/john/agent_inst ORACLE_HOME=/scratch/agent_base_dir/core/12.1.0.2.0 AGENT_PORT=1832 AGENT_REGISTRATION_PASSWORD=welcome b_startAgent=TRUE

- If the Master Agent was installed using the Add Host Targets Wizard, then ensure that you pass the following arguments with these values:
AGENT_REGISTRATION_PASSWORD=<password>

b_startAgent=TRUE

- Do NOT pass the -invPtrLoc argument because, by default, the location <AGENT_HOME>/oraInst.loc is honored, where <AGENT_HOME> is the Master Agent. Also ensure that the Oracle Inventory directory, to which the inventory file points, is not in a shared location.

- If you restart the destination host after installing a Shared Agent, and the Shared Agent does not start up automatically, restore the mount, and start the Shared Agent manually by running the following commands:

mount -t nfs -o ro <master_agent_host_name>:<master_agent_base_dir> <shared_agent_base_dir>
$<INSTANCE_HOME>/bin/emctl start agent

3. When prompted to run the root.sh script, run it from the instance directory of the Management Agent:
<AGENT_INSTANCE_HOME>/root.sh

If you are not a root user, then use SUDO to change to a root user. For example, run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/agent_inst/root.sh

4. Repeat Step (1) to Step (3) on the remaining hosts where you want to install the Shared Agent.

Creating a Response File

For silently installing a Shared Agent, you must invoke the AgentNFS.pl script and pass a response file that captures all the required information. Table 8-3 describes the various parameters you must include in the response file.

Table 8-3 Creating a Response File for Installing Oracle Management Agent Using the AgentNFS.pl Script

Parameter

Description

ORACLE_HOME

Specify the absolute path to the Master Agent home, which is shared and visible on the destination host.

For example, /scratch/agent_base_dir/core/12.1.0.2.0

AGENT_PORT

(Optional) Enter the port on which the Shared Agent process should be started. You can enter any free port between 1830 and 1849. The same port is used for both HTTP and HTTPS.

For example, 1832

AGENT_INSTANCE_HOME

Specify the absolute path to a location on the destination host where you want to store all Management Agent-related configuration files.

For example, /home/john/agent_inst

b_startAgent

Set it to TRUE so that the Shared Agent is started automatically once it is installed and configured.

Note: If the Master Agent was installed using the Add Host Targets Wizard, then you must pass this parameter.

ORACLE_HOSTNAME

(Optional) (Only for Installation on Virtual Hosts) Specify the virtual host name where you are installing the Shared Agent.

AGENT_REGISTRATION_PASSWORD

Enter a password for registering new Management Agents that join the Enterprise Manager system.

By default, the communication between the OMS and the Management Agents is secured and locked. Any new Management Agents that join the Enterprise Manager system must be authenticated before they become part of the system. The password you enter here will be used for authenticating those new Management Agents.

For example, Wel456come

Note: If the Master Agent was installed using the Add Host Targets Wizard, then you must pass this parameter.

After You Install

After you install a Shared Agent, follow these steps:

1. (Only for Graphical Mode) Verify the installation on the Add Host Status page. Review the progress made on each of the phases of the deployment operation — Initialization, Remote Prerequisite Check, and Agent Deployment.

Note:
In the Add Host Targets Wizard, after you click Deploy Agent to install one or more Management Agents, you are automatically taken to the Add Host Status page.
If you want to view the details or track the progress of all the deployment sessions, then from the Setup menu, select Add Target, and then, click Add Targets Manually. On the Add Targets Manually page, select Add Host Targets and click Add Host Results.

If a particular phase fails or ends up with a warning, then review the details provided for each phase in the Agent Deployment Details section, and do one of the following:

- Ignore the warning or failure, and continue with the session if you prefer.

- You can choose to proceed with the deployment of Management Agents only on those remote hosts that have successfully cleared the checks, and you can ignore the ones that have Warning or Failed status. To do so, click Continue and select Continue, Ignoring Failed Hosts.

- You can choose to proceed with the deployment of Management Agents on all the hosts, including the ones that have Warning or Failed status. To do so, click Continue and select Continue, All Hosts.

- Fix the problem by reviewing the error description carefully, understanding its cause, and taking action as recommended by Oracle.

- You can choose to retry the deployment of Management Agents with the same installation details. To do so, click Retry and select Retry Using Same Inputs.

- You can retry the deployment of Management Agents with modified installation details. To do so, click Retry and select Update Inputs and Retry.

2. Verify the installation:

1. Navigate to the Shared Agent instance home and run the following command to see a message that confirms that the Management Agent is up and running:
$<AGENT_INSTANCE_HOME>/bin/emctl status agent

Note:
If the status of the Management Agent is down for some reason, then manually start the Management Agent by running the following command from its Oracle home:
$<AGENT_INSTANCE_HOME>/bin/emctl start agent

2. Navigate to the Shared Agent home and run the following command to see a message that confirms that EMD upload completed successfully:
$<AGENT_INSTANCE_HOME>/bin/emctl upload

3. (Only for Graphical Mode) If you have restrictive Privilege Delegation Provider (PDP) configuration settings, enter the location of nmosudo in your PDP configuration file.
Enterprise Manager supports PDPs such as SUDO and PowerBroker that enable administrators to restrict certain users from running certain commands.

In Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), nmosudo is located in the sbin directory, which is in the agent base directory. For example, <AGENT_BASE_DIRECTORY>/sbin/nmosudo. In Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1], nmosudo is located in the agent instance directory. For example, <AGENT_INSTANCE_DIRECTORY>/bin/nmosudo.

Therefore, when you install an Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) Management Agent, you must modify your PDP configuration file to update the new location of nmosudo.

For example, if you use SUDO as your PDP, the configuration file for SUDO is typically /etc/sudoers. In this file, update the following entry with the new location to nmosudo.

sudouser ALL : oracle /eminstall/basedir/sbin/nmosudo *

4. (Only for UNIX Operating Systems) If you had ignored the prerequisite check warning about not having root privileges, SUDO binaries, or SUDO privileges, then manually run the following scripts as a root user from each of the hosts where the cloning was done. If you do not have SUDO privileges, then request your Administrator who has the privileges to run these scripts.

- If this is the first Oracle product you just cloned on the host, then run the oraInstroot.sh script from the inventory location specified in the oraInst.loc file that is available in the Management Agent home.
For example, if the inventory location specified in the oraInst.loc file is $HOME/oraInventory, then run the following command:

$HOME/oraInventory/oraInstRoot.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/bin/sudo $HOME/oraInventory/oraInstRoot.sh

- Run the root.sh script from the Management Agent home:
$<AGENT_HOME>/root.sh

Note:
If you are not a root user, then use SUDO to change to a root user. For example, run the following command:
/usr/bin/sudo $<AGENT_HOME>/root.sh

5. If you had ignored a prerequisite check warning about wrong time zone settings, follow these steps:

1. Set the correct time zone on the required host.
For information on how to set the time zone on a host, refer Time Zone Requirements in Table 8-1.

2. Deinstall the Management Agent present on the host.
For information on how to deinstall a Management Agent, refer to Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

3. Install a Management Agent on the host.

6. By default, the host and the Shared Agent get automatically added to the Enterprise Manager Cloud Control console for monitoring. None of the targets running on that host get automatically discovered and monitored.
To monitor the other targets, you need to add them to Enterprise Manager Cloud Control either using the Auto Discovery Results page, the Add Targets Manually page, or the discovery wizards offered for the targets you want to monitor.

For information about discovering targets in Enterprise Manager Cloud Control, refer to the chapter on adding targets in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

9 Installing Oracle Management Agent Software Now and Configuring Later

This chapter explains how you can install only the software binaries of Oracle Management Agent (Management Agent) at one point and configure the installation at a later stage. In particular, this chapter covers the following:

- Overview

- Before You Begin

- Prerequisites

- Installation Procedure

- Configuration Procedure

- After You Install

Overview

You can choose to install only the software binaries of the Management Agent at one point and configure it at a later stage to work with the associated Oracle Management Service (OMS). This approach enables you to divide the installation process into two phases, mainly the installation phase and the configuration phase.

During the installation phase, you invoke the agentDeploy.sh script passing the -softwareOnly argument to copy the software binaries and create an Oracle home for the Management Agent. During the configuration phase, you invoke the same script passing -configOnly to configure the software binaries.

Understandably, the installation phase takes much lesser time compared to the configuration phase because the installation phase involves only copying of binaries. This helps you plan your installation according to the time and priorities you have.

Note:
This installation type is available only in silent mode.

Note:
If you want to repoint your existing Management Agents to a new Oracle Management Service (OMS), then you must first deinstall those Management Agents and plug-ins, and then redeploy those Management Agents and plug-ins using the new OMS. This is typically done when you want to move from an Enterprise Manager Cloud Control system in a test environment to an Enterprise Manager Cloud Control system in a production environment.
When you repoint your existing Management Agents to a new OMS, you cannot move the targets monitored by the Management Agents, the target history, and the Management Agent history. The monitored targets and the history data is lost.

Before You Begin

Before you begin installing a Management Agent, review the points outlined in Before You Begin.

Prerequisites

Before installing the Management Agent, ensure that you meet the prerequisites described in Prerequisites.

Installation Procedure

To install only the software binaries of a Management Agent in silent mode, follow these steps:

1. Follow the Step (1) to Step (7) outlined in Installation Procedure.

2. Invoke the deployment script and pass the response file with the -softwareOnly argument:
<Software_Extracted_Location>/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile> -softwareOnly

Note:
Do not pass the option -forceConfigure.

Configuration Procedure

To configure the software binaries of a Management Agent in silent mode, invoke the deployment script with the following options from the Management Agent home:

$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> RESPONSE_FILE=<absolute_path_to_responsefile> -configOnly

Note:
The response file you pass here is the same response file you passed in Installation Procedure.

Note:
Do not pass the option -forceConfigure.

After You Install

After you install the Management Agent, follow the steps outlined in After You Install.

Note:
If you want to repoint your existing Management Agents to a new Oracle Management Service (OMS), then you must first deinstall those Management Agents and plug-ins, and then redeploy those Management Agents and plug-ins using the new OMS. This is typically done when you want to move from an Enterprise Manager Cloud Control system in a test environment to an Enterprise Manager Cloud Control system in a production environment.
When you repoint your existing Management Agents to a new OMS, you cannot move the targets monitored by the Management Agents, the target history, and the Management Agent history. The monitored targets and the history data is lost.

Part V

Advanced Installation and Configuration

This part describes the advanced installation and configuration tasks you can perform after you have installed Enterprise Manager Cloud Control and have started using the product.

In particular, this part contains the following chapters:

- Chapter 10, "Configuring Enterprise Manager for Firewalls"

- Chapter 11, "Sizing Your Enterprise Manager Deployment"

- Chapter 12, "Installing ADP with Advanced Installation Options"

- Chapter 13, "Installing JVMD with Advanced Install Options"

- Chapter 14, "Integrating BI Publisher with Enterprise Manager"

10 Configuring Enterprise Manager for Firewalls

Firewalls protect a company's Information Technology (IT) infrastructure by providing the ability to restrict network traffic by examining each network packet and determining the appropriate course of action.

Firewall configuration typically involves restricting the ports that are available to one side of the firewall, for example the Internet. It can also be set up to restrict the type of traffic that can pass through a particular port such as HTTP. If a client attempts to connect to a restricted port (a port not covered by a security "rule") or uses a protocol that is incorrect, then the client will be disconnected immediately by the firewall. Firewalls can also be used within a company Intranet to restrict user access to specific servers.

You can deploy the components of Oracle Enterprise Manager on different hosts throughout your enterprise. These hosts can be separated by firewalls. This chapter describes how firewalls can be configured to allow communication between the Enterprise Manager components.

This chapter contains the following sections:

- Firewall Configuration Considerations

- Overview of Enterprise Manager Components and Ports

- Firewall Configurations for Enterprise Management Components

Firewall Configuration Considerations

Firewall configuration should be the last phase of Enterprise Manager deployment. Before you configure your firewalls, make sure you are able to log in to the Enterprise Manager console and that your Oracle Management Agents (Management Agent) are up and monitoring targets.

If you are deploying Enterprise Manager in an environment where firewalls are already installed, open the default Enterprise Manager communication ports for all traffic until you have completed the installation and configuration processes and are certain that you are able to log in to Enterprise Manager and that your Management Agents are up and monitoring targets.

The default communication ports for Enterprise Manager are assigned during the installation. If you modify the default ports, be sure to use the new port assignments when you configure the firewalls.

If you are enabling Enterprise Manager Framework Security for the Oracle Management Service (OMS), the final step in that configuration process is to restrict uploads from the Management Agents to secure channels only. Before completing that step, configure your firewalls to allow both HTTP and HTTPS traffic between the Management Agent and Management Repository and test to be sure that you can log in to Enterprise Manager and that data is being uploaded to the Management Repository.

After you have confirmed that the OMS and Management Agents can communicate with both protocols enabled, complete the transition to secure mode and change your firewall configuration as necessary. If you incrementally configure your firewalls, it will be easier to troubleshoot any configuration problems.

Enabling ICMP Echo Requests on Firewalls

OMS uses the Internet Control Message Protocol (ICMP) Echo Request to check the status target host machines. If the ICMP Echo Request is blocked by the firewall, a host machine will be appear to be down.

To determine the status of any machine in the environment, ICMP Echo Requests must be enabled on the firewall. If the ICMP Echo Request is enabled, the ping command can be issued by the OMS to check the status of the machine.

By default, port 7 will be used for the ICMP Echo Request.

Overview of Enterprise Manager Components and Ports

As described in the previous sections of this chapter, it is important to understand and identify the ports used by each of the Enterprise Manager components before you configure your firewalls.

Viewing a Summary of the Ports Assigned During Installation

The last panel in the Enterprise Manager installer, which is displayed just before the actual installation is started, list all of the ports assigned during the installation.

Post-installation, you can view these values in the staticports.ini file at the following location on the OMS host:

MIDDLEWARE_HOME/.gcinstall_temp/staticports.ini

You can get the Middleware home value by viewing the Oracle Home target for the OMS in Enterprise Manager.

Default Port Assignments for Enterprise Manager Components

Table 10-1 notes the default ports and/or port ranges assigned to various Enterprise Manager components that should be accessible through a firewall. These components include WebLogic Server components created as part of the WebLogic domain the Enterprise Manager installation belongs to, as well as optional components such as JVM Diagnostics and Application Dependency and Performance.

Table 10-1 Default Ports and Port Ranges for Enterprise Manager Components

Port

Default Values

Enterprise Manager Upload HTTP Port

4889 - 4898

Enterprise Manager Upload HTTPS (SSL) Port

1159, 4899 - 4908

Management Agent Port

3872

Management Repository Database Port

1521

Cloud Control Console HTTP Port

7788 - 7798

Cloud Control Console HTTPS (SSL) Port

7799 -7809

EM Domain WebLogic Admin Server HTTP Port

7001

EM Domain WebLogic Admin Server HTTPS (SSL) Port

7101 - 7200

Cloud Control Managed Server HTTP Port

7201 - 7300

Cloud Control Managed Server HTTPS (SSL) Port

7301 - 7400

WebLogic Node Manager HTTPS (SSL) Port

7401 - 7500

JVM Diagnostics Managed Server

3800

JVM Diagnostics Managed Server (SSL)

3801

Application Dependency and Performance RMI Registry Port

51099

Application Dependency and Performance Java Provider Port

5503

Application Dependency and Performance Remote Service Controller Port

55000

Real User Experience Insight HTTPS (SSL)

443

Firewall Configurations for Enterprise Management Components

Your main task in enabling Enterprise Manager to work in a firewall-protected environment is to take advantage of proxy servers whenever possible, to make sure only the necessary ports are open for secure communications, and to make sure that only data necessary for running your business is allowed to pass through the firewall.

Figure 10–1 provides a topology of an Enterprise Manager environment that is using a firewall, and also illustrates the default ports that can be used.

Figure 10-1 Firewall Port Requirements (Default)

Description of "Figure 10-1 Firewall Port Requirements (Default)"

The conventions used in the preceding illustration are as follows:

Table 10-2 Conventions Used In Illustration

Convention

Description

C

Is the entity that is making the call.

*

Enterprise Manager will default to the first available port within an Enterprise Manager set range.

**

Enterprise Manager will default to the first available port.

***

Database listener ports.

Notes:

- The direction of the arrows specify the direction of ports.

- Port 1159, 4898-4989 indicates that 1159 is the default. If this port is not available, the Oracle Management Service will search in the specified range (4889 - 4897).

- To clone between two target hosts separated by a firewall, the agents will need to communicate to each other on the agent ports. The initiating Management Agent will make the call.

The following sections describe the ports and types of data required by Enterprise Manager in a secure, firewall-protected environment:

- Firewalls Between Your Browser and the Enterprise Manager Console

- Configuring the Management Agent on a Host Protected by a Firewall

- Configuring the OMS on a Host Protected by a Firewall

- Firewalls Between the OMS and the Management Repository

- Firewalls Between Enterprise Manager and a Managed Database Target

- Firewalls Used with Multiple OMS Instances

- Configuring Firewalls to Allow ICMP and UDP Traffic for Beacons

Firewalls Between Your Browser and the Enterprise Manager Console

Connections from your browser to the Enterprise Manager console are performed over the default port used for your Oracle HTTP Server.

For example, the default, non-secure port for the Oracle HTTP Server is usually port 7788. If you are accessing the Enterprise Manager console using the following URL and port, then you must configure the firewall to allow the Enterprise Manager console to receive HTTP traffic over port 7788:

http://omshost.example.com:7788/em

On the other hand, if you have enabled security for your Oracle HTTP Server, you are likely using the default secure port for the server, which is usually port 7799. If you are accessing the Enterprise Manager console using the following URL and port, then you must configure the firewall to allow the Enterprise Manager console to receive HTTPS traffic over port 7799:

https://omshost.example.com:7799/em

Configuring the Management Agent on a Host Protected by a Firewall

If your Management Agent is installed on a host that is protected by a firewall and the OMS is on the other side of the firewall, you must perform the following tasks:

- Configure the Management Agent to use a proxy server for its uploads to the OMS.

- Configure the firewall to allow incoming HTTP traffic from the OMS on the Management Agent port. Regardless of whether or not Enterprise Manager Framework Security has been enabled, the default port is 3872. Incoming traffic can be received only if the port corresponding to the Management Agent is open in the firewall.

Figure 10-2 illustrates the connections the Management Agent must make when it is protected by a firewall.

Figure 10-2 Configuration Tasks When the Management Agent Is Behind a Firewall

Description of "Figure 10-2 Configuration Tasks When the Management Agent Is Behind a Firewall"

Configuring the Management Agent to Use a Proxy Server

You can configure the Management Agent to use a proxy server for its communications with an OMS outside the firewall, or to manage a target outside the firewall.

1. From the Setup menu, select Agents.

2. Click the Agent you want to configure in the Name column in the Management Agents table. The target home page for the Management Agent opens.

3. Select Properties from the Agent menu.

4. Select Advanced Properties from the pull down menu.

5. Supply the correct values for the proxyHost and proxyPort properties.

6. Click Apply to save your changes, which will be saved to the AGENT_HOME/sysman/config/emd.properties file.

Note:
The proxy password will be obfuscated when you restart the Management Agent.

Configuring the Firewall to Allow Incoming Communication From the Management Service

While the Management Agents in your environment must upload data from your managed hosts to the OMS, the OMS must also communicate with the Management Agents. As a result, if the Management Agent is protected by a firewall, the OMS must be able to contact the Management Agent through the firewall on the Management Agent port.

By default, the Enterprise Manager installation procedure assigns port 3872 to the Management Agent. However, if that port is occupied, the installation may assign an alternate port number.

After you determine the port number assigned to the Management Agent, you must then configure the firewall to allow incoming HTTP or HTTPS traffic (depending upon whether or not you have enabled Enterprise Manager Framework Security) on that port.

Configuring the OMS on a Host Protected by a Firewall

If your OMS is installed on a host that is protected by a firewall and the Management Agents that provide management data are on the other side of the firewall, you must perform the following tasks:

- Configure the OMS to use a proxy server for its communications to the Management Agents.

- Configure the firewall to allow incoming HTTP traffic from the Management Agents on the Management Repository upload port.
If you have enabled Enterprise Manager Framework Security, the upload URL uses port 1159 by default. If this port is not available, Enterprise Manager will default to first available port in the range 4899-4908. If you have not enabled Enterprise Manager Framework Security, the upload port is the first available port in the range 4889 - 4897.

Figure 10-3 illustrates the connections the Management Agent must make when it is protected by a firewall.

Figure 10-3 Configuration Tasks When the Management Service Is Behind a Firewall

Description of "Figure 10-3 Configuration Tasks When the Management Service Is Behind a Firewall"

Configuring the OMS to Use a Proxy Server to Communicate with Management Agents

This section describes how to configure the OMS to use a proxy server for its communications with Management Agents outside the firewall.

To configure the OMS to use a proxy server, do the following:

1. From the Setup menu, select Proxy Settings.

2. Under “Agent Connection Setting”, click Manual Proxy Configuration.

3. Supply the necessary HTTP or HTTPS property values for your configuration.

4. Click Apply to save your changes to the OMS_HOME/sysman/config/emd.properties file for the OMS instance.

5. After you have supplied your configuration, supply a Management Agent URL (or use the URL supplied by default) to test it.

Configuring the Firewall to Allow Incoming Management Data From the Management Agents

While the Management Agents in your environment must contact the Management Agents on your managed hosts, the OMS must also be able to receive upload data from the Management Agents. If the OMS is behind a firewall, you must configure the firewall to allow the Management Agents to upload data on the upload port.

By default, the Enterprise Manager installation procedure assigns port 4889 as the Repository upload port. However, if that port is occupied, the installation will assign an alternate port number.

In addition, when you enable Enterprise Manager Framework Security, the upload port is automatically changed to the secure 1159 HTTPS port.

Administrators can also change the upload port after the installation.

After you determine the port number assigned to the OMS upload port, you must then configure the firewall to allow incoming HTTP or HTTPS traffic (depending upon whether or not you have enabled Enterprise Manager Framework Security) on that port.

Enabling OMS to Access My Oracle Support

Unless online access to the Internet is strictly forbidden in your environment, OMS should be enabled to access My Oracle Support. This access is necessary to enable updates and patches to be downloaded, for example.

At minimum, the following URLs should be made available through the firewall:

- aru-akam.oracle.com

- ccr.oracle.com

- login.oracle.com

- support.oracle.com

- updates.oracle.com

About the dontProxyfor Property

When you configure the OMS or a Management Agent to use a proxy server, it is important to understand the purpose of the dontProxyFor property, which identifies specific URL domains for which the proxy will not be used.

For example, suppose the following were true:

- You have installed the OMS and several Management Agents on hosts that are inside the company firewall. These hosts are in the internal .example.com and .example.us.com domains.

- You have installed several additional Management Agents on hosts that are outside the firewall. These hosts are installed in the .example.uk domain.

- You have configured Enterprise Manager to automatically check for critical software patches on My Oracle Support.

In this scenario, you want the OMS to connect directly to the Management Agents inside the firewall without using the proxy server. On the other hand, you want the OMS to use the proxy server to contact the Management Agents outside the firewall, as well as the My Oracle Support site, which resides at the following URL:

http://support.oracle.com

The following properties will prevent the OMS from using the proxy server for connections to the Management Agents inside the firewall. Connections to My Oracle Support and to Management Agents outside the firewall will be routed through the proxy server:

proxyHost=proxy42.example.com
proxyHost=80
dontProxyFor=.example.com, .example.us.com

Firewalls Between the OMS and the Management Repository

Secure connections between the OMS and the Management Repository are performed using features of Oracle Advanced Security. As a result, if the OMS and the Management Repository are separated by a firewall, you must configure the firewall to allow Oracle Net firewall proxy access.

Firewalls Between Enterprise Manager and a Managed Database Target

When you are using the Enterprise Manager console to manage a database, you must log in to the database from the Enterprise Manager console in order to perform certain monitoring and administration tasks. If you are logging in to a database on the other side of a firewall, you will need to configure the firewall to allow Oracle Net firewall proxy access.

Specifically, to perform any administrative activities on the managed database, you must be sure that the firewall is configured to allow the OMS to communicate with the database through the Oracle Listener port.

You can obtain the Listener port by reviewing the Listener home page in the Enterprise Manager console.

Firewalls Used with Multiple OMS Instances

Enterprise Manager supports the use of multiple OMS instances that communicate with a common Management Repository. For example, using more than one OMS can be helpful for load balancing as you expand your central management capabilities across a growing e-business enterprise.

When you deploy multiple OMS instances in an environment protected by firewalls, be sure to consider the following:

- Each Management Agent is configured to upload data to one OMS. As a result, if there is a firewall between the Management Agent and its OMS, you must configure the firewall to allow the Management Agent to upload data to the OMS using the upload URL.

See Also:
Configuring the Management Agent on a Host Protected by a Firewall
Configuring the OMS on a Host Protected by a Firewall

- In addition, each OMS must be able to contact any Management Agent in your enterprise so it can check for the availability of the Management Agent. As a result, you must be sure that your firewall is configured so that each OMS you deploy can communicate over HTTP or HTTPS with any Management Agent in your enterprise.
Otherwise, an OMS without access to a particular Management Agent may report incorrect information about whether or not the Management Agent is up and running.

See Also:
"About Availability" in the Enterprise Manager online help for information about how Enterprise Manager determines host and Management Agent availability.

Configuring Firewalls to Allow ICMP and UDP Traffic for Beacons

Oracle Beacons provide application performance availability and performance monitoring. They are part of the Application Service Level Management features of Enterprise Manager.

See Also:
"About Application Service Level Management" in the Enterprise Manager Online Help

Enterprise Manager uses the industry-standard Internet Control Message Protocol (ICMP) and User Datagram Protocol (UDP) to transfer data between Beacon and the network components you are monitoring. There may be situations where your Web application components and the Beacons you use to monitor those components are separated by a firewall. In those cases, you must configure your firewall to allow ICMP, UDP and HTTP traffic.

11 Sizing Your Enterprise Manager Deployment

Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.2 has the ability to scale for hundreds of users and thousands of systems and services on a single Enterprise Manager implementation.

This chapter describes techniques for achieving optimal performance using the Oracle Enterprise Manager application. It can also help you with capacity planning, sizing and maximizing Enterprise Manager performance in a large scale environment. By maintaining routine housekeeping and monitoring performance regularly, you insure that you will have the required data to make accurate forecasts of future sizing requirements. Receiving good baseline values for the Enterprise Manager Cloud Control vital signs and setting reasonable warning and critical thresholds on baselines allows Enterprise Manager to monitor itself for you.

This chapter contains the following sections:

- Overview of Oracle Enterprise Manager Cloud Control Architecture

- Enterprise Manager Cloud Control Sizing

- Enterprise Manager Cloud Control Performance Methodology

- Overview of Repository and Sizing Requirements for Fusion Middleware Monitoring

Overview of Oracle Enterprise Manager Cloud Control Architecture

The architecture for Oracle Enterprise Manager Cloud Control exemplifies two key concepts in application performance tuning: distribution and parallelization of processing. Each component of Cloud Control can be configured to apply both these concepts.

The components of Enterprise Manager Cloud Control include:

- The Management Agent - A process that is deployed on each monitored host and that is responsible for monitoring all services and components on the host. The Management Agent is also responsible for communicating that information to the middle-tier Management Service and for managing and maintaining the system and its services.

- The Management Service - A J2EE Web application that renders the user interface for the Cloud Control console, works with all Management Agents to process monitoring and jobs information, and uses the Management Repository as its data store.

- The Management Repository - The schema is an Oracle Database that contains all available information about administrators, services, and applications managed within Enterprise Manager.

For more information about the Cloud Control architecture, see the Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.2 documentation:

- Oracle Enterprise Manager Grid Control Installation and Basic Configuration

- Oracle Enterprise Manager Concepts

The Oracle Enterprise Manager 12c documentation is available at the following location on the Oracle Technology Network (OTN):

http://www.oracle.com/technetwork/indexes/documentation/index.html

Enterprise Manager Cloud Control Sizing

Oracle Enterprise Manager provides a highly available and scalable deployment topology. This chapter lays out the basic minimum sizing and tuning recommendations for initial capacity planning for your Oracle Enterprise Manager deployment. This chapter assumes a basic understanding of Oracle Enterprise Manager components and systems. A complete description of Oracle Enterprise Manager can be obtained from http://docs.oracle.com/cd/E24628_01/doc.121/e25353/overview.htm. This information is a starting point for site sizing. Every site has its own characteristics and should be monitored and tuned as needed.

Sizing is a critical factor for Enterprise Manager performance. Inadequately sized Enterprise Manager deployments will result in frustrated users and the overall benefits of Enterprise Manager may be compromised. The resources required for Enterprise Manager OMS and Repository tiers will vary significantly based on the number of monitored targets. While there are many additional aspects to be considered when sizing Enterprise Manager infrastructure, the following guidelines provide a simple methodology that can be followed to determine the minimum required hardware resources and initial configuration settings for the OMS and Repository tiers.

Overview of Sizing Guidelines

The following sections provide an overview of the sizing guidelines.

Hardware Information

The sizing guidelines outlined in this chapter were obtained by running a virtual environment on the following hardware and operating system combination.

- Hardware -- Oracle's Sun Fire X4170 M2

- Hypervisor -- 64 bit Linux Oracle Virtual Server

- Operating System of Virtual Machines -- 64 bit Oracle Enterprise Linux

The virtual environment setup had a one to one mapping of CPUs between the Oracle Virtual Server (OVS) host and the virtual machines running on it. The OVS servers had enough RAM to support all virtual machines without memory swapping.

This information is based on a 64 bit Oracle Enterprise Linux environment. If you are running on other platforms, you will need to convert the sizing information based on similar hardware performance. This conversion should be based on single-thread performance. Running on a machine with 24 slow cores is not equivalent to running on a machine with 12 fast cores even though the total machine performance might be the same on a throughput benchmark. Single thread performance is critical for good Enterprises Manager user interface response times.

Sizing Specifications

The sizing guidelines for Oracle Enterprise Manager are divided into three sizes: Small, Medium and Large. The definitions of each size are shown in Table 11-1.

Table 11-1 Oracle Enterprise Manager Site Sizes

Size

Agent Count

Target Count

Concurrent User Sessions

Small

< 100

< 1000

<10

Medium

>= 100, < 1000

>= 1000, < 10,000

>= 10, < 25

Large

>= 1000

>= 10,000

>= 25, <= 50*

For larger user loads see Large Concurrent UI Load.

Sizing for Upgraded Installs

For upgraded installs the following queries can be run as the sysman user to obtain the Management Agent and target counts for use in Table 1.

- Agent count - select count(*) from mgmt_targets where target_type = 'oracle_emd'

- Target count – select count(*) from mgmt_targets where target_type != 'oracle_emd'

Minimum Hardware Requirements

Table 11-2 lists the minimum hardware requirements for the three configurations.

Table 11-2 Oracle Enterprise Manager Minimum Hardware Requirements

Size

OMS Machine Count*

Cores per OMS

Memory per OMS (GB)

Database Machine Count*

Cores per Database Machine

Memory per Database Machine (GB)

Small

1

2

6

1

2

6

Medium

2

4

8

2 (Oracle RAC)

4

8

Large

2

4

8

4

16

8

2 (Oracle RAC)

2 (Oracle RAC)

8

8

16

16

*The OMS and database instances are not co-located

Network Topology Considerations

A critical consideration when deploying Enterprise Manager Cloud Control is network performance between tiers. Enterprise Manager Cloud Control ensures tolerance of network glitches, failures, and outages between application tiers through error tolerance and recovery. The Management Agent in particular is able to handle a less performant or reliable network link to the Management Service without severe impact to the performance of Enterprise Manager as a whole. The scope of the impact, as far as a single Management Agent's data being delayed due to network issues, is not likely to be noticed at the Enterprise Manager Cloud Control system wide level.

The impact of slightly higher network latencies between the Management Service and Management Repository will be substantial, however. Implementations of Enterprise Manager Cloud Control have experienced significant performance issues when the network link between the Management Service and Management Repository is not of sufficient quality.

The Management Service host and Repository host should be located in close proximity to each other. Ideally, the round trip network latency between the two should be less than 1 millisecond.

Software Configurations

The following sections provide information about small, medium and large configurations.

Small Configuration

The Small configuration is based on the minimum requirements that are required by the Oracle Enterprise Manager installer.

Minimum OMS Settings

No additional settings are required.

Minimum Database Settings

Table 11-3 lists the minimum recommended database settings.

Table 11-3 Small Site Minimum Database Settings

Parameter

Minimum Value

*memory_target of 3GB can be used in place of sga_target and pga_aggregate_target

processes

300

pga_aggregate_target*

1024M

sga_target*

2G

redo log file size

300M

shared_pool_size

600M

Medium Configuration

The Medium configuration modifies several out-of-box Oracle Enterprise Manager settings.

Minimum OMS Settings

The Oracle Management Service (OMS) heap size should be set to 4096m.

Minimum Repository Database Settings

Table 11-4 lists the minimum repository database settings that are recommended for a Medium configuration.

Table 11-4 Medium Site Minimum Database Settings

Parameter

Minimum Value

*memory_target of 5.25GB can be used in place of sga_target and pga_aggregate_target

processes

600

pga_aggregate_target*

1280M

sga_target*

4G

redo log file size

600M

shared_pool_size

600M

Large Configuration

The Large configuration modifies several out-of-box Oracle Enterprise Manager settings.

Minimum OMS Settings

Table 11-5 lists the minimum OMS settings that are recommended for Large configurations.

Table 11-5 Large Site Minimum OMS Settings

OMS Count

Heap Size Minimum Value

2

8192M

4

4096M

Minimum Repository Database Settings

Table 11-6 lists the minimum repository database settings that are recommended for a Large configuration.

Table 11-6 Large Site Minimum Database Settings

Parameter

Minimum Value

*memory_target of 7.5GB can be used in place of sga_target and pga_aggregate_target

processes

1000

pga_aggregate_target*

1536M

sga_target*

6G

redo log file size

1000M

shared_pool_size

600M

Repository Tablespace Sizing

Table 11-7 lists the required minimum storage requirements for the Management Repository.

Table 11-7 Total Management Repository Storage

Deployment Size

Minimum Tablespace Sizes*

SYSTEM**

MGMT_TABLESPACE

MGMT_ECM_DEPOT_TS

MGMT_AD4J_TS

TEMP

*These are strictly minimum values and are intended as rough guidelines only. The actual size of the MGMT_TABLESPACE could vary widely from deployment to deployment due to variations in target type distribution, user customization, and several other factors. These tablespaces are defined with AUTOEXTEND set to ON by default to help mitigate space constraint issues. On raw file systems Oracle recommends using more than the minimum size to help prevent space constraint issues.
**The SYSTEM and TEMP tablespace sizes are minimums for Enterprise Manager only repositories. If Enterprise Manager is sharing the repository database with other application(s), these minimums may be too low.
Note: You cannot monitor tablespaces through the use of alerts with auto extended files in version 11g of Enterprise Manager. You can either set up TABLESPACE FULL alerts generate if you want to have greater control over the management of your tablespaces, or you can allow Oracle to grow your database and not alert you through the AUTOEXTEND feature. Therefore to exercise greater control of the TABLESPACE FULL alerts, you can turn off autoextend.

Small

600 MB

50 GB

1 GB

100 MB

10 GB

Medium

600 MB

200 GB

4 GB

200 MB

20 GB

Large

600 MB

300 GB

Greater than 4 GB

400 MB

40 GB

Additional Configurations

Some Enterprise Manager installations may need additional tuning settings based on larger individual system loads. Additional settings are listed below.

Large Concurrent UI Load

If more than 50 concurrent users are expected per OMS, the following settings should be altered as seen in Table 11-8.

Table 11-8 Large Concurrent UI Load Additional Settings

Process

Parameter

Value

Where To Set

OMS

-Djbo.recyclethreshold

Number of concurrent users / number of OMS

Per OMS

OMS

-Djbo.ampool.maxavailablesize

Number of concurrent users / number of OMS

Per OMS

OMS

Heap Size

Additional 4GB for every increment of 50 users

Per OMS

Database

sga_target

Additional 1GB for every increment of 50 users

Per Instance

Higher user loads will require more hardware capacity. An additional 2 cores for both the database and OMS hosts for every 50 concurrent users.

Example: A site with 1500 agents and 15,000 targets with 150 concurrent users would require at a minimum the setting modifications listed in Table 11-9 (based on a LARGE 2 OMS configuration).

Table 11-9 Large Concurrent UI Load Additional Settings Example for 2 OMS Configurations

Process

Parameter

Value

Calculation

OMS

-Djbo.recyclethreshold

75 (set on each OMS)

150 users / 2 OMS

OMS

-Djbo.ampool.maxavailablesize

75 (set on each OMS)

150 users / 2 OMS

OMS

Heap Size

12GB (set on each OMS)

8GB (standard large setting) + ((150 users – 50 default large user load) / 2 OMS)* (4GB / 50 users)

Database

sga_target

8GB

6GB (standard large setting) + (150 users - 50 default large user load) * (1GB / 50 users)

Minimum Additional Hardware required is listed in Table 11-10.

Table 11-10 Large Concurrent UI Load Minimum Additional Hardware Example For 2 OMS Configuration

Tier

Parameter

Value

Calculation

OMS

CPU cores

24 (total between all OMS hosts)

8 cores * 2 OMS (default large core count) + (150 users - 50 default large user load) *(2 cores * 2 OMS)/ 50 users)

Database

CPU cores

24 (total between all Database hosts)

8 cores * 2 OMS (default large core count) + (150 users - 50 default large user load) *(2 cores * 2 OMS / 50 users)

The physical memory of each machine would have to be increased to support running this configuration as well.

BI Publisher Configuration

If you plan on integrating BI Publisher version 11.1.1.5 with Enterprise Manager Release 12c Cloud Control, which is required for BI Publisher reports to function, add 1.5 GB to the host memory requirements stated above.

Enterprise Manager Cloud Control Performance Methodology

An accurate predictor of capacity at scale is the actual metric trend information from each individual Enterprise Manager Cloud Control deployment. This information, combined with an established, rough, starting host system size and iterative tuning and maintenance, produces the most effective means of predicting capacity for your Enterprise Manager Cloud Control deployment. It also assists in keeping your deployment performing at an optimal level.

Here are the steps to follow to enact the Enterprise Manager Cloud Control sizing methodology:

1. If you have not already installed Enterprise Manager Cloud Control, choose a rough starting host configuration as listed in Table 11-1.

2. Periodically evaluate your site's vital signs (detailed later).

3. Eliminate bottlenecks using routine DBA/Enterprise Manager administration housekeeping.

4. Eliminate bottlenecks using tuning.

5. Extrapolate linearly into the future to plan for future sizing requirements.

Step one need only be done once for a given deployment. Steps two, three, and four must be done, regardless of whether you plan to grow your Enterprise Manager Cloud Control site, for the life of the deployment on a regular basis. These steps are essential to an efficient Enterprise Manager Cloud Control site regardless of its size or workload. You must complete steps two, three, and four before you continue on to step five. This is critical. Step five is only required if you intend to grow the deployment size in terms of monitored targets. However, evaluating these trends regularly can be helpful in evaluating any other changes to the deployment.

Step 1: Choosing a Starting Platform Cloud Control Deployment

For information about choosing a starting platform Cloud Control deployment, see Overview of Sizing Guidelines.

Step 2: Periodically Evaluating the Vital Signs of Your Site

This is the most important step of the five. Without some degree of monitoring and understanding of trends or dramatic changes in the vital signs of your Enterprise Manager Cloud Control site, you are placing site performance at serious risk. Every monitored target sends data to the Management Repository for loading and aggregation through its associated Management Agent. This adds up to a considerable volume of activity that requires the same level of management and maintenance as any other enterprise application.

Enterprise Manager has "vital signs" that reflect its health. These vital signs should be monitored for trends over time as well as against established baseline thresholds. You must establish realistic baselines for the vital signs when performance is acceptable. Once baselines are established, you can use built-in Oracle Enterprise Manager Cloud Control functionality to set baseline warning and critical thresholds. This allows you to be notified automatically when something significant changes on your Enterprise Manager site. The following table is a point-in-time snapshot of the Enterprise Manager Cloud Control vital signs for two sites:

Module

Metrics

EM Site 1

EM Site 2

Site URL

emsite1.acme.com

emsite2.acme.com

Target Counts

Database Targets

192 (45 not up)

1218 (634 not up)

Host Targets

833 (12 not up)

1042 (236 not up)

Total Targets

2580 (306 not up)

12293 (6668 not up)

Loader Statistics

Loader Threads

6

16

Total Rows/Hour

1,692,000

2,736,000

Rows/hour/load/thread

282,000

171,000

Rows/second/load thread

475

187

Percent of Hour Run

15

44

Rollup Statistics

Rows per Second

2,267

417

Percent of Hour Run

5

19

Job Statistics

Job Dispatchers

2

4

Job Steps/second/dispatcher

32

10

Event Statistics

Events Processed (last hour)

536

1,100

Management Service Host Statistics

Average % CPU (Host 1)

9 (emhost01)

13 (emhost01)

Average % CPU (Host 2)

6 (emhost02)

17 (emhost02)

Average % CPU (Host 3)

N/A

38 (em6003)

Average % CPU (Host 4)

N/A

12 (em6004)

Number of CPUs per host

2 X 2.8 (Xeon)

4 X 2.4 (Xeon)

Memory per Host (GB)

6

6

Management Repository Host Statistics

Average % CPU (Host 1)

12 (db01rac)

32 (em6001rac)

Average % CPU (Host 2)

Average % CPU (Host 3)

Average % CPU (Host 4)

Number of CPUs per host

Buffer Cache Size (MB)

Memory per Host (GB)

6

12

Total Management Repository Size (GB)

56

98

Oracle RAC Interconnect Traffic (MB/s)

1

4

Management Server Traffic (MB/s)

4

4

Total Management Repository I/O (MB/s)

6

27

Enterprise Manager UI Page Response/Sec

Home Page

3

6

All Host Page

3

30+

All Database Page

6

30+

Database Home Page

2

2

Host Home Page

2

2

The two Enterprise Manager sites are at the opposite ends of the scale for performance.

EM Site 1 is performing very well with high loader rows/sec/thread and high rollup rows/sec. It also has a very low percentage of hours run for the loader and the rollup. The CPU utilization on both the OMS and Management Repository Server hosts are low. Most importantly, the UI Page Response times are excellent. To summarize, Site 1 is doing substantial work with minimal effort. This is how a well configured, tuned and maintained Oracle Enterprise Manager Cloud Control site should look.

Conversely, EM Site 2 is having difficulty. The loader and rollup are working hard and not moving many rows. Worst of all are the UI page response times. There is clearly a bottleneck on Site 2, possibly more than one.

The following table outlines metric guidelines for the different modules based on tests that were run with the configurations outlined. It can serve as a reference point for you to extrapolate information and data based on the metrics and test environment used in the specified environment.

Table 11-11 Metric Guidelines for Modules Based On Test Environments

Module

Metrics

Value

Test Environment

Loader Statistics

NA

NA

OMS Details

# of OMS Hosts = 2
# of CPU Per Host = 4 Intel Xeon
Memory = 6 GB
Repository Details

# of Repository Nodes = 2
# of CPU per host = 4 Intel Xeon
Memory = 6 GB
EM Details

Shared Recv Directory = Yes
# of Agents = 867
# of Hosts = 867
Total Targets = 1803
The Metrics are collected for 5 hours after 2 OMS instances were started and each agent had 50 MB of upload backlog files.

Total Rows/Hour

4,270,652

Rows/Hour/loaderthread

427,065

Rows/second/loaderthread

120

Rollup Statistics

Rows per second

Job Statistics

Job Dispatchers

1 x Number of OMS instances

Job Steps/second/dispatcher

Notification Statistics

Notifications per second

16

OMS Details

# of OMS Hosts = 1
# of CPU Per Host = 4 Intel Xeon
Memory = 6 GB
Repository Details

# of Repository Nodes = 1
# of CPU per host = 4 Intel Xeon
Memory = 6 GB
EM Details

# of OMS instances = 1
# of Repository Nodes = 1
# of Agents = 2474
# of Hosts = 2474
DB Total Targets = 8361

Alert Statistics

Alerts per hour

7200

OMS Details

# of OMS Hosts = 1
# of CPU Per Host = 4 Intel Xeon
Memory = 6 GB

Repository Details

# of Repository Nodes = 1
# of CPU per host = 4 Intel Xeon
Memory = 6 GB

EM Details

# of OMS instances = 1
# of Repository Nodes = 1
# of Agents = 2474
# of Hosts = 2474
DB Total Targets = 8361

Management Service Host Statistics

Average % CPU (Host 1)

31%

OMS Details

# of OMS Hosts = 2
# of CPU Per Host = 4 Intel Xeon
Memory = 6 GB

Repository Details

# of Repository Nodes = 2
# of CPU per host = 4 Intel Xeon
Memory = 6 GB

EM Details

Shared Recv Directory = Yes

# of Agents = 867
# of Hosts = 867
Total Targets = 1803

The Metrics are collected for 5 hours after 2 OMS instances were started and each agent had 50 MB of upload backlog files.

Average % CPU (Host 2)

34%

Number of CPUs per host

4 (Xeon)

Memory per Host (GB)

6

Management Repository Host Statistics

Average % CPU (Host 1)

32%

OMS Details

# of OMS Hosts = 2
# of CPU Per Host = 4 Intel Xeon
Memory = 6 GB

Repository Details

# of Repository Nodes = 2
# of CPU per host = 4 Intel Xeon
Memory = 6 GB

EM Details

Shared Recv Directory = Yes

# of Agents = 867
# of Hosts = 867
Total Targets = 1803

The Metrics are collected for 5 hours after 2 OMS instances were started and each agent had 50 MB of upload backlog files.

Average % CPU (Host 2)

26%

Number of CPUs per host

4

SGA Target

2 GB

Memory per Host (GB)

6

Total Management Repository Size (GB)

94

Oracle RAC Interconnect Traffic (MB/s)

1

Management Server Traffic (MB/s)

Total Management Repository I/O (MB/s)

Enterprise Manager UI Page Response/Sec

Home Page

9.1 secs

OMS Details

# of OMS Hosts = 1
# of CPU Per Host = 4 Intel Xeon
Memory = 6 GB

Repository Details

# of Repository Nodes = 1
# of CPU per host = 4 Intel Xeon
Memory = 6 GB

EM Details

# of OMS instances = 1
# of Repository Nodes = 1
# of Agents = 2474
# of Hosts = 2474
DB Total Targets = 8361

All Host Page

9.8 secs

All Database Page

5.7 secs

Database Home Page

1.7 secs

Host Home Page

< 1 sec

These vital signs are all available from within the Enterprise Manager interface. Most values can be found on the All Metrics page for each host, or the All Metrics page for the OMS. Keeping an eye on the trends over time for these vital signs, in addition to assigning thresholds for warning and critical alerts, allows you to maintain good performance and anticipate future resource needs. You should plan to monitor these vital signs as follows:

- Take a baseline measurement of the vital sign values seen in the previous table when the Enterprise Manager Cloud Control site is running well.

- Set reasonable thresholds and notifications based on these baseline values so you can be notified automatically if they deviate substantially. This may require some iteration to fine-tune the thresholds for your site. Receiving too many notifications is not useful.

- On a daily (or weekly at a minimum) basis, watch for trends in the 7-day graphs for these values. This will not only help you spot impending trouble, but it will also allow you to plan for future resource needs.

The next step provides some guidance of what to do when the vital sign values are not within established thresholds. Also, it explains how to maintain your site's performance through routine housekeeping.

Step 3: Using DBA and Enterprise Manager Tasks To Eliminate Bottlenecks

It is critical to note that routine housekeeping helps keep your Enterprise Manager Cloud Control site running well. The following are lists of housekeeping tasks and the interval on which they should be done.

Offline Monthly Tasks

Enterprise Manager Administrators should monitor the database built-in Segment Advisor for recommendations on Enterprise Manager Repository segment health. The Segment Advisor advises administrators which segments need to be rebuilt/reorganized and provides the commands to do so.

For more information about Segment Advisor and issues related to system health, refer to notes 242736.1 and 314112.1 in the My Oracle Support Knowledge Base.

Step 4: Eliminating Bottlenecks Through Tuning

The most common causes of performance bottlenecks in the Enterprise Manager Cloud Control application are listed below (in order of most to least common):

1. Housekeeping that is not being done (far and away the biggest source of performance problems)

2. Hardware or software that is incorrectly configured

3. Hardware resource exhaustion

When the vital signs are routinely outside of an established threshold, or are trending that way over time, you must address two areas. First, you must ensure that all previously listed housekeeping is up to date. Secondly, you must address resource utilization of the Enterprise Manager Cloud Control application. The vital signs listed in the previous table reflect key points of resource utilization and throughput in Enterprise Manager Cloud Control. The following sections cover some of the key vital signs along with possible options for dealing with vital signs that have crossed thresholds established from baseline values.

High CPU Utilization

When you are asked to evaluate a site for performance and notice high CPU utilization, there are a few common steps you should follow to determine what resources are being used and where.

1. Use the Processes display on the Enterprise Manager Host home page to determine which processes are consuming the most CPU on any Management Service or Management Repository host that has crossed a CPU threshold.

2. Once you have established that Enterprise Manager is consuming the most CPU, use Enterprise Manager to identify what activity is the highest CPU consumer. Typically this manifests itself on a Management Repository host where most of the Management Service's work is performed. Here are a few typical spots to investigate when the Management Repository appears to be using too many resources.

1. Click the CPU Used database resource listed on the Management Repository's Database Performance page to examine the SQL that is using the most CPU at the Management Repository.

2. Check the Database Locks on the Management Repository's Database Performance page looking for any contention issues.

High CPU utilization is probably the most common symptom of any performance bottleneck. Typically, the Management Repository is the biggest consumer of CPU, which is where you should focus. A properly configured and maintained Management Repository host system that is not otherwise hardware resource constrained should average roughly 40 percent or less total CPU utilization. An OMS host system should average roughly 20 percent or less total CPU utilization. These relatively low average values should allow sufficient headroom for spikes in activity. Allowing for activity spikes helps keep your page performance more consistent over time. If your Enterprise Manager Cloud Control site interface pages happen to be responding well (approximately 3 seconds) while there is no significant (constant) loader backlog, and it is using more CPU than recommended, you may not have to address it unless you are concerned it is part of a larger upward trend.

The recommended path for tracking down the root cause of high Management Repository CPU utilization is captured under step 3.b above. This allows you to start at the Management Repository Performance page and work your way down to the SQL that is consuming the most CPU in its processing. This approach has been used very successfully on several real world sites.

If you are running Enterprise Manager on Intel based hosts, the Enterprise Manager Cloud Control Management Service and Management Repository will both benefit from Hyper-Threading (HT) being enabled on the host or hosts on which they are deployed. HT is a function of certain late models of Intel processors, which allows the execution of some amount of CPU instructions in parallel. This gives the appearance of double the number of CPUs physically available on the system. Testing has proven that HT provides approximately 1.5 times the CPU processing power as the same system without HT enabled. This can significantly improve system performance. The Management Service and Management Repository both frequently have more than one process executing simultaneously, so they can benefit greatly from HT.

Loader Vital Signs

The vital signs for the loader indicate exactly how much data is continuously coming into the system from all the Enterprise Manager Agents. The most important items here are the percent of hour runs and rows/second/thread. The (Loader) % of hour run indicates whether the loader threads configured are able to keep pace with the incoming data volume. As this value approaches 100%, it becomes apparent that the loading process is failing to keep pace with the incoming data volume. The lower this value, the more efficiently your loader is running and the less resources it requires from the Management Service host. Adding more loader threads to the OMS can help reduce the percent of hour run for the loader.

Rows/Second/Thread is a precise measure of each loader thread's throughput per second. The higher this number, the better. Rows/Second/Thread as high as 1200 have been observed on some smaller, well configured and maintained Enterprise Manager Cloud Control sites. If you have not increased the number of loader threads and this number is trending down, it may indicate a problem later. One way to overcome a decreasing rows/second/thread is to add more loader threads.

The number of Loader Threads is always set to one by default in the OMS configuration file. Each OMS can have a maximum of 10 loader threads. Adding loader threads to a OMS typically increases the overall host CPU utilization by 2% to 5% on a Enterprise Manager Cloud Control site with many Management Agents configured. Customers can change this value as their site requires. Most medium size and smaller configurations will never need more than one loader thread. Here is a simple guideline for adding loader threads:

Max total (across all OMS instances) loader threads = 2 X number of Management Repository host CPUs

There is a diminishing return when adding loader threads. You will not yield 100% capacity from the second, or higher, thread. There should be a positive benefit, however. As you add loader threads, you should see rows/second/thread decrease, but total rows/hour throughput should increase. If you are not seeing significant improvement in total rows/hour, and there is a constantly growing loader file backlog, it may not be worth the cost of the increase in loader threads. You should explore other tuning or housekeeping opportunities in this case.

To add more loader threads, you can change the following configuration parameter where n is a positive integer [1-10]:

em.loader.threadPoolSize=n

The default is 1 and any value other than [1-10] will result in the thread pool size defaulting to 1. This property file is located in the {ORACLE_HOME}/sysman/config directory. Changing this parameter will require a restart of the Management Service to be reloaded with the new value.

The following two parameters are set for the Receiver module which receives files from agents.

1. em.loader.maxDataRecvThreads=n (Default 75)
Where n is a positive integer and default value is 75. This is used to limit the maximum number of concurrent data file receiver threads. So at the peak time only 75 receiver threads will be receiving files and an extra request will be rejected with a Server Busy error. These rejected requests will be resent by the agent after the default retry time.

Care should be taken while setting this value as too high a value will put an increased load on the OMS machine and shared receiver directory box. If too low a value is set then data file receive throughput will be low.

2. oracle.sysman.emRep.dbConn.maxConnForReceiver=n (Default 25)
Where n is a positive integer and default value is 25. This is used to set the maximum number of Repository Database connections for the receive threads. Oracle recommends you set this value equal to em.loader.maxDataRecvThreads, as each Receiver thread gets one DB session and there will be no wait for DB connections.

Rollup Vital Signs

The rollup process is the aggregation mechanism for Enterprise Manager Cloud Control. The two vital signs for the rollup are the rows/second and % of hour run. Due to the large volume of data rows processed by the rollup, it tends to be the largest consumer of Management Repository buffer cache space. Because of this, the rollup vital signs can be great indicators of the benefit of increasing buffer cache size.

Rollup rows/second shows exactly how many rows are being processed, or aggregated and stored, every second. This value is usually around 2,000 (+/- 500) rows per second on a site with a decent size buffer cache and reasonable speedy I/O. A downward trend over time for this value may indicate a future problem, but as long as % of hour run is under 100 your site is probably fine.

If rollup % of hour run is trending up (or is higher than your baseline), and you have not yet set the Management Repository buffer cache to its maximum, it may be advantageous to increase the buffer cache setting. Usually, if there is going to be a benefit from increasing buffer cache, you will see an overall improvement in resource utilization and throughput on the Management Repository host. The loader statistics will appear a little better. CPU utilization on the host will be reduced and I/O will decrease. The most telling improvement will be in the rollup statistics. There should be a noticeable improvement in both rollup rows/second and % of hour run. If you do not see any improvement in any of these vital signs, you can revert the buffer cache to its previous size. The old Buffer Cache Hit Ratio metric can be misleading. It has been observed in testing that Buffer Cache Hit Ratio will appear high when the buffer cache is significantly undersized and Enterprise Manager Cloud Control performance is struggling because of it. There will be times when increasing buffer cache will not help improve performance for Cloud Control. This is typically due to resource constraints or contention elsewhere in the application. Consider using the steps listed in the High CPU Utilization section to identify the point of contention. Cloud Control also provides advice on buffer cache sizing from the database itself. This is available on the database Memory Parameters page.

One important thing to note when considering increasing buffer cache is that there may be operating system mechanisms that can help improve Enterprise Manager Cloud Control performance. One example of this is the "large memory" option available on Red Hat Linux. The Linux OS Red Hat Advanced Server™ 2.1 (RHAS) has a feature called big pages. In RHAS 2.1, bigpages is a boot up parameter that can be used to pre-allocate large shared memory segments. Use of this feature, in conjunction with a large Management Repository SGA, can significantly improve overall Cloud Control application performance. Starting in Red Hat Enterprise Linux™ 3, big pages functionality is replaced with a new feature called huge pages, which no longer requires a boot-up parameter.

Rollup Process

The Rollup process introduces the concept of rollup participating instance; where rollup processing will be distributed among all participating instances. To add a candidate instance to the participating EMROLLUP group, the parameter instance_groups should be set on the instance level as follows:

- Add EMROLLUP_1 to the instance_group parameter for node 1
Add EMROLLUP_2 to the instance_group parameter for node 2

- Introduce the PQ and PW parallel processing modes where:

- PQ is the parallel query/parallel dml mode. In this mode, each participating instance will have one worker utilizing the parallel degree specified.

- PW is the parallel worker mode. In this mode, each participating instance will have a number of worker jobs equal to the parallel level specified

- Distribute the work load for all participating Oracle RAC instances as follows:

- Each participating instance will be allocated equal number of targets. So for (n) number of participating instances with total workload (tl), each instance will be allocated (tl/n).

- Each worker on any participating instance will be allocated equal number of targets of that instance workload. So for (il) number of targets per instance with (w) number of workers, each worker will be allocated (il/w).

- For each worker, the load is further divided into batches to control the number of times the rollup SQL is executed. The number of rows per batch will be the total number of rows allocated for the worker divided by the number of batches.

Use the following recommendations as guidelines during the Rollup process:

- Use the parallel worker (PW) mode, and utilize the participating EMROLLUP_xx instance group.

- The recommendation is to use the parallel worker mode.

- Splitting the work among more workers will improve the performance and scalability until a certain point where the diminishing returns rule will apply. This is dependent on the number of CPUs available on each Oracle RAC node. In this test case, running with 10 workers was the optimal configuration, balancing the response time, machine CPU and IO utilization.

- It is important to set a proper batch size (10 recommended). The optimal run was the one with 10 batches, attributed to balancing the number of executions of the main SQL (calling EMD_1HOUR_ROLLUP) and the sort space needed for each individual execution.

- Start by setting the number of batches to 10 bearing in mind the number of batches can be changed based on the data distribution.

The recommendations above will yield the following results. Using the multi-instance parallel worker (8 PW) mode (with the redesigned code described earlier) improves the performance by a factor of 9-13 when utilizing two participating Oracle RAC instances.

Rollup row count (in millions) in MGMT_METRICS_1HOUR

Time (min)

Workers

Batch Size

29.5

30

8

1

9.4

5

8

10

** For the entire test there were 15779 distinct TARGET_GUID
** The test produced “29.5 Million” new rollup rows in MGMT_METRICS_1HOUR

Run **

Rows/Workers

Batches/Workers

Rows/Batch

Time (min)

8 PW /1 instance

3945

3945

1

40

8 PW /2 instances

1973

1973

1

30

Job, Notification, and Alert Vital Signs

Jobs, notifications, and alerts are indicators of the processing efficiency of the Management Service(s) on your Enterprise Manager Cloud Control site. Any negative trends in these values are usually a symptom of contention elsewhere in the application. The best use of these values is to measure the benefit of running with more than one OMS. There is one job dispatcher in each OMS. Adding OMS instances will not always improve these values. In general, adding OMS instances will improve overall throughput for Cloud Control when the application is not otherwise experiencing resource contention issues. Job, Notification, and Alert vital signs can help measure that improvement.

I/O Vital Signs

Monitoring the I/O throughput of the different channels in your Enterprise Manager Cloud Control deployment is essential to ensuring good performance. At minimum, there are three different I/O channels on which you should have a baseline and alert thresholds defined:

- Disk I/O from the Management Repository instance to its data files

- Network I/O between the OMS and Management Repository

- Oracle RAC interconnect (network) I/O (on Oracle RAC systems only)

You should understand the potential peak and sustained throughput I/O capabilities for each of these channels. Based on these and the baseline values you establish, you can derive reasonable thresholds for warning and critical alerts on them in Cloud Control. You will then be notified automatically if you approach these thresholds on your site. Some Cloud Control site administrators can be unaware or mistaken about what these I/O channels can handle on their sites. This can lead to Enterprise Manager Cloud Control saturating these channels, which in turn cripples performance on the site. In such an unfortunate situation, you would see that many vital signs would be impacted negatively.

To discover whether the Management Repository is involved, you can use Cloud Control to check the Database Performance page. On the Performance page for the Management Repository, click the wait graph showing the largest amount of time spent. From this you can continue to drill down into the actual SQL code or sessions that are waiting. This should help you to understand where the bottleneck is originating.

Another area to check is unexpected I/O load from non-Enterprise Manager Cloud Control sources like backups, another application, or a possible data-mining co-worker who engages in complex SQL queries, multiple Cartesian products, and so on.

Total Repository I/O trouble can be caused by two factors. The first is a lack of regular housekeeping. Some of the Cloud Control segments can be very badly fragmented causing a severe I/O drain. Second, there can be some poorly tuned SQL statements consuming much of the site I/O bandwidth. These two main contributors can cause most of the Cloud Control vital signs to plummet. In addition, the lax housekeeping can cause the Management Repository's allocated size to increase dramatically.

One important feature of which to take advantage is asynchronous I/O. Enabling asynchronous I/O can dramatically improve overall performance of the Cloud Control application. The Sun Solaris™ and Linux operating systems have this capability, but may be disabled by default. The Microsoft Windows™ operating system uses asynchronous I/O by default. Oracle strongly recommends enabling of this operating system feature on the Management Repository hosts and on Management Service hosts as well.

Automatic Storage Management (ASM) is recommended for Enterprise Manager Cloud Control repository database storage.

About the Oracle Enterprise Manager Performance Page

There may be occasions when Enterprise Manager user interface pages are slow in the absence of any other performance degradation. The typical cause for these slow downs will be an area of Enterprise Manager housekeeping that has been overlooked. The first line of monitoring for Enterprise Manger page performance is the use of Enterprise Manager Beacons. These functionalities are also useful for web applications other than Enterprise Manager.

Beacons are designed to be lightweight page performance monitoring targets. After defining a Beacon target on an Management Agent, you can then define UI performance transactions using the Beacon. These transactions are a series of UI page hits that you will manually walk through once. Thereafter, the Beacon will automatically repeat your UI transaction on a specified interval. Each time the Beacon transaction is run, Enterprise Manager will calculate its performance and store it for historical purposes. In addition, alerts can be generated when page performance degrades below thresholds you specify.

When you configure the Enterprise Manager Beacon, you begin with a single predefined transaction that monitors the home page you specify during this process. You can then add as many transactions as are appropriate. You can also set up additional Beacons from different points on your network against the same web application to measure the impact of WAN latency on application performance. This same functionality is available for all Web applications monitored by Enterprise Manager Cloud Control.

After you are alerted to a UI page that is performing poorly, you can then use the second line of page performance monitoring in Enterprise Manager Cloud Control. This new end-to-end (or E2E) monitoring functionality in Cloud Control is designed to allow you to break down processing time of a page into its basic parts. This will allow you to pinpoint when maintenance may be required to enhance page performance. E2E monitoring in Cloud Control lets you break down both the client side processing and the server side processing of a single page hit.

The next page down in the Middle Tier Performance section will break out the processing time by tier for the page. By clicking the largest slice of the Processing Time Breakdown pie chart, which is JDBC time above, you can get the SQL details. By clicking the SQL statement, you break out the performance of its execution over time.

The JDBC page displays the SQL calls the system is spending most of its page time executing. This SQL call could be an individual DML statement or a PL/SQL procedure call. In the case of an individual SQL statement, you should examine the segments (tables and their indexes) accessed by the statement to determine their housekeeping (rebuild and reorg) needs. The PL/SQL procedure case is slightly more involved because you must look at the procedure's source code in the Management Repository to identify the tables and associated indexes accessed by the call.

Once you have identified the segments, you can then run the necessary rebuild and reorganization statements for them with the OMS down. This should dramatically improve page performance. There are cases where page performance will not be helped by rebuild and reorganization alone, such as when excessive numbers of open alerts, system errors, and metric errors exist. The only way to improve these calls is to address (for example, clean up or remove) the numbers of these issues. After these numbers are reduced, then the segment rebuild and reorganization should be completed to optimize performance. These scenarios are covered in Step 3: Using DBA and Enterprise Manager Tasks To Eliminate Bottlenecks. If you stay current, you should not need to analyze UI page performance as often, if at all.

Determining the Optimum Number of Middle Tier OMS Servers

Determining the optimum number of middle tier OMS servers is not a trivial task. A number of data points must be considered for an informed, justified and acceptable decision for introducing additional OMS instances. The number of monitored targets is one of the first considerations, but its weight in decision making is normally not substantial.

The following items should be considered and examined as part of this exercise:

- The volume of job automation and scheduling used

- The number of administrators working simultaneously in the console

- Network bandwidth and data channel robustness from agents to the OMS servers

- Number of triggered violations and notifications

- Speed and stability of the IO system the OMS servers use

Careful investigation of each category is essential to making an informed decision. In some cases, just adding an OMS server or providing more CPU or memory to the same host may not make any difference in performance enhancement. You can use the current running OMS instances to collect accurate statistics on current OMS performance to calculate the number of required OMS servers for current or future deployments. Enterprise Manager has "vital signs" that reflect its health. These vital signs should be monitored for trends over time as well as against established baseline thresholds.

Step 5: Extrapolating Linearly Into the Future for Sizing Requirements

Determining future storage requirements is an excellent example of effectively using vital sign trends. You can use two built-in Cloud Control charts to forecast this: the total number of targets over time and the Management Repository size over time.

Both of the graphs are available on the All Metrics page for the Management Service. It should be obvious that there is a correlation between the two graphs. A straight line applied to both curves would reveal a fairly similar growth rate. After a target is added to Enterprise Manager Cloud Control for monitoring, there is a 31-day period where Management Repository growth will be seen because most of the data that will consume Management Repository space for a target requires approximately 31 days to be fully represented in the Management Repository. A small amount of growth will continue for that target for the next year because that is the longest default data retention time at the highest level of data aggregation. This should be negligible compared with the growth over the first 31 days.

When you stop adding targets, the graphs will level off in about 31 days. When the graphs level off, you should see a correlation between the number of targets added and the amount of additional space used in the Management Repository. Tracking these values from early on in your Enterprise Manager Cloud Control deployment process helps you to manage your site's storage capacity proactively. This history is an invaluable tool.

The same type of correlation can be made between CPU utilization and total targets to determine those requirements. There is a more immediate leveling off of CPU utilization as targets are added. There should be no significant increase in CPU cost over time after adding the targets beyond the relatively immediate increase. Introducing new monitoring to existing targets, whether new metrics or increased collections, would most likely lead to increased CPU utilization.

Using Returning Query Safeguards to Improve Performance

On the All Targets page, Enterprise Manager uses a safeguard that prevents a flood of data from slowing performance and consuming excessive resources within the OMS by limiting the number of rows that can be returned from a query. By default, the limit is set to 2000, but an Enterprise Manager administrator can modify the limit with the following command:

emctl set property -name oracle.sysman.emSDK.eml.maxRows -value 2000

Providing a value equal to 0 will turn off the safeguard and fetch all rows. The new value takes immediate effect; no OMS restart is required. If the value is less than 0, the default value (2000) will be used instead. The only way to indicate that no limiting should be performed is to set the value to exactly 0.

When there are too many results returned from a query and this limit comes into effect, the following message appears under the results table:

"This table of search results is limited to 2000 targets. Narrow the results by using Refine Search or Search Target Name. See the tuning guide for how to modify this limit."

Similar behaviors (and messages) are applied to other large tables throughout Enterprise Manager. The same OMS property (oracle.sysman.emSDK.eml.maxRows) controls the maximum limit for all of them together. This matches the behavior (and reuses the existing property) from previous Enterprise Manager releases.

Overview of Repository and Sizing Requirements for Fusion Middleware Monitoring

A Fusion Middleware target is like any other Enterprise Manager target. Therefore any repository or sizing guideline that is applicable for an Enterprise Manager target would be applicable on a Fusion Middleware target.

One major concern in the case of Fusion Middleware discovery is that too many targets may be discovered, created and monitored. This adds additional load on the OMS instance, repository and agent. In the case of very large number of targets, after target discovery Oracle recommends that users should review all the targets and their respective metrics.

Based on requirements, users should finalize which targets and metrics should be monitored and the required frequency those targets should be monitored.

After discovery, Oracle recommends you allow Fusion Middleware/ADP/JVMD monitoring to run for some duration (a few days to possibly a few weeks) and continuously monitor the database size and Operating System file system growth (in the case of ADP; ADP Manager requires a minimum of 10GB of disk space) until it becomes constant. You can then fine tune various parameters associated with these different features.

In version 12c of Enterprise Manager, both ADP and JVMD use Enterprise Manager repository as their repository. Their data are stored in the MGMT_AD4J_TS tablespace.

ADP Monitoring

Use the following information when utilizing ADP Monitoring.

- ADP Manager Resources Requirement
While managing 70K managed entities, if the number of managed entities is high you must allocate resources accordingly.

Resource

Amount

Physical Memory

2 GB

Minimum Disk Space

10 GB

- ADP Data requirement
To monitor each entity per JVM, the MGMT_AD4J_TS tablespace must have 8 MB available.

- ADP Data Retention Policy
ADP maintains sophisticated multi-tiered logic for aggregation (or compression) of performance data. This helps to optimize performance of interaction with the internal data repository both when querying data for presentation or inserting new performance metrics.

Users who want to store longer term data should look for this section in Acsera.properties:

Example 11-1

#########################
# Production setting
# NOTE: use Model.GlobalSamplingRateSecs to configure Metric.Grain.0
#########################
Metric.Grain.0 0s
Metric.TableInterval.0 = 4h
Metric.DataLife.0 = 2d

Metric.Grain.1 = 3m
Metric.TableInterval.1 =1d
Metric.DataLife.1 = 8d

#Metric.Grain.2 = 30m
#Metric.TableInterval.2 = 7d
#Metric.DataLife.2 = 420d

Uncomment the last 3 lines for the Metric.*.2 properties.

JVMD Monitoring

Use the following information when employing JVMD Monitoring.

- JVMD Manager Resources Requirement
To manage 200-300 jvms, JVMD manager requires physical memory of 1 GB. JVMD manager caches monitoring data in the TEMP space for each pool and flushes to the database frequently. Usually, depending on the number of pools the manager is monitoring and the amount of data being gathered from each pool, the size requirement of these temporary cache files varies, but it is rare to see more than a few MBs for each pool. If this is a concern, the TEMP space should be allocated accordingly.

- JVMD Data requirement
To monitor every JVM with OOB settings, the MGMT_AD4J_TS tablespace must have 50-100MB available.

- JVM Diagnostics Historical Data and its Retention policy
Historical data is available at three summary levels 0, 1 and 2.

- Summary level 0 - is raw sample data taken at the specified pool polling interval (default 2 seconds). If you look at data within one hour on the Performance Diagnostics page, it shows summary level 0 data. Level 0 data is retained for 24 hours and subsequently purged. It can be changed via the Console Setup page, but before increasing the value, you should ensure that the repository is tuned properly to handle such large amounts of data.

- Summary level 1 - is aggregated data. If you view data after more than one hour but less than 5 hours, it is summary level 1 data. The default aggregation interval is 90 seconds. This value can be changed via the Console Setup page. Level 1 data is retained for 20 days and subsequently purged.

- Summary level 2 - is further aggregated data. If you view data more than five hours old, it is summary level 2 data. This data is aggregated every 60 minutes. Level 2 data is retained for 400 days and subsequently purged.

There are two JVMD features that can drastically affect MGMT_AD4J_TS tablespace usage:

- JVMD Heap Dumps
Analyzing heap requires massive tablespace resources. Oracle recommends having 5 times the size of the heap dump file you are loading free in your tablespace. Since you will have the heap dump file and know its size before you run the load script, you should ensure that you have adequate space to accommodate the dump before you load it into your database.

- Thread Traces
While these are smaller than heaps by an order of magnitude, these are loaded into the database automatically by default when you initiate a trace at the console. The size of these traces can vary dramatically depending on the number of active threads during the trace, the duration of the trace, and the sample interval of the trace. They should generally be under 100MB each, but a user utilizing a large number of these could manually fill up the database quickly. Again, since these are created only by manual intervention, you should ensure that there is adequate space to accommodate traces before initiating them.

12 Installing ADP with Advanced Installation Options

This chapter describes how you can install Application Dependency and Performance (ADP) in the Enterprise Manager Cloud Control environment.

In particular, this chapter covers the following:

- Application Dependency and Performance Architecture

- Before you Begin

- Prerequisites

- Installation Procedure

- After You Install

Application Dependency and Performance Architecture

Application Dependency and Performance (ADP) is one of the critical functionalities in Enterprise Manager Cloud Control that allows you to analyze Java EE, SOA, and Portal applications. It captures the complex relationships among various application building blocks in its application schema model - the core of the Oracle intelligent platform. To manage these applications effectively, enterprises must first gain an understanding of the complex relationships among the business functions, associated interconnected components, and the underlying runtime environments. To enable clear and accurate understanding, IT organizations need holistic, service-oriented views that span across heterogeneous environments.

Using the insights stored in Application Schema, ADP is able to deliver an Application Service Management (ASM) environment that self-customizes out-of-the-box, evolves with change, minimizes expert involvement, and delivers a holistic, service-oriented view across heterogeneous environments.

ADP employs a multi-tier, fully distributed, configurable architecture to provide the scalability and flexibility to meet the changing needs of enterprise deployments.

Figure 12-1 ADP Architecture

ADP Manager is the core analytical engine of the ADP ASM system. In real-time, ADP Manager performs complex mathematical modeling and statistical calculations with summarized data from all ADP Java Agents. ADP Manager can be configured with a backup to provide higher level of availability.

ADP Java Agents are the data collectors of the ADP ASM system. ADP Java Agents are deployed to all managed application servers to perform a series of tasks including collecting performance managements, tracking contextual relationships, and summarizing data in real-time while introducing as little overhead as possible.

Before you Begin

Before installing an ADP Manager, or an ADP Agent, review the points outlined in the Basic Install Guide.

Prerequisites

Before installing an ADP Manager, or an ADP agent, ensure that you meet the prerequisites described in the Basic Install Guide.

Installation Procedure

This section describes the following:

- Deploying ADP Manager on a Previously Created Managed Server

- Deploying ADP Agents (Remote Deployment)

- Performing Postinstallation Tasks

Deploying ADP Manager on a Previously Created Managed Server

To deploy ADP Manager on a previously created managed server, you must log in with SYSMAN account (a default Super Administrators account that is installed with Enterprise Manager).

This section contains the following topics:

- Deploying ADP Manager on an OMS Host

- Deploying ADP Manager on a Separate Host from OMS (Remote Deployment)

Deploying ADP Manager on an OMS Host

To deploy ADP Manager on a previously created managed server running on an OMS host, perform the following steps:

1. In Cloud Control, from the Setup menu, select Application Performance Management.

2. On the Application Performance Management page, from the Add menu, select Application Dependency and Performance Engine.
The Deploy ADP Engine page appears.

3. To deploy ADP Engine on an existing managed server, select Deploy on an existing managed server.

Perform the following steps

1. From the Managed Server menu, select the WebLogic Managed Server on which you want to deploy the ADP Manager application. Ensure that you select managed server with the name EMGC_ADPMANAGER* to deploy the ADP manager application.
For example, EMGC_ADPMANAGER1, EMGC_ADPMANAGER2, and so on.

2. The Port numbers for ADP Manager Registry Port, ADP Manager Java Provider Port, and ADP Manager Controller Port are populated with the default values 51099, 55003, and 55000 respectively. You can change these values by entering custom value if required.

Note:
An ADP Manager can only be deployed on a managed server that is part of the EMGC domain.

4. Depending on the host selected in the previous step, you are prompted for the credentials. The following cases are possible:

- If you select the same host (EMGC_OMS1) where the Administration Server is running, then you must enter the Oracle WebLogic Administration Server Host Credentials and Oracle WebLogic Domain Credentials.

- If you select a host (EMGC_OMS2) different from the Administration Server to deploy ADP Manager, then in addition to Oracle WebLogic Administration Server Host Credentials and Oracle WebLogic Server Domain Credentials, you must provide Oracle WebLogic Managed Server Host Credentials.

Where,

Oracle WebLogic Administration Server Host Credentials are credentials for the host where the WebLogic Administration Server is running.

Oracle WebLogic Server Domain Credentials are credentials of the WebLogic domain for Enterprise Manager Cloud Control.

Oracle WebLogic Managed Server Host Credentials are the credentials of the host machine where the managed server is running.

5. Click Deploy to submit the job.
The ADP Deployment Status Page appears with a link to the job status page, click the link to see the status of the job that you submitted.

Deploying ADP Manager on a Separate Host from OMS (Remote Deployment)

To deploy ADP Manager on a separate host from OMS (remote deployment), you must perform the following tasks:

- Prerequisites

- Installation Procedure

Prerequisites

Before deploying ADP Manager on a separate host from OMS (remote deployment), perform the following steps:

Note:
This section will use the following convention:

- host-a is the host where the OMS server is running

- host-b is the remote host which means that there is no OMS running on the host machine.

1. Install a Management Agent on host-b (remote host)
For information about installing a Management Agent, see Basic Install Guide.

2. Install WebLogic Server on host-b using Enterprise Manager Software Only installation option.
For information about performing a software only install, see Basic Install Guide.

These WebLogic Server bits must be registered with the Enterprise Manager Domain running on host-a, so that all the managed servers appear under the same WebLogic Domain.

Note:
For a successful installation, all managed servers running on different hosts in a WebLogic Domain must have the same version and patch level.

3. Configure a new managed server (ADPRemoteServer) using the WebLogic Server Administration Console as follows:

1. Log into the Enterprise Manager WebLogic Domain console (EMGC_DOMAIN) of host-a.
The WebLogic Server Administration Console home page appears.

2. In Weblogic Server Administration Console, from the Domain Structure section, select Environment and then click Servers.

3. On the Create a New Server page, enter the Server Name, Server Listen Address, and Server Listen port.

Note:
Ensure that the Server Listen Address corresponds to the listen address of the remote host, and the Server Listen port is free on the remote host.

4. Configure a new machine using the WebLogic Server Administration Console as follows:

1. Log into the Enterprise Manager WebLogic Domain console (EMGC_DOMAIN) of host-a.
The WebLogic Server Administration Console home page appears.

2. In WebLogic Server Administration Console, from the Domain Structure section, select Environment and click Machines.

3. To associate this machine with the nodemanager running on host-b, associate this machine with the nodemanager running on host-b, enter the Listen Address of the remote host, and the node manager port number which is 5556 by default.
This node manager primarily controls the start and stop of a remote host.

4. Click Finish to create the machine.

5. Select the new created machine, and click on Servers to add the managed server (ADPRemoteServer) to this machine. This step associates the machine with the nodemanager running on host-b.

6. To extend the WebLogic Domain, a template of the Enterprise Manager Cloud Control domain running on host-a is created using the following command:

./pack.sh - domain = $DOMAIN_HOME -template = <absolute_path_to_the_new_weblogic_template> - template_name="My WebLogic Domain" -managed={true}

Where:

$DOMAIN_HOME is the location of EMGC domain on host-a.

<absolute_path_to_the_new_weblogic_template> is the location where you want to create the template.

7. Copy emgcdomain.jar from host-a (where the OMS is running) to host-b (remote host).

8. Run the following command to unpack emgcdomain.jar template on host-b:

./unpack.sh -domain = $DOMAIN_HOME -template= <absolute_path_to_domain_template_created>

Where:

$DOMAIN_HOME is the domain location of EMGC on host-b (remote host)

<absolute_path_to_domain_template_created> is the location of the template on host-b where emgcdomain.jar template is present.

9. To enroll the WebLogic Domain with node manager, perform the following steps on host-b:

1. Run the following command to update the node manager properties file so that it can start monitoring the remote host:
$WEBLOGIC_HOME/common/bin/wlst.sh

nmEnroll($DOMAIN_HOME)

2. Start the Node Manager as follows:
$WEBLOGIC_HOME/bin/startNodeManager.sh

Note:
Ensure that you set the property in the nodemanager property file before starting the Node Manager. You can set the property in one of the following methods:

- Manually edit the nodemanager.properties file to set the property startScriptEnabled=true.

- Run the script setNMProps.sh as follows: $MIDDLWARE_HOME/oracle_common/common/bin/setNMProps.sh

3. Perform the following steps to modify startWebLogic.sh:

1. Navigate to the following location:
- On Unix : $DOMAN_HOME/bin/startWebLogic.sh

- On Windows : $DOMAN_HOME/bin/startWebLogic.cmd

2. Set maximum heap size (-Xmx) to 1.7GB for 64 bit systems and set maximum permanent generation (-XX:MaxPermSize) to 768M for 64 bit systems as follows:
USER_MEM_ARGS="-Xms256m -Xmx1740m -XX:MaxPermSize=768m"

3. Set max heap size to 1.4GB for 32 bit systems and set maximum permanent generation to 512M for 32 bit system as follows:
USER_MEM_ARGS="-Xms256m -Xmx1434m -XX:MaxPermSize=512m"

10. Perform the following steps on host-a, and then start the ADPRemoteServer as follows:

1. Copy the emreposauthbean.jar located in $OMS_HOME/sysman/jlib, to <middleware_home>/wlserver_10.3/server/lib/mbeantypes. Where, $OMS_HOME is the location of the OMS server on host-a, and <middleware_home> is on host-b.

2. Copy the emCoreCommon.jar from $WEBLOGIC_HOME/sysman/jlib on host-a to $WEBLOGIC_HOME/server/lib on host-b

3. Import SSL Certificate to Enterprise Manager Agent Trust store present on the host where managed server (ADPRemoteServer) is running.

4. Start the managed server (ADPRemoteServer) from the WebLogic Server Administration Console to complete the WebLogic Server setup.

11. Perform the following steps to discover the new managed server running on host-b:

1. In cloud Control, from Targets menu, select Middleware.
On the Middleware page, from the list of WebLogic Servers running, select the WebLogic Domain (EMGC_DOMAIN) where the managed server is deployed.

2. On The Cloud Control Domain page, from the WebLogic Domain menu, select Refresh WebLogic Domain.
The new server now gets registered in the Enterprise Manager Cloud Control Domain.

12. Restart the server for all the changes to take effect.

Installation Procedure

To deploy ADP Manager on a separate host from OMS (remote deployment), perform the following steps:

Note:
For a successful remote deployment, ensure that:

- You install Enterprise Manager agent on the remote machine, and point it to the OMS running on a different managed server present in the same Enterprise Manager Cloud Control domain (EMGC_DOMAIN)

- The remote WebLogic Server version and patch level should match with servers in Enterprise Manager Domain (EMGC_DOMAIN). To ensure that the versions and patch levels match, Oracle recommends that you install WebLogic by selecting the Software Only install option in the Enterprise Manager OUI install.

1. In Cloud Control, from Setup menu, select Application Performance Management.

2. On the Application Performance Management page, from the Add menu select Application Dependency and Performance Engine.
The Deploy ADP Engine page appears.

3. To deploy ADP Manager on the managed server running on a separate host from OMS, perform the following steps:

1. Select Deploy on an existing Managed Server. For example, EMGC_ADPMANAGER2, EMGC_ADPMANAGER3, and so on.

2. The Port numbers for ADP Manager Registry Port, ADP Manager Java Provider Port, and ADP Manager Controller Port are populated with the default values 51099, 55003, and 55000 respectively. You can change these values by entering custom value if required

4. In the Credentials section, provide Oracle WebLogic Administration Server Host Credentials, Oracle WebLogic Domain Credentials, and Oracle WebLogic Managed Server Host Credentials.
Where,

Oracle WebLogic Administration Server Host Credentials are credentials for the host where the WebLogic Administration Server is running.

Oracle WebLogic Domain Credentials are credentials of the WebLogic domain in the Enterprise Manager Cloud Control.

Oracle WebLogic Managed Server Host Credentials are the credentials of the host machine where the Managed Server is running.

5. Click Deploy to submit the job.
The progress page appears with a link to the job processing page. Click the link to see the status of the job that you submitted.

Deploying ADP Agents (Remote Deployment)

To deploy ADP Agents on a Weblogic Domain which is monitored by the Management Agent present in the Enterprise Manager WebLogic Domain, perform the following steps:

Note:
This section will use the following convention:

- host-a corresponds to the WebLogic Domain where the ADP Agent will be deployed.

- host-b corresponds to the Enterprise Manager Domain (EMGC_DOMAIN) where the Management Agent is deployed to monitor the WebLogic Domain on host-a.

1. In Cloud Control, from Targets menu, select Middleware.
The Middleware page displays a list of all the Middleware targets discovered and managed in Cloud Control. Click target name to select the desired target.

2. On the Middleware page, click Oracle WebLogic Domain. Ensure that the selected domain is not an Enterprise Manager Cloud Control domain (EMGC_DOMAIN).

Note:
ADP Agent cannot be deployed on a managed server (WebLogic Server) present in the Enterprise Manager domain.

All the managed servers present in the selected domain appear on the domain home page.

3. From the WebLogic Domain menu, select Diagnostics, and then click Setup Diagnostics Agents to deploy ADP agents to the selected managed servers.

4. On the Deploy Diagnostics Agents page, choose the Oracle WebLogic Server (managed server) to which you want to deploy the ADP agents.

Note:

Ensure that you retain the selection of only those Diagnostic Agent(s) that you want to deploy to each of the managed server, deselect the others.

In Addition to the managed server selected, the ADP Agent is deployed to the Administration Server of the selected domain.

By default, the following servers appear deselected:

- The Administration server.

- All the managed servers that are not up and running.

- If the Deployed Version and the Version to Deploy are the same, and the status of the already deployed ADP agent is up and running.

5. In the Diagnostics Agent Configuration section, enter the ADP Configuration Properties for the selected agents:

- Select the desired ADP Manager from the ADP Manager list.
The ADP agents after deployment will report to the selected ADP Manager.

- If you select the Update Remote Start configuration option, then some configuration scripts run in the background to facilitate the monitoring process. Select this option if you use node manager to stop or start the WebLogic Servers to which ADP agent is being deployed.

Important:
If WebLogic domain on host-a is discovered using Management Agent on host-b, then you must do the following:

1. Navigate to the following location:

<WEBLOGIC_HOME>/server/lib

Where,
<WEBLOGIC_HOME> is the full abstract path to the Weblogic home for the monitored WebLogic domain on host-a.

2. Do the following to generate wlfullclient.jar:
If the WebLogic Server version is 10.3.x or higher, then run the following command:

java -jar wljarbuilder.jar

If the WebLogic Server version is less than 10.3.x or equal to 10.3.0, then use other WebLogic installations (10.3.x or higher) to create the wlfullclient.jar.

For example, you can use the <WEBLOGIC_DOMAIN> corresponding to the EMGC domain for generating the wlfullclient.jar, since Enterprise Manager setup uses JDK6.

3. Copy the following files from <WEBLOGIC_HOME>/server/lib/ to <AGENT_HOME>/sysman/jlib directory:
- wlfullclient.jar

- wljmxclient.jar

- webserviceclient+ssl.jar

- wlcipher.jar

Where <AGENT_HOME> is the Oracle home for the Management agent on host-b.

6. If Management Agent present on host-b is used to monitor the WebLogic Domain on host-a (remote Agent) where the ADP Agent will be deployed, then you must provide credentials for Oracle WebLogic Administration Server Host Credentials, Oracle WebLogic Domain Credentials, Oracle Enterprise Manager WebLogic Administration Server Host Credentials, and Oracle Enterprise Manager WebLogic Domain Credentials.
Where,

Oracle WebLogic Administration Server Host Credentials are the credentials for the host-b, where the Management Agent used to discover the monitored domain is present.

Oracle WebLogic Domain Credentials are credentials of the WebLogic domain of host-a, where the ADP Agent will be deployed.

Oracle Enterprise Manager WebLogic Administration Server Host Credentials are credentials of host-b where the Administrator Server of EMGC_DOMAIN exists.

Oracle Enterprise Manager WebLogic Domain Credentials are credentials of the WebLogic Domain of host-b (EMGC_DOMAIN).

7. Click Deploy to submit the job.
The status page appears with a link to the job status. Click the link to see the status of the job that you submitted.

Note:

- Restart the administration server, and the managed servers to which the ADP Agents have been deployed. These servers should be restarted only after the deployment has completed successfully.

- If the ADP Agent deployment fails with an SSL handshake error, see "SSL Handshake Failure Agent Deployment Errors" to fix the problem.

Performing Postinstallation Tasks

This section contains the following topics:

- Configuring Oracle SOA Suite for Secure Connectivity

- Configuring Oracle WebLogic Server or Oracle WebLogic Portal (WLP) for Secure Connectivity

- Importing a Certificate into the Manager's Keystore

- Configuring the ADP Agent When WebLogic Is Installed As a Windows Service

Configuring Oracle SOA Suite for Secure Connectivity

The Oracle SOA Suite may be configured to support RMIS (RMI over SSL) connectivity. In this case, ADP can be configured to use this secure connection. To configure ADP to do this, perform the following steps:

1. On the Oracle SOA Suite install, look at ORACLE_HOME/j2ee/<instance>/config/rmi.xml, locate the <ssl-config> element, and identify the path in the keystore attribute.

2. Copy the keystore file indicated to ADP manager's config directory (for example, em10/config)

3. Import this keystore file following the instructions in Importing a Certificate into the Manager's Keystore.

Configuring Oracle WebLogic Server or Oracle WebLogic Portal (WLP) for Secure Connectivity

To configure Oracle WebLogic Server 10.0 to handle connectivity using t3s, the location of the keystore files needs to be updated through the console.

1. Log in to the WebLogic Server console and select the servers under the Environment Servers list that is displayed which you plan to manage with ADP.

2. Select a server from the server list.

3. Select the keystores tab, click Load & Edit to update the Keystore.

4. Make the following changes. Identify the keystore, and truststore file paths from the following properties:

Identity

Custom Identity Keystore

Trust

Custom Trust Keystore: location of the trust file

5. Repeat steps 2 through 4 for additional server instances that will be managed.

6. Copy the identified keystore and truststore files to the ADP manager.

7. Copy the BEA_HOME/license.bea to the ADP manager's config directory (for example, em11g/config)

8. Import the keystore and truststore files following the instructions in Importing a Certificate into the Manager's Keystore.

9. Locate the following properties in the Acsera.properties file, and set them as follows:

weblogic.security.TrustKeyStore=CustomTrust
weblogic.security.CustomTrustKeyStoreFileName=AcseraManagerTrust.jks
weblogic.security.CustomTrustKeyStorePassPhrase=acseramanager

Importing a Certificate into the Manager's Keystore

To import entries from a keystore or truststore, perform the following steps, replacing ServerStoreFile.jks with the keystore or truststore from your application server. You will generally need to complete these steps twice, once for the keystore and once for the truststore.

1. List the key aliases in the keystore/trustfile file from the server

keytool -list -keystore ServerStoreFile.jks –storepass DemoIdentityKeyStorePassPhrase

Output:

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry:

demoidentity, Wed Nov 19 13:34:56 PST 2008, keyEntry, Certificate fingerprint
(MD5): 36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A

2. Export a key entry to an intermediate file

keytool -export -alias demoidentity -keystore ServerStoreFile.jks -storepass
DemoIdentityKeyStorePassPhrase -file demo103

Output:

Certificate stored in file <demo103>

3. Import the key into the ADP store file (either AcseraManagerKey.jks or AcseraManagerTrust.jks in the ADP manager's config directory)

keytool -import -alias demoidentity1 -keystore AcseraManagerKey.jks
-storepass acseramanager -file demo103

Output:

Owner: CN=b91, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
Issuer: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
Serial number: 510fb3d4b2872e3a093d436fcbe9b24b
Valid from: Tue Nov 18 13:34:47 PST 2008 until: Sun Nov 19 13:34:47 PST 2023
Certificate fingerprints:
MD5:  36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A
SHA1: BB:85:6D:4C:0B:4A:92:63:CA:5E:E9:A8:54:42:80:2D:0D:BE:7C:91
Trust this certificate? [no]:  yes
Certificate was added to keystore

4. Verify that the key was imported successfully

keytool -list -keystore AcseraManagerKey.jks -storepass acseramanager

Output:

Keystore type: jks
Keystore provider: SUN

Your keystore contains 3 entries:

demoidentity1, Wed Apr 01 13:03:21 PST 2009, trustedCertEntry,Certificate fingerprint (MD5): 36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A
demoidentity, Fri Mar 13 15:15:06 PST 2009, trustedCertEntry,Certificate fingerprint (MD5): 0B:11:02:B5:44:0D:2A:CC:7F:C5:30:5C:1A:C9:A1:6C
mykey, Thu May 19 16:57:36 PDT 2005, keyEntry,Certificate fingerprint (MD5): 5D:B0:EC:28:14:33:26:1F:44:F5:BE:DD:A8:50:15:9D

5. Repeat steps 2 through 4 for each key entry listed in step 1.

6. Locate the following properties in the Acsera.properties file, and set them as follows:

weblogic.security.TrustKeyStore=CustomTrust
weblogic.security.CustomTrustKeyStoreFileName=AcseraManagerTrust.jks
weblogic.security.CustomTrustKeyStorePassPhrase=acseramanager

At present with ADP running with a bundled Sun HotSpot JDK, it is not possible for ADP to configure with PKCS12 type key/trust stores for secured connections. IBM JDK has built-in enhancements that allow it to work with PKCS12 key/trust stores, such as WebSphere 6.1's default key.p12 and trust.p12 stores. Also, there is a WebSphere 6.1 automatic function that is enabled with the property com.ibm.ssl.enableSignerExchangePrompt=true that allows a client connecting to a secure WebSphere port that allows automatic download of server's signer certificate and update of client's truststore. However, this automatic function is only available when ADP is running with an IBM JDK which is not the case at present. This is the reason why we need to follow the above procedure to connect with a secured WebSphere 6.1.

Configuring the ADP Agent When WebLogic Is Installed As a Windows Service

When the monitored WebLogic server is installed as a Windows Service, the automatic startup changes to deploy the ADP Agent need to be manually applied to the registry entries that control WebLogic startup.

The parameters which need to be changed are in the Windows registry key:

HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\$ServiceName\Parameters

Users should then consult the file on the ADP Manager:

deploy/agent/bea9/bin/agentoptions.bat (for WebLogic 9.x and higher)

Inspect this file and resolve the net results of its execution as Parameters in the registry.

After You Install

After installing the ADP Managed Server, or the ADP Agent, follow the steps outlined in the Basic Installation Guide

13 Installing JVMD with Advanced Install Options

This chapter describes how you can install JVM Diagnostics (JVMD) in the Enterprise Manager Cloud Control environment.

In particular, this chapter covers the following:

- JVMD Architecture

- Before you Begin

- Prerequisites

- Installation Procedure

- After You Install

JVMD Architecture

JVM Diagnostics is integrated with Oracle Enterprise Manager Cloud Control. It primarily enables administrators to diagnose performance problems in Java applications in the production environment. By eliminating the need to reproduce problems, it reduces the time required to resolve these problems thus improving application availability and performance. Using JVMD, administrators will be able to identify the root cause of performance problems in the production environment without having to reproduce them in the test or development environment.

The following diagram shows the JVMD Architecture:

Figure 13-1 JVMD Architecture

JVMD Manager is the core analytical engine of the JVMD monitoring system. JVMD Manager collects runtime data from JVMD Agents on request from OMS or while monitoring during which it sends periodic requests to the JVMD agents and collects runtime JVM data and stores it into repository. Multiple JVMD Managers can be configured.

JVMD Agents are the data collectors of the target JVM. JVMD Agents are deployed to managed application servers to collect JVM monitoring data related to JVM threads, stacks, heap and CPU usage in real-time while introducing minimal overhead.

The JVMD Manager runs as an Enterprise JavaBeans (EJB) Technology on a WebLogic Server. The JVMD Agent is deployed on the targeted JVM (the one running a production WebLogic Server). It collects real-time data and transmits it to the JVM Diagnostics Manager. This data is stored in the Management Repository, and the collected information is displayed on Enterprise Manager Cloud Control console for monitoring purposes. The communication between the JVMD Manager and the JVMD Agent can be a secure (SSL) or non-secure connection.

Before you Begin

Before installing an JVMD Manager, or an JVMD Agent, review the points outlined in the Basic Install Guide.

Prerequisites

Before installing the JVMD Manager, or the JVMD agent, ensure that you meet the prerequisites described in the Basic Install Guide.

Installation Procedure

This section contains the following topics:

- Deploying JVMD Manager

- Deploying JVMD Agents

Deploying JVMD Manager

To deploy JVMD Manager on a previously created managed server, you must log in with SYSMAN account (a default Super Administrators account that is installed with Enterprise Manager).

The following deployment options are possible:

- Deploying JVMD Manager on an OMS Host

- Deploying JVMD Manager on a Separate Host from OMS (Remote Deployment)

- Deploying JVMD Manager Manually

- Redeploying JVMD Manager

Deploying JVMD Manager on an OMS Host

To deploy JVMD Manager on a previously created managed server which is running on an OMS host, perform the following steps:

1. In Cloud Control, from Setup menu, select Application Performance Management.

2. On the Application Performance Management page, from the Add menu, select JVM Diagnostics Engine.
The Deploy JVM Diagnostics Engine page appears.

3. To deploy JVMD Manager on the managed server running on an OMS host, perform the following steps:

1. Select Deploy on an existing Managed Server.

2. From the Managed Server menu, select the managed server on which you want to deploy the JVMD Manager. For example, EMGC_JVMDMANAGER1, EMGC_JVMDMANAGER2, and so on.

The managed server selected for deploying JVMD Manager should be part of the Enterprise Manager Cloud Control domain.

4. Specify the Oracle Management Server Host Credentials and Oracle WebLogic Server Domain Credentials:
Where,

Oracle Management Server Host Credentials are the credentials for the host machine where the Managed Server is created.

Oracle WebLogic Server Domain Credentials are credentials of the Weblogic domain in the Enterprise Manager Cloud Control.

5. Click Deploy to submit the job.
The progress page appears with a link to the job processing page. Click the link to see the status of the job that you submitted.

Deploying JVMD Manager on a Separate Host from OMS (Remote Deployment)

To deploy JVMD Manager on a separate host from OMS (remote deployment), you must perform the following tasks:

- Prerequisites

- Installation Procedure

Prerequisites

Before deploying JVMD Manager on a separate host from OMS (remote deployment), perform the following steps:

Note:
This section will use the following convention:

- host-a is the host where the OMS is running

- host-b is the remote host which does not have an OMS on the machine.

1. Install a Management Agent on host-b (remote host)
For information about installing a Management Agent, see Basic Install Guide.

2. Install WebLogic Server on host-b using Enterprise Manager Software Only installation option.
For information about performing a software only install, see Basic Install Guide

These WebLogic Server bits must be registered with the Enterprise Manager Domain running on host-a, so that all the managed servers appear under the same WebLogic Domain.

Note:
For a successful installation, all managed servers running on different hosts in a WebLogic Domain must have the same version and patch level.

3. Configure a new managed server (JVMDRemoteServer) using the WebLogic Server Administration Console as follows:

1. Log into the Enterprise Manager WebLogic Domain console (EMGC_DOMAIN) of host-a.
The WebLogic Server Administration Console home page appears.

2. In Weblogic Server Administration Console, from the Domain Structure section, select Environment and then click Servers.

3. On the Create a New Server page, enter the Server Name, Server Listen Address, and Server Listen port.

Note:
Ensure that the Server Listen Address corresponds to the listen address of the remote host, and the Server Listen port is free on the remote host.

4. Configure a new machine using the WebLogic Server Administration Console as follows:

1. Log into the Enterprise Manager WebLogic Domain console (EMGC_DOMAIN) of host-a.
The WebLogic Server Administration Console home page appears.

2. In Weblogic Server Administration Console, from the Domain Structure section, select Environment and click Machines.

3. On the Create a New Machine page, to associate this machine with the nodemanager running on host-b, enter the Listen Address of the remote host, and the node manager port number which is 5556 by default.
This node manager primarily controls the start and stop of a remote host.

4. Click Finish to create the machine.

5. Select the new created machine, and click on Servers to add the managed server (JVMDRemoteServer) to this machine. This step associates the machine with the nodemanager running on host-b.

Note:
After the JVMD Application is successfully deployed on the targeted managed server, to view the managed server in the WebLogic Domain, or to add a JVMD agents, ensure that you refresh the WebLogic Domain as follows:

1. In Cloud Control, from Targets menu, select Middleware. On the Middleware home page, select the WebLogic Domain on which the JVMD Manager application is deployed.

2. From the WebLogic Domain menu, select Refresh Weblogic Domain, and click Continue.

3. All the newly added targets are discovered in the WebLogic Domain, and then click Add Targets.

4. After adding the targets successfully, close the dialog box, and then click OK.

6. To extend the WebLogic Domain, a template of the Enterprise Manager Cloud Control domain running on host-a is created using the following command:

./pack.sh -domain = $DOMAIN_HOME -template = <absolute_path_to_the_new_weblogic_template> - template_name="My WebLogic Domain" -managed={true}

Where:

$DOMAIN_HOME is the location of EMGC domain on host-a.

<absolute_path_to_the_new_weblogic_template> is the location where you want to create the template.

7. Copy emgcdomain.jar from host-a (where the OMS is running) to host-b (remote host).

8. Run the following command to unpack emgcdomain.jar template on host-b:

./unpack.sh -domain = $DOMAIN_HOME -template= <absolute_path_to_domain_template_created>

Where:

$DOMAIN_HOME is the domain location of EMGC on host-b (remote host)

<absolute_path_to_domain_template_created> is the location of the template on host-b where emgcdomain.jar template is present.

9. To enroll the WebLogic Domain with node manager, perform the following steps on host-b:

1. Run the following command to update the node manager properties file so that it can start monitoring the remote host:
$WEBLOGIC_HOME/common/bin/wlst.sh

nmEnroll($DOMAIN_HOME)

2. Start the Node Manager as follows:
<Weblogic Home>server/bin/startNodeManager.sh

Note:
Ensure that you set the property in the nodemanager property file before starting the Node Manager. You can set the property in one of the following methods:

- Manually edit the nodemanager.properties file to set the property startScriptEnabled=true.

- Run the script setNMProps.sh as follows: $MIDLLEWARE_HOME/oracle_common/common/bin/setNMProps.sh

3. Perform the following steps to modify startWebLogic.sh:

1. Navigate to the following location:
- On Unix : $DOMAN_HOME/bin/startWebLogic.sh

- On Windows : $DOMAN_HOME/bin/startWebLogic.cmd

2. Set maximum heap size (-Xmx) to 1 GB for 64 bit systems and set maximum permanent generation (-XX:MaxPermSize) to 768M for 64 bit systems as follows:
USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:MaxPermSize=768m"

Note: If the remote Managed Server is started using sun JVM, then you must add following memory options to USER_MEM_ARGS: XX:+UnlockDiagnosticVMOptions and XX:+UnsyncloadClass.

3. Set max heap size to 1 GB for 32 bit systems, and maximum permanent generation to 512M for 32 bit system as follows:
USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:MaxPermSize=512m"

10. Perform the following steps on host-a, and then start the JVMDRemoteServer as follows:

1. Copy the emreposauthbean.jar located in $OMS_HOME/sysman/jlib, to <middleware_home>/wlserver_10.3/server/lib/mbeantypes. Where, $OMS_HOME is the location of the OMS server on host-a, and <middleware_home> is on host-b.

2. Copy the emCoreCommon.jar from $WEBLOGIC_HOME/sysman/jlib on host-a to $WEBLOGIC_HOME/server/lib on host-b.

3. Import SSL Certificate to Enterprise Manager Agent Trust store present on the host where managed server (JVMDRemoteServer) is running.

4. Start the managed server (JVMDRemoteServer) from the WebLogic Server Administration Console to complete the WebLogic Server setup.

11. Perform the following steps to discover the new managed server running on host-b:

1. In cloud Control, from Targets menu, select Middleware.
On the Middleware page, from the list of WebLogic Servers running, select the WebLogic Domain (EMGC_DOMAIN) where the managed server is deployed.

2. On the Cloud Control Domain page, from the WebLogic Domain menu, select Refresh WebLogic Domain.
The new server now gets registered in the Enterprise Manager Cloud Control Domain.

12. Restart the server for all the changes to take effect.

Installation Procedure

To deploy JVMD Manager on a separate host from OMS (remote deployment), perform the following steps:

Note:
For a successful remote deployment, ensure that:

- You install Enterprise Manager agent on the remote machine, and point it to the OMS running on a different managed server present in the same Enterprise Manager Cloud Control domain (EMGC_DOMAIN)

- The remote WebLogic Server version and patch level should match with servers in Enterprise Manager Domain (EMGC_DOMAIN). To ensure that the versions and patch levels match, Oracle recommends that you install WebLogic by selecting the Software Only install option in the Enterprise Manager OUI install.

1. In Cloud Control, from Setup menu, select Application Performance Management.

2. On the Application Performance Management page, from the Add menu, select JVM Diagnostics Engine.
The Deploy JVM Diagnostics Engine page appears.

3. To deploy JVMD Manager on the managed server running on a separate host from OMS, perform the following steps:

1. Select Deploy on an existing Managed Server.

2. From the Managed Server menu, select the managed server on which you want to deploy the JVMD Manager. For example, EMGC_JVMDMANAGER1, EMGC_JVMDMANAGER2, and so on.

4. Specify the Oracle WebLogic Managed Server Host Credentials and Oracle WebLogic Domain Credentials:
Where,

Oracle WebLogic Domain Credentials are credentials of the Weblogic domain in the Enterprise Manager Cloud Control.

Oracle WebLogic Managed Server Host Credentials are the credentials for the host machine where the Managed Server is created.

5. Click Deploy to submit the job.
The progress page appears with a link to the job processing page. Click the link to see the status of the job that you submitted.

Deploying JVMD Manager Manually

To deploy JVMD Manager manually, you must perform the following tasks:

- Downloading jvmd.zip

- Deploying JVMD Manager

Downloading jvmd.zip

Before deploying JVMD Manager ensure that you have downloaded the jvmd.zip. To do so, in Enterprise Manager 12c, navigate to the following default location to access the jvmd.zip file:

<Middleware HOME>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.0.0/archives/jvmd.

You can download this file to your local machine, and run the following command to extract the contents of the zip file:

unzip jvmd.zip

The jvmd.zip file contains the following:

inflated: jamagent.war
inflated: jammanager.war
inflated: janmanager_dummy.ear
extracted: loadheap.zip
inflated: Dep1oyAD4JManager.cmd
inflated: Dep1oyAD4JManager.py
inflated: Dep1oyAD4JManager.sh
created: customprov/
inflated: customprov/DeployJVMDAgent.cmd
inflated: customprov/DeployJVMDAgent.py
inflated: customprov/DeployJVMDAgent.sh
inflated: customprov/deploy_jvmdagent.pl
inflated: customprov/README.txt
inflated: customprov/sample_jymdagent_deploy.properties
inflated: upgrade/README.txt
inflated: upgrade/jvmd_monitoringupgradell_12.sql
inflated: upgrade/jvmd_targetupgradell-12.sql
inflated: upgrade/jvmd_traceupgrade1l_12.sq1

The jvmd.zip file contains the following scripts:

- DeployAD4jManager.cmd: This script enables you to deploy the JVMD Manager on a Windows host.

- DeployAD4jManager.sh: This script enables you to deploy JVMD Manager on a Linux host.

- DeployAD4jManager.py: This script is invoked by the DeployAD4jManager.cmd and DeployAD4jManager.sh scripts to deploy the JVMD Manager.

- jamagent.war: JVMD Agent.

- jammanager_dummy.ear: A dummy JVMD Manager is deployed by deployment scripts on the OMS, and is deleted when JVMD Manager deployment is complete.

- jammanager.ear: JVMD Manager

- loadheap.zip: The zip file contains the processlog for each platform, and scripts for loading the heap.

- customprov Folder: The customprov folder contains the scripts used to deploy the JVMD agent from the command line, and is specifically suitable for mass deployment.

- upgrade Folder: The folder contains scripts for upgradation.

Deploying JVMD Manager

To deploy the JVMD Manager from the command line, follow these steps:

1. Navigate to the following location, and download the jvmd.zip file here:
<middleware_home>/oms/jvmd

2. Run the following command to extract all the scripts from the jvmd.zip file:
unzip jvmd.zip

3. Select the SSL port or the Non-SSL ports to be assigned to the Managed Server, that will be created on the host where you want to deploy the JVMD Manager.

Note:
To verify if the ports are free or not, run the following command:
netstat -a|grep <port_number>

4. Run the following script from the command line to deploy JVMD Manager.
On Linux:

./DeployAD4JManager.sh

On Windows:

DeployAD4JManager.cmd

The script updates the default values for many of the parameters. If you want to change any of the parameter values, you can provide them when prompted, if not, press Enter to choose the default values.

Note:
A temporary file jammanager_dummy.ear is deployed on the OMS so that JVMD manager can access the repository. This file is deleted once the deployment is complete.

Once the deployment is successful, you will see a status as follows:

Current Status of your Deployment:
Deployment command type : deploy
Deployment State        : completed
Deployment Message      : no message

5. Once the connection to the repository is established, a server is created in the Enterprise Manager Cloud Control WebLogic Domain on which the JVMD Manager gets installed. By default, this server is called EMAD4JAMANAGER.You will see an output as follows:

Starting server EMAD4JMANAGER
Server with name EMAD4JMANAGER started successfully

Redeploying JVMD Manager

To redeploy a JVMD Manager, follow these steps:

1. Enter the following URL: https://<machine_name>:<EM_ADMINSERVER_SSL_PORT>/console to log in to the WebLogic Administration Console.

2. Perform a Force Shutdown to stop the existing JVMD Manager, and then click Delete to delete all the files associated with it.

Note:
Sometimes the Java processes are not completely removed, and continue to run even after the instance has been stopped and deleted. To avoid this, Oracle recommends that you use new set of port numbers when you redeploy the JVMD manager.

3. Copy the jvmd.zip archive file to your local drive, and replace it with your version of the jvmd.zip file.

4. Either perform the steps mentioned in Deploying JVMD Manager Manually to deploy the JVMD Manager manually, or use the steps outlined in Deploying JVMD Manager on an OMS Hostfor deploying the JVMD manager from UI.

Note:
The previously deployed JVMD Managers will continue to appear the Application Performance Management page unless you use the same server name while redeploying the JVMD Manager.

Deploying JVMD Agents

This section contains the following:

- Deploying JVMD Agents Using Enterprise Manager Cloud Control

- Downloading and Deploying JVMD Agents

- Redeploying JVMD Agents on WebLogic Servers

- Deploying JVMD Database Agent

- Connecting JVMD Agent to the JVMD Manager Secure Port

Deploying JVMD Agents Using Enterprise Manager Cloud Control

To deploy JVMD Agents on a Weblogic Domain which is monitored by the Management Agent present in the Enterprise Manager Weblogic Domain, perform the following steps:

Note:
This section will use the following convention:

- host-a corresponds to the WebLogic Domain where the JVMD Agent will be deployed.

- host-b corresponds to the Enterprise Manager Domain (EMGC_DOMAIN) where the Management Agent is deployed to monitor the WebLogic Domain on host-a.

1. In Cloud Control, from Targets menu, select Middleware.
The Middleware page displays a list of all the Middleware related targets discovered, and being managed in Cloud Control. Click target name to select the desired target.

2. From the Middleware page, click Oracle WebLogic Domain.
All the managed server present in the domain appear in the domain home page.

Note:
JVMD Agent cannot be deployed on the WebLogic managed server where the ADP Manager application is running. You can deploy JVMD Agents on Admin Server, OMS Server, or JVMD Managed Server in the Enterprise Manager Domain, or on any other WebLogic Domain.

3. From the WebLogic Domain menu, select Deploy Diagnostics Agents to deploy agents to the selected managed servers.

4. On the Deploy Diagnostics Agents page, choose the Oracle WebLogic Server (managed server) to which you want to deploy the JVMD Agents.

Note:
Ensure that you retain the selection of only those Diagnostic Agent(s) that you want to deploy to each of the managed server, deselect the others.

By default, the following servers appear deselected:

- The Administration server.

- All the managed servers that are not up and running.

- If the Deployed Version and the Version to Deploy are the same, and the status of the already deployed JVMD agent is up and running.

5. In the Diagnostics Agent Configuration section, enter the JVMD Configuration Properties for the selected agents.
Select the desired JVMD manager from the JVMD Manager list. The JVMD agents selected for deployment will report to this JVMD Manager.

Important:
If WebLogic domain on host-a is discovered using Management Agent on host-b, then you must do the following:

1. Navigate to the following location:

<WEBLOGIC_HOME>/server/lib

Where,
<WEBLOGIC_HOME> is the full abstract path to the Weblogic home for the monitored WebLogic domain on host-a.

2. Do the following to generate wlfullclient.jar:
If the WebLogic Server version is 10.3.x or higher, then run the following command:

java -jar wljarbuilder.jar

If the WebLogic Server version is less than 10.3.x or equal to 10.3.0, then use other WebLogic installations (10.3.x or higher) to create the wlfullclient.jar.

For example, you can use the <WEBLOGIC_DOMAIN> corresponding to the EMGC domain for generating the wlfullclient.jar, since Enterprise Manager setup uses JDK6.

3. Copy the following files from <WEBLOGIC_HOME>/server/lib/ to <AGENT_HOME>/sysman/jlib directory:
- wlfullclient.jar

- wljmxclient.jar

- webserviceclient+ssl.jar

- wlcipher.jar

Where <AGENT_HOME> is the Oracle home for the Management agent on host-b.

6. If Management Agent present on host-b is used to monitor the Weblogic Domain on host-a (remote Agent) where the JVMD Agent will be deployed, then you must provide credentials for Oracle Weblogic Administration Server Host Credentials and Oracle WebLogic Domain Credentials.
Where,

Oracle WebLogic Administration Server Host Credentials are the credentials for the host-b, where the Management Agent used to discover the monitored domain is present.

Oracle WebLogic Domain Credentials are credentials of the WebLogic Domain of host-a, where the JVMD Agent will be deployed.

7. Click Deploy to submit the job.
The progress page appears with a link to the job processing page. Click the link to see the status of the job that you submitted.

Note:
If the JVMD Agent deployment fails with an SSL handshake error, see "SSL Handshake Failure Agent Deployment Errors" to fix the problem.

Downloading and Deploying JVMD Agents

To complete the process of deploying JVMD Agents, follow the sequence of the steps listed in this section:

- Step1: Downloading jamagent.war File

- Step 2: Deploying JVMD Agent

Step1: Downloading jamagent.war File

Use one of the following methods to download the jamagent.war file:

- Using Cloud Control to Download the jamagent.war File

- Procuring jvmd.zip File from the Shiphome Location

Using Cloud Control to Download the jamagent.war File

Follow these steps:

1. In Cloud Control, from Setup menu, select Application Performance Management.

2. On the Application Performance Management page, select JVM Diagnostics Engine.
The Configure icon in the Application Performance Management Engines page gets enabled.

3. Click Configure. The JVM Diagnostics Setup page appears.

4. On the JVM Diagnostics Setup page, click JVMs and Pools, then click Download. The Download JVM Diagnostics Component dialog box appears.

5. From the JVMD Component menu, select JVMD Agent, and click Ok. The JVM Diagnostics Agent web.xml parameters dialog box appears.

6. From the Available Managers menu, select a Managed Server on one of the ports from the list, and click Download:

- Select the Non-SSL port (3800) to connect to the JVMD Manager.

- Select e SSL port (3801) to securely connect to the JVMD Manager.

For example:

Non-SSL port: slc01.us.example.com:3800

SSL port: slc01.us.example.com:3801 (Secure Communication)

Note:
If you do not want to select an existing manager, you can select Other from the Available Managers menu, and specify the hostname and port for the agent to connect to. This is specially useful when multiple JVMD Managers are load balanced.

7. The downloaded jamagent.war file is ready for deployment either from the WebLogic Administration Console or using a Non WebLogic Server.
To deploy a JVMD agent using a Non-WebLogic Server, do the following:

1. Copy the jamagent.war file to your Application Server host machine, and make a no te of its location.

2. Add following JVM options to your application server start up command:

-classpath <original classpath>:<full path to jamagent.war inclusive> jamagent.jamrun jamconshost=<jamconshost> jamconsport=<jamconsport> jamjvmid=<a unique identifier, e.g. 1234> jamtimeout=30 jamloglevel=3

Procuring jvmd.zip File from the Shiphome Location

Follow these steps:

1. Navigate to the following location, and download the jvmd.zip file here:
<middleware_home>/oms/jvmd

2. Run the following command to extract the JVMD Agent script present in the jvmd.zip file:
unzip jamagent.war

3. Navigate to the following location: WEB-INF/web.xml.

4. Edit the web.xml file to update the values of the parameters jamconshost and jamconsport.
Where,

jamconshost is the IP of the machine on which the JVMD Manager (jammanager ) is deployed.

jamconsport is the port of the host on which the JVMD Manager is deployed.

Note:
To enable secure communication with the selected JVMD Manager, make the following change to the web.xml file:
jamsecureCommunication = 1

For example:

<init-param>
<param-name>jamconshost</param-name>
<param-value>slc01axn</param-value>
<description>Jam console host - demolnx.auptyma.com</description>
</init-param>
<init-param>
<param-name>jamconsport</param-name>
<param-value>3800</param-value>
<description>Jam console port</description>
</init-param>

Note:
Once the JVMD Manager is deployed, the IP and the port appear on JVMD Deployment page as: <Machine Name:Port Number>

5. Run the following command to reassemble the jamagent.war file:
jar -cMvf jamagent.war META-INF WEB-INF jamagent oracle

6. The updated jamagent.war file is ready for deployment either from the WebLogic Administration Console or using a Non WebLogic Server.

Step 2: Deploying JVMD Agent

Deployment of JVMD Agents is possible either using Oracle WebLogic Server or from a Non-WebLogic Server.

- Deploying JVMD Agents on a WebLogic Server

- Deploying JVMD Agents on a Non-WebLogic Server

Deploying JVMD Agents on a WebLogic Server

Use one of the following methods to deploy the JVMD Agents:

You can either use the WebLogic Administration Server Console to deploy the JVMD Agents, or deploy them using the Custom Provisioning Script. To deploy using the Custom Provisioning script, follow these steps:

1. Make a copy of the Deployment profile sample_jvmdagent_deploy.properties available in the jvmd.zip file. Basically, update the details like: location of jamagent.war file, the WebLogic domain, and server information, and save the profile as jvmdagent_deploy.properties.
For more information about the parameters, see the README.txt file present in the customprov folder.

2. Run the following perl script available in the customprov folder to deploy JVMD Agent on all the specified servers.
perl deploy_jvmdagent.pl

Note:
Ensure that the deployment profile jvmdagent_deploy.properties and the perl scripts are available in the same folder.

Deploying JVMD Agents on a Non-WebLogic Server

To deploy a JVMD agent using a Non-WebLogic Server, do the following:

1. Copy the jamagent.war file to your Application Server host machine, and make a note of its location.

2. Add following JVM options to your application server start up command:

-classpath <original classpath>:<full path to jamagent.war inclusive> jamagent.jamrun jamconshost=<jamconshost> jamconsport=<jamconsport> jamjvmid=<a unique identifier, e.g. 1234> jamtimeout=30 jamloglevel=3

For example:

If earlier the command to start the server was:
java –classpath x.jar -Dfoo=value server.Main
now it would be:
java –classpath x.jar:<absolute path of jamagent.war> -Dfoo=value jamagent.jamrun jamconshost=<jamconshost> jamconsport=<jamconsport> jamjvmid=<a unique identifier, e.g. 1234> jamtimeout=30 jamloglevel=3 server.Main

Redeploying JVMD Agents on WebLogic Servers

On the Deploy Diagnostics Agents page, if the Deployed Version and the Version to Deploy are different, then it could mean that there is a higher version of the JVMD Agent available. For redeploying the agent to a higher version, use the UI, and follow the steps listed in Downloading and Deploying JVMD Agents.

Alternately, you can manually stop the JVMD Agent and delete the earlier deployed agent, and then perform the steps listed in Step 2: Deploying JVMD Agent to manually deploy the JVMD Agents.

Deploying JVMD Database Agent

If you need JVMD Database Agent, download the JVMD Agent from Cloud Control as it can serve as a Database Agent too. If the JVMD Agent is downloaded and installed on the same host as the Database, then you do not require a separate Database Agent. The JVMD Agent itself orchestrates between the Database and the JVMD Manager. However, if the JVMD Agent and the Database are on separate hosts, then you need a Database Agent to collect the Database specific information, and transmit the data to JVMD Manager.

Note:
JVMD Database Agents are supported on the platforms on which the JVMD Agents are supported except for Windows, and need Java 1.4.X or higher to run.

For downloading and deploying JVMD agents, do the following:

1. Follow the steps listed in Step1: Downloading jamagent.war File to download the jamagent.war file using Cloud Control.

2. To start the Database Agent, run the following command:

$JAVA_HOME/bin/java -Xms126M -Xmx512M -cp ./jamagent.war jamagent.Dbagent jamconshost=<Machine on which manager is running> jamconsport=<Port of the server on which Manger is installed>

For Example: /usr/local/packages/jdk14/bin/java -Xms126M -Xmx512M -cp ./jamagent.war jamagent.Dbagent jamconshost=adc2190661.us.example.com jamconsport=3900

Note:
IF you see the error message TIMEOUT from console JAM Agent: Error receiving data from console, then restart the Database Agent with the option jamconsretr = 5.

Connecting JVMD Agent to the JVMD Manager Secure Port

To deploy the JVMD Agents from the command line, you can follow the steps outlined in Downloading and Deploying JVMD Agents.

Note:
For ensuring secure communication with JVMD Manager, the JVM should have the access to a KeyStore in which the certificate of the Managed Server on which manager is deployed, is added. The KeyStore of the Cloud Control Domain in which the Managed Server (MANAGER) is created can be used for same.

If you have access to Enterprise Manager Cloud Control Domain, then do the following:

1. Locate the KeyStore, it is normally available in the following location:
<weblogic_directory>/server/lib/DemoTrust.jks

Where, WebLogic home refers to the installation directory of WebLogic Server.

2. Add the following to the command line of the JVMD Agent, and start it:
-Djavax.net.debug=ssl -Djavax.net.ssl.trustStore=<location of DemoTrust.jks of the manager server> -Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase

Note:
The default password for the WebLogic Key Store is DemoTrustKeyStorePassPhrase.

If you do not have access to Enterprise Manager Cloud Control Domain, then do the following:

1. If the target server already has a KeyStore, for example DemoTrust.jks, then use DemoTrust.jks. Otherwise, you need to create a new Keystore, for example Keystore.jks. To create a new KeyStore, see step 3.

2. Follow these steps to download the certificate of the Managed Server:

1. Enter the URL: https://<jamconshost>:<jamconsport(secure)>

2. On the home page of the JVMD Agent, select Details Tab, then click Export.

3. Save the certificate as myCert.crt.

3. To add certificate to an existing keystore DemoTrust.jks, or to create a new KeyStore keystore.jks and add certificate to it, run the following command:

keytool -import -trustcacerts -alias root -file myCert.crt -keystore <keystore/DemoTrust>.jks

The command creates a new KeyStore with a default password changeit.

After You Install

After installing the JVMD Managed Server, or the JVMD Agent, follow the steps outlined in the Basic Installation Guide

14 Integrating BI Publisher with Enterprise Manager

Oracle Business Intelligence (BI) Publisher is Oracle's primary reporting tool for authoring, managing, and delivering all your highly formatted documents. BI Publisher ships standard with Enterprise Manager Cloud Control 12c.

IMPORTANT:
Only BI EE 11.1.1.6.0, which contains BI Publisher 11.1.1.6.0, is supported for use with Enterprise Manager 12c Cloud Control Release 2 (12.1.0.2.0).

WARNING:
Do NOT attempt to install BI EE 11.1.1.6.0 onto Enterprise Manager 12c Cloud Control Release 1 (12.1.0.1.0)

This chapter covers the following topics:

- Overview

- Configuring BI Publisher with a Custom Trust Store

- BI Publisher Administration

- Post-Upgrade Steps to take after upgrading to BI Publisher to 11.1.1.6.0

- EMBIP* Roles: Granting Access to Folders and Catalog Objects

- Access to Enterprise Manager Repository

- Troubleshooting

- Managing Enterprise Manager - BI Publisher Connection Credentials

- Managing the BI Publisher Server

- Configuring BI Publisher behind a Load-Balancer

Overview

In order to integrate BI Publisher with Enterprise Manager 12c, BI Publisher is installed separately, but shares the same Middleware home, as Enterprise Manager. This installation is performed using the standard Business Intelligence Enterprise Edition 11.1.1.6.0 installation that is specific to the platform on which Enterprise Manager is installed. BI Publisher is then integrated into the same WebLogic Server domain as Enterprise Manager using the configureBIP script. Once configured, you will be able to take advantage of the standard features BI Publisher offers, such as:

- Highly formatted, professional quality, reports, with pagination and headers/footers.

- PDF, Excel, Powerpoint, Word, and HTML report formats.

- Develop your own custom reports against the Enterprise Manager repository (read-only repository access).

- Integration with Enterprise Manager Security.

- Grant varying levels of BI Publisher functionality to different Enterprise Manager administrators.

- Use BI Publisher's scheduling capabilities and delivery mechanisms such as e-mail and FTP.

Note:
The Information Publisher (IP) reporting framework, though still supported in Enterprise Manager 12c Cloud Control, was deprecated as of Enterprise Manager 12c release 12.1.0.1. No further report development will occur using the IP framework.

Limitations

The following are limitations apply to the use of reports and data sources.

- Out-of-box reports cannot be edited.

- If Out-of-box reports are copied, there is no guarantee that the copies will work with future product releases.

Downloading Oracle BI Publisher

Only Oracle Business Intelligence (BI) Publisher version 11.1.1.6.0 can be used with Enterprise Manager 12c Cloud Control Release 2 (12.1.0.2) .Versions of Business Intelligence Publisher older than 11.1.1.6.0 are not compatible with Enterprise Manager Cloud Control Release 2 (12.1.0.2). You can download Oracle Business Intelligence Publisher version 11.1.1.6.0 directly from the Enterprise Manager Cloud Control download Web site.

http://www.oracle.com/technetwork/oem/grid-control/downloads/index.html

See the link titled Oracle Business Intelligence Publisher 11.1.1.6.0.

Determining BI Publisher Platform Support

To determine whether your software platform is supported by BI Publisher, refer to Chapter 2: System Requirements and Certification of the Oracle® Fusion Middleware Quick Installation Guide for Oracle Business Intelligence 11g Release 1 (11.1.1) for BI EE system requirements.

For system requirements and certification information, refer to the Oracle Business Intelligence chapter in the Oracle Fusion Middleware Release Notes for your platform. The documents are available on Oracle Technology Network (OTN) at the following location:

http://www.oracle.com/technetwork/indexes/documentation/index.html

BI Publisher Installation and Integration with Enterprise Manager 12c

The following procedures assume that you are familiar with both BI Publisher and Enterprise Manager. Refer to the Oracle Enterprise Manager Basic Installation Guide and the Oracle Enterprise Manager Advanced Installation and Configuration Guide for detailed information about Enterprise Manager.

Enterprise Manager and BI Publisher Inventory

Both Enterprise Manager and BI Publisher must be installed with a centralized inventory file. This means that /etc/oraInst.loc (or the Windows registry) points to the same directory for both installs. Although it is possible to install both products with an inventory file specific to each product, this configuration is not supported and will not allow complete integration between Enterprise Manager 12c and BI Publisher 11g.

Installing Enterprise Manager and Required Infrastructure

In order to support the required resources for BI Publisher, the first OMS system (where BI Publisher is initially installed) needs the following additional system requirements above and beyond what is already required by Enterprise Manager:

- +1.5 GB of RAM

- +10 GB of disk space

- Any additional OMS(s) that is added to the domain, after BI Publisher has been installed on the first OMS, will also require an additional 10 GB of disk space.

For additional resource requirements, see the following support note:

How to Determine the Number of Servers Needed to Run BI Publisher Enterprise in a Production 10g or 11g Environment? (Doc ID 948841.1)

Installing Plug-in-Specific Reports: Some Enterprise Manager-provided BI Publisher reports belong to specific plug-ins. These plug-ins must be installed in order for these reports to be available. A plug-in can be installed before or after BI Publisher is configured to work with Enterprise Manager 12c. Enterprise Manager plug-ins can be installed using different mechanisms. All of these mechanisms support the installation of BI Publisher reports that are part of a plug-in.

Note:
Refer to the Oracle Enterprise Manager Basic Installation Guide for complete installation specifics.

Installing BI EE Using Software-only Install

Note:
The BI EE Software-only Install instructions apply in the case of a new installation or in the case of an upgrade from 12.1.0.1 to 12.1.0.2 where 12.1.0.2 has been installed into a new Fusion Middleware Home.

As mentioned at the beginning of this chapter, ONLY Oracle Business Intelligence Enterprise Edition 11g 11.1.1.6.0 can be used to integrate with Enterprise Manager 12c Release 2 (12.1.0.2)). No other product combination is compatible.

Integrating BI Publisher with Enterprise Manager requires changing the domain configuration and the Middleware home used by the Oracle Management Service. Backing up the entire Enterprise Manager Oracle Management Service installation ensures that you can recover the OMS in the event that errors occur during installation and configuration of BI Publisher.. For instructions on performing OMS backup, see the "Backing up Enterprise Manager" chapter of the Oracle® Enterprise Manager Cloud Control Administrator's Guide. Go to the section Oracle Management Service Backup.

Once the correct version of Business Intelligence Enterprise Edition 11g is downloaded, and the OMS backup has been performed, perform a software-only install of BI Enterprise Edition using the following steps:

1. Run the BI Enterprise Edition Publisher Installer:
Linux/UNIX: Disk1/runInstaller

Windows: Disk1/setup.exe

Note:
Insure that you use the correct media or download for BI EE 11.1.1.6.0.

Note:
Insure that you use the correct media or download for BI EE that is appropriate for your hardware and operating system platform.

2. (Optional) Choose E-Mail address for updates and click Next.

3. VERY IMPORTANT: Choose Software-only Install.

4. Click Next. Prerequisite checks will run.

5. After passing the prerequisite checks, click Next.

6. Choose the Middleware home of your Enterprise Manager installation. This is the Middleware home that you created previously.

7. BI Oracle home name must be left as the default Oracle_BI1. Click Next.

8. (Optional) Enter My Oracle Support (MOS) credentials to be notified of any security updates. Click Next.

When the software-only install of BI EE completes successfully, proceed to Integrating BI Publisher with Enterprise Manager using the configureBIP Script.

Integrating BI Publisher with Enterprise Manager using the configureBIP Script

Integrating BI Publisher with Enterprise Manager requires changing the domain configuration. However, you must first back up the domain in case configuration problems occur. File permissions for the domain must be maintained when creating a backup, therefore the ZIP utility is the preferred mechanism to do so. For example:

cd  <Instance-Home>/user_projects/domains
zip -r GCDomain.zip GCDomain

IMPORTANT:
The configureBIP script must be run as the same operating system user who owns the Oracle Middleware Home.
DO NOT run configureBIP as the Unix Super User (root).

There are two scenarios in which you would run configureBIP:

For both the fresh install and upgrade scenarios, in order to install and integrate BI Publisher 11.1.1.6.0 with Enterprise Manager 12c Release 2 (12.1.0.2), it is first necessary to do a software-only install of BI Enterprise Edition 11.1.1.6.0. However, when running the configureBIP script, there are additional command-line arguments that are necessary in the upgrade scenario.

- Scenario 1: Fresh install of 12.1.0.2
The fresh install case is used when either of these conditions are met:

- You are installing or upgrading to Enterprise Manager 12c for the first time. You did not have Enterprise Manager 12c Release 1 (12.1.0.1) installed previously.

- You are upgrading to Enterprise Manager 12c Release 2 (12.1.0.2) from Enterprise Manager 12c Release 1 (12.1.0.1) and you had not previously installed and integrated BI Publisher 11.1.1.5.0 with Enterprise Manager 12c Release 1 (12.1.0.1).

- Scenario 2: Upgrade from 12.1.0.1 to 12.1.0.2
Use the configureBIP script in upgrade mode if both of the following conditions are true:

- You have already upgraded Enterprise Manager 12c Release 1 (12.1.0.1) to Enterprise Manager 12c Release 2 (12.1.0.2).

- The previous installation of Enterprise Manager 12c Release 1 (12.1.0.1) had been integrated with BI Publisher 11.1.1.5.0.

Regardless of whether you run the configureBIP script in normal mode or upgrade mode, the script requires the following credentials in order to operate:

- An Oracle account with SYSDBA privilege; normally the SYS account.

- The database password for this account.

- The WebLogic Admin Server password.

- The Node Manager password.

Make sure to gather the above credentials before proceeding.

Both the normal mode and upgrade mode of configureBIP are discussed in detail in the following two sections. Be sure to operate the configureBIP script in the appropriate mode for your installation scenario.

Integrating BI Publisher with Enterprise Manager using the configureBIP Script in Normal Mode

1. From the OMS instance's ORACLE_HOME/bin directory (of the current Enterprise Manager 12c Release 2 (12.1.0.2) installation), execute the configureBIP script from the command line. For example:

cd /oracle/EM12cR2/middleware/oms/bin
./configureBIP

2. The script prompts for the necessary credentials.

3. The script executes the Repository Creation Utility (RCU), since this is normal mode, to create the BI Publisher database schema.

4. The script prompts for two inputs for the port(s) to use for the BI Publisher Managed Server: One port for non-SSL (not recommended) and one port for SSL.

5. The script then performs the extend-domain operations.

6. The last step the script performs is to deploy the Enterprise Manager-supplied BI Publisher Reports to the newly installed BI Publisher Web application.

Script Input

1. Confirm that you have backed up your domain by answering the confirmation prompt with YES.

2. Enter a database user with SYSDBA privileges (typically SYS), and then enter the password (Enterprise Manager Repository database).

3. Enter the adminserver and then the nodemanager password. These accounts are part of Enterprise Manager WebLogic Domain.

Script Operation - Normal Mode (RCU):

Since you are installing BI Publisher for the first time, the schema will be created. You should see the something like the following output:

Checking for SYSMAN_BIPLATFORM schema...
Attempting to create SYSMAN_BIPLATFORM schema...
Processing command line ....
Repository Creation Utility - Checking Prerequisites
Checking Global Prerequisites
Repository Creation Utility - Checking Prerequisites
Checking Component Prerequisites
Repository Creation Utility - Creating Tablespaces
Validating and Creating Tablespaces
Repository Creation Utility - Create
Repository Create in progress.
Percent Complete: 0
Percent Complete: 10
Percent Complete: 30
Percent Complete: 50
Percent Complete: 50
Percent Complete: 100
Repository Creation Utility: Create - Completion Summary
Database details:
Connect Descriptor: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host.com)(PORT=1521)))(CONNECT_DATA=(SID=orcl)))
Connected As: sys
Prefix for (prefixable) Schema Owners : SYSMAN
RCU Logfile: .../middleware/oms/cfgtoollogs/bip/emBIPLATFORM.log
Component schemas created:
Component  Status  Logfile
Business Intelligence Platform  Success .../middleware/oms/cfgtoollogs/bip/biplatform.log
Repository Creation Utility - Create : Operation Completed

Extend Domain Steps

1. You will then be asked to enter BI Publisher HTTP and HTTPS (SSL) ports (either one or both). The script will identify free ports and ask if you want to take them as a default. Once entered, Extend Domain will then run. The ports can be in the range 9701-49152. Default port numbers are provided.

2. The Enterprise Manager-supplied BI Publisher Reports will be deployed to the newly installed BI Publisher Web application.

3. Once processing is complete, screen output similar to the following will be shown:

Extending domain with BI Publisher. This may take a few minutes...
BI Publisher server running at https://host.com:9701/xmlpserver.
Registering BI Publisher with Enterprise Manager and deploying reports...
Successfully setup BI Publisher with Enterprise Manager

Integrating BI Publisher with Enterprise Manager Using the configureBIP Script in Upgrade Mode

From the OMS instance's ORACLE_HOME/bin directory (of the current Enterprise Manager 12c Release 2 (12.1.0.2) installation), execute the configureBIP script with the -upgrade command-line argument. For example:

cd /oracle/EM12cR2/middleware/oms/bin
./configureBIP -upgrade

1. The script prompts for the necessary credentials.

2. The script prompts for the full directory path to the domain of the prior Enterprise Manager 12c Cloud Control Release 1 (12.1.0.1) installation. This installation already contains BI Publisher 11.1.1.5.0 report definitions and certain configuration data.

3. The script then executes the Patch Set Assistant (PSA) steps to upgrade the BI Publisher database schema, since this is an upgrade from a prior release of the BI Publisher.

4. The script prompts for two inputs for the port(s) to use for the BI Publisher Managed Server. One port for non-SSL (not recommended) and one for SSL.

5. The script then performs the extend-domain operations, but does not start the BI Publisher Managed Server.

6. The script migrates the reports and certain configuration data from the prior installation of BI Publisher 11.1.1.5.0 that was installed onto Enterprise Manager 12c Release 1 (12.1.0.1).

7. The script then starts the BI Publisher Managed Server.

8. The last step the script performs is to deploy the Enterprise Manager-supplied BI Publisher Reports to the newly installed BI Publisher Web application.

Note:
During an upgrade of BI Publisher 11.1.1.6.0 onto Enterprise Manager 12c Release 2 (12.1.0.2), the existing BI Publisher 11.1.1.5.0 schema will be upgraded from 11.1.1.5.0 to 11.1.1.6.0. This means that when performing an upgrade, all existing BI Publisher schedules will be carried over to the new installation of BI Publisher 11.1.1.6.0

Optional: If your BI Publisher file system-based repository is in a shared storage location from the prior install, and you also want to continue to use this shared location for the new install, then the report and configuration migration performed in step 6 above is not required. In this situation, you can run configureBIP using the following syntax:

./configureBIP -upgrade -nomigrate

Script Input

1. Confirm that you have backed up your domain by answering the confirmation prompt with "yes".

2. Enter a database user with SYSDBA privileges (typically 'sys'), then enter the password. (Enterprise Manager repository database).

3. Enter the adminserver and then the nodemanager password. These accounts are part of Enterprise Manager WebLogic Domain.

4. Enter the full directory path to the domain from the Enterprise Manager 12c Release 1 (12.1.0.1) installation. For example:

/oracle/em12cR1/middleware/gc_inst/user_projects/domains/GCDomain

When executing the script on a Windows operating system, use double-backslashes to separate directory entries. For example:

C:\\EMInstall\\middleware\\gc_inst\\user_projects\\domains\\GCDomain

5. The patch set assistant then runs to upgrade the BI Publisher schema. Output similar to the following will be generated.

Upgrading from a prior release of BI Publisher With a file-system repository Located at: /oracle/em12cR1/middleware/gc_inst/user_projects/domains/GCDomain
Checking for SYSMAN_BIPLATFORM schema...
Attempting to upgrade SYSMAN_BIPLATFORM schema...
EM 12c BIPLATFORM 11.1.1.5.0 schema detected. Begin upgrade process to 11.1.1.6.0 ...
Begin to execute Oracle Fusion Middleware Patch Set Assistant (PSA) ...
PSA returns with status: 0
Successfully upgraded SYSMAN_BIPLATFORM schema...

Extend Domain Steps

1. You will then be asked to enter BI Publisher HTTP and HTTPS (SSL) ports (either one or both). The script will identify free ports and ask if you want to take them as a default. The ports can be in the range 9701-49152. Defaults are provided. Once entered, Extend Domain will run, but the BI Publisher Managed Server will not be started until step three.

2. Certain reports and configurations from the BI Publisher 11.1.1.5.0 installation will be migrated (unless the "-nomigrate" option was supplied on the command-line).

3. The BI Publisher Managed Server will be started

4. The Enterprise Manager-supplied BI Publisher Reports will be deployed to the newly installed BI Publisher Web application.

5. Once processing is complete, screen output similar to the following will be generated.

Extending domain with BI Publisher. This may take a few minutes...
Migrating BI Publisher Filesystem repository from "/oracle/em12cR1/middleware/gc_inst/user_projects/domains/GCDomain /config/bipublisher/repository" to "/oracle/emNewInstall/middleware/gc_inst/user_projects/domains/GCDomain /config/bipublisher/repository"...
Starting the Upgraded BI Publisher Managed Server...
BI Publisher server running at https://host.com:9704/xmlpserver.
Registering BI Publisher with Enterprise Manager and deploying reports...
Successfully setup BI Publisher with Enterprise Manager

Verifying Integration of BI Publisher with Enterprise Manager

1. Log in to Enterprise Manager as a Super Administrator.

2. From the Enterprise menu, select Reports and then BI Publisher Enterprise Reports.
Prior to BI Publisher being integrated with Enterprise Manager, the BI Publisher Reports page appears as follows:

3. Once BI Publisher has been integrated with Enterprise Manager, you may have to click the refresh icon at the top right of the Enterprise Manager window (highlighted in the previous graphic) in order for the UI to reflect the changes.

4. Enterprise Manager displays a tree list showing all of the Enterprise Manager- supplied BI Publisher reports as shown in the following graphic

This graphic shows the list of reports after all plug-ins have been installed. The report list will vary in size depending on the number of plug-ins that have been installed.

5. Click on the provided EM Sample Reports and the select Targets of Specified Type.

6. Log in to BI Publisher using your Enterprise Manager credentials.

7. You will see the sample report rendered on the screen. You can then use the full capabilities of BI Publisher such as PDF report generation and e-mail delivery.

Allowing Access to BI Publisher for Enterprise Manager Administrators

BI Publisher shares the same security model, via WebLogic, that Enterprise Manager is configured to use. The security model is used both for authenticating access to BI Publisher, and also setting up access to different features of BI Publisher. The items to be discussed in the following sections are:

- Enterprise Manager Authentication Security Model

- BI Publisher security model

- BI Publisher Permissions

- BI Publisher OPSS Application Roles

- Authenticating and limiting access BI Publisher features

Enterprise Manager Authentication Security Model

Once integrated, BI Publisher reports conform to the Enterprise Manager authentication security model.Enterprise Manager supports a variety of security models, as defined in the Oracle® Enterprise Manager Cloud Control Administrator's Guide (Configuring Security). To summarize, the security models that Enterprise Manager 12c supports are:

- Repository-Based Authentication

- Oracle Access Manager (OAM) SSO

- SSO-Based Authentication

- Enterprise User Security Based Authentication, with 2 options

- LDAP Authentication Options: Oracle Internet Directory and Microsoft Active Directory

BI Publisher security model

When BI Publisher is integrated with Enterprise Manager, it shares the same security model as Enterprise Manager. Security Model 1 - Repository-Based authentication, uses the Oracle database for authentication. The remaining 4 security models use an underlying LDAP server to authenticate users. For the purposes of this document, we classify the BI Publisher security model into one of these two categories:

- Repository-Based Authentication

- Underlying LDAP-based Authentication

The primary security attributes that apply to BI Publisher Reports are:

- BI Publisher Permissions

- BI Publisher OPSS Application Roles

Each of these security attributes is detailed in the following sections.

BI Publisher Permissions

Enterprise Manager ships with certain Oracle-provided BI Publisher catalog objects. These catalog objects consist of:

- Folders

- Reports (layout definitions and translations)

- Datamodels (SQL queries against the Enterprise Manager repository)

- Subtemplates (standard Enterprise Manager header shown above all pages of all report output)

These catalog objects are created when BI Publisher is installed and integrated with Enterprise Manager. They are placed in the "Enterprise Manager Cloud Control" folder. These catalog objects are created with certain permissions that, combined with the roles/groups discussed below, achieve the desired security model.

BI Publisher OPSS Application Roles

The domain policy store (OPSS) is used to control Enterprise Manager administrator access to objects in the BI Publisher catalog and conditional access to the BI Publisher "Administration" button.

OPSS is the repository of system and application-specific policies. Details regarding OPSS can be found in the Oracle® Fusion Middleware Application Security Guide. In a given domain, there is one store that stores all policies (and credentials) that all applications deployed in the domain may use. As both Enterprise Manager and BI Publisher are separate applications in the same domain, it is necessary to grant specific BI Publisher OPSS application roles to Enterprise Manager administrators in order for them to access and use BI Publisher.

When BI Publisher is installed, four OPSS application roles are created. These four OPSS application roles are combined with the permissions on the BI Publisher catalog objects in the "Enterprise Manager Cloud Control Folder" to achieve the rules shown in the following sections. In addition, when the underlying LDAP authentication security model is used, the LDAP groups can be mapped to these OPSS application roles.

In the Repository-based authentication security model, the domain policy store (OPSS) is used solely to control Enterprise Manager administrator's access to BI Publisher.

Authenticating and limiting access BI Publisher features

Below is a list of the OPSS application roles, and a description of the effective security model placed on BI Publisher catalog objects that ship with Enterprise Manager.

- None - Enterprise Manager administrators without any BI Publisher role can access BI Publisher Reports via any delivery channel that BI Publisher supports, and that has been configured and made accessible the BI Publisher System Administrator. For example, any user can receive BI Publisher Reports via the BI Publisher scheduling and e-Mail delivery mechanism, if configured.

- EMBIPViewer - Enterprise Manager administrators with this BI Publisher role can receive e-mails plus can view the Enterprise Manager-supplied BI Publisher reports.

- EMBIPScheduler - Enterprise Manager administrators with this BI Publisher role can receive e-mails and can schedule the Enterprise Manager-supplied BI Publisher reports if they also have the EMBIPViewer role.

- EMBIPAuthor - Enterprise Manager administrators with this BI Publisher role can receive e-mails, view the Enterprise Manager-supplied BI Publisher reports, and can create new reports in their private folder. They can also copy the Enterprise Manager-supplied BI Publisher reports into their private folder and customize them.

- EMBIPAdministrator (Super Users) - Enterprise Manager administrators with this BI Publisher role have complete access to BI Publisher.

The following diagram shows the hierarchy of the above roles:

Note:
Access to the BI Publisher "Administration" button is granted via the OPSS application role. This button is used to perform advanced configuration on BI Publisher, such as setting up the e-mail server.

Enterprise Manager Super Administrators

When the repository-based authentication security model is used, all Enterprise Manager Super Administrators are automatically granted the EMBIPAdministrator OPSS application role to facilitate setting up BI Publisher.

When an underlying LDAP authentication security model is used, Enterprise Manager Super Administrators are not automatically granted EMBIPAdministrator access to BI Publisher. See Section 16.x for more information on allowing access to BI Publisher for Enterprise Manager Administrators in an underlying LDAP-based Authentication security Model environment.

Limiting access to BI Publisher features

Granting the previously discussed four OPSS application roles is somewhat different depending on the BI Publisher security model that is in place. To review, the 2 security models that BI Publisher supports are:

- Repository-Based Authentication

- Underlying LDAP-based Authentication

Granting BI Publisher OPSS Application Roles to Enterprise Manager Administrators in Repository-Based Authentication Mode Using wlst

wlst.sh can be used to grant access to the BI Publisher to Enterprise Manager administrators. The following wlst.sh usage example demonstrates using wlst.sh to grant VIEW access to the Enterprise Manager administrator named "JERRY" (italicized items are entered at the command-line). It is important to use uppercase letters for Enterprise Manager Administrator names.

Note:
If you have just upgraded to BI Publisher 11.1.1.6.0 on Enterprise Manager 12c Release 2 (12.1.0.2) from a prior installation of BI Publisher 11.1.5.0 on Enterprise Manager 12c Release 1 (12.1.0.1), all of your prior OPSS application grants are carried over from the prior installation. It is not necessary to grant access to BI Publisher to specific Enterprise Manager administrators that had already been granted access. In order to grant access to additional, or revoke access from existing, Enterprise Manager administrators, this step is still required.

To run the script:

1. Connect to the Administration Server over the t3s protocol using the connect() command. The command takes three arguments:

- Username: Always 'weblogic'.

- Password: This is the password that you used when you setup Enterprise Manager 12c Cloud Control.

- Protocol: t3s (ssl), the host, and the port. These are the values for the WLS Administration Server. The port number is the same port number that you use when you connect to the WLS Administration Console in a browser. For example: https:<host>:<port>/console).

2. Grant EMBIP* role(s) to individual Enterprise Manager 12c Cloud Control administrators. Administrator "JERRY" is used in this example.

Example Session

$MW_HOME/oracle_common/common/bin/wlst.sh [linux]
wlst.cmd [windows]
...
...
Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect('weblogic','<pw>','t3s://host:port')
...
...
Successfully connected to Admin Server 'EMGC_ADMINSERVER' that belongs to domain 'GCDomain'.

wls:/GCDomain/serverConfig> grantAppRole(appStripe="obi",appRoleName="EMBIPViewer",principalClass="weblogic.security.principal.WLSUserImpl",principalName="JERRY")

Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.

For more help, use help(domainRuntime)
wls:/GCDomain/serverConfig> exit()

Revoking VIEW Access to BI Publisher Reports

In the following example session you revoke VIEW access to BI Publisher reports from user "JERRY" (case is important).

$MW_HOME/oracle_common/common/bin/wlst.sh [linux]
wlst.cmd [windows]

...
...
Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect('weblogic','<pw>','t3s://host:port')
...
...
Successfully connected to Admin Server 'EMGC_ADMINSERVER' that belongs to domain 'GCDomain'.

wls:/GCDomain/serverConfig> revokeAppRole(appStripe="obi",appRoleName="EMBIPViewer",principalClass="weblogic.security.principal.WLSUserImpl",principalName="JERRY")

Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.

For more help, use help(domainRuntime)
wls:/GCDomain/serverConfig> exit()

Propagation Time for Changes to OPSS

When changing an Enterprise Manager administrator's BI Publisher access privileges (EMBIPViewer, EMBIPAdministrator, EMBIPScheduler, EMBIPAuthor) the Super Administrator needs to wait 15 or more minutes for the changes to propagate through OPSS and become effective. The change will then be effective the next time the administrator logs into BI Publisher.

Allowing Access to BI Publisher for Enterprise Manager Administrators in an underlying LDAP Authentication security model environment

Enterprise Manager and BI Publisher are separate applications. When using an underlying LDAP-based authentication model, LDAP groups defined in the external LDAP server can also be used to manage access to BI Publisher. These LDAP groups allow varying levels of access to BI Publisher. Hence, you can add an LDAP user as a member of one or more of these LDAP group and appropriate capabilities of BI Publisher will be exposed. These LDAP groups, which either need to be created or existing ones used, are coordinated with the permissions of the catalog object in the "Enterprise Manager Cloud Control" folder.

In an underlying LDAP-based authentication security model, the following steps are required:

- The administrator of the LDAP server needs to use four external groups of any chosen name. These groups need to be grouped hierarchically. Existing groups can be used, or new ones can be created.

Important:
The group names must be all upper-case.

Group Name Examples:

- EMBIPADMINISTRATOR

- EMBIPVIEWER

- EMBIPSCHEDULER

- EMBIPAUTHOR

- The administrator of the LDAP server must then make the additional changes below in order to achieve the necessary hierarchical structure shown in the hierarchy diagram above. For example, using the sample LDAP group names above:
Make EMBIPADMINISTRATOR a member of EMBIPAUTHOR

Make EMBIPADMINISTRATOR a member of EMBIPSCHEDULER

Make EMBIPAUTHOR a member of EMBIPVIEWER

Note:
In LDAP, the terminology and concepts can seem backwards and confusing. For example, you want the EMBIPAUTHORS group to have as a member the EMBIPADMINISTRATORS group.

Then, in order to grant access to BI Publisher and its catalog objects, the administrator of the LDAP server needs to make respective LDAP users a members of one or more of the above LDAP groups.

Mapping LDAP Groups to BI Publisher OPSS Application Roles

In order to map the four LDAP groups to the OPSS application roles described above, the LDAP groups need to be mapped using wlst.sh.

Note:
If you have just upgraded to BI Publisher 11.1.1.6.0 on Enterprise Manager 12c Release 2 (12.1.0.2) from a prior installation of BI Publisher 11.1.5.0 on Enterprise Manager 12c Release 1 (12.1.0.1), and the names of your LDAP groups have not changed, this step is not necessary, as the prior OPSS application grants are carried over to the new installation.

For example, using the LDAP groups above (case is very important):

$MW_HOME/oracle_common/common/bin/wlst.sh [linux]
wlst.cmd [windows]
...
...
Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect('weblogic','<pw>','t3s://host:port')
...
...
Successfully connected to Admin Server 'EMGC_ADMINSERVER' that belongs to domain 'GCDomain'.

wls:/GCDomain/serverConfig> grantAppRole(appStripe="obi",appRoleName="EMBIPViewer",principalClass="weblogic.security.principal.WLSGroupImpl",principalName="EMBIPVIEWER")
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

wls:/GCDomain/serverConfig> grantAppRole(appStripe="obi",appRoleName="EMBIPAuthor",principalClass="weblogic.security.principal.WLSGroupImpl",principalName="EMBIPAUTHOR")
Already in Domain Runtime Tree

wls:/GCDomain/serverConfig> grantAppRole(appStripe="obi",appRoleName="EMBIPScheduler",principalClass="weblogic.security.principal.WLSGroupImpl",principalName="EMBIPSCHEDULER")
Already in Domain Runtime Tree

wls:/GCDomain/serverConfig> grantAppRole(appStripe="obi",appRoleName="EMBIPAdministrator",principalClass="weblogic.security.principal.WLSGroupImpl",principalName="EMBIPADMINISTRATOR")
Already in Domain Runtime Tree

wls:/GCDomain/serverConfig> exit()

Configuring BI Publisher with a Custom Trust Store

If you reconfigure your WebLogic Administration to use a custom trust store, then you must also configure BI Publisher accordingly. This also requires the trust store for the OMS to contain the certificate for the BI Publisher-managed server.

In order to use a trusted certificate from a signing authority, create a Java Key Store (JKS) containing the user certificate of BI Publisher server.

Note:
If you use an e-mail server with SSL, you will need to add the e-mail server's certificate to your trust store as well.

BI Publisher Administration

Please refer to the BI Publisher documentation for instructions on configuring BI Publisher settings.

Common administrative tasks:

- Configuring server properties, such as e-mail servers.

- Configuring report delivery channels, such as FTP.

Post-Upgrade Steps to take after upgrading to BI Publisher to 11.1.1.6.0

When performing an upgrade (using the configureBIP -upgrade command) from Enterprise Manager 12c Cloud Control Release 1 (12.1.0.1) that contains an installed BI Publisher 11.1.1.5.0, to Enterprise Manager 12c Cloud Control Release 2 (12.1.0.2), containing BI Publisher 11.1.1.6.0, you need to perform post-upgrade steps. This is required due to the removal of the underscores on all Enterprise Manager-supplied BI Publisher Catalog objects.

1. Any schedules associated with the following eight reports must be stopped [note the underscores]
EM_Sample_Reports

Targets_of_Specified_Type

[Chargeback]

Charge_Summary_Report

Charge_Trend_Report

Usage_Summary_Report

Usage_Trend_Report

[Consolidation_Planner]

Consolidation_Reports

[Events reports]

Escalated_Incidents_Report

Incident_History_Report

Top_Events_Report

2. The following datamodels [note the underscores] should be deleted from the EM_Datamodels folder:
Charge_Summary_Report

Charge_Trend_Report

Consolidation_Reports

Escalated_Incidents_Report

Incident_History_Report

Target_of_Specified_Type

Top_Events_Report

Usage_Summary_Report

Usage_Trend_Report

3. Delete these folders:
EM_Sample_Reports

Consolidation_Planner

4. The following reports must be deleted from their respective folders:
[Chargeback]

Charge_summary_report

Charge_trend_report

Usage_summary_report

Usage_trend_report

[Events]

Escalated_Incidents_Report

Incident_History_Report

Top_Events_Report

Any desired schedules from above that were stopped need to be restarted on the new report names without underscores.

EMBIP* Roles: Granting Access to Folders and Catalog Objects

By default, the shipping security model (as described in Authenticating and limiting access BI Publisher features, applies to BI Publisher catalog objects that are inside the "Enterprise Manager Cloud Control" folder. This is due to the fact that the catalog objects that exist in this folder are set up with a default set of permissions. See BI Publisher Permissions. BI Publisher catalog objects that are outside of this folder will not automatically contain these same permissions. For example, BI Publisher ships with numerous reports in a shared folder called "Samples". If it is desired to grant access to this folder to Enterprise Manager/BI Publisher users, other than EMBIPAdministrator, it is necessary for a BI Publisher super administrator (EMBIPAdministrator) to change the permissions of this folder. They do so by selecting the folder "Samples" and choosing "Permissions" in the bottom left task bar. They then need to add the four privileges (EMBIPAdministrator, EMBIPViewer, EMBIPAuthor, EMBIPScheduler) and grant appropriate access to that privilege such as VIEW report, run report online, to EMBIPViewer. The administrator can model the appropriate privileges to grant based on any of the shipping Enterprise Manager reports (for example, Targets of Specified Type).

Individual users, who have the EMBIPAuthor OPSS application role, can develop reports in their own private folders. These reports will not be available to other users.

Note:
The shared folder "Enterprise Manager Cloud Control" contains Enterprise Manager-provided BI Publisher Reports and is reserved for such. No custom-developed reports may be added to this folder hierarchy. The default security model that ships with Enterprise Manager specifically prohibits this.

Note:
Only reports in the "Enterprise Manager Cloud Control" folder will show up in the Enterprise Manager BI Publisher Enterprise Reports menu (From the Enterprise menu, select Reports, and then BI Publisher Enterprise Reports).

If a BI Publisher administrator (EMBIPAdministrator) wishes to create a new shared folder outside of the "Enterprise Manager Cloud Control" folder, they can do so. These reports would not show up in the Enterprise Manager BI Publisher reports menu but would be available to other Enterprise Manager administrators as long as appropriate permissions are granted as previously described.

Access to Enterprise Manager Repository

All BI Publisher reports are granted read-only access to the Enterprise Manager Repository. This access is via the BI Publisher data source named EMREPOS. This access is via the Enterprise Manager user MGMT_VIEW, which is a special internal Enterprise Manager user who has read-only access to the Enterprise Manager Published MGMT$ database views. In addition, when reports are run, they are further restricted to the target-level security of the user running the report. For example, if user JOE has target-level access to "hostabc" and "database3", when user JOE runs a BI Publisher report (any report) he can only view target-level data associated with these two targets.

Troubleshooting

The following sections provide common strategies that can be used if problems occur with the Enterprise Manager/BI Publisher integration.

Rerunning configureBIP

It is sometimes necessary to rerun configureBIP if certain error conditions occur. Before attempting to re-run configureBIP, be sure to use the WebLogic console to shutdown the existing BI Publisher managed server.

BI Publisher Log File Locations

The following log files can be used to trace problems to their point of origin.

configureBIP Log Files

Location: ORACLE_HOME(oms)/cfgtoollogs/bip/*

- Creating/upgrading the BI Publisher schema in the database

- "emBIPLATFORM.log

- "emBIPLATFORMcreate_<date>.log

- "biplatform.log

- "emBIPLATFORMcreate.err

- Extending the Enterprise Manager domain with BI Publisher

- "bipca_<date>.log

Enterprise Manager BI Publisher Tree and EM CLI Log File Output

emoms.trc

emoms.log

Messages specific to the BI Publisher integration can be found by searching for "BIP" (all caps) in the log files.

BI Publisher Runtime

Location: Domain home. For example, gc_inst/user_projects/domains/GCDomain

- servers/BIP/logs/*

- servers/BIP/logs/bipublisher.log

Additional Troubleshooting

If BI Publisher is able to run successfully, but BI Publisher registration with Enterprise Manager fails, you can retry the registration by running:

emcli login -username=<admin username> -password=<admin password>
emcli sync
emcli setup_bipublisher -proto=http[s] -host=<bip_host> -port=<bip_port>
-uri=xmlpserver

Redeploying All Enterprise Manager-Supplied BI Publisher Reports

If a plug-in is installed subsequent to BI Publisher being installed and configured to work with Enterprise Manager, the BI Publisher reports that are part of the plug-in can be deployed from the Enterprise Manager installation to BI Publisher using the following commands:

emcli login –username=sysman
Password: <pw>
emcli sync
emcli deploy_bipublisher_reports –force

This procedure can also be used to restore reports on BI Publisher if they become damaged.

Managing Enterprise Manager - BI Publisher Connection Credentials

Accessing BI Publisher from Enterprise Manager requires a direct connection between the two products in order to retrieve, display, and manage report definitions. Example: From the Enterprise menu, choose Reports and then BI Publisher Enterprise Reports. A tree view displaying BI Publisher reports within the Enterprise Manager Cloud Control shared folder appears as shown in the following graphic.

The first time you run the configureBIP script to configure BI Publisher to integrate with Enterprise Manager, a dedicated WebLogic user is automatically created with the requisite credentials solely for the purpose of installation/configuration. Beginning with Enterprise Manager 12c Cloud Control release 12.1.0.1, you can configure these credentials using the EMCTL command config oms.

Verb Syntax

emctl config oms -store_embipws_creds [-admin_pwd <weblogic_pwd>] [-embipws_user <new_embipws_username>] [-embipws_pwd <new_embipws_pwd>]

The config oms command allows you to change the password, and optionally the username, used by Enterprise Manager to access the installed BI Publisher Web Server. Running the config oms command requires the WebLogic Admin user's password.

Note 1: The config oms command only changes the user credentials required for the Enterprise Manager - BI Publisher connection. The Enterprise Manager - BI Publisher connection credentials should match the credentials used elsewhere by the user. Example: Enterprise Manager users (database authentication), LDAP users, and WebLogic Server users. Use the corresponding application/console to create or manage the user within the installed credential store.

Note 2: This command is operational only if BI Publisher has been installed.

Note 3: It is not necessary to restart any managed server, such as EMGC_OMSnnnn or BIPnnnn.

Any valid credential that WebLogic supports is acceptable as long as that user also has the EMBIPAdministrators privilege (either in OPSS or LDAP, as appropriate).

Example: You have configured Enterprise Manager to use single sign-on (SSO) (backed by an LDAP credential store). The following steps illustrate the credential update process:

1. Create the LDAP user. Example: Create EM_BIP_INTERNAL_USER and assign this LDAP user a password such as XYZ123.

2. Make EM_BIP_INTERNAL_USER a member of the EMBIPADMINISTRATORS LDAP group. For more information about LDAP groups and Enterprise Manager-BI Publisher integration, see Allowing Access to BI Publisher for Enterprise Manager Administrators in an underlying LDAP Authentication security model environment.

3. Execute the EMCTL config oms command:

emctl config oms -store_embipws_creds -embipws_user EM_BIP_INTERNAL_USER
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
Enter Admin User's Password: <pw>
Enter new password that Enterprise Manager will use to connect to BI Publisher: XYZ123
Successfully updated credentials used by Enterprise Manager to connect to BI Publisher.

If you later change the EM_BIP_INTERNAL_USER password in the LDAP server, you can change the LDAP user's password by executing the config oms command with the -store_embipws_creds option. In the following example, the password is changed to ABC123.

emctl config oms -store_embipws_creds
Oracle Enterprise Manager Cloud Control 12c Release 2
Copyright (c) 1996, 2012 Oracle Corporation.  All rights reserved.
Enter Admin User's Password: <pw>
Enter new password that Enterprise Manager will use to connect to BI Publisher : ABC123
Successfully updated credentials used by Enterprise Manager to connect to BI Publisher.

Managing the BI Publisher Server

BI Publisher operates as a separate, managed server in the same WebLogic domain that contains the OMS(s) and the AdminServer.

In order to shut down the BI Publisher managed server, do the following:

1. Log in to the AdminServer console as the WebLogic user with the correct password.

2. Click Servers.

3. Click the Control tab underneath the text Summary of Servers.

4. Place a check-mark next to the managed server BIP.

5. Double-check to make sure the check mark is next to the BI Publisher managed server, as opposed to EMGS_OMS1 or EMGC_ADMINSERVER managed servers.

6. Click Shutdown and choose when work completes.

7. Wait until BI Publisher has shut down. You can monitor the status of this operation by clicking on the refresh icon (the two arrows in a circle) above the text Customize this Table.

To start the BI Publisher managed server, do the following:

1. Navigate to the control page using steps 1-4 above.

2. Place a check mark next to the managed server BIP.

3. Double-check to make sure the check mark is next to the BI Publisher managed server and not the EMGS_OMS1x or EMGC_ADMINSERVER managed servers.

4. Click Start.

5. Wait until BI Publisher has started. You can monitor the status of this operation by clicking on the refresh icon (the two arrows in a circle) above the text Customize this Table.

Configuring BI Publisher behind a Load-Balancer

If BI Publisher is to be run behind a load-balancer, as detailed in the Oracle® Enterprise Manager Cloud Control Administrator's Guide, issue the following commands after all configuration is complete:

emcli login -username=sysman
Password: <sysman_password>
emcli setup_bipublisher -proto=https -host=<load_balancer_host> -port=<load balancer port> -uri=xmlpserver -force -nodeploy

Part VI

Deinstallation

In particular, this part contains the following chapters:

- Chapter 15, "Deinstalling Enterprise Manager Cloud Control"

- Chapter 16, "Deinstalling Oracle Management Agent"

- Chapter 17, "Deinstalling ADP and JVMD"

15 Deinstalling Enterprise Manager Cloud Control

This chapter describes how you can deinstall Enterprise Manager Cloud Control (the entire Enterprise Manager system, or one or more Oracle Management Services). In particular, this chapter covers the following:

- Prerequisites

- Deinstallation Procedure

- After You Deinstall

Prerequisites

Before you deinstall Enterprise Manager Cloud Control, follow these steps:

1. Deconfigure and delete Oracle Management Service (OMS):
$<OMS_HOME>/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.

2. Shut down Oracle Management Agent (Management Agent) by running the following command from the Management Agent home:
$<AGENT_HOME>/bin/emctl stop agent

3. If you want to deinstall the entire Enterprise Manager system, including Oracle Management Repository (Management Repository) that is configured in your database, then follow these steps:

1. Ensure that there are no SYSMAN users logged in.

2. Drop the Enterprise Manager Cloud Control schema (SYSMAN schema) and the Metadata schema (MDS schema) from the Management Repository by running the following command from the OMS home:
$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -reposName <repository_name> -mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <OMS_HOME>

Note:

- For Microsoft Windows, invoke RepManager.bat.

- RepManager 12c and 11.1 support -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN). However, RepManager 10.2.0.5 supports -action drop (drops only SYSMAN).

- The action dropall might not drop all the repository objects. For learn more about this issue and the workaround to be used, see My Oracle Support note 1365820.1.

- If you want to drop the Enterprise Manager schema completely, then use the RepManager available in the OMS home. Do not use the one in database home because it cannot remove the Enterprise Manager schema completely.

3. Manually delete the data files mgmt.dbf and mgmt_ecm_depot1.dbf from the database home.

WARNING:

Once the Management Repository is dropped, it CANNOT be retrieved. Therefore, drop the Management Repository ONLY IF you want to deinstall the entire Enterprise Manager Cloud Control system, that is, all your OMS instances, Management Agents, and also the Management Repository. If you want to deinstall only an OMS (additional OMS installation), then do not drop the Management Repository.

Deinstallation Procedure

This section describes the following:

- Deinstalling in Graphical Mode

- Deinstalling in Silent Mode

Deinstalling in Graphical Mode

To deinstall Enterprise Manager Cloud Control in graphical mode, follow these steps:

Note:
Deinstall the components in the order described in this procedure. Otherwise, the installation wizard displays an error.

1. Invoke the installer from the OMS home by running the following command:
$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall ORACLE_HOME=<absolute_path_to_oms_home> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- You can invoke the installer even from the directory where you downloaded the software. For example, <software_location>/.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- When you run runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

Note:
When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have read and write access to the /stage subdirectory, which a subdirectory in the Disk1 directory of the Enterprise Manager software.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have read and write permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have read and write access to the /stage directory. If you do not have, then set the TEMP variable to a location where the install user has access to, and then relaunch the installation wizard.

2. On the Inventory screen, select the plug-in homes, and click Remove.

3. On the Inventory screen, select the sbin home, and click Remove.

4. On the Inventory screen, select the Java Development Kit (JDK) home, and click Remove.

Note:
Deinstall JDK only if it was installed by the installation wizard while installing the Enterprise Manager system. Otherwise, you can skip this step.

Note:
After deinstalling JDK, do NOT exit the installer. If you exit the installer inadvertently, then follow these steps:

1. Manually download and install JDK 1.6 v24+ on the OMS host. If you already have this supported version, then you can reuse it.

2. Invoke the installer again and pass the absolute path to the location where you have JDK:
$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -jreLoc <JDK_HOME> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

5. On the Inventory screen, select the Oracle WebTier home, and click Remove.

6. On the Inventory screen, select the following, and click Remove.

- OMS home

- Management Agent home

- Oracle Common directory

7. On the Inventory screen, click Close to exit the wizard.

8. Manually delete the middleware home:
For UNIX platforms:

rm -rf <absolute_path_to_middleware_home>

For Microsoft Windows platforms:

del <absolute_path_to_middleware_home>

Note:
If you see an error stating that the middleware home could not be deleted because of a long path, then shorten the middleware home name in one of the following ways:

- Rename the middleware home to a short name.
For example, change C:\Oracle\Middleware to C:\OR\MW.

- Mount a drive to the middleware home path.
For example, if C:\Oracle\Middleware\oms\bin is the directory that is causing an issue, then shorten the path in such a way that path length decreases to a reasonable extent (the file path limits differ from one operating system to another).

Mount C:\Oracle\Middleware\oms to drive Z.

- Navigate to drive Z, and deleted the files:
prompt>Z:

prompt>del bin

- Navigate to the middleware home, and delete the leftover files:
prompt:>C:

prompt>del C:\Oracle\Middleware\

Deinstalling in Silent Mode

To deinstall Enterprise Manager Cloud Control in silent mode, follow these steps:

Note:
Deinstall the components in the order described in this procedure. Otherwise, the installation wizard displays an error.

1. Deinstall Oracle WebLogic Server 11g Release 1 (10.3.5) following the instructions outlined in the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server. See the chapter that describes how you can deinstall the software.
The Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server is available in the Oracle WebLogic Server documentation library available at:

http://www.oracle.com/technetwork/indexes/documentation/index.html

Note:
Deinstall Oracle WebLogic Server 11g Release 1 (10.3.5) only if it was installed by the installation wizard while installing the Enterprise Manager system.

2. Deinstall the plug-in homes:
$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={absolute_path_to_plug-in_home}" ORACLE_HOME=<absolute_path_to_oms_home> [-removeallfiles -invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- You can invoke the installer even from the directory where you downloaded the software. For example, <software_location>/.
If you invoke the installer from here, then do NOT pass -removeallfiles.

- When you run runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

- To deinstall multiple plug-ins, enter the plug-in homes separated by a comma.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

For example,

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/agent/plugins/oracle.sysman.ssa.oms.plugin_12.1.0.2.0,/home/oracle/middleware/agent/plugins/oracle.sysman.emas.oms.plugin_12.1.0.2.0}" ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

3. Deinstall the sbin home:
$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={absolute_path_to_sbin_home}" ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

For example,

$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/agent/sbin}" ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

4. Deinstall the Java Development Kit (JDK) home:
$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstallrunInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={absolute_path_to_jdk_home}" ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

For example,

$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/jdk16}" ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

Note:
Deinstall JDK only if it was installed by the installation wizard while installing the Enterprise Manager system. Otherwise, you can skip this step.

5. Manually download and install JDK 1.6 v24+ on the OMS host. If you already have this supported version, then you can reuse it.
You must reinstall JDK because the installer has a dependency on it. The new JDK can be installed anywhere on the OMS host, not necessarily in the same location where it existed before. However, ensure that you pass the -jreLoc parameter (as described in the following steps) while invoking the installer to indicate the location where you have installed the JDK.

6. Deinstall the Oracle WebTier home:
$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={absolute_path_to_web_tier}" -jreLoc <JDK_HOME> ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

For example,

$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/Oracle_WT}" -jreLoc </home/oracle/jdk> ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

7. Deinstall the OMS, the Management Agent, and the Oracle Common directory:
$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={absolute_path_to_oracle_homes_and_directories_to_be_deinstalled}" -jreLoc <JDK_HOME> ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:
The argument REMOVE_HOMES accepts more than one path separated by a comma.

For example,

$<OMS_HOME>/oui/bin/runInstaller -jreLoc <path> -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/oms,/home/oracle/middleware/agent/core/12.1.0.2.0,/home/oracle/middleware/oracle_common}" -jreLoc </home/oracle/jdk> ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

8. Manually delete the middleware home:
For UNIX platforms:

rm -rf <absolute_path_to_middleware_home>

For Microsoft Windows platforms:

del <absolute_path_to_middleware_home>

After You Deinstall

The Oracle homes you deinstalled are deregistered from the central inventory. However, some files might still remain in these Oracle homes. You might also see the OMS instance base directory and the Oracle home for Web Tier. You can manually delete these files and directories.

You must also manually delete the auto-start script titled S98gcstartup. To do so, navigate to the /etc/rc.d/ directory, and search for the auto-start script S98gcstartup. This script is usually present in a subdirectory within the /etc/rc.d/ directory. Navigate to the subdirectory where the script is found and delete the script. For example, /etc/rc.d/rc3.d/S98gcstartup.

16 Deinstalling Oracle Management Agent

This chapter describes how you can deinstall Oracle Management Agent (Management Agent). In particular, this chapter covers the following:

- Prerequisites

- Deinstallation Procedure

- After You Deinstall

Note:
On a cluster, ensure that you deinstall the Management Agents from all the nodes one by one. To do so, follow the instructions outlined in this chapter.

Prerequisites

Before you deinstall a Management Agent, do the following:

1. Shut it down by running the following command from the Management Agent home:
$<AGENT_HOME>/bin/emctl stop agent

2. Wait for the Management Agent to go to the unreachable state in the Cloud Control console.

3. Delete the Management Agent targets and their monitored targets (from any host where EM CLI is installed):
emcli delete_target

-name="example.com:1836"

-type="oracle_emd"

-delete_monitored_targets

Note:
For information on EM CLI and instructions to set it up, see Oracle Enterprise Manager Command Line Interface Guide.

Deinstallation Procedure

This section describes the following:

- Deinstalling Oracle Management Agent in Graphical Mode

- Deinstalling Oracle Management Agent in Silent Mode

- Deinstalling Shared Agent

- Deinstalling Oracle Management Agent Installed Using an RPM File

Deinstalling Oracle Management Agent in Graphical Mode

To deinstall a Management Agent in graphical mode, follow these steps:

Note:
Deinstall the components in the order described in this procedure. Otherwise, the installation wizard displays an error.

1. Invoke the installer from the Management Agent home by running the following command:
$<AGENT_HOME>/oui/bin/runInstaller -deinstall ORACLE_HOME=<absolute_path_to_agent_home> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- You can invoke the installer even from the directory where you downloaded the software. For example, <software_location>/.

- When you run runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- For Microsoft Windows, invoke the setup.exe file.

Note:
When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not access to the /stage directory.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have the permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have access to the /stage directory. If you do not have access to it, then set the TEMP variable to a location where the install user has access to, and then relaunch the installation wizard.

2. In the installation wizard, click Installed Products.

3. On the Inventory screen, select the plug-in homes, and click Remove.

4. On the Inventory screen, select the sbin home, and click Remove.

5. On the Inventory screen, select the Management Agent, and click Remove.

6. Manually delete the agent base directory. For information on installation base directory, see What Is Agent Base Directory?.
For UNIX platforms:

rm -rf <absolute_path_to_agent_base_dir>

For Microsoft Windows platforms:

del <absolute_path_to_agent_base_dir>

Deinstalling Oracle Management Agent in Silent Mode

This section describes the following methods to deinstall the Management Agent in silent mode:

- Deinstaling in Slient Mode Using the Installer

- Deinstalling in Silent Mode Using AgentDeinstall.pl Script

Deinstaling in Slient Mode Using the Installer

To deinstall a Management Agent in silent mode using the installer, follow these steps:

Note:
Deinstall the components in the order described in this procedure. Otherwise, the installation wizard displays an error.

1. Deinstall the plug-in homes:
$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_plug-in_home}" ORACLE_HOME=<absolute_path_to_agent_home> [-removeallfiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- When you run runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

- On Microsoft Windows, invoke the setup.exe file.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- To deinstall multiple plug-ins, enter the plug-in homes separated by a comma.

For example,

$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/agent/plugins/oracle.sysman.emas.oms.plugin_12.1.0.2.0,/home/oracle/agent/plugins/oracle.sysman.emct.oms.plugin_12.1.0.2.0}" ORACLE_HOME=/home/oracle/middleware/agent/core/12.1.0.2.0 -removeAllFiles -invPtrLoc $<AGENT_HOME>/oraInst.loc

2. Deinstall the sbin home:
$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_sbin_directory}" ORACLE_HOME=<absolute_path_to_agent_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

For example,

$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/agent/sbin}" ORACLE_HOME=/home/oracle/middleware/agent/core/12.1.0.2.0 -removeAllFiles -invPtrLoc $<AGENT_HOME>/oraInst.loc

3. Deinstall the Management Agent:
$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_agent_oracle_home}" ORACLE_HOME=<absolute_path_to_agent_home> -removeAllFiles -invPtrLoc <absolute_path_to_oraInst.loc>

For example,

$<AGENT_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/agent/core/12.1.0.2.0}" ORACLE_HOME=/home/oracle/middleware/agent/core/12.1.0.2.0 -removeAllFiles -invPtrLoc $<AGENT_HOME>/oraInst.loc

4. Manually delete the agent base directory. For information on agent base directory, see What Is Agent Base Directory?.
For UNIX platforms:

rm -rf <absolute_path_to_install_base_dir>

For Microsoft Windows platforms:

del <absolute_path_to_install_base_dir>

Deinstalling in Silent Mode Using AgentDeinstall.pl Script

To deinstall a Management Agent in silent mode using the AgentDeinstall.pl script, follow these steps:

1. Invoke the AgentDeinstall.pl script:
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/AgentDeinstall.pl -agentHome <AGENT_HOME>

For example,

$/u01/app/Oracle/core/12.1.0.2.0/perl/bin/perl /u01/app/Oracle/core/12.1.0.2.0/sysman/install/AgentDeinstall.pl -agentHome /u01/app/Oracle/core/12.1.0.2.0/

2. Manually remove the targets, which were being monitored by the Management Agent you deinstalled, from the Enterprise Manager Cloud Control console.

3. Manually delete the agent base directory. For information on agent base directory, see What Is Agent Base Directory?.
For UNIX platforms:

rm -rf <absolute_path_to_install_base_dir>

For Microsoft Windows platforms:

del <absolute_path_to_install_base_dir>

Deinstalling Shared Agent

To deinstall a Shared Agent, run the following command from the Master Agent home that is visible on the host where your Shared Agent is installed:

$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=<absolute_path_to_agent_instance_home> ORACLE_HOME=<absolute_path_to_agent_home>

For example,

/home/john/software/oracle/agent/core/12.1.0.2.0/perl/bin/perl /home/john/software/oracle/agent/core/12.1.0.2.0/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=/home/john/software/oracle/agent/agent_inst ORACLE_HOME=/home/john/software/oracle/agent/core/12.1.0.2.0

Note:
If you encounter an error while deinstalling the Shared Agent, then refer to Troubleshooting Deinstallation Failures.

Deinstalling Oracle Management Agent Installed Using an RPM File

To deinstall a Management Agent that was installed using a .rpm file, run the following command as a root user:

rpm -e <rpm_name>

Note:
As a prerequisite, ensure that you have Resource Package Manager (RPM) installed on the host.

After You Deinstall

After you deinstall the Management Agent, follow these steps:

1. (Only for Graphical Mode) Verify whether the Oracle homes and other directories were successfully deinstalled. To do so, follow these steps:

1. Invoke the installation wizard by running the following command from the Management Agent home:
<DVD>/runInstaller

Note:
On Microsoft Windows, invoke the setup.exe file.

2. In the installation wizard, on the My Oracle Support Details screen, click Installed Products.

3. On the Inventory screen, check whether or not the Oracle homes and other directories you deinstalled appear. If the deinstallation was successful, then those Oracle homes and directories should not appear.

2. The Oracle homes you deinstalled are deregistered from the central inventory. However, some files might still remain in these Oracle homes. If they do, you can manually delete them.
You must also manually delete the auto-startup script called gcstartup which will be present under /etc/init.d directory.

Note:
These auto-start scripts are not available on Microsoft Windows.

3. If you deinstalled on a Microsoft Windows platform, then follow these steps. Ensure that you are logged in as a user with Administrator privileges on that host.
Remove Entries from Microsoft Windows Registry

1. Start the registry editor by selecting Start and then Run. Type regedit and click OK.

2. In the Registry Editor window, in the left pane, expand HKEY_LOCAL_MACHINE, SOFTWARE, and then Oracle. Under the Oracle directory, delete the following:
(a) KEY_agent12gn

(b) KEY_sbin12gn

Note:
Here, n refers to a numeral indicating the agent instance. For example, KEY_sbin12g9 for the first agent installation.

3. Expand HKEY_LOCAL_MACHINE, SOFTWARE, Oracle, and then Sysman. Under the Sysman directory, delete the Management Agent service. For example, Oracleagent12g9Agent.

4. Expand HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, and then Services. Under the Services directory, delete the Management Agent keys.

5. Expand HKEY_LOCAL_MACHINE, SYSTEM, ControlSet002, and then Services. Under the Services directory, delete the Management Agent service.

6. Close the registry editor.

Clean Up Environment Settings

1. Open the Environment Variables window.
On Microsoft Windows NT, select Start, Settings, Control Panel, System, and then Environment.

On Microsoft Windows XP or 2000, select select Start, Settings, Control Panel, System, Advanced, and then Environment Variables.

2. In the System Variables section, click the variable PATH and modify the value.

3. Delete Management Agent home.

4. Click Apply and then click OK.

5. Close the Control Panel window.

6. Restart the host.

17 Deinstalling ADP and JVMD

This chapter describes how you can deinstall Application Dependency and Performance (ADP), and JVM Diagnotics (JVMD) in the Enterprise Manager Cloud Control environment.

In particular, this chapter covers the following:

- Deinstallation Procedure for ADP

- Deinstallation Procedure for JVMD

Deinstallation Procedure for ADP

The section contains the following topics:

- Deinstalling ADP Manager

- Deinstalling ADP Agents

Deinstalling ADP Manager

To remove the ADP Manager application running on the Managed Server, perform the following steps:

1. In Cloud Control, from the Targets menu, select Middleware.

2. On the Middleware page, from Middleware Features menu, select Application dependency and Performance.
The Application dependency and Performance is displayed.

3. From the Registration tab, select the ADP manager application, and click Remove.

4. Log in to WebLogic Administration Console of Enterprise Manager Domain.

5. On the Home Page, click Servers.

6. From the Summary of Servers page, click Control tab, then select the ADP Manager Servers.

7. From the Shutdown menu, select Force Shutdown Now to stop the servers.

8. Click the Configuration tab, select ADP Manager Servers, then click Delete.

9. Undeploy the ADP applications. For example, ADPManager_EMGC_ADPMANAGER1 for ADP.

10. Connect to the host machine where the Managed Server was present, and navigate to the following location to manually delete the Managed Server:

$DOMAIN_HOME/<ADP_managed_server>

Where, $DOMAIN_HOME is the location of the Cloud Control domain

Deinstalling ADP Agents

To remove the agents which are deployed to the ADP Manager, perform the following steps:

1. In Cloud Control, from Targets menu, select Middleware.

2. On the Middleware page, from Middleware Features menu, select Application dependency and Performance.
The Application dependency and Performance is displayed.

3. From the Configuration tab, select the desired ADP Manager application on which the agent(s) have been deployed.

4. Expand the ADP Manager menu, select Resource Configuration.

5. From the Resource table, select the agent name, and click Edit Resource, and then click Deploy.

6. From the Deploy Parameters table, select the servers to undeploy the agent. Change the default menu select from Deploy to:

- Remove, to erase all the agent files from the application servers.

- Disable, to remove the agent startup arguments from the application servers

Note:
Select the Server Started by Node Manager option only when the node manager is used.

Deinstallation Procedure for JVMD

This section contains the following:

- Deinstalling JVMD Managers

- Deinstalling JVMD Agents

Deinstalling JVMD Managers

To remove the JVMD Manager application running on the Managed Server, perform the following steps:

1. Log in to WebLogic Administration console.

2. On the Home Page, click Deployments.

3. Select the JVMD application (jammanagerEMGC_JVMDMANAGER1), from Stop menu, select Force Stop Now.

4. After they are stopped, select the same applications, and click Delete.

5. Click Home to go back to the WebLogic Administration home page. From the Environment table, select Servers.

6. From the Summary of Servers page, click Control tab, then select the JVMD Manager Servers that need to be shut down.

7. From the Shutdown menu, select Force Shutdown Now to stop the servers.

8. Click the Configuration tab, select JVMD Manager Servers, then click Delete.

Deinstalling JVMD Agents

To remove the agents which are deployed to the JVMD Manager, perform the following steps:

1. Log in to the Domain Administration Console of the target server.

2. On the Home Page, click Deployments.

3. Select the JVMD Agent application (javadiagnosticagent<server_name>.ear or jamagent.ear), from Stop menu, select Force Stop Now.

4. After they are stopped, select the same applications, and click Delete.

5. Log in to Enterprise Manager Cloud Control.

6. In Cloud Control, from Targets menu, click Middleware.

7. On the Middleware page, in the Search table, search for targets of type Java Virtual Machine, select the target corresponding to the server, and click Remove.

Part VII

Appendixes

This part contains the following appendixes:

- Appendix A, "Understanding the Enterprise Manager Directory Structure"

- Appendix B, "Installation and Configuration Log Files"

- Appendix C, "Redirecting Oracle Management Agent to Another Oracle Management Service"

- Appendix D, "Using RepManager Utility"

- Appendix E, "Collecting OCM Data Using Oracle Harvester"

- Appendix F, "Enabling Enterprise Manager Accessibility Features"

- Appendix G, "Troubleshooting"

A Understanding the Enterprise Manager Directory Structure

Before you perform maintenance and advanced configuration tasks, you must be familiar with the directories and files that are copied to disk when you install Enterprise Manager. Understanding where specific files are located can help you if you need to troubleshoot installation or configuration problems.

When installing Enterprise Manager, if you select a location that does not contain WebLogic Server, then JDK will be installed in the jdk16 directory before installation of WebLogic Server.

Use the following sections to become familiar with the directories that are created on your disk when you install Enterprise Manager:

- Understanding the Enterprise Manager Directories Installed with Oracle Enterprise Manager Cloud Control 12c

- Understanding the Enterprise Manager Directories Installed with an Oracle Management Service

- Understanding the Enterprise Manager Directories Installed with Management Agent

Understanding the Enterprise Manager Directories Installed with Oracle Enterprise Manager Cloud Control 12c

When you install Oracle Enterprise Manager Cloud Control 12c, you install the Oracle Management Service. With the Oracle Management Service, you install the following Oracle home directories:

- Oracle Management Service home directory

- Middleware WebTier home directory

- Middleware Common home directory

- Oracle Management Service Instance home directory

- Oracle Management Agent home directory

- Oracle Management Service Plugins home

- Oracle Management Agent Plugin home

- Oracle Business Intelligence Publisher home (Optional)

About the Oracle Management Service Home Directory

The Oracle Management Service is a J2EE application that is installed and deployed using the Oracle WebLogic Server.

The installation procedure installs the Enterprise Manager components within the Cloud Control Home, including the Oracle Management Service.

Information about the directories that are specific to the Fusion Middleware installation can be found in the Fusion Middleware documentation.

About the Oracle Management Agent Home (AGENT_HOME) Directory

The Oracle Management Service is a J2EE application that is installed and deployed using the Oracle WebLogic Server.

The installation procedure installs the Enterprise Manager components within the Cloud Control Home, including the Oracle Management Service. For more details about the OMS directories, see About the Oracle Management Service Home Directory.

Information about the directories that are specific to the Fusion Middleware installation can be found in the Fusion Middleware documentation.

About Business Intelligence Publisher Home Directory

The Business Intelligence Publisher is a J2EE application that is installed and configured as described in Chapter 14.

Summary of the Important Directories in the Oracle Management Service Home

Figure A-1 shows some of the important directories you should be familiar with in a typical Cloud Control installation. You can use this information as you begin to maintain, troubleshoot, and configure the Oracle Management Service installation.

Figure A-1

Table A-1 Directories Installed with Enterprise Manager

Directory

Description

wlserver_10.3, logs, utils, modules

These directories contain Fusion Middleware files.

jdk16

This directory contains JDK configuration files.

oms

This directory contains OMS configuration files. For more information, see Section 10.2.2.

plugins

This directory contains metadata plug-ins configuration files installed on the OMS.

agent

This directory contains agent configuration files. For more details, see Section 10.2.3.

[optional] Oracle_BI1

This directory contains the Oracle Business Intelligence Publisher configuration files.

oracle_WT

This directory contains Oracle WebTier configuration files.

oracle_common

This directory contains common files used by OMS, Oracle WebTier, and WebLogic Server directories.

Understanding the Enterprise Manager Directories Installed with Management Service

Table A-2 describes in detail the Oracle Management Service directories installed with Oracle Management Service. In the table, ORACLE_HOME refers to the Oracle Management Service home directory in which the Oracle Management Service is installed and deployed.

Table A-2 Important Directories in the Management Service Oracle Home

Directory

Description

ORACLE_HOME/bin

The bin directory in the Management Service home contains commands used to control the components of the Cloud Control installation.

OMS_INSTANCE_HOME

This directory contains configuration files for OMS home. The default OMS_INSTANCE_HOME location is gc_inst.

OMS_INSTANCE_HOME/WebTierIH1

This directory contains WebTier instance Oracle Home corresponding to EMGC_OMS#.

OMS_INSTANCE_HOME/NodeManager

This directory contains WebLogic Node Manager properties, logs, and domain information.

OMS_INSTANCE_HOME/em

This is the OMS instance directory and contains emgc.properties and Enterprise Manager log files.

OMS_INSTANCE_HOME/user_projects

This directory contains EMGC_ADMINSERVER and EMGC_OMS# domains and their logs.

ORACLE_HOME/sysman/log

This directory contains schema log files. The repository log files are under sysman/log/schemamanager. The install logs are under ORACLE_HOME/cfgtoollogs. The operation logs are under OMS_INSTANCE_HOME/em/EMGC_OMS1/sysman/log.

Understanding the Enterprise Manager Directories Installed with Management Agent

The Oracle Management Agent is installed automatically when you install Oracle Management Service. This local instance of the Oracle Management Agent gathers management information about the targets on the Oracle Management Service host. You can then manage those targets, such as the host itself, from the Cloud Control Console.

You can install additional Oracle Management Agents using different installation methods. This enables you to install the Oracle Management Agent on the hosts throughout your enterprise. The Oracle Management Agent can then gather management data about the targets on each host so those targets can be managed from the Cloud Control Console.

Specifically, the Oracle Management Agent files are installed into the same directory structure shown in the agent directory when you install the Oracle Management Service (Figure A-1).

The agent directory structure, when you install a standalone agent or install the OMS is the same. The AGENT_BASE_DIR is the directory where agent is installed and contains the following main directories:

- AGENT_HOME

- AGENT_INSTANCE_HOME

- SBIN_HOME

- PLUGIN_HOME

The directory that contains the files required to run the Oracle Management Agent is referred to as the AGENT_INSTANCE_HOME directory. For example, to start or stop an Oracle Management Agent, you use the emctl command located in the bin directory of the AGENT_INSTANCE_HOME. Similarly, to configure files for the Oracle Management Agent, you modify the configuration files in the sysman/config directory of the AGENT_INSTANCE_HOME. See Figure A-2 for the agent directory structure.

Figure A-2 Agent Directory Structure

Summary of the Important Directories in the Oracle Management Agent Home

Table A-3 describes some of the important agent directories.

Table A-3 Important Directories in Oracle Management Agent Home

Directory

Description

AGENT_HOME

The AGENT_HOME directory contains all the binaries required to configure and run the Oracle Management Agent on this host.

The default AGENT_HOME location is AGENT_BASE_DIR/core/12.1.0.2.0.

This directory serves as the Oracle Home for the Oracle Management Agent.

AGENT_HOME/bin

This directory contains binaries for the Oracle Management Agent.

AGENT_HOME/install

This directory contains installation-related files for deploying the agent.

AGENT_HOME/prereqs

This directory contains prerequisite files for EMPrereqKit.

AENT_HOME/oui

This directory contains files related to the installer framework.

AGENT_HOME/cfgtoollogs

This directory contains agent deployment and configuration log files.

AGENT_HOME/EMStage

This directory is used by the provisioning framework for provisioning activities.

AGENT_HOME/sysman/admin

This directory contains the files used by the Oracle Management Agent to define agent core target types (such as databases, hosts, and so on), to run configuration scripts, and other administrative tasks.

AGENT_INSTANCE_HOME

The AGENT_INSTANCE_HOME directory contains agent-related configuration files after agent is installed and configured.

The default AGENT_INSTANCE_HOME location is AGENT_BASE_DIR/agent_inst.

AGENT_INSTANCE_HOME/bin

The AGENT_INSTANCE_HOME/bin directory in the Cloud Control Home contains the emctl command that controls the Oracle Management Agent for this host.

You use the following emctl commands in this directory to start and stop the Oracle Management Agent on this host:

<AGENT_INSTANCE_HOME>/bin/emctl start agent

<AGENT_INSTANCE_HOME>/bin/emctl stop agent

AGENT_INSTANCE_HOME/sysman/config

This directory contains the configuration files for the Oracle Management Agent. For example, this is where Enterprise Manager stores the emd.properties file. The emd.properties file defines settings such as the Oracle Management Service upload URL for this particular agent.

AGENT_INSTANCE_HOME/sysman/log

This directory contains the log files for the Oracle Management Agent.

AGENT_INSTANCE_HOME/sysman/emd

The emd directory contains information about targets discovered on hosts.

SBIN_HOME

This directory contains set UIDs for the agent. The default location is AGENT_BASE_DIR/sbin.

PLUGIN_HOME

This directory contains all the discovery and monitoring plugins required for the agent.

The default location is AGENT_BASE_DIR/plugins.

Understanding the Oracle Management Agent Directory Structure in Windows

When you install the Oracle Management Agent on a Windows system, the directory structure of the AGENT_HOME directory is the same as the directory structure for installations on a UNIX system.

Identifying the Agent Instance Home When Using the emctl Command

When you install Cloud Control, the resulting directory structure can often include multiple subdirectories with the same name. For example, you can have a bin directory within the agent_instance_home directory. Use the emctl command within the agent_instance_home/bin directory to control the Oracle Management Agent.

In addition, you can have a bin directory within the Oracle Management Service Oracle home. Use the emctl command in this directory to control the Oracle Management Service.

To quickly identify the Agent Instance home that is controlled by the files in a particular bin directory, use the following command:

$PROMPT> emctl getemhome

This command displays the path to the current Agent Instance home that will be affected by commands executed by this instance of the emctl command.

B Installation and Configuration Log Files

This appendix lists the locations of the various log files that are created during the prerequisites check, installation, and configuration phases of Enterprise Manager Cloud Control components.

In particular, this appendix covers the following:

- Enterprise Manager Cloud Control Installation Logs

- Add Host Log Files

Enterprise Manager Cloud Control Installation Logs

This section describes the following log files that are created while installing Enterprise Manager Cloud Control:

- Installation Logs

- Configuration Logs

Installation Logs

The following are the installation logs, which provide complete information on the installation status:

- <ORACLE_INVENTORY_HOME>/logs/installActions<timestamp>.log

- <ORACLE_HOME>/cfgtoollogs/oui/installActions<timestamp>.log

Note:
The installActions log file is located in the <ORACLE_INVENTORY_HOME> directory by default. This log file will be copied on to the above-mentioned Oracle home location after the installation is complete.

Configuration Logs

This section describes the following configuration logs:

- General Configuration Logs

- Repository Configuration Logs

- Secure Logs

General Configuration Logs

The Oracle Management Service (OMS) configuration logs are located in the following location of the Oracle home of the OMS.

<ORACLE_HOME>/cfgtoollogs/omsca

Table B-1 lists the configuration logs for different installation types.

Table B-1 General Configuration Logs

Installation Type

Location

Install a new or Upgrade Enterprise Manager system

- <ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger<timestamp>.log

- <ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.oms.<timestamp>.log

Note: <ORACLE_HOME> refers to the Oracle home of the OMS.

Add an additional Management Service

- <ORACLE_HOME>/cfgtoollogs/omsca/logs/omsca<timestamp.log>

- <ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.oms.<timestamp>.log

Note: <ORACLE_HOME> refers to the Oracle home of the OMS.

Install Oracle Management Agent

- <ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger

- <ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.agent.<timestamp>.log

Note: <ORACLE_HOME> refers to the Oracle home of the Management Agent.

Repository Configuration Logs

This section describes the following repository configuration logs:

- SYSMAN Schema Operation Logs

- MDS Schema Operation Logs

SYSMAN Schema Operation Logs

The SYSMAN schema operation logs are available in the following location of the Oracle home of the OMS. Listed in this directory is an overall log file, emschema.log, which logs all the actions performed by all the instances of RepManager run.

$<ORACLE_HOME>/sysman/log/schemanager/

In this location, for each run of RepManager, a new subdirectory is created based on the time at which the RepManager was run.

For example, if the RepManager was run and an instance was created at 09/29/2007 12:50PM, then the following subdirectory is created.

$<ORACLE_HOME>/sysman/log/schemananager/m_092907_1250_PM/

An instance of RepManager (or equivalently RepManager) can have schema actions, mainly CREATE, DROP, UPGRADE, TRANSX, and RESUME_RETRY. For each action, a subdirectory is created.

For example, if a CREATE action is performed by a RepManager instance at 09/29/2006 12:51PM, then the following subdirectory is created. Listed under this subdirectory are RCU-related log files and emschema.log.CREATE log file that logs the CREATE action-specific messages.

$<ORACLE_HOME>/sysman/log/schemananager/m_092907_1250_PM/m_092907_1251PM.CREATE/

In general, in $<ORACLE_HOME>/sysman/log/schemananager/m_<time-stamp>/m_<time-stamp>.<schema-action>, the following files are created:

- RCU per component (i.e. init, common, modify, drop, config, outofbox, preupgrade log

- RCU log

- Schema action-specific RCU logs

- TransX action-specific log (emrep_config.log)

If the any of the schema operations (CREATE/UPGRADE/PREUPGRADE/DROP) fail in SQL execution, and if you retry the operation by clicking Retry, then a separate subdirectory titled m_<time-stamp>.RESUME_RETRY is created.

The following shows the overall directory structure of repository operation logs for different schema actions:

$<ORACLE_HOME>/sysman/log/schemamanager
emschema.log
m_030210_0349_AM
m_030210_0325_AM.TRANSX
emrep_config.log
emschema.log.TRANSX
m_030210_0438_AM
m_030210_0438_AM.DROP (Same structure for Drop and Dropall actions)
rcu.log
emschema.log.DROP
em_repos_drop.log
m_030210_0450_AM
m_030210_0450_AM.CREATE
custom_comp_create_tbs.log
em_repos_common.log
em_repos_init.log
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
emschema.log
rcu.log
emschema.log.CREATE
em_repos_config.log
m_030210_1006_PM
m_030210_1006_PM.RESUME_RETRY
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
emschema.log
rcu.log
emschema.log.RESUME_RETRY
em_repos_modify.log
m_030210_1021_PM
m_030210_1021_PM.UPGRADE
em_repos_init.log
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
emschema.log
rcu.log
emschema.log.UPGRADE
em_repos_modify.log
m_030210_1100_PM
m_030210_1100_PM.PREUPGRADE
em_repos_preupgrade.log
emschema.log.PREUPGRADE
rcu.log
em_repos_init.log
emrep_config.log.3
emrep_config.log.2
emrep_config.log.1
emrep_config.log
em_repos_common.log
m_030210_1125_PM
m_030210_1125_PM.MY_ORACLE_SUPPORT
emschema.log.MY_ORACLE_SUPPORTm_030210_1135_PM            m_030210_1135_PM.PLUGINPURGE                emschema.log.PLUGINPURGE
em_repos_pluginpurge.logrcu.log

EMPrereqKit Logs

For EMPrereqKit, the logs are available at the <oraInventoryLoc>/logs/ location.

The details of execution of the prerequisites per prerequisite components location is available at:

<oraInventoryLoc>/logs/emdbprereqs/LATEST/repository.log or emprereqkit.log

The details of execution of the EMPrereqkit is available at:

<oraInventoryLoc>/logs/emdbprereqs/LATEST/emprereqkit.log

The errors are located at

<oraInventoryLoc>/logs/emdbprereqs/LATEST/emprereqkit.err.log

MDS Schema Operation Logs

MDS Schema Creation Log

For MDS schema creation operation, the following log is available in the Oracle home of the OMS:

$<ORACLE_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

For more information, review the following logs from the Oracle home of the OMS:

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/mds.log

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/rcu.log

MDS Schema Drop Logs

For MDS schema drop operation, the following logs are available in the location you specified by using the -logDir argument while invoking the MDS schema drop command:

$<user_specified_location>/mds.log

$<user_specified_location>/emmdsdrop_<timestamp>.log

However, if you did not specify any custom location while invoking the MDS schema drop command, then the logs are created in the Oracle home of the OMS. For example, /scratch/OracleHomes/oms12c/mds.log and /scratch/OracleHomes/oms12c/emmdsdrop_<timestamp>.log.

Secure Logs

For OMS, the following secure log is available in the OMS Instance Base location. Here, <oms_name>, for example, can be EMGC_OMS1.

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/secure.log

For Management Agents, the following secure log is available in the Oracle home of the Management Agent.

<Agent_Instance_Home/sysman/log/secure.log

Oracle Management Service Logs

The following log files that provide information about the running OMS are available in the OMS Instance Base location. Here, <oms_name>, for example, can be EMGC_OMS1.

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/emoms.trc

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/emoms.log

Add Host Log Files

This section describes the locations for the following Add Host log files:

- Initialization Logs

- Application Prerequisite Logs

- System Prerequisite Logs

- Agent Installation Logs

- Other Add Host Logs

Initialization Logs

Table B-2 lists the initialization logs of the remote host and their locations. Note that <OMS_INSTANCE_HOME> mentioned in this table refer to the OMS instance base directory (by default, it is gc_inst).

Table B-2 Initialization Logs

Log File

Location

<hostname>_deploy.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/applogs

Application Prerequisite Logs

Table B-3 lists the application prerequisite logs and their locations. Note that <ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS, and the <install_type> mentioned in this table refer to one of the installation types mentioned in Table B-4.

Table B-3 Prerequisite Logs

Log File

Location

prereq<time_stamp>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/<install_type>_logs/<hostname>/

prereq<time_stamp>.out

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/<install_type>_logs/<hostname>/

prereq<time_stamp>.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/<install_type>_logs/<hostname>/

Table B-4 Install Types

Install Type

Description

Target Operating System Type

emagent_install

New Agent Installation

UNIX

emagent_clone

Agent Cloning

UNIX

nfs_install

Shared Agent Installation

UNIX

System Prerequisite Logs

Table B-5 lists the system prerequisite logs and their locations. Note that<ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS.

Table B-5 System Prerequisite Logs

Log File

Location

prereq<time_stamp>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/productprereq_logs/<hostname>/

prereq<time_stamp>.out

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/productprereq_logs/<hostname>/

prereq<time_stamp>.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/prereqlogs/productprereq_logs/<hostname>/

Agent Installation Logs

Table B-6 lists the agent installation logs and their locations. Note that <ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS.

Table B-6 Agent Installation Logs

Log File

Location

Description

install.log/.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/logs/<hostname>

Fresh and Cloned Agent install logs

nfs_install.log/.err

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/logs/<hostname>

Shared Agent installation logs

cfgfw/*.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/cfgtoollogs/<hostname>

Agent Configuration logs

Other Add Host Logs

Table B-7 lists all the other installation logs that are created during an agent installation using the Add Host wizard. Note that <ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS.

Table B-7 Other Add Host Logs

Logs

Location

Description

EMAgentPushLogger<TIMESTAMP>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/logs/

Agent Deploy application logs.

remoteInterfaces<TIMESTAMP>.log

<OMS_INSTANCE_HOME>/sysman/agentpush/logs/

Logs of the remote interfaces layer.

deployfwk.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/applogs/

Add Host Deployment Framework logs

ui.log

<OMS_INSTANCE_HOME>/sysman/agentpush/<time-stamp>/applogs/

Add Host User Interface logs.

C Redirecting Oracle Management Agent to Another Oracle Management Service

If you want to redirect or repoint your Oracle Management Agent (Management Agent), which is already communicating with an Oracle Management Service (OMS), to communicate and upload data to another OMS, then follow these steps:

1. Stop the Management Agent:
$<AGENT_INSTANCE_HOME>/bin/emctl stop agent

2. Remove the Management Agent instance home:
rm -rf <absolute_path_to_agent_instance_home>

3. From the Enterprise Manager Cloud Control console, remove the targets monitored by the Management Agent.

4. Create a new instance home for the Management Agent so that it directs to the new OMS:
$<AGENT_BASE_DIR>/core/12.1.0.2.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agent_base_dir> OMS_HOST=<new_oms hostname> EM_UPLOAD_PORT=<http/https_upload_port> AGENT_REGISTRATION_PASSWORD=<registration_password> AGENT_INSTANCE_HOME=<absolute_path_to_new_agent_instance_home> -configOnly

Note:
The specified agent base directory location and the new agent instance home location map to locations on the same host, where the Management Agent was already configured. The OMS host name, of course, maps to the other host where the new OMS is configured, that is, the OMS with which you want the Management Agent to communicate now.

D Using RepManager Utility

This appendix describes the RepManager utility. In particular, this appendix covers the following:

- Overview

- Supported Actions and Commands

Overview

RepManager is a utility that enables you to upgrade and drop Oracle Management Repository, selectively purge plug-ins, and load dlf messages to Oracle Management Repository. This utility is available in the Oracle Management Service (OMS) home:

For UNIX operating systems:

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager

For Microsoft Windows operating systems:

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager.bat

This utility is invoked by Repository Configuration Assistant while installing a complete Enterprise Manager system, and by Repository Upgrade Configuration Assistant while upgrading to Enterprise Manager Cloud Control. For information about these Configuration Assistants, see What Are Configuration Assistants?.

Note:
If you want to drop the Enterprise Manager schema completely, then use the RepManager available in the OMS home. Do not use the one in database home because it cannot remove the Enterprise Manager schema completely.

Supported Actions and Commands

Table D-1 shows the list of actions and their associated commands supported by the RepManager utility.

Table D-1 Actions and Commands Supported by RepManager

Action

Command

Description

Example

preupgrade

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -action preupgrade [-mwHome <Middleware home>]-pluginDepList "<pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>" -dlfSources "<oms home>,<plugin1 home>,<plugin2home>"

Use this action to perform steps before upgrading an Oracle Management Repository with the following parameters:

- Specify the host, port, and SID to connect to Oracle RDBMS where Oracle Management Repository is to be upgraded.

- Specify the database user and password, repository name (SYSMAN) and password for SYSMAN user, and Middleware home to upgrade the Oracle Management Repository.

- Specify the comma-separated list of plugin-information according to dependency to be deployed. You can pass a file with this option, the contents being the comma-separated list of plugin-information according to dependency to be deployed. If the pluginDepList is missing or has a value of empty list i.e. "{}", $<OMS_HOME>/sysman/admin/emdrep/plugininfo/pluginDepList is read, by default, to get plugin dependency list.

- Specify the comma-separated locations for DLF files from platform/plugins. You can pass a file with this option, the contents being the comma-separated locations for DLF files from platform/plugins. If the dlfSources option is missing or has a value of empty list i.e., "{}", $<OMS_HOME>/sysman/admin/emdrep/plugininfo/dlfSources is read, by default, to get dlf resource locations. If this option is missing and default dlfSources file is not present, only dlf files for platform will be picked. If this is present, only the DLFs under these sources will be picked up.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action preupgrade -mwHome /scratch/weblogic/middleware -pluginDepList <pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>

upgrade

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -action upgrade [-mwHome <Middleware home>]-pluginDepList "<pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>" -dlfSources "<oms home>,<plugin1 home>,<plugin2home>"

Note: Run preupgrade before performing upgrade action.

Use this action to upgrade an Oracle Management Repository with the following parameters:

- Specify the host, port, and SID to connect to Oracle RDBMS where Oracle Management Repository is to be upgraded.

- Specify the database user and password, repository name (SYSMAN) and password for SYSMAN user, and Middleware home to upgrade the Oracle Management Repository.

- Specify the comma-separated list of plugin-information according to dependency to be deployed. You can pass a file with this option, the contents being the comma-separated list of plugin-information according to dependency to be deployed. If the pluginDepList is missing or has a value of empty list i.e. "{}", $<OMS_HOME>/sysman/admin/emdrep/plugininfo/pluginDepList is read, by default, to get plugin dependency list.

- Specify the comma-separated locations for DLF files from platform/plugins. You can pass a file with this option, the contents being the comma-separated locations for DLF files from platform/plugins. If the dlfSources option is missing or has a value of empty list i.e. "{}", $<OMS_HOME>/sysman/admin/emdrep/plugininfo/dlfSources is read, by default, to get dlf resource locations. If this option is missing and default dlfSources file is not present, only dlf files for Platform would be picked. If this is present, only the DLFs under these sources will be picked up.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action upgrade -mwHome /scratch/weblogic/middleware -pluginDepList <pluginid1>=<pluginid1 home>,<pluginid2>=<pluginid2 home>

transX

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -reposName sysman -action transx [-mwHome <Middleware home>] -dlfSources "<oms home>,<plugin1 home>,<plugin2home>"

Note: You can also run -do transX. By default, it is set to true. If you set the value to false, no translation bundles are loaded. This is applicable for -dlfSources for preupgrade and upgrade actions.

Use this action to load the translation resources to the Oracle Management Repository with the following parameters:

- Specify the host, port, and SID to connect to Oracle RDBMS to load translation resources to Oracle Management Repository.

- Specify the database user and password, repository name (SYSMAN) and password for SYSMAN user, and Middleware home to load translation resources to Oracle Management Repository.

- Specify the comma-separated locations for DLF files from platform/plugins. You can pass a file with this option, the contents being the comma-separated locations for DLF files from platform/plugins. If the dlfSources option is missing or has a value of empty list i.e. "{}", $<OMS_HOME>/sysman/admin/emdrep/plugininfo/dlfSources is read, by default, to get dlf resource locations. If this option is missing and default dlfSources file is not present, only dlf files for Platform would be picked. If this is present, only the DLFs under these sources will be picked up.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -reposName sysman -action transx -mwHome /scratch/WLS/middleware

resume

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -resume retry -checkpointLocation <directory where schemamanager stores checkpoints> [-mwHome <Middleware home>]

Use this action to resume the last failed action, for example, upgrade.

- Specify the host, port, and SID to connect to Oracle RDBMS where the action is to be resumed.

- Specify the database user and password, repository name (SYSMAN) and password for SYSMAN user, and Middleware home where the action is to be resumed.

- Specify the location at which to resume the step. The checkpoint location is $<OMS_HOME>/sysman/log/schemamanager.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -resume retry -checkpointLocation /scratch/weblogic/middleware/oms/sysman/log/schemamanager -mwHome /scratch/weblogic/middleware

drop

OR

dropall

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -action drop [-mwHome <Middleware home>] [-mwOraHome <Oracle Home>]

OR

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -action dropall [-mwHome <Middleware home>] [-mwOraHome <Oracle Home>]

Ensure that there are no active sessions, scheduler jobs, and dbms_jobs running for SYSMAN, SYSMAN_MDS SYSMAN_OPSS, and SYSMAN_APM. Ensure that none of these users are logged in. To ensure this, stop the OMS using the command emctl stop oms -all on all OMS instances.

Note: If BI Pubilsher (BIP) had been installed and configured, then BIP should be stopped using the Admin Server before running this command.

Use this action to remove all Enterprise Manager repository schemas as follows:

- Specify the host, port, and SID to connect to Oracle RDBMS from which all schemas are to be dropped.

- Specify the database user and password, repository name (SYSMAN) and password for SYSMAN user, and Middleware home.

At the end, a confirmation message appears to confirm the status of this operation. If all the schemas were successfully dropped, then a message confirming the same appears. Otherwise, a message providing details on each of the schemas appears.

For example,

SYSMAN_OPSS schema is not cleaned.
EM_X synonyms are not dropped.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action drop -mwHome /scratch/weblogic/middleware

OR

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action dropall -mwHome /scratch/weblogic/middleware -mwOraHome /scratch/weblogic/middleware

pluginpurge

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -action pluginpurge -pluginPurgeList "<plugin_name>=<plugin_location>" [-mwHome <Middleware home>] -mwOraHome <Oracle Home>

Note: To purge multiple plug-ins, for the -pluginPurgeList argument, enter the plug-ins separated by a command. For example, <pluginid1>=<pluginid1 home>, <pluginid2>=<pluginid2 home>

Use this action to deinstall a plug-in from the repository as follows:

- Specify the host, port, and SID to connect to Oracle RDBMS from which the plug-in is to be deinstalled.

- To specify the comma-separated list of plugin-information to be purged from Enterprise Manager Repository with EM-EXT model.

$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager example.com 1521 db3 -dbUser sys -dbRole sysdba -reposName sysman -action pluginpurge -pluginPurgeList "oracle.sysman.myyempwpax.oms.plugin_12.1.0.2.0=/scratch/weblogic/middleware/plugins/oracle.sysman.myyempwpax.oms.plugin_12.1.0.2.0" -mwHome /scratch/weblogic/middleware

Note:

- RepManager 12.1.0.2 supports -action dropall and -action drop. Both commands drop all schemas and users (SYSMAN, SYSMAN_BIP, SYSMAN_MDS, SYSMAN_APM, BIP, and SYSMAN_OPSS).

- RepManager 11.1 supports -action dropall and -action drop. But -action dropall drops only users SYSMAN and SYSMAN_MDS. And -action drop drops users SYSMAN.

- RepManager 10.2.0.5 supports only "-action drop" (drops only SYSMAN, the only users associated with the repository in this version)

Note:
If you do not specify passwords during RepManager actions, you will be prompted to do so.

E Collecting OCM Data Using Oracle Harvester

My Oracle Support provides a key set of features and functionality that greatly enhance the customer's interaction with Oracle Support. My Oracle Support streamlines the Service Request submission process by providing in-context information specific to a customer's configurations, as well as proactive support. To enable these features within My Oracle Support, the customer's configuration information must be uploaded to Oracle. When the configuration data is uploaded on a regular basis, customer support representatives can analyze this data and provide better service to customers.

The following mechanisms are provided to customers for collecting and uploading configuration data to Oracle.

- Oracle Enterprise Manager Harvester (Oracle Harvester)

- Oracle Configuration Manager (OCM)

In particular:

- When installing any product, the first screen asks for My Oracle Support credentials. THIS IS A PIVOTAL SCREEN in the installation. The user name and password that you provide are the credentials against which the configuration data is uploaded to Oracle.

- Configuration collections run and the configuration data is uploaded to Oracle every 24 hours.

- Once the data is uploaded, it can be viewed by logging into My Oracle Support (https://support.oracle.com) using the same credentials supplied during product installation.

Note: If you use Enterprise Manager to manage your applications, we recommend that you use Oracle Harvester to upload your configurations to Oracle. Otherwise, use OCM.

Oracle Harvester

Oracle Harvester only harvests data for targets that are managed by Enterprise Manager. Because Oracle Harvester has the same OCM dependencies, Oracle Harvester enables the gathering of target configuration data by leveraging Enterprise Manager collection methods thus precluding the need to install OCM on target homes managed by Oracle Harvester.

Highlights of Oracle Harvester

The following are highlights of Oracle Harvester:

- Data is uploaded by default against the same credentials with which OCM in the Oracle Management Service (OMS) home is configured.

- Requires OCM to be configured and running in the OMS home for Enterprise Manager.

- Gathers target configuration data from the Management Repository

- Automatically runs periodically so no user intervention is required

Oracle Harvester and OCM

When you install Enterprise Manager, Oracle Harvester and Oracle Configuration Manager are automatically installed as are all the necessary subcomponents. The Oracle Harvester will run as long as the OCM in the OMS home is configured and running.

OCM must be enabled in the Oracle Home of the OMS and configured (and running in connected mode) in the Instance Home of the OMS. The reason is that the Oracle OMS target will not be discovered by the OCM collector if ORACLE_CONFIG_HOME is not set.

Perform the following steps to ensure the Oracle OMS target is discovered:

1. Locate the OMS instance home.
In the $ORACLE_HOME/sysman/config/emInstanceMapping.properties file (where ORACLE_HOME is the Oracle Home of the OMS), there is an entry referencing a file called emgc.properties.

The directory in which the emgc.properties file is located is the "instance home" of the OMS. In the following example, /u01/app/oracle/product/gc_inst/em/EMGC_OMS1 is the instance home of the OMS:

EMGC_OMS1=/u01/app/oracle/product/gc_inst/em/EMGC_OMS1/emgc.properties

2. Set the environment variable ORACLE_CONFIG_HOME to the directory of this emgc.properties file.
Example:$export ORACLE_CONFIG_HOME=/u01/app/oracle/product/gc_inst/em/EMGC_OMS1

3. Configure OCM.

New For Enterprise Manager Release 12.1

By default, all targets are uploaded using the credentials used to register Oracle Configuration Manager in the OMS Home. In Enterprise Manager release 12.1, you have the option of assigning a Customer Support Identifier (CSI) to each target home.

The Oracle Harvester supports uploading configuration data to different CSIs for each different Oracle Home.

The steps include:

1. Ensuring that the Oracle Harvester has run. This job runs automatically. The status of the run can be monitored from the Support Identifier Assignment page. To access this page from the Enterprise Manager home page, select Setup, then select My Oracle Support. From the menu, select Support Identifier Assignment.

2. Setting My Oracle Support preferred credentials. From the Enterprise Manager home page, select Setup, then select My Oracle Support. From the menu, select Set credentials and supply any valid My Oracle Support credentials.

3. Assigning the Support Identifier.

1. From the Enterprise Manager home page, select Setup, then select My Oracle Support. Select Support Identifier Assignment and provide the correct user name and password. Select Set credentials.

2. Select Home. Click Assign button. Select CSI and click OK.

4. Ensuring the message displays indicating the assignment was successful. The message reads:

Support Identifier has been assigned for 1 Oracle homes. The changes in the Customer Support Identifiers will be reflected in My Oracle Support after the next Harvester run.

Viewing CSIs in Enterprise Manager

You can see the CSI associated with a target by viewing the target property or by doing a configuration search with CSI set as the search criteria. Any user with operator privilege on all targets for a given Oracle Home can assign a CSI for that Oracle Home.

Refer to the help in the Enterprise Manager interface on how to access this information.

Supported Targets in Oracle Harvester

Oracle Harvester collects configuration data from Enterprise Manager for the same set of targets collected by OCM. See Table E-1 for the list of targets.

Table E-1 Supported Targets in Enterprise Manager 12c

Target

Host

Oracle Application Server

Oracle Database

Oracle Home

Oracle Exadata Storage Server

Oracle Virtual Manager

Oracle WebLogic Server

Management Agent

Management Repository

Oracle Database Machine

Oracle Fusion Applications

Oracle Fusion Middleware

Oracle Management Service

Oracle SOA Suite

Configuration Data Not Available in My Oracle Support

In previous versions of Enterprise Manager, Oracle Harvester configuration data was only uploaded to My Oracle Support when 30 days had passed since the last upload of data by a standalone OCM Collector if such data already existed in My Oracle Support.

This restriction has been lifted in Enterprise Manager 12c. Configuration data for targets collected from Oracle Harvester running in Enterprise Manager release 12c displays in My Oracle Support immediately, regardless of how recently data was uploaded by a standalone OCM Collector.

Oracle Configuration Manager

Oracle Configuration Manager is installed and configured automatically when you install an Oracle product. It is installed in the product Home and collects configuration data for all targets installed in that Home.

The OCM setup requires specifying the My Oracle Support account and password, or My Oracle Support account and Customer Support Identifier (CSI). Configuration data will be uploaded using this information and can be viewed by logging in to My Oracle Support using the same credentials.

OCM must be installed in every Oracle Home from which you want to upload configuration data to Oracle. In addition to being part of the product installation, OCM can also be downloaded from My Oracle Support. The Mass Deployment tool is available to help with deploying OCM across data centers. The OCM kit is available from the Collector tab on My Oracle Support.

Once OCM is installed, no additional work is required. By default, automatic updates are enabled and you are encouraged to use this feature to ensure you are always running the latest version of OCM. This feature can be disabled if required, for example, for security reasons. If you disable the feature, you can turn it on by executing the following command:

<ocm_install_root>/ccr/bin/emCCR automatic_update on

Additional Information

To find additional information about My Oracle Support, see:

https://support.oracle.com

To find more information about OCM, perform the following steps:

1. Log into My Oracle Support at https://support.oracle.com

2. Access the Collector tab. The What, Why, How, Using It, and Additional Resources sections all contain useful information.

Troubleshooting Configuration Data Collection Tools

The following sections describe how to resolve issues with the configuration data collections.

In Enterprise Manager release 12.1.0.2, ensure that collection data is uploaded to Oracle by using the emccr status command. Look at the last uploaded date and time.

Note: This emccr status command shows that collected data was uploaded, but does not ensure the Oracle Harvester collections were successful and uploaded.

Location of error logs:

- Oracle Harvester error logs:

- For Harvester Job errors, look at:

INSTANCE_HOME/sysman/log/emoms_pbs.trc

- UI errors, for example CSI Assignment errors, look at:

INSTANCE_HOME/sysman/log/emoms.trc

for example: /gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/sysman/log/emoms.trc

- Oracle Configuration Manager log is located at:

ccr/hosts/<hostname>/log/collector.log

Oracle Harvester Collection Fails If the state/upload/external Directory Is Missing

If the Oracle Harvester collection fails with the following error, the required directory named external is missing.

[JobWorker 75210:Thread-61] ERROR gcharvester.GcCollectionMgr initOcm.? - GC OCM
Harvester: Caught GC Harvester exception from GCInit.init(): The installed version
of Oracle Configuration Manager in the ORACLE_HOME
(/scratch/aime/work/midlwre8937/oms11g) is prior to 10.3.1. The Grid Control
Configuration harvesting requires at a minimum, 10.3.1

To resolve this issue, create the external directory:

$ORACLE_INSTANCE_HOME/ccr/state/upload/external

(Bug 12795503)

Oracle Configuration Manager Is Not Running

When OCM is not running, you may see the following error:

2011-08-29 16:34:20,709 [JobWorker 97285:Thread-60] WARN
gcharvester.HarvesterJobUtils performOCMCollections.? - GC OCM Harvester: OCM was
stopped and is not running

To resolve this issue, verify that the OCM was installed and configured in the appropriate directories (execute emCCR status).

In particular, OCM must be installed in the OMS Oracle Home and configured (and running in connected mode) in the OMS Instance Home.

Configuration Data Not Available in My Oracle Support

When you look at My Oracle Support and do not find configuration data, it could be that the Oracle Harvester collection did not run.

To resolve this issue, verify that the OCM was installed and configured in the appropriate directories (execute emCCR status). In particular, OCM must be installed in the OMS Oracle Home and configured (and running in connected mode) in the OMS Instance Home.

To verify that OCM is running, perform the following steps:

1. Set ORACLE_CONFIG_HOME to the INSTANCE HOME

2. Execute $ORACLE_HOME/ccr/bin/emCCR status

F Enabling Enterprise Manager Accessibility Features

As part of the effort to make Oracle products, services, and supporting documentation accessible and usable to the disabled community, Enterprise Manager offers several features that make management data available to users of assistive technology. Enterprise Manager provides the following accessibility features:

- Support for Screen Reader

- Support for High Contrast

- Support for Large Fonts

This appendix consists of the following configuration settings you must modify to enable Screen Reader support:

- Enabling Enterprise Manager Accessibility Mode

- Setting uix-config.xml Flag

- Configuring web.xml File

- Verifying That Screen Reader Support Is Enabled

Note:
If Screen Reader support is enabled, then all pages related to Refresh Process Status are not refreshed automatically because PPR is turned off. This is an expected behavior.

Enabling Enterprise Manager Accessibility Mode

To enable screen reader mode, do the following:

1. On the Cloud Control home page, from the <user_name> menu, select My Preferences and then select Accessibility.

2. In the Accessibility Preference page, select I use a screen reader. Click Apply.
ADF accessibility mode is a session based setting which takes place immediately and does not require you to restart the Enterprise Manager Management Service.

For ADF pages, you will see an Accessibility Preferences dialog after logging into Cloud Control for the first time. The settings in this dialog are the same as those in the Accessibility Preference page mentioned above.

Setting uix-config.xml Flag

To enable screen reader mode for UIX pages, do the following:

1. Locate the uix-config.xml configuration file.
To locate the uix-config.xml file in a Cloud Control installation, change directory to the following location in the Oracle Management Service home:

./oms/sysman/archives/emgc/deployments/EMGC_DOMAIN/emgc.ear/em.war/WEB-INF/uix-config.xml

2. Open the uix-config.xml file using a text editor and set the following entry:

<!-- An alternate configuration that disables accessibility features  -->
<default-configuration>
<accessibility-mode>screenReader</accessibility-mode>
</default-configuration>

3. Save and close the file.

4. Restart the Oracle Management Service.

Note:
UIX accessibility mode is a product-wide setting. You will have to restart the Enterprise Manager Management Service for this setting to take effect.

Note:
In the uix-config.xml file, enable-auto-table-ctlr-labels is set to true. This enables tool tip boxes containing labels to appear when you hover your cursor over UI elements such as checkboxes and radio buttons in tables. To disable this function, change the setting to false.

Configuring web.xml File

To configure web.xml file, follow these steps:

1. Locate the web.xml configuration file.
To locate the web.xml file in a Cloud Control installation, change directory to the following location in the Oracle Management Service home:

./oms/sysman/archives/emgc/deployments/EMGC_DOMAIN/emgc.ear/em.war/WEB-INF/web.xml

2. Open the web.xml file with your favorite text editor and locate the following six lines of the file:

<!-- Uncomment this to enable textual chart descriptions
<context-param>
<param-name>enableChartDescription</param-name>
<param-value>true</param-value>
</context-param>
-->

3. Remove comments from this section by deleting the first line and the last line of this section so that the section consists of only these 4 lines:

<context-param>
<param-name>enableChartDescription</param-name>
<param-value>true</param-value>
</context-param>

4. Save and exit the file.

5. Restart the Oracle Management Service.

Verifying That Screen Reader Support Is Enabled

Throughout Enterprise Manager, charts are used to display performance data. For most users, these charts provide a valuable graphical view of the data that can reveal trends and help identify minimum and maximum values for performance metrics.

However, charts do not convey information in a manner that can be read by a screen reader. To remedy this problem, you can configure Enterprise Manager to provide a complete textual representation of each performance chart. By default, support for the textual representation of charts is disabled. When textual description for charts is enabled, Enterprise Manager displays a small icon for each chart that can be used as a drill-down link to the textual representation.

To verify whether Screen Reader support has been enabled for ADF pages, follow these steps:

1. On the Cloud Control home page, click Help and then select About Enterprise Manager.

2. In the About Enterprise Manager dialog box, ensure that Accessibility Preference - Screen Reader Support is set to Enabled.

3. If Accessibility Preference - Screen Reader Support is set to Disabled, follow the steps listed in Enabling Enterprise Manager Accessibility Features.

To verify whether Screen Reader support has been enabled for UIX pages, follow these steps:

1. On the Cloud Control home page, from the Enterprise menu, select Reports and then select Information Publisher Reports.

2. In the Information Publisher Reports page, click Hardware Summary. The Hardware Summary page is displayed. If accessibility setting has been enabled, you will see the icon shown in Figure F-1:

Figure F-1 Icon Representing Textual Representation of Charts

G Troubleshooting

This appendix describes how to troubleshoot issues that you might encounter while working with Enterprise Manager Cloud Control.

- Troubleshooting Configuration Assistant Failures

- Troubleshooting ADP and JVMD Failures

- Troubleshooting Package-Related Issues

- Troubleshooting Deinstallation Failures

Troubleshooting Configuration Assistant Failures

This section describes the log files you must review and the actions you must take when the following configuration assistants fail:

- Plugins Prerequisites Check Configuration Assistant

- Repository Configuration Assistant

- Repository Out Of Box Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Oracle Configuration Manager Repeater Configuration Assistant

- OCM Configuration for OMS Configuration Assistant

- Agent Configuration Assistant

- Agent Upgrade Configuration Assistant

- Repository Upgrade Configuration Assistant

- Stopping APM Engines Configuration Assistant

- Stop Admin Server Configuration Assistant

Plugins Prerequisites Check Configuration Assistant

Log Files

Review the following log files:

- $<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- $<OMS_HOME>/cfgtoollogs/pluginca/configplugin_prereq_check_<timestamp>.log

Workaround Steps

Run the following command:

$<OMS_HOME>/oms/bin/pluginca -action prereqCheck -oracleHome <oms_home_path> -middlewareHome <middleware_home_path> -plugins <plugin_id>=<plugin_version>

Note:
For multiple plug-ins, separate the plug-in details with a comma. For example, -plugins <plugin_id>=<plugin_version>, <plugin_id>=<plugin_version>

Repository Configuration Assistant

Log Files

Review the following log files:

- $<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- $<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

Note:
<ACTION> refers to any of the schema actions, for example, CREATE, TRANSX, MY_ORACLE_SUPPORT, and so on.

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Clean up the Management Repository by running the following command:
$<OMS_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>

Note:

- For Microsoft Windows, invoke RepManager.bat.

- RepManager 12.1 and 11.1 from the OMS home support -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN).

- RepManager 10.2.0.5 supports -action drop (drops only SYSMAN).

3. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

Repository Out Of Box Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

Workaround Steps

1. Resolve the cause of the issue.

Caution:
Do NOT clean up or drop the Management Repository.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

MDS Schema Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

For more information, review the following log files:

- <OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/mds.log

- $<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/rcu.log

Workaround Steps

Follow these steps:

1. Drop the MDS schema by running the following command from the OMS home:
$<OMS_HOME>/sysman/admin/emdrep/bin/mdsschemamanager.pl -action=-dropRepository -connectString=<database_connect_string> -dbUser= <database_user> -dbPassword=<database_password> -oracleHome=<OMS_oracle_home> -mwHome=<middleware_home>

Where <database_connect_string> must be in the following format:<database_host>:<database_port>:<database_sid>

2. Rerun the Configuration Assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

OMS Configuration Assistant

Log Files

Review the following log files:

- If the installer fails BEFORE the OMS configuration assistant starts running, then review the following log file:
$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- If the installer fails AFTER the OMS configuration assistant starts running, then review the following log file:
$<OMS_HOME>/cfgtoollogs/omsca/omsca_<timestamp>.log

Workaround Steps

Follow these steps:

1. Check whether any Java processes are running from the Middleware home. To do so, run the following command from the host where the OMS is running:
ps -ef | grep java | grep <Oracle_Middleware_Home>

2. Kill all the running processes, except for installer-related Java processes, by the running the following command. The installer-related Java processes run from the temp directory, so you can ignore the processes from that directory.
kill -9 <process_id>

3. Remove the Oracle Management Service Instance Base by running the following command:
rm -rf <OMS_Instance_Home>

4. Rerun the Configuration Assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

Plugins Deployment and Configuration Configuration Assistant

Log Files

Review the following log files:

- $<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- $<OMS_HOME>/cfgtoollogs/pluginca/configplugin_deploy_<timestamp>.log

Workaround Steps

Run the following command:

$<OMS_HOME>/oms/bin/pluginca -action deploy -oracleHome <oms_home_path> -middlewareHome <middleware_home_path> -plugins <plugin_id>=<plugin_version>

Note:
For multiple plug-ins, separate the plug-in details with a comma. For example, -plugins <plugin_id>=<plugin_version>, <plugin_id>=<plugin_version>

Start Oracle Management Service Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

Workaround Steps

Run the following command:

$<OMS_HOME>/bin/emctl start oms

Plugins Inventory Migration Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

Oracle Configuration Manager Repeater Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

OCM Configuration for OMS Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

Agent Configuration Assistant

Log Files

Review the following log files:

- $<AGENT_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

- If secure fails, then review the following log file:
$<AGENT_HOME>/sysman/log/secure.log

- In the log file, search for the following statement:
SEVERE:Plugin configuration has failed.

If you find this statement, then review the following log file:

$<AGENT_INSTANCE_HOME>/install/logs/agentplugindeploy_<timestamp>.log

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

If you are installing in silent mode, then run the following command from the Management Agent home:

$<AGENT_HOME>/sysman/install/agentDeploy.sh OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_upload_https_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password>

Note:
Enter the HTTPS port (secure port) for the EM_UPLOAD_PORT argument.

Agent Upgrade Configuration Assistant

Log Files

If the agent upgrade configuration assistant fails, then review the following log file:

$<AGENT_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

Workaround Steps

Resolve the cause of the issue, and rerun the configuration assistant from the Jobs page of the Enterprise Manager Cloud Control console.

Note:
The Jobs page referred to here is the page within the earlier release of the Enterprise Manager Cloud Control console.

Repository Upgrade Configuration Assistant

Log Files

Review the following log files:

$<OMS_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

$<OMS_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

Note:
(<ACTION> refers to any of the schema actions, for example, PREUPGRADE, UPGRADE, TRANSX, and so on.)

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

Stopping APM Engines Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

Stop Admin Server Configuration Assistant

Log Files

Review the following log file:

$<OMS_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

Workaround Steps

Follow these steps:

1. Resolve the cause of the issue.

2. Rerun the configuration assistant.
If you are installing in graphical mode, then return to the Enterprise Manager Cloud Control Installation Wizard and click Retry.

If you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If you are installing in silent mode, then rerun the runConfig.sh script (runConfig.bat on Microsoft Windows) from the OMS home:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<oms_home_path> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

Note:
For Microsoft Windows, run runConfig.bat.

Troubleshooting ADP and JVMD Failures

This section discribes how to troubleshoot the errors encountered while deploying ADP/JVMD Managers, and ADP/JVMD Agents:

- ADP Manager Name Conflict

- Failure to Deploy ADP Agent On a Target

- SSL Handshake Failure Agent Deployment Errors

- Copying ADP Agent Zip or Javadiagnosticagent Ear Step Failure

ADP Manager Name Conflict

Error Message

When you deploy ADP Manager to an existing managed server whose instance (for example: EMGC_ADPMANAGER2) has not been completely removed, then the new deployment of ADP manager with the same name fails on the unzip step with the following error:

@ Are you sure you haven't deployed adp manager to a managed server with name
@ <ADP_managed_server> already?

Workaround Steps

To remove the existing managed server completely, perform the following steps:

1. Follow the steps listed in Chapter 17 to remove the ADP Manager application and the managed server to which the ADP application is deployed.

2. Connect to the host machine where the managed server was present, and navigate to the following location to manually delete the managed server (EMGC_ADPMANAGER2):

$DOMAIN_HOME/<ADP_managed_server>

Where, $DOMAIN_HOME is the location of the Cloud Control domain

Failure to Deploy ADP Agent On a Target

Error Message

While deploying the ADP Agent, the deployment job may fail on the Deploy ADP Agent On Target step, with the following error:

Failed to connect to https://<host>:<port>/HttpDeployer/HttpDeployerServlet

Also, if you check the output of the Deploy HttpDeployer OnTarget (the previous step), then you will see a message as follows:

Operation is pending and will be activated or cancelled when the ongoing edit session is activated or cancelled.

Workaround Steps

To correct this error, perform the following steps:

1. Log into WebLogic Administration Console of the domain where the ADP Agent was to be deployed.

2. On the Administration home page, click Save Changes or Discard Changes, and start deploying the ADP agent afresh.

SSL Handshake Failure Agent Deployment Errors

Error Message

If the WebLogic Domain is SSL enabled using a demo certificate, then the agent deployment may fail due to an SSL Handshake Failure. The following error normally occurs because the demo certificate is not present in AgentTrust.jks:

Certificate chain received from myhost.acme.com - 123.34.11.11 was not trusted causing SSL handshake failure. Check the certificate chain to determine if it should be trusted or not. If it should be trusted, then update the client trusted CA configuration to trust the CA certificate that signed the peer certificate chain. If you are connecting to a WLS server that is using demo certificates (the default WLS server behavior), and you want this client to trust demo certificates, then specify -Dweblogic.security.TrustKeyStore=DemoTrust on the command line for this client.

Note: If the WebLogic Domain is using a production certificate, then this issue will not occur as AgentTrust.jks has trusted certificates from all well known CA's.

Workaround Steps

To correct the error, import WebLogic demo certificate to Management Agent keystore as follows:

1. Export WebLogic Demo certificate from cacerts file. This file is present under the WebLogic home of the Middleware installation at the following location:
keytool -export -keystore $WEBLOGIC_HOME/server/lib/cacerts -alias certgencab -file mycert.cer

Press Enter when prompted for a password.

2. Import WebLogic Demo certificate to TrustStore of Oracle Management Agent as follows:
keytool -import -keystore $ORACLE_HOME/core/12.1.0.0.0/stage/sysman/config/montrust/AgentTrust.jks -alias wlscertgencab -file mycert.cer

Enter the password welcome when prompted, and press Enter.

To check if the certificate has been imported correctly, run the following command:

keytool -list -keystore $ORACLE_HOME/core/12.1.0.0.0/stage/sysman/config/montrust/AgentTrust.jks

Where, $ORACLE_HOME is Oracle Management Agent home.

Press Enter when prompted for password, a certificate with the name wlscertgencab is generated with the current date.

Copying ADP Agent Zip or Javadiagnosticagent Ear Step Failure

Error Message

If the users who installed the OMS, and the Management Agent are not in the same group, then the job fail on Copying ADP Agent Zip step for an ADP agent, and Copy Javadiagnosticagent Ear step for a JVMD agent, with the following error:

oracle.sysman.emSDK.emd.comm.RemoteOperationException: Error while streaming
JobReader:java.io.IOException: Broken pipe

Workaround Steps

To correct the error, either install the Enterprise Manager Agent using OMS host user credentials.

OR

Enable sudo or Powerbroker settings for the agent host, so that the job runs as if run by an OMS host user.

To set the sudo, or Powerbroker settings, do the following:

1. In Cloud Control, from the Setup menu, select Security, and then click Privilege Deligation.

2. On the Manage Privilege Delegation Settings page, do the following:

1. Select the Sudo or PowerBroker from the type menu.

2. Enter the host name, or alternatively select the name from the list of host targets. Ensure that the host selected corresponds to the EM Agent; this agent must be the one monitoring the WebLogic Domain where the ADP/JVMD agents have to be deployed.

3. Click Go.

Troubleshooting Package-Related Issues

While installing Enterprise Manager Cloud Control, you might see the following error message:

Lin.X64 SUSE 10 : Backup fails with the given below error
install_driver(Oracle) failed: Attempt to reload DBD/Oracle.pm aborted.
Compilation failed in require at (eval 15) line 3.

If you see this error, then install the following packages, and try again.

- libaio-32bit-0.3.104-14.2

- libaio-devel-32bit-0.3.104-14.2

Troubleshooting Deinstallation Failures

While deinstalling the Shared Agent as described in Deinstalling Shared Agent, you might see the following error:

SEVERE:The home <AGENT_HOME> cannot be deinstalled. Please deinstall all referenced home(s) <REFERENCE_HOME>

For example,

SEVERE:The home /tmp/agt_install/core/12.1.0.1.0 cannot be deinstalled. Please deinstall all referenced home(s) /tmp/agt_install/plugins

If you see the error, then deinstall the Shared Agent following these steps:

1. Identify the dependent plug-ins and the sbin home to be detached from the Central Inventory:

1. On the host where the Shared Agent is installed, open the following file from the Central Inventory:
<absolute_path>/oraInventory/ContentsXML/inventory.xml

2. Make a note of the dependent plug-ins listed within the <REFHOMELIST> and </REFHOMELIST> tags.
For example,

<HOME NAME="nfs5515" LOC="/home/john/software/oracle/agent/core/12.1.0.0.0" TYPE="O" IDX="1">
<REFHOMELIST>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.oh.discovery.plugin_12.1.0.0.0"/>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.db.discovery.plugin_12.1.0.0.0"/>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.emas.discovery.plugin_12.1.0.0.0"/>
<REFHOME LOC="/home/john/software/oracle/agent/plugins/oracle.sysman.oh.agent.plugin_12.1.0.0.0"/>
</REFHOMELIST>
</HOME>

3. Make a note of the sbin directory listed within the <REFHOMELIST> and </REFHOMELIST> tags.
For example,

<HOME NAME="nfs5515" LOC="/home/john/software/oracle/agent/core/12.1.0.0.0" TYPE="O" IDX="1">
<REFHOMELIST>
<REFHOME LOC="home/john/software/oracle/agent/sbin"/>
</REFHOMELIST>

4. Detach the dependent plug-ins you identified in Step 1 (b) from the Central Inventory. To do so, run the following command from the Master Agent home that is visible on the host where your Shared Agent is installed:
$<AGENT_HOME>/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc <absolute_path>/oraInst.loc ORACLE_HOME=<plug-in_home> -nogenerateGUID

For example,

/home/john/software/oracle/agent/core/12.1.0.2.0/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc /home/john/software/oracle/agent/core/12.1.0.2.0/oraInst.loc ORACLE_HOME=/home/john/software/oracle/agent/plugins/oracle.sysman.emas.discovery.plugin_12.1.0.2.0 -nogenerateGUID

Note:
This step detaches only one plug-in at a time. Therefore, if you have multiple plug-ins, repeat this step to detach every other dependent plug-in.

5. Detach the sbin home you identified in Step 1 (c) from the Central Inventory. To do so, run the following command from the Master Agent home that is visible on the host where your Shared Agent is installed:
$<AGENT_HOME>/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc <absolute_path>/oraInst.loc ORACLE_HOME=<sbin_home> -nogenerateGUID

For example,

/home/john/software/oracle/agent/core/12.1.0.2.0/oui/bin/runInstaller -detachHome -silent -waitForCompletion -invPtrLoc /home/john/software/oracle/agent/core/12.1.0.2.0/oraInst.loc ORACLE_HOME=/home/john/software/oracle/agent/sbin -nogenerateGUID

2. Deinstall the Shared Agent. To do so, run the following command from the Master Agent home that is visible on the host where your Shared Agent is installed:
$<AGENT_HOME>/perl/bin/perl <AGENT_HOME>/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=<absolute_path_to_agent_instance_home> ORACLE_HOME=<absolute_path_to_agent_home>

For example,

/home/john/software/oracle/agent/core/12.1.0.2.0/perl/bin/perl /home/john/software/oracle/agent/core/12.1.0.2.0/sysman/install/NFSAgentDeInstall.pl AGENT_INSTANCE_HOME=/home/john/software/oracle/agent/agent_inst ORACLE_HOME=/home/john/software/oracle/agent/core/12.1.0.2.0

Index

A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  V  W

A

accessibility, F

accessibility mode, F.1

configuring web.xml file, F.3

enabling accessibility mode, F.1

screen reader, F.4

screen reader support, F.4

uix-config.xml, F.2

web.xml File, F.3

add host log files, B.2 Add Host Status page, 7.4.1 Add Host Target Wizard

overview, 2.1.5

Add Host Targets Wizard, 1.3

best practice, 2.1.5

install types offered, 2.1.5

Add Management Service deployment procedure, 2.1.6 ADP, 12 ADP agents, 12.1 ADP architecture, 12.1 ADP managers, 12.1 ADPRemoteServer managed server, 12.4.1.2 advanced installer options, 3.4.2 agent base directory, 2.3.5

requirements, 6.3, 7.3

agent home, 2.3.4 agent installation logs, B.2.4 agent instance directory, 2.3.6 agent instance home, A.4

permissions, 6.3

requirements, 6.3

agent plug-in home, 2.3.4 agent_inst, 2.3.6 agentDeploy.sh script

limitation, 6.2

location, 6.2

purpose, 6.1

running from, 6.2

software-only install, 9.1

agentDeploy.sh script supported options, 6.4.6 AgentNFS.pl script

alternate way, 8.4.2

purpose, 8.1

response file, 8.4.2

AgentPull.sh script, 6.1

response file, 6.4.2

usage, 6.4.1.1

AgentPull.sh script supported options, 6.4.5 allroot.sh script, 2.8.2, 4.4.1.2, 4.4.2.2 Application Dependency and Performance, 12

advaced installation

architecture

advanced installation

facts, 12.2

postinstallation, 12.5

prerequisites, 12.3

procedure, 12.4

advanced installation options, 12 credentials

Oracle WebLogic Domain Credentials, 12.4.1.2

Oracle WebLogic Managed Server Host Credentials, 12.4.1.2

Oracle WebLogicAdministration Server HostCcredentials, 12.4.1.2

deinstallation

ADP Agents, 17.1.2

ADP Manager, 17.1.1

see ADP Application Performance Management, 10.3.7 application prerequisite logs, B.2.2 applying, 2.4.2.2 assistive technology, F asynchronous I/O, 11.3.4.6

B

baselines, 11.3.2

Beacons, 11.3.4.7

configuring firewalls to allow ICMP traffic, 10.3.7

BI Publisher, 14

Administration, 14.8

Allowing Access, 14.4

custom strust store, 14.7

Repository Access, 14.11

Troubleshooting, 14.12

Verifying Integration, 14.3

BI Publisher Installation, 14.2 BI Publisher Inventory, 14.2.1 BI Publisher Security Model, 14.4.5 buffer cache, 11.3.4.3 business intelligence publisher, A.1.3

C

capacity

predicting, 11.3

central inventory, 6.3 cksum command, 1.2.2.2, 1.2.2.2, 1.2.2.2 Cloud Control

architecture overview, 11.1

components, 11.1

sizing, 11.3, 11.3

commands

data file commands

deleting data files, 15.1

deleting data files, 2.1.9 Enterprise Manager commands

deinstalling in GUI mode, 15.2.1, 15.2.1

deinstalling in silent mode, 15.2.2

management agent commands

deinstalling from all nodes in GUI mode, 16.2.1

deinstalling from all nodes in silent mode, 16.2.2.1, 16.2.2.1

shutting down management agent, 15.1

OMS commands

deleting OMS, 15.1

verifying file size, 1.2.2.2 configuration assistants

overview, 2.5.1

resolving failures, 2.5.3

run by default, 2.5.2

configuration logs, B.1.2

general, B.1.2.1

repository, B.1.2.2

sysman schema operation logs, B.1.2.2.1

configuration phase, 4.1 configureBIP script, 14.2.2.2 console port, 2.1.7.1

D

data files, 2.1.8

deleting, 2.1.9

overview, 2.1.8

database templates

handling errors, 3.4.1, 4.4.1.3, 4.4.2.3

overview, 3.2, 3.2, 4.2

providing details in installer, 4.4.1.3

providing details in response file, 3.4.4

resetting user account passwords, 3.4.4, 3.4.4, 4.4.1.3, 4.4.1.3, 4.4.2.3.1, 4.4.2.3.1

defaults assigned, 10.2.1 deinstallation

deinstalling in GUI mode

deinstalling Enterprise Manager system, 15

deinstalling management agent, 16, 17

deinstalling management agent installed with RPM file, 16.2.4

deinstalling in silent mode

deinstalling shared agent, 16.2.3

Deinstalling ADP, 17.1 Deinstalling JVMD, 17.2 Deploy ADP Manager, 12.4.1.1 deploying ADP agents, 12.4.2 deploying ADP manager, 12.4.1.1, 12.4.1.2

seperate host from the OMS, 12.4.1.2

deploying ADP Manager

same OMS host, 12.4.1.1

deploying JVMD agents, 13.4.2 deploying JVMD manager

existing OMS host, 13.4.1.1

deployment procedure, 2.1.6, 2.1.6 deployment size

changing deployment size, 2.1.4

handling errors, 3.4.1

overview, 2.1.4

running prerequisite checks, 2.1.4

selecting in installer, 4.4.1.3

small, medium, large, 2.1.4, 4.4.1.3, 4.4.1.3

target count, agent count, session count, 2.1.4, 4.4.1.3

DHCP, 2.7.2 directories, A.1, A.1.4

Middleware Common home directory, A.1

Middleware WebTier home directory, A.1

Oracle Business Intelligence Publisher home, A.1

Oracle Management Agent home directory, A.1

Oracle Management Agent Plugin home, A.1

Oracle Management Service home directory, A.1

Oracle Management Service Instance home directory, A.1

Oracle Management Service Plugins home, A.1

directory structure, A

Oracle Management Agent, A.3

Oracle Management Service, A.2

Oracle Management Service home, A.1.4

dontProxyFor

description of property, 10.3.3.4

E

E2E monitoring, 11.3.4.7

editing response file, 3.4.4

EMBIP* Roles

folder/catalog object access, 14.10

EMBIPAdministrator, 14.4.5 EMBIPAuthor, 14.4.5 EMBIPScheduler, 14.4.5 EMBIPViewer, 14.4.5 EMCLI, 6.4.1.2, 6.4.1.3 emctl command, A.4 emgcdomain.jar file, 12.4.1.2, 13.4.1.2 emreposauthbean.jar file, 12.4.1.2, 13.4.1.2 Enterprise Manager

See Oracle Enterprise Manager

Enterprise Manager Cloud Control

configuration assistants, 2.5

creating data files, 2.1.8

deinstallation

dropping MDS schema, 15.1

dropping SYSMAN schema, 15.1

graphical mode, 15.2.1

overview, 15

prerequisites, 15.1

silent mode, 15.2.2

deleting data files, 2.1.9 installation

silent, 3.1, 3.2, 3.3, 3.4, 3.4.2, 3.4.4, 3.5

software-only installation, 2.1.3.3, 4.1, 4.1, 4.1, 4.2, 4.3, 4.4.1, 4.4.2

installation modes, 2.1.1 installation types, 2.1.3 installation wizard, 2.1.2 ports

console port, 2.1.7.1

customizing ports, 2.1.7.2, 2.1.7.3

default ports, 2.1.7.1

HTTP port, 2.1.7.1

HTTPS port, 2.1.7.1

overview, 2.1.7

upload port, 2.1.7.1

prerequisite checks, 2.6 software

procuring from OTN, 1.2.2.2, 1.2.2.3, 1.2.2.4

upgrade

overview, 2.1.3.2

Enterprise Manager Framework Security

in a firewall environment, 10.1

Enterprise Manager Prerequisite Kit, B.1.2.2.2 /etc/hosts file, 6.3 extracting contents, 1.2.2.3

F

facts, 3.2, 4.2, 6.2

files

RepManager.bat, 15.1

firewalls

between browser and the Cloud Control, 10.3.1

between Cloud Control and a managed database target, 10.3.5

between Management Service and Management Agents, 10.3.6

between Management Service and Management Repository, 10.3.4

configuring for ICMP traffic, 10.3.7

configuring for UDP traffic, 10.3.7

configuring the Management Agent for, 10.3.2

configuring the Management Service for, 10.3.3

configuring to allow incoming data from Management Service, 10.3.3.2

configuring to allow incoming traffic to Management Agent, 10.3.2.2

considerations when using with multiple Management Services, 10.3.6

G

gc_inst, 2.3.3

graphical mode, 2.1.1, 2.1.1, 4.4.1

H

host list file, 2.8.1

HTTP port, 2.1.7.1

HTTPS port, 2.1.7.1

Hyper-Threading, 11.3.4.1

I

ICMP, 10.3.7

ICMP echo request default port, 10.1.1

initialization logs, B.2.1

install logs, B.1

installActions, B.1.1

installation base directory

permission, 7.3

requirements, 7.3

installation modes, 2.1.1 installation phase, 4.1 installation types, 2.1.3 installation wizard, 2.1.2 installing ADP

see alsoremote deployment

installing ADP agents, 12.4.2 installing JVMD, 13

see alsoremote deployment

seperate host from the OMS, 13.4.1.2

installing jvmd agents, 13.4.2 instance directory

permission, 7.3

requirements, 8.3

Integrating BI Publisher, 14.2.2.2 Internet Control Message Protocol, 10.3.7 -invPtrLoc parameter, 2.3.1 I/O Channels

monitoring, 11.3.4.6

J

Java Development Kit

default version installed, 3.2

supported version, 2.2

JROCKIT, 3.2 JVM diagnostics, 13 JVM Diagnostics

advanced installation

architecture

postinstallation steps, 13.5

prerequisites, 13.3

procedure, 13.4

see JVMD JVMD

architecture

JVMD advanced install options, 13 JVMD agents, 13.1 JVMD Architecture, 13.1 JVMD managers, 13.1 JVMDRemoteServer managed server, 13.4.1.2

L

licenses, 2.7.1

Listener port

obtaining, 10.3.5

Loader, 11.3.4.2 loader threads, 11.3.4.2 locked user account, 7.2 logs

application prerequisite logs, B.2.2

cfgfw/*.log, B.2.4

configuration logs, B.1.2.1

deployfwk.log, B.2.5

initialization logs, B.2.1

installation logs, B.1.1

install.log/.err, B.2.4

MDS schema operation logs, B.1.2.2.3

nfs_install.log/.err, B.2.4

Oracle Management Service log files, B.1.2.4

secure logs, B.1.2.3

sysman schema operation logs, B.1.2.2.1

system prerequisite logs, B.2.3

ui.log, B.2.5

M

management agent

deinstallation in GUI mode

overview, 16, 17

postdeinstall tasks, 16.3

installation

verifying, 6.5, 8.5

installation using response file

creating response file, 6.4.2, 6.4.3, 6.4.4

prerequisites, 6.3

Management Agent, 11.1, 11.2.1.5, 11.3.2

configuring to allow incoming communication from the Management Service, 10.3.2.2

configuring to use a proxy server, 10.3.2.1

management agent home, 2.3.4 Management Servers

adding, 11.3.4.5

Management Service, 11.1, 11.2.1.5

See Oracle Management Service

master agents, 8.1, 8.2 MDS schema, 2.1.9 MDS schema creation log, B.1.2.2.3 MDS schema drop logs, B.1.2.2.3 mgmt_ad4j.dbf data file, 2.1.8 mgmt_ecm_depot1.dbf data file, 2.1.8 mgmt.dbf data file, 2.1.8 middleware home

NFS-mounted drive, 3.2, 4.2

My Oracle Support

enabling OMS access, 10.3.3.3

N

Named Credentials, 7.2

new_install.rsp response file, 3.4.4

node manager, 2.2.5

node manager credentials, 2.2.5

O

OMS home, 2.3.4

OMS instance base location, 2.3.3

OMS plug-in home, 2.3.4

OpenSSH, 7.2, 8.2

operating system groups, 6.3, 7.3, 8.3

operating system requirements, 8.3

operating system users, 6.3, 7.3, 8.3

operating systems supported, 6.3

Oracle Advanced Security, 10.3.4

Oracle BI Publisher, downloading, 14.1.2

Oracle BI Publisher, integration, 14.1.2

Oracle Business Intelligence, 14

Oracle Configuration Manager

enabling, 2.4.1.2

manually collecting, uploading, 2.4.1.1

overview, 2.4.1

Oracle Enterprise Manager

directory structure, A

rollup process, 11.3.4.3

Oracle Enterprise Manger

tuning, 11.3.4

Oracle home, 2.3.4 Oracle Inventory Directory, 2.3.1 Oracle Management Agent

cloning

facts, 7.2

in graphical mode, 7.4.1

in silent mode, 7.4.2

overview, 7.1

postclone steps, 7.5

prerequisites, 7.3

supported additional parameters, 7.4.1.1, 8.4.1.1

configuring when protected by a firewall, 10.3.2 deinstallation

deinstalling shared Agent, 16.2.3

graphical mode, 16.2.1

overview, 16

prerequisites, 16.1

silent mode, 16.2.2

installation

packages, 6.3

silent, 6, 6.1, 6.2, 6.3, 6.4, 6.5

installing shared agents

facts, 8.2

in graphical mode, 8.4.1

in silent mode, 8.4.2

overview, 8.1

postinstall steps, 8.5

prerequisites, 8.3

ports, 2.1.7.1 software, 1.3 software-only installation

configuring, 9.5

facts, 9.2

installing, 9.4

overview, 9.1

postinstall steps, 9.6

prerequisites, 9.3

Oracle Management Repository, 11.1 Oracle Management Service, B.1.2.1

configuring for use with a proxy server, 10.3.3.1

configuring to allow incoming data from Management Agent, 10.3.3.2

configuring when protected by a firewall, 10.3.3

Oracle Management Service home directory, A.1.1 Oracle Management Service logs, B.1.2.4 Oracle Middleware home, 2.3.2 Oracle Net firewall proxy access, 10.3.4, 10.3.5 Oracle WebLogic Server, 2.2

admin server

admin server port, 2.2.6

existing admin server, 2.2.3

starting admin server, 2.2.8

verifying admin server, 2.2.7

cluster support, 2.2.2 credentials, 2.2.4, 2.2.4 default version installed, 3.2 domain, 2.2.3 log file output, 2.2.1 manual installation, 3.2 node manager, 2.2.5 verifying, 2.2.1 verifying installation, 2.2.1 Oracle WebLogic Server Cluster, 2.2.2 oraInst.loc file, 4.4.1.2, 4.4.2.2 oraInstroot.sh script, 4.4.1.2, 4.4.2.2 oraInstRoot.sh script, 2.8.2 oraInventory, 2.3.1 other installation logs, B.2.5 overview, 3.1, 4.1, 6, 6.1

P

packages, 6.3, 8.3

permissions, 6.3, 6.3

plug-ins

selecting plug-ins, 4.4.1.3, 5

verifying installation, 6.5

ports, 2.1.7

4888, 10.3.3, 10.3.3.2

4889, 10.3.3.2

admin server port, 2.2.6

Admin Server port, 2.1.7.1, 2.2.6

console ports, 2.1.7.1

custom EM ports, 2.1.7.2

customize ports, 2.1.7.2

default ports, 2.1.7.1

HTTP port, 2.1.7.1

HTTPS port, 2.1.7.1

managed server port, 2.1.7.1

node manager port, 2.1.7.1

upload ports, 2.1.7.1

viewing a summary of ports assigned during installation, 10.2.1

postinstall steps, 3.5 postinstall tasks, 6.5 postinstallation scripts, 7.3, 8.3 preinstallation scripts, 7.3, 8.3 prerequisite checks

default checks, 2.6.1

overview, 2.6

run by default, 2.6.1

run in standalone mode, 2.6.2

running in standalone mode, 2.6.2

prerequisites, 3.3, 4.3, 6.3 privileged delegation setting, 7.3, 7.4.1, 7.4.1, 8.3, 8.4.1, 8.4.1 procedure, 3.4, 6.4 proxy server

configuring Management Agent for, 10.3.2.1

configuring the Management Service for, 10.3.3.1

R

refreshing WebLogic Domain, 13.4.1.2

remote deployment

ADP agents, 12.4.2

ADP managers

JVMD agents, 13.4.2

JVMD managers

RepManager, 2.1.9 RepManager Utility, D, D.1

supported actions, D.2

drop, D.2

dropall, D.2

pluginpurge, D.2

preupgrade, D.2

resume, D.2

transX, D.2

upgrade, D.2

response file, 3.1 rollup process, 11.3.4.3 root.sh script, 2.8.2 RPM File, 16.2.4

S

schemanager, B.1.2.2.1

secure logs, B.1.2.3

self update console, 1.3

setNMProps.sh script, 12.4.1.2, 13.4.1.2

shared agents

auto-discovery of targets, 8.2

compatibility, 8.2

configuring instance directory, 8.2

overview, 8.1

shared oracle home, 8.3 silent mode, 2.1.1, 2.1.1, 4.4.2 software

Enterprise Manager Cloud Control, 1.2

Oracle Management Agent, 1.3

software updates

applying, 2.4.2.2

downloading, 2.4.2.1, 2.4.2.1

overview, 2.4.2

software-only installation, 2.1.3.3 SSH, 7.2, 8.2 SSH ports, 7.3, 8.3 SSH public key authentication, 7.2, 8.2 SSH1, 7.2, 8.2 SSH2, 7.2, 8.2 startScriptEnabled properties file, 12.4.1.2 startScriptEnabled property, 13.4.1.2 startWebLogic.sh file, 12.4.1.2 startWebLogic.sh script, 13.4.1.2 staticports.ini file, 2.1.7.2, 2.1.7.2, 2.1.7.2, 2.1.7.3, 2.1.7.3 SUDO, 7.3, 7.3, 8.3, 8.3 SYSMAN schema, 2.1.9 system prerequisite logs, B.2.3

T

temporary directory

permissions, 6.3

space, 6.3, 7.3, 8.3

thresholds, 11.3.2, 11.3.2 troubleshooting

ADP manager name conflict, G.2.1

Copying ADP Agent Zip or Javadiagnosticagent Ear Step, G.2.4

deploy ADP agent failure, G.2.2

SSL Handshake error, G.2.3

troubleshooting ADP and JVMD, G.2

U

UDP, 10.3.7

uix-config.xml, F.2

uix-config.xml Flag, F.2

upload port, 2.1.7.1

User Datagram Protocol, 10.3.7

USER_MEM_ARGS parameter, 12.4.1.2, 12.4.1.2

V

verifying file size, 1.2.2.2

verifying platform information, 1.2.2.4

W

webserviceclient+ssl.jar file, 12.4.2, 13.4.2.1

web.xml, F.3

wlcipher.jar file, 12.4.2, 13.4.2.1

wlfullclient.jar file, 12.4.2, 13.4.2.1

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.