Configuring the Oracle Management Agent

The Management Agent's role and its history relative to the old Intelligent Agent are covered earlier in this module. This lesson focuses on the actual mechanics of configuring one, an agent still deployed on each target host, still communicating with the OMS, but with real, current specifics worth getting right. Worth remembering while working through this: the agent's own communication protocol moved on the same way Net8-era connectivity guidance has, current environments configure HTTPS and TLS parameters directly rather than relying on anything from that older networking stack.

1. Open the agent's own homepage in the console.
2. Go to Agent, then Properties.
3. Filter to Basic or Advanced settings as needed.
4. Change the values and save.

This requires at least Configure privilege on the agent. To apply the same settings across many agents at once, use Setup, then Manage Enterprise Manager, then Agents, select the agents, and edit properties in bulk rather than one at a time.

The agent's main configuration file lives at:

$AGENT_HOME/sysman/config/emd.properties

Parameter	Purpose
REPOSITORY_URL	The OMS upload URL
EMD_URL	The agent's own listener URL and port
emdWalletSrcUrl	Wallet download URL from the OMS
agentTZRegion	The agent's time zone
Logger.*.filename, .level, .totalSize	Agent log size and level settings

The safe procedure for hand-editing this file:

emctl stop agent
# edit emd.properties
emctl start agent
emctl status agent
emctl pingOMS

For some settings, a dedicated emctl command is safer than hand-editing directly:

emctl config agent updateTZ
emctl resetTZ agent
emctl secure agent

The time zone setting deserves special attention. Confirmed directly from Oracle's own current troubleshooting documentation: if the Management Agent's time zone changes after installation, and the change isn't propagated correctly, the OMS will signal the agent to shut down as soon as it detects the mismatch. Never edit agentTZRegion in the file alone; run emctl resetTZ agent instead, which updates both the agent and reports the change appropriately.

Walked through end to end, changing a logging setting looks like this: stop the agent, confirm it's actually stopped with emctl status agent rather than assuming the stop command succeeded, edit the specific Logger.* line in emd.properties, start the agent back up, check status again, and finish with emctl pingOMS to confirm the agent can actually reach its OMS, not just that the local process is running. Skipping that last step is a common mistake: an agent process can start successfully and still be unable to communicate, which looks identical to a healthy agent until the next scheduled upload silently fails.

Editing one agent's properties by hand doesn't scale past a handful of hosts, which is exactly why the console's bulk path exists. From Setup, then Manage Enterprise Manager, then Agents, selecting multiple agents at once and editing their properties together applies the same change everywhere in one pass, rather than repeating the stop-edit-start cycle host by host. This matters more than it might first appear: a setting like a logging level or a timeout value that's inconsistent across an estate's agents is a common, hard-to-trace source of "why does this one host behave differently" investigations later. Setting it once, in bulk, at deployment time or whenever a standard changes, avoids creating that inconsistency in the first place.

If the 26ai database runs on a managed platform such as Amazon RDS, you don't edit emd.properties on the database host directly; you set the platform's own agent option parameters instead:

• AGENT_VERSION = 24.1.0.0.v1, the only supported version for 26ai
• AGENT_PORT, the port the OMS uses to reach the agent, often 3872
• OMS_HOST and the OMS security group access rules
• TLS_CIPHER_SUITE, restricted for 26ai specifically to TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Agent 24.1 also requires OMS 24.1 specifically; mismatched pairings aren't supported.

Oracle Cloud Infrastructure has its own, separate product also called "Management Agent," used for OCI's Observability and Management Platform rather than Enterprise Manager. It's configured through a response file, typically input.rsp, with parameters like ManagementAgentInstallKey and GatewayServerHost, nothing in common with emd.properties or emctl. If you're configuring monitoring for 26ai and encounter instructions mentioning an install key and a response file rather than an OMS URL and a wallet, you're looking at documentation for this different product, not the Enterprise Manager agent this lesson covers. ^[1]

The quickest way to tell which one you're actually reading about: Enterprise Manager's Management Agent talks about the OMS, wallets, and emctl; OCI's Management Agent talks about install keys, gateways, and compartments. Neither vocabulary appears in the other product's documentation, so a single glance at which terms show up settles the question faster than reading the whole page.

Worth a brief mention, since the name invites the question: the Management Agent shows real autonomy, reactivity, and proactiveness within its own domain, monitoring, alerting, and running jobs without constant manual intervention. But it operates on pre-configured rules and thresholds rather than independent learning or goal formulation, closer to a highly capable, automated system administrator than to an intelligent agent in the AI sense. Worth knowing, not worth confusing with the actual configuration work above.

The next lesson looks at customizing Oracle alerts and reactions.

A short list of the mistakes this lesson's specifics are actually meant to prevent, worth reading back through once the configuration itself is done:

• Editing agentTZRegion directly in emd.properties instead of running emctl resetTZ agent, the single most common cause of an agent that starts, then gets shut down by the OMS shortly after.
• Skipping emctl pingOMS after a restart and assuming a running process means a working connection.
• Editing agent properties host by host across a large estate instead of using Enterprise Manager's bulk-edit path, which is how inconsistent settings creep in over time.
• Following OCI Management Agent instructions, install keys, response files, gateways, when what's actually needed is Enterprise Manager configuration, or the reverse. Checking which vocabulary a given document uses settles this in seconds.
• Assuming a cloud-hosted 26ai target uses the same agent version and TLS settings as an on-premises one, when the managed platform's own certification matrix may require a specific, narrower combination.

[1] Oracle Management Agent (OMA): the lightweight process deployed on each target host to monitor Oracle assets, including Oracle AI Database 26ai instances. It collects performance data, configuration details, and logs, then transmits that information securely to Oracle Enterprise Manager, enabling centralized monitoring and automation from a single console. Not to be confused with OCI's separate Management Agent product.