Configure Job Credentials and Email in Enterprise Manager 24ai

In the previous lesson, you prepared a Windows account with the batch logon rights and resource permissions needed for host jobs. This lesson connects that identity to Oracle Enterprise Manager 24ai and establishes email delivery for management notifications.

These are two related configuration tasks. Job credentials determine how an operation authenticates to its target. Mail configuration determines how a notification reaches its recipient. A successful host job does not prove that email works, and a successful email test does not prove that the host account can execute a command.

Enterprise Manager 24ai is a separate management platform for supported environments, including supported Oracle AI Database 26ai targets. Oracle Management Service (OMS) coordinates management activity; the Management Agent performs applicable work on managed hosts. The settings in this lesson concern that platform's jobs and notifications.

Understand the Accounts and Settings

The running example uses the illustrative host DBWIN01, Windows identity CONTOSO\em_job_runner, and credential label NC_DBWIN01_HOST_JOB. Replace these with approved values for your environment. The Windows account remains an execution identity on the intended host; storing it in Enterprise Manager does not change the OMS service account.

1. Confirm Prerequisites and Responsibilities

Verify that the target is discovered, its agent is communicating normally, and the account prepared in Lesson 3 is enabled and usable. Check the supported combination of Enterprise Manager release update, agent, plug-in, operating system, and database where applicable.

The administrator submitting a job needs access to the target, permission to submit the operation, and authorization to use its credential. A stored password does not grant Windows file permissions or database privileges. Likewise, an OMS host must be properly managed and authorized before you use it as a host-job target.

Divide responsibilities appropriately. Oracle documents Super Administrator privileges for configuring the site's SMTP gateway. Coordinate that work with the Enterprise Manager platform administrator and mail administrator. Routine job submitters need only their required privileges, not unrestricted administration access. Use individually assigned console accounts rather than shared infrastructure accounts.

2. Register the Host Identity as a Named Credential

A named credential gives stored authentication information a reusable label. In this example, the label identifies credentials for work on DBWIN01; it is different from the Windows username.

1. Open Setup > Security > Named Credentials and select Create.
2. Enter a meaningful name, such as NC_DBWIN01_HOST_JOB, and a description of its intended use.
3. Choose the credential type supported by the Windows host operation and supply the qualified account name and managed secret.
4. Choose the appropriate target association or reusable scope.
5. Validate against the intended target where the workflow offers testing, then save.

Restrict who can use and maintain the credential. An administrator may be authorized to use a stored credential without knowing its password. Permission to use it should not automatically imply permission to change or delete it.

For example, a team member might need to run approved diagnostics while the account owner manages password rotation. Keep those responsibilities explicit. Credential validation is an initial authentication check; it does not prove that every script, directory, or database operation is accessible.

3. Set Preferred Credentials for the Intended Host

Open Setup > Security > Preferred Credentials, select the Host target type, and choose Manage Preferred Credentials. For the example host, associate the prepared credential with the appropriate normal host credential setting and validate it. Specific controls can vary with the installed release update and workflow.

Start with a target-specific assignment so the example account is not accidentally applied to unrelated servers. Broader defaults are useful only when the same authentication design is intended across those targets.

When an operation resolves preferred credentials, the precedence is:

1. The administrator's preference for the specific target.
2. The administrator's default for the target type.
3. A configured and authorized global preference for the target.
4. A configured and authorized global default for the target type.

This is a selection hierarchy, not a password-retry list. A configured credential with an invalid password should be corrected; do not expect authentication failure to try every lower entry. An explicitly selected job credential is a separate choice.

Global preferences require appropriate privileges and deliberate scope. Their existence does not mean that every job uses one global Windows identity. Before submitting work, inspect the actual credential selection.

4. Verify the Job's Execution Context

Create a one-time diagnostic host job, such as VERIFY_DBWIN01_IDENTITY, using the supported Windows command execution workflow. Confirm whether it uses preferred credentials or an explicitly selected named credential.

For a command body executed through the Windows command processor, use:

whoami
hostname

The job type determines how to supply this body; these lines are not a complete API request. Review the job in Job Activity, including output, execution status, and exit details. Confirm that the reported identity and hostname match the intended account and server.

A saved credential, a saved preference, and a successful execution are separate checkpoints. If this test succeeds, validate any required file access with another benign operation. Avoid using a database shutdown, patch installation, or production backup as the first credential test.

5. Configure Email Transport and Sender Identity

Have the authorized administrator open Setup > Notifications > Mail Servers. Current Oracle documentation describes this as opening the Notification Methods page; deployed interfaces can differ in their labels.

Configure the approved sender identity and outgoing SMTP service. Obtain the endpoint, port, authentication method, and secure connection requirements from the mail administrator. Do not reuse host preferred credentials as mail authentication simply because both forms request a username.

Use Test Mail Servers and verify receipt at the address used by that test. Oracle's documented procedure sends the test to the configured Sender's Email Address. That address is distinct from each administrator's notification recipient address.

Mail capabilities depend on the installed update. Oracle documents Exchange Online OAuth 2.0 support beginning with 24ai RU 10, with restrictions including Always-On Monitoring. Consult the applicable mail setup documentation for that deployment rather than assuming every 24ai installation supports the same authentication choices.

6. Configure Recipients and Notification Timing

Decide where notifications should go and who is responsible for responding. An example operations address is dba-operations@example.com; use an approved recipient in the actual configuration.

Set the administrator's recipient address through the account's Enterprise Manager Password & Email page. Review the applicable notification schedule and its time zone. An address can be correct while its schedule excludes the time when an event occurs.

Confirm that the intended recipient has the necessary visibility of the target or source object. For a job-related event, that can involve access to the job. Credential ownership and permission to receive a notification are different concerns.

If using an operations distribution list, confirm its ownership, membership, and delivery restrictions with the mail team. Do not assume that acceptance by the SMTP server guarantees delivery to every member. Keep an accountable recipient arrangement so a message does not arrive in an unmonitored mailbox.

7. Select the Conditions That Should Send Notifications

Use Setup > Incidents > Incident Rules for event and incident routing. Review the rule set's target scope, matching conditions, actions, recipients, and enabled state before saving changes.

For a monitored database condition, choose the relevant target or group and the condition or severity that warrants attention. Configure incident creation and notification actions as needed; creating an incident does not by itself prove that an email action is configured.

Job-status notifications can use the relevant job workflow's notification options or applicable event rules. They should not be treated as though every job email requires a tablespace metric rule.

For example, a tablespace utilization event can be routed to the responsible DBA without writing a Windows batch script to send email. Choose thresholds based on capacity and response needs. A corrective action that executes a command is a separately configured response with its own execution requirements.

8. Test Execution, Transport, and Routing Separately

Complete three checks before calling the setup operational:

1. Execution: run the identity job and verify the account, host, output, and status.
2. Transport: run the mail-server test and verify that the expected test message arrives.
3. Routing: validate one narrowly scoped notification path using an approved test job or event and confirm delivery to the intended recipient.

Use a lab target or an approved test mechanism for the final check. Do not stop a production database, fill a tablespace, or alter production thresholds just to manufacture an alert. Record the event or job identifier and compare its time with notification and mail records.

A successful transport test leaves several questions unanswered: Did the condition occur? Did a rule match? Was its action enabled? Was the recipient eligible at that time? Following those questions in order helps isolate failures without changing unrelated Windows permissions.

Consider an example where the diagnostic job completes and the mail-server test arrives, but the operations team receives no job-failure message. The remaining investigation concerns whether the tested job produced the selected status, whether notification was enabled for that status, and whether the recipient settings applied. Recreating the Windows account would not address those facts.

Troubleshoot the Configuration That Failed

Keep evidence from the failed attempt, including timestamps and non-sensitive error details. Change one relevant setting at a time and repeat the corresponding test. This preserves a clear explanation of what corrected the problem.

Maintain the Configuration

Document the credential owner, Windows execution account, target scope, job credential choice, SMTP configuration owner, and notification recipients. Include the dates and results of the three validation checks. Record dependencies without recording passwords in the document.

Coordinate account password rotation with stored credentials and dependent jobs. Mail authentication has its own maintenance cycle, including any application-secret expiration. Updating one credential does not prove that another independently stored copy has changed.

Review preferences when targets move or staff responsibilities change. A forgotten administrator-specific setting can continue to override an intended global default. Review recipient assignments at the same time so alerts continue to reach the team responsible for the target.

Keep sensitive values out of command bodies and job output. Before expanding a working example to more hosts or recurring schedules, confirm that its credential scope and permissions remain appropriate. The result should be a repeatable configuration whose execution identity and notification path are both understood.

Oracle Documentation

• Configuring and Using Target Credentials
• Specifying Host and Database Credentials
• Setting Up a Mail Server for Notifications
• Notifications
• Creating a Rule to Notify Administrators Based on Event Type
• Monitoring Privileges

Configure Shared Server - Exercise