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).

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.

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:

Where <database_connect_string> must be in the following format:<database_host>:<database_port>:<database_sid>

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 Configuration Assistant

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:

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>

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>

Remove the Oracle Management Service Instance Base by running the following command:

rm -rf <OMS_Instance_Home>

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:

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:

Resolve the cause of the issue.

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:

Oracle Configuration Manager Repeater 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:

OCM Configuration for OMS 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:

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:

Repository Upgrade Configuration Assistant

(<ACTION> refers to any of the schema actions, for example, PREUPGRADE, UPGRADE, TRANSX, and so on.)

Workaround Steps

Follow these steps:

Resolve the cause of the issue.

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:

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:

Follow the steps listed in Chapter 19 to remove the ADP Manager application and the managed server to which the ADP application is deployed.

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:

Log into WebLogic Administration Console of the domain where the ADP Agent was to be deployed.

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.

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:

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:

In Cloud Control, from the Setup menu, select Security, and then click Privilege Deligation.

On the Manage Privilege Delegation Settings page, do the following:

Select the Sudo or PowerBroker from the type menu.

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.

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:

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.

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: