Oracle Configuration Manager personalizes the support experience by collecting configuration information and uploading it to the Management Repository. The collector of this information can be configured to gather information for all products on the server, or to gather information in separate collection sites.
When customer configuration data is uploaded on a regular basis, customer support representatives can analyze this data and provide better service to the customers. For example, when a customer logs a service request, he can associate the configuration data directly with that service request. The customer support representative can then view the list of systems associated with the customer and solve problems accordingly.
Some of the benefits of using Oracle Configuration Manager are as follows:
Reduces time for resolution of support issues
Provides pro-active problem avoidance
Improves access to best practices and the Oracle knowledge base
Improves understanding of customer's business needs and provides consistent responses and services
The following introductory topics are presented in this chapter:
The new features in the 12.0 release include:
Oracle Configuration Manager Supports Oracle Enterprise Manager Cloud Control 12c Release 2 (188.8.131.52)
Oracle Configuration Manager now supports Oracle Enterprise Manager Cloud Control 12c release 2 (184.108.40.206).
Support for NTLM
Oracle Configuration Manager now supports the NTLM (NT LAN Manager) authorization scheme for proxy servers.
Data Masking Supported for Oracle Configuration Manager Harvester
Oracle Configuration Manager now supports data masking for Harvester. [Enhancement Request 14258759]
Central Collector That You Can Configure to Collect Your Oracle Homes Not Previously Configured or Left Disconnected
You can configure a central collector that collects data for Oracle homes that were not previously configured or left in disconnected mode. The central collector uploads these Oracle homes under its own My Oracle Support credentials. See About the Central Collector.
The Oracle Configuration Manager architecture is displayed in Figure 1-1.
Figure 1-1 displays the following:
Oracle Configuration Manager: This is the Oracle Configuration Manager infrastructure.
Site 1: Systems that are directly connected to the Internet.
Site 2: Systems that are connected to the Internet through a proxy server.
Site 3: Systems that do not have direct access to the Internet but do have access to an Intranet proxy server which in turn has Internet connection through the Support Hub.
Site 4: Systems that do not have direct access to the Internet but do have access to the Support Hub which in turn is connected to the Internet through a proxy server.
You can configure a central collector to collect all the Oracle homes that you own on the host that have a disconnected or unconfigured collector, and upload them under its My Oracle Support (MOS) credentials. To reap the benefits of a collector, such as a personalized support experience, quicker resolution of support issues, and proactive problem avoidance, the configuration data for each Oracle installation must be collected and uploaded. This is normally the task of the collector installed in the Oracle home. However, sometimes the collector in Oracle homes might not have been configured or is left disconnected.
Here are the characteristics of a central collector:
A central collector collects:
Oracle home in which it resides
Oracle homes that you own on the host where the collector is not configured or left disconnected. Central collector considers collectors running in unauthenticated mode as not completely configured and will collect these homes as well.
If a collector in an Oracle home has been configured using a pre-10.3.8 collector and with
ORACLE_CONFIG_HOME defined (shared homes), then the central collector will not collect that home.
You can designate a collector to be a central collector by providing the
-c option to the
If the central collector is running as "root" then it collects all the Oracle homes on the host, unless the home already has a collector or is being collected by a "user" central collector. The Oracle Solaris operating system release 11.1 and any Oracle Solaris 10 release after 8/11 configure a central collector as root by default.
The Oracle Universal Installer central inventory is the source from which the central collector obtains the set of candidate Oracle homes to be collected. This central inventory is found in one of two ways:
oraInst.loc file in the Oracle home in which the collector is being configured,
Or, if not found, from the OUI default central inventory location. See the Oracle Universal Installer and OPatch User's Guide for more detail.
Note:Oracle homes not found in one of the ways above will not be collected by the central collector. For example, if you have installed an Oracle product using your own OUI inventory then that Oracle home will not be found.
Only Oracle Fusion Middleware based products that use Oracle WebLogic and Oracle Database are collected by the central collector.
All configuration data collected by the central collector from Oracle homes is uploaded using the My Oracle Support credentials of the central collector.
The central collector feature is not supported on HP, Linux PPC, Linux Itanium, and Windows platforms. Also, the Java used must be run in 32-bit mode, except on Linux, where Java can be run in 32-bit or 64-bit mode.
Oracle Configuration Manager can be installed in the following modes:
Connected (Authenticated) Mode
This mode is recommended if your server has direct connection to the Internet, connection through a proxy server, or connection using Oracle Support Hub. In this mode, configuration data is automatically collected and uploaded to the Oracle server. In addition, updates to Oracle Configuration Manager occur automatically.
Connected (Unauthenticated) Mode
This mode, though not recommended, is used when only the e-mail address is specified but no password. Though this mode allows you to register and upload data, you are not able to view or use the data collected in the My Oracle Support interface.
This mode is required when your server does not have a connection to the Internet and you cannot configure an Oracle Support Hub. In this mode, you can collect configuration data manually by using the
emCCR collect command. When you run this command, the collected configuration data is stored in the <
jar file. If problems occur, you can then upload this file to Oracle by way of a Service Request and My Oracle Support from another system that has Internet access.
Refer to Section C.3, "
emCCR collect" for details. In this mode, the only commands supported are:
Note:For Fusion MiddleWare 12.1.2, a mini version of the OCM collector kit is included. This version of the kit includes a minimal set of components that are needed for initial configuration. During configuration if the OCM is connected, the remaining components are download and installed.
If the OCM is not connected, the remaining components must be installed manually. You can download the full OCM collector kit from My Oracle Support (download the latest version of the patch for bug 5567658):
Once you have downloaded the patch, update OCM with the following command:
cd $FMW_HOME/oracle_common/ccr/bin/emCCR update_components -distribution=/scratch/distribution/ccr-Production-10.3.8.0.0-Linux-i386.zip
For more details, refer to Section C.16, "
You can switch between Connected and Disconnected modes by using the configCCR command. Refer to Section C.19, "
configCCR" for details.
A shared home is an installation of an Oracle product that can be used and accessed by multiple hosts, or across multiple configurations on a single host. There are shared homes that require special Oracle Configuration Manager setup, and those that do not.
Examples of shared homes that do not require special Oracle Configuration Manager setup are:
When multiple database instances are created on the same host, from a single software installation.
When a single installation is shared across multiple hosts and each host has one or more database instances. In this case, though Oracle Configuration Manager requires no special setup, the collector must be setup separately on each host.
Some software products allow for the installation of the executables to be placed in a shared directory structure. Each use of the product requires a separate directory to segregate the product's run-time specific information.
An example of this is the Oracle Fusion Middleware installation with its separate directories. Typically the product-specific information collected by Oracle Configuration Manager is found in files in each of these separate directories.
To support this type of shared home, Oracle Configuration Manager treats each separate run-time state directory as an
If you have a software installation of this type, read Appendix A, "Shared Homes" before deciding whether you absolutely need shared homes.
Typically, most Oracle homes are not shared Oracle homes, therefore special Oracle Configuration Manager setup is not required.
Important:If you are upgrading from an existing version of Oracle Configuration Manager that is before release 10.2.7, you cannot take advantage of the Shared Homes functionality. This functionality is only available with a new installation of Oracle Configuration Manager release 10.2.7 or later.
To use this feature, you must deinstall the current installation of Oracle Configuration Manager and then reinstall Oracle Configuration Manager release 10.2.7 or later.
The Oracle Support Hub conveys the configuration payload from individual Oracle Configuration Manager instances to the repository maintained at Oracle. The Oracle Support Hub is situated inside the customer network, so that it becomes the only point of access needed between inside the network and the outside Internet.
For the complete description of the Oracle Support Hub, refer to the Oracle Support Hub Guide.
Oracle Harvester (Harvester) collects target configuration data from the Management Repository and uploads it to Oracle.
When Oracle Configuration Manager is configured in Enterprise Manager release 10.2.0.5 or higher, it enables the Harvester functionality. The Harvester job runs every 24 hours and collects configuration data from the Management Repository which Oracle Configuration Manager uploads to Oracle as part of its next collection. Some target types for which data is collected include: Oracle Database, Host, Oracle home, Oracle Virtual Machine, Oracle Real Application Cluster, Oracle Application Server, and Web Logic Server.
If Oracle Configuration Manager is also installed in the actual target home, the data collected by Oracle Configuration Manager in this home overrides data collected by the Harvester from the Management Repository.
Note:For Oracle Harvester to work properly, your installed version of Oracle Configuration Manager (OCM) should be 12.0 or later and the OMS should be bounced. If OCM is not upgraded to 12.0 or later or if the OMS is not bounced, then you may see following error in the
ERROR netmgr.EndPoint log.? - Invalid response from OMS [https://ccr.oracle.com,Gone]
Much of the configuration information collected by OCM may be collected by other means when there is a support issue. OCM simplifies this data collection, improves the accuracy and reliability of the information and provides secure transmission of the data back to Oracle.
Oracle security teams carefully review all proposed enhancements to OCM to ensure that all data collected is used only to facilitate more efficient use of Oracle products and services, including Oracle Support.
Note:OCM does not collect business transactions, production data, or passwords.
The following security topics are presented:
When transmitting data between your site and Oracle, a key security concern is to ensure that only Oracle accesses the data. To protect against unauthorized access, Oracle uses Secure Socket Layer (SSL) and HTTPS for all communications.
When transmitting data, the first step authenticates Oracle as the recipient by interrogating the certificate returned by the server. A recognized certificate authority, specified by Oracle, issues the certificate to Oracle Corporation.
Once authentication is complete, OCM requires that 128-bit encryption using public/private key exchange (otherwise known as asymmetric encryption) be used for all communications. OCM initiates outbound communications with Oracle and does not listen for inbound communications, so that your firewall protections are preserved.
If you are unable to establish an HTTPS connection from your environment, OCM can be configured to run in disconnected mode. While running in disconnected mode, OCM will not collect data automatically nor attempt to connect to Oracle; performing a configuration collection produces an output file that can then be manually uploaded to Oracle by way of My Oracle Support.
OCM permits your users to view and verify the configuration data that is collected and transmitted to Oracle. The output of configuration collections is stored on the local host for viewing; those XML files are the ones uploaded to Oracle. These XML files may be found in the
OCM_INSTALL_ROOT/ccr/host/<host name>/state/review directory.
Refer to the Oracle Configuration Manager Collection Overview for a listing of all the configuration parameters that OCM can collect (any individual collection will contain a subset of these configuration items).
The customer configuration repository (CCR) is secured inside the Oracle data center and protected by Oracle network security infrastructure and security teams. All access to the CCR goes through a rigorous security review.
Traditionally, data is collected from a database by making a connection to the database and passing user credentials. The disadvantages of this approach are that credentials have to be stored and password changes have to be tracked over time.
OCM has implemented a different approach:
OCM instructs the database to collect its own configuration and write that configuration to a report or file within the
$ORACLE_HOME/ccr/state directory. The output may also appear in the
OCM_INSTALL_ROOT/ccr/host/<host name>/state directory, depending on the configuration settings.
Only the owner of Oracle home can read the contents of the configuration report generated.
During the installation of OCM, the
installCCRSQL.sh script creates an account in the database to house a PL/SQL procedure, installs a PL/SQL package and sets up a DBMS job so that the procedure is executed on a regular basis.
To avoid security vulnerabilities, the account that OCM creates is immediately locked and the password expired. This can be done because OCM does not connect to the database for collections. The account is only needed to house the PL/SQL procedure.
Auto-update provides the ability to automatically detect, authenticate and apply the latest package updates to OCM. This allows you to maintain the OCM software without the need to apply patches or upgrade software or configuration over time. By default, auto-update capability is enabled when you install and configure OCM.
As with any interaction with Oracle Support, the communication link is authenticated and encrypted. Once the server is authenticated, any OCM package updates, which are digitally signed by Oracle, are downloaded to a staging directory. Before an update is applied to the OCM installation, the digital signature is validated. This process confirms that the update was signed with a certificate issued to Oracle by a specific certificate authority. This certificate is different from the certificate used to secure the communications link. The update is applied to the OCM installation only if this entire process passes validation.
Lifetime Support of an Oracle Configuration Manager (OCM) release means that Oracle will investigate issues related to the OCM collector. Once a release is no longer supported, you must upgrade to a newer release to continue receiving support.
Note:If you have a current support contract in place, then you are entitled to Premier Support, Extended Support, or Sustaining Support based on where your product version is in the Lifetime Support cycle.
Every minor or patch release within a major release of OCM will be supported for up to 12 months after the release of the next major release of OCM. In the event the current major release is the terminal release for this product line, it will be supported for 3 years from its initial release date.
Note:Starting with OCM release 10.3, the concept of mandatory updates, as defined for releases before OCM release 10.3, is now obsolete.
OCM Release Numbering Scheme Examples
|Release Example||Release Type|
|16 to 17||Product Family (marketing version) release|
|16.3 to 16.4||Major release|
|16.3.1 to 16.3.2||Minor release (part of 16.3 major release)|
|220.127.116.11 to 16 3.1.2||Patch set release (part of 16.3 major release)|