Scenario
For the purposes of this post I will concentrate on the re-branding customer. The re-branding process is occurring because the financial backers made the decision to consolidate all the various subsidiaries into one company in order to save money as well as to create a stronger brand image for their customers. To create the new image, all forms of communication need to reflect these changes. Without revealing the company we’ll review their steps for making this new branded message appear within their email signatures.
Using Exchange Server 2010 as their messaging platform, their options for creating signature range from inserting a signature into a message (at the end, like a disclaimer), creating VBScript for Outlook or use a third-party product. At first they attempted to use Transport rules, using PowerShell with the html signature defined in a variable and applied via multiple rules. One of the issues they have is they have conditional field – if an attribute in AD has no value then it should not display in the signature. There are also two fields that would appear in tandem if a certain AD attribute contained data. Here is some of the sample code they had [cleansed of private information]:
# Define logo and formatting of the logo $Logo = '<br><div style="color:#675C53; letter-spacing: 2px; line-height: 125%;"><a href="http://justaucguy.wordpress.com/"> <img alt="http://justaucguy.wordpress.com/" src="https://justaucguy.files.wordpress.com/2015/02/contoso.png"></a><br></div>' # Display Name $Name='<div style="font-size:12px; font-family: ComicSans; font-color:#000000;"><span style="font-weight:bold;">%%DisplayName%%</span><br></div>' # Title 1 - option, displayed if available $Title1='<div style="font-size:10px; font-family: ComicSans; font-color:#000000;font-weight:normal;">%%CustomAttribute10%%,&nbsp;%%Title%%<br></div>' # Title 2 - always displayed $Titl2e='<div style="font-size:10px; font-family: ComicSans; font-color:#000000;font-weight:normal;">%%Title%%<br></div>'
The above list is a sampling of the 7 or so rules HTML sections for the signature. The reason behind the different variables (one per line) is for formatting and allowing for blank fields to not be populated. To actually apply these to the messages as they let the organization, multiple transport rules were used to apply each of these signature elements to the email messages.
new-TransportRule -name 'Contoso_Signature_logo' -comments 'Contoso Signature - Logo' -FromMemberOf 'signature@contoso.com' -ApplyHtmlDisclaimerText $Logo -ApplyHtmlDisclaimerLocation Append -ApplyHtmlDisclaimerFallbackAction Wrap -ExceptIfHeaderContainsWords 'Default'-Enabled $False -Priority 11 new-TransportRule -name 'Contoso_Signature_Name' -comments 'Contoso Signature - Full Name' -FromMemberOf 'signature@contoso.com' -ApplyHtmlDisclaimerText $Name -ApplyHtmlDisclaimerLocation Append -ApplyHtmlDisclaimerFallbackAction Wrap -ExceptIfHeaderContainsMessageHeader "X-1ReplySigApplied" -ExceptIfHeaderContainsWords 'Default' -Enabled $False -Priority 12 new-TransportRule -name 'Contoso_Signature_Title1' -comments 'Contoso Signature Title 1' -FromMemberOf 'signature@contoso.com' -SenderADAttributeMatchesPatterns 'CustomAttribute2 :\S\S*' -ApplyHtmlDisclaimerText $Title1 -ApplyHtmlDisclaimerLocation Append -ApplyHtmlDisclaimerFallbackAction Wrap -ExceptIfHeaderContainsMessageHeader "X-1ReplySigApplied" -ExceptIfHeaderContainsWords 'Default' -Enabled $False -Priority 13 new-TransportRule -name 'Contoso_Signature_Title2' -comments 'Contoso Signature - Title' -FromMemberOf 'signature@contoso.com'-ExceptIfSenderADAttributeMatchesPatterns 'CustomAttribute2 :\S\S*' -ApplyHtmlDisclaimerText $Title2 -ApplyHtmlDisclaimerLocation Append -pplyHtmlDisclaimerFallbackAction Wrap -ExceptIfHeaderContainsMessageHeader "X-1ReplySigApplied" -ExceptIfHeaderContainsWords 'Default' -Enabled $False -Priority 14
With the transport rules each line of the signature is applied individually. The client ended up with a dozen rules (to handle different scenarios) and was having a hard time managing the end solution that they developed. Excess CPU cycles were also being burned with this implementation.
Solution
The built-in functionality of Exchange Transport Rules can only take a custom signature so far. To truly make a complex signature, either VBScript or a third-party tool needs to be applied. In this case I recommended Exclaimer because it did what they wanted, allowed for RTF signatures and allowed for conditional logic. I also recommended it because I had used it in the past with previous versions of Exchange and had great luck with their support model.
Installation
Exclaimer supports single and multiple server installations (using a file share) and requires the product be installed on the Hub role in Exchange 2010 or the Mailbox role in Exchange 2013. For a single server environment, other than choosing the installation directory, the only concern is the restart of the Transport services on the Exchange server. For an environment with multiple Exchange Servers, each server will need a central reference point for its configuration which can be found on a file server like so:
** NOTE ** The servers will attempt to update the configuration every 5-10 seconds.
Desired Signature
The desired end state signature looks something like this:
The key features, or the hardest to deal with, is the indent of the block of text, the various fields dependent on fields in AD and making sure blank lines are not created if an AD field is blank.
Below is a break down of the fields and how they should operate with Exclaimer configuring them for the users. While the below diagram looks complicated, I am attempting to show all the fields and what information should be displayed:
Configure Template
This now brings us back full circle to why we choose Exclaimer as out solution. This is the template editor, which you can see contains fields that just have ‘Conditional Field’.
The first challenge and the what shows as “Vice President” in the signature screenshot. This field is a custom attribute that contains what is known as a Hierarchical Title, according to what the client has set. This field needed to be displayed if and if the attribute was populated and it needed to be follows by a command and a space because the other title for the user account appear directly after it. In order to accomplish this we need to create a conditional field:
With a conditional field we can choose to add a field if it is not blank, which is what we are doing here:
Notice in the ‘value’ part art the bottom I’ve added the attribute itself, along with a comma and a space to allow for formatting with the title field next to it. If the attribute is blank, neither the attribute, nor the comma or the space would be present.
Just below the titles, another field needed to be populated, NMLS. This particular number is specific to the banking industry and we needed to populate it if a user had this on their AD account. The same field also needed to pre-populate the wording “NMLS #” prior to the number being applies. So we use another Conditional Field and look for this value to be populated:
Other Useful Features
The ability for an administrator to test an implementation without affecting production is very important. Exclaimer has this built-in:
Once the Run Test button, which will display the results of the testing:
Lastly, there are many options that can be configured on a signature:
Another advantage is that an AD security Group and DL could be used instead of just a DL. A Plain Text message can be formatted to HTML and date range could be set as well
Summary
From my experience, if a disclaimer is needed, use the built-in Transport Rules. If a custom signature is needed, Exclaimer (or equivalent) is what should be installed for the client. the flexibility and ability to heavily customize option will save your IT team money. Lastly, Exclaimer support has always been good. For this particular client, we are piloting the software and have not purchased it, yet their support (via IM) has been able to answer all of our question sin a reasonable time.
