One challenge enterprises face when moving all email to Office 365 is maintaining centralized signatures. Most options for on-premises Exchange intercept mail on the Exchange Server. If a client-side add-in to Outlook isn't viable, you'll need to assess other options.
Office 365 provides some signature management options, and while they likely won't be as good as third-party options, they are still adequate. Here, we'll look at the issues you face when implementing signatures in Office 365 and offer some options for resolving them.
In on-premises Exchange, mail flows through servers with the Hub Transport role, which is effectively the Message Transfer Agent (MTA) component of Exchange Server. Third-party signature software plugs into this layer to insert signatures after clients send mail. Third-party options usually are Transport Agents, which plug in at the message transfer stage and allow the third-party custom code to process all messages.
Challenges with an Office 365 move
In Office 365, you can't install any Transport Agents on Microsoft's infrastructure. If you want to continue using existing signatures, you'll need to stay in a hybrid setup and route mail through one or more hybrid Exchange Servers using the Centralized Transport option in the Hybrid Configuration Wizard. This requires your on-premises infrastructure for outbound mail flow.
The hybrid server license is free and doesn't require you to size mailboxes. In addition, it's relatively easy to build a simple high-availability hybrid infrastructure. You're relying on your on-premises infrastructure anyway if you use Active Directory Federation Services (AD FS), so this might not be as big of an issue as you think.
If you want to use what's provided to implement signatures in Office 365, you have two main options: use transport rules or apply individual signatures through PowerShell. We'll walk through both options and look at the benefits and downsides of each.
Use transport rules to apply signatures in Office 365
If you want the ability to add a simple signature that can be customized to each end user, one or more custom transport rules might be the right option.
Transport rules can apply a custom HTML signature to each message using attributes from the local AD; if you aren't using DirSync, use the values configured in Office 365 for the mailboxes. Each value, such as the person's first name, can be contained within the template, for example:
The values listed on TechNet are used within the HTML, but they are enclosed in double percentage marks (%%) so they can be replaced in transit.
The primary limitation of using transport rules is they work using the same technique as disclaimers in Exchange, meaning they are added to the end of each message. If you choose to always add the signature, it won't show correctly when replying to mail since it will be inserted at the bottom of the email chain rather than directly after the text in the most recent reply.
One way to fix this is to only add the signature to new messages, and it will look for messages that don't yet have a Received header set. Test this first to see if it works correctly in your environment.
Configure the transport rule to add signatures with the following options:
- Apply the rule if the sender is located inside the organization.
- Append the disclaimer with the text shown above, and if it can't be added, fall back to ignore and continue, unless the header Message-ID is set and contains "<".
To create this rule, open the Exchange Admin Center and navigate to Mail Flow. In Rules, choose Add and then Apply Disclaimers (Figure 1).
Next, specify the settings for the rule as defined above (Figure 2).
In this example, we've potentially used the simplest method to apply signatures -- and we have a range of options if we want to be specific. For example, if we wanted to apply different signatures based on the recipient, such as only adding a signature to messages destined for external recipients, we could add a condition (Figure 3).
To see the results of the transport rule, send a test message. We won't see the disclaimer as we send it, but the test recipient should see the signature applied (Figure 4).
Apply signatures in Office 365 via PowerShell
If using a transport rule to apply signatures doesn't meet requirements, the second approach is to apply centralized signatures to individuals using PowerShell. You need to have custom HTML code for each end user, or potentially write a script that takes a HTML template similar to our transport rule example and replaces values based on those in AD via the script.
For our example, this script will set the signature on one mailbox with the following base HTML:
Then save the HTML contents to the file: Signature.html. To apply the signature, connect to Exchange Online using PowerShell:
After connecting via Exchange Online PowerShell, use the Set-MailboxMessageConfiguration cmdlet to set the signature to appear automatically:
Although this uses PowerShell, the signature remains visible from an end user's perspective. It can be edited in the Outlook Web App (OWA) options page (Figure 5).
Admins would lose central control, but would gain the benefits of normal signature options. Even so, you'd still have some control if you re-apply this using a script on a daily basis. It's automatically added to messages sent to external recipients in Outlook, on mobile devices or in OWA.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and with Office 365 since its origins in Exchange Labs and Live@EDU.