Standardized Signatures in Exchange Server 2010: enforcing your company’s brand image

How to automatically add dynamic signatures to email messages using the New-TransportRule cmdlet.

After last week’s really great “discussion” about Apple, I have decided to turn back to a more technical topic for tonight’s post. Email signatures… we all know that people try their hardest to make their personal signature as creative and zingy as possible. Don’t believe me, just look at some examples on this posting: http://www.sitepoint.com/blogs/2009/09/18/personalities-of-poor-email-signatures/

Unfortunately, in a corporate environment the powers that be tend to like standardization in how their employees represent the “brand”. After all, a good email signature can help a business be perceived as more professional and can also double as free advertising. Therefore, do not be surprised if someone from above comes to you, the person in the trenches, and asks if you can force everyone in the organization to have the same standardized signature. However, have no fear, like disclaimers the ability to force a standardized signature via a transport rule was first introduced in Exchange Server 2007 and made easier in Exchange Server 2010.

The first step to enforcing a signature is to design the layout for how the signature should look. After all, isn’t the whole point of this exercise to make something that looks nice? Luckily, if you want, you can use HTML to define the signature layout. Furthermore, you can also use information from Active Directory attributes to make up the signature information. Therefore, provided that you took the time to standardize your Active Directory user data, you can make the signatures dynamic and relevant to each user’s current location, name, phone number, etc. For example:

<div style="font-size:9pt;  font-family: ''Calibri'',sans-serif;">
========================================================</br>
%%displayname%%</br>
%%title%%</br>
%%company%%</br>
%%street%%</br>
%%city%%, %%state%% %%zipcode%%</br>
<div><img alt="companyabc.com"  src="http://companyabc.com/logo.png"></div>
========================================================</div>

Seems pretty simple… my only suggestion from a design perspective would be as follows:

1. Try to keep your signatures as short as possible while still providing all of the relevant information.
2. If possible skip the HTML and graphics and just use plain text. Otherwise, your signature might not display correctly depending on the email application the recipient is using (iPhone, Blackberry, non-Windows machines, etc.).
3. Use some sort of delimiter (==) to help set your signature apart from the rest of the email message.
4. Do not overload your signatures with too many contact references. Instead, only use your primary contact preferences and drop the rest.
5. Do not include quotes as they might offend some people or project the wrong message about your organization.

Lastly, there really isn’t any reason to include virus scanning status information.

Once you have the signature designed, the next step is to create the transport rule that will apply the “enforced” signature. To do this, use the New-TransportRule cmdlet. For example:

New-TransportRule -Name 'StandardSignature' -Enabled $true -Comments 'Standard Corporate Signature' -FromMemberOf 'Email Users' -ApplyHtmlDisclaimerLocation 'Append' -ApplyHtmlDisclaimerText '<div style="font-size:9pt;  font-family: ''Calibri'',sans-serif;">========================================================</br>%%displayname%%</br>%%title%%</br>%%company%%</br>%%street%%</br>%%city%%, %%state%% %%zipcode%%</br><div><img alt="companyabc.com"  src="http://companyabc.com/logo.png"></div>========================================================</div>' -ApplyHtmlDisclaimerFallbackAction Wrap -Priority '0'

Once executed, a new transport rule is created that appends an HTML based “disclaimer/signature” to all emails that are sent from users in the “Email Users” group (a group supposedly populated with living email users vs. mail enabled service accounts). However, I could have also used the FromScope parameter defined as InOrganization. This would have applied the “disclaimer/signature” to all emails coming from mail enabled accounts within the organization. But, for this example, I choose to limit the scope.

In addition, you will notice that I’m using variables such as %%company%% or %%zipcode%%. These are actually called transport rule predicates. The predicates that are being used refer to attributes in Active Directory. For a list of supported predicates please use the following URL: http://technet.microsoft.com/en-us/library/dd638183.aspx#PropertyTypes

Well… that’s it, hopefully you find this helpful.

If you like this, check out some other posts from Tyson:

• Using social networks to establish a publicly verifiable level of trust…
• Which browser is more secure IE8, Safari 4, Firefox 3.5, Chrome 4, or Opera 10?
• When a computer science degree matters, and when it doesn't
• Since when did cloud computing become/need a manifesto?
• Why would one phish using a Certificate Authority (CA) as bait?
• Would I trust you, if everyone else trusted you?
• Here is a good question: Is scripting programming or just systems administration?
• Fun with PowerShell 2.0 Eventing!
• Creating a custom 404 page to handle link redirection for ASP.NET web applications

Or if you want, you can also check out some of Tyson's latest publications:

• Windows PowerShell Unleashed (2^ndEdition)
• Windows Server 2008 Unleashed (Yes, I did help on this book)

Lastly, visit the Microsoft Subnet for more news, blogs, and opinions from around the Internet. Or, sign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert)

• Microsoft
• best practice
• ce
• Exchange Server 2010
• signatures