Sending Authenticated and Anonymous Email from System Center Orchestrator

System Center Orchestrator provides several methods for sending email from a runbook. Perhaps the most commonly used of these is the Send Email activity, which is the only activity in the built-in “Email” integration pack. It allows sending email with a specified “from” address and supports delivery through email servers that require authentication and those providing anonymous relay.

With anonymous relay, you shouldn’t have to provide credentials, since the mail server just asks who you are and trusts you. This isn’t a great idea in the age of spam and email spoofing and should be avoided whenever possible, but in some internal environments that are relatively protected or isolated it can make integration, development, and testing easier.

Anonymous Send Error

In some recent projects I’ve come across an error when attempting to send anonymously through Exchange. The configuration of Send Email looked like this:

 

 

But when sending the email, the activity would fail with the following error message:

 

 

 

Client not authenticated? We shouldn’t need to. What’s going on?

Confirming Server Allows Anonymous Relay

The first thing to confirm is whether the server is actually configured to allow anonymous relay. If you don’t have immediate access to the server configuration, you can test with a simple procedure using telnet as described in this article. In the case of Exchange, anonymous relay is configured within a receive connector, which should have the permission group “Anonymous users” checked to allow anyone to send mail through the server without credentials. A receive connector that only allows authenticated sending:

 

Workarounds

There are a couple ways to deal with the issue, including configuring authenticated sending instead. Let’s look at each.

Option 1: Add a Placeholder Username

It’s not clear what combination of factors is causing this, but a simple workaround that can fix the issue is simply to supply a dummy username, e.g. “anonymous”. After doing this, the email would send successfully:

 

Option 2: Use Authentication

Arguably a better approach is to have Orchestrator authenticate itself while sending, which is a good practice to follow in general. For this to work you’ll need to create an Exchange mailbox for the Orchestrator service account and then configure the SMTP authentication section of the activity with the credentials, like so:

 

 

 

Within the Connect tab, make sure the mail account email address matches the email address of the Exchange mailbox, which can be different than the username.

The Security tab configuration doesn’t come into play for connecting to Exchange, and can be left with the default “Use the security of the account assigned to the service”.

With this configuration in place, you should be able to send via an authenticated connection. Woot.

Option 3: Exchange User Integration Pack

The downside to the Send Email activity with authentication is all the configuration details that would be needed every time you need to use the activity in various runbooks. You could mitigate this somewhat by storing those items as global variables and then referencing them, but this is still extra work. Arguably a better way when using Exchange server is to use the Exchange User integration pack, which allows creating a single configuration for a mailbox account that can be referenced as a single unit when using the alternative activity, Create and Send Email.

This also requires an Exchange mailbox for Orchestrator, but works differently than the built-in Send Email activity type. Instead of just sending through Exchange, you are creating a message in the mailbox and sending from Exchange, as if you had sent from Outlook. This brings some nice advantages for getting fancy, including having every sent email in Orchestrator’s “Sent Items” mailbox folder for historical and troubleshooting purposes, and allowing responses to come back to the mailbox with references to the original message for continuity when processing replies. You can also set some extra properties like sensitivity level or read receipt requests.

To use this option, you’ll need to install the Exchange User integration pack, create a configuration for the Orchestrator mailbox from the Options menu in Runbook Designer, and then use the Create and Send Email activity type.

 

 

Wrapping Up

Hopefully that helps get some emails flowing. If you have other ideas or questions, please let us know in the comments.