Transport Rules

[David]

Transport Rules



Transport rules let you apply messaging policies to e-mail messages that flow through the transport pipeline on Hub Transport and Edge Transport servers. These rules allow information technology (IT) administrators to comply with messaging policies, secure messages, protect messaging systems, and prevent information leakage.

• Preventing inappropriate content from entering or leaving the organization
  
• Filtering confidential organization information
  
• Tracking or archiving messages that are sent to or received from specific individuals
  
• Redirecting inbound and outbound messages for inspection before delivery
  
• Applying disclaimers to messages as they pass through the organization
  

Transport Rule Components
Conditions : Transport rule conditions are used to identify messages to which a transport rule action should be applied. Conditions consist of one or more predicates that specify the parts of a message that should be examined. Some predicates examine message fields or headers, such as To, From, or Cc. Other predicates examine message characteristics such as message subject, body, attachments, message size, and message classification. Most predicates require that you specify a comparison operator, such as equals, doesn't equal, or contains, and a value to match

This example returns all available predicates for transport rules used with the Transport Rules agent.

Get-TransportRulePredicate

This example retrieves the single predicate SubjectMatches. The command is piped to the Format-List command to display detailed transport rule predicate information.

Get-TransportRulePredicate -Name SubjectMatches | Format-List

Exceptions :
Exceptions override conditions and prevent actions from being applied to an e-mail message, even if the message matches all configured conditions.
Exceptions are based on the same predicates used to build transport rule conditions. However, unlike conditions, exceptions identify messages to which transport rule actions shouldn't be applied.

Actions : Actions are applied to messages that match the conditions and don't match any exception defined in the transport rule

Transport rules have many actions available, such as rejecting, deleting, or redirecting messages, adding additional recipients, adding prefixes in the message subject, or inserting disclaimers and personalized signatures in the message body.

This example returns all available transport rule actions for transport rules used with the Transport Rules agent.

Get-TransportRuleAction

This example retrieves a single transport rule action. The command is piped to the Format-List command to display all properties of the transport rule action.

Get-TransportRuleAction -Name DeleteMessage | Format-List

---

Rules Agents
Transport rules are applied on Hub Transport and Edge Transport servers by transport agents. On the Hub Transport server, rules are applied by the Transport Rules agent. On the Edge Transport server, this is the job of the Edge Rules agent.

Transport Rules Agent
The Transport Rules agent processes transport rules on Hub Transport servers.All messages in an Exchange 2010 organization are touched by at least one Hub Transport server.(Including Messages to and from users in the same Active Directory site, including users with mailboxes on the same Mailbox server)
Transport rules configured on Hub Transport servers are stored in Active Directory, making them accessible to all Hub Transport servers in the organization as the configuration is replicated to all domain controllers across the Active Directory forest. This allows Exchange to consistently apply a single set of rules across the entire organization. Each Hub Transport server queries Active Directory to retrieve the organization's current transport rule configuration and then applies the rules to messages it handles.
Note : Replication of transport rules across an organization is dependent on Active Directory replication. Replication time between Active Directory domain controllers varies depending on the number of Active Directory sites in the organization, slow links, and other factors outside the control of Exchange. When deploying transport rules, consider replication delays.

Edge Rules Agent
The Edge Rules agent processes transport rules on Edge Transport servers.The Edge Transport server, which serves as an e-mail gateway to and from external messaging systems, is the ideal place to apply messaging hygiene and policy to inbound Internet e-mail. Rules applied by the Edge Rules agent can reduce the total number of messages delivered to and processed by Hub Transport servers, and ultimately delivered to recipients. The agent can also help remove any harmful or objectionable message content.Outbound Internet e-mail can also be subjected to similar policy-based scrutiny, and harmful or objectionable content can be prevented from leaving the organization. Additionally, message content can be checked to prevent sensitive information from being leaked outside the organization.

Transport rules configured on Edge Transport servers are stored in Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM), on each Edge Transport server. Rules configured on one Edge Transport server aren't automatically replicated to other Edge Transport servers in your organization, with or without the use of EdgeSync. Depending on your requirements, you may want to configure each Edge Transport server with identical transport rules, or you may want to configure different transport rules on different Edge Transport servers that address the unique e-mail message traffic patterns of each server. To duplicate rule configuration, you can use the Export-TransportRuleCollection and Import-TransportRuleCollection cmdlets.

Export - EXAMPLE 1
--------------------------------------------------------------------------------

This example exports transport rules on an Exchange 2010 Hub Transport or Edge Transport server. Rule data is exported to the variable $file, and then written to the XML file Rules.xml in the C:\MyDocs folder

$file = Export-TransportRuleCollection
Set-Content -Path "C:\MyDocs\Rules.xml" -Value $file.FileData -Encoding Byte

EXAMPLE 2
--------------------------------------------------------------------------------

This example exports legacy transport rules created in Exchange 2007 using the ExportLegacyRules switch. The cmdlet should be run from an Exchange 2010 Hub Transport server. The exported rules collection can then be imported to Exchange 2010 using the Import-TransportRuleCollection cmdlet.

$file = Export-TransportRuleCollection -ExportLegacyRules
Set-Content -Path "C:\MyDocs\LegacyRules.xml" -Value $file.FileData -Encoding Byte

Import - EXAMPLE 1
--------------------------------------------------------------------------------

This example imports a transport rule collection from the XML file ExportedRules.xml.

[Byte[]]$Data = Get-Content -Path "C:\TransportRules\ExportedRules.xml" -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data

---

Using Exchange Hosted Services
Transport messaging policies are enhanced by or are also available as a service from Microsoft Exchange Hosted Services.

Exchange Hosted Services is a set of four distinct hosted services:

Hosted Filtering, which helps organizations protect themselves from e-mail-borne malware

Hosted Archive, which helps them satisfy retention requirements for compliance

Hosted Encryption, which helps them encrypt data to preserve confidentiality

Hosted Continuity, which helps them preserve access to e-mail during and after emergency situations

These services integrate with any on-premises Exchange servers that are managed in-house or Hosted Exchange e-mail services that are offered through service providers

[Alex]

Creating and using Transport Rules in exchange 2010

Example we have two users: Clark Kent and John Hammond. We must validate that no messages can be sent between them, except messages with a subject including the words: Ticket or Case. With this feature, we can get internal traffic protection; avoiding that vital information leaves the organization or is exchanged between users, depending on your own criteria

This scenario is called Ethical Wall, because we can protect the message flow between users and groups based on transport rules
To create rule, we will need to expand the Organization Configuration, click on Hub Transport in the left pane of the Exchange Management Console, then click on the Transport Rules Tab and finally clicking on New Transport Rule on the Action Pane, as shown in below image



In New Transport Rule Wizard, we should fill out the Name and Description and make sure that ‘Enable Rule’ is selected. After that click Next



Conditions:
We can define from who or to a message is going, based on string or message fields or some address inside the fields (To:, From: or Cc). In this example mark From People and you can see in Step 2 the construction of the rule, like the Rules and Alerts in Outlook.

During step 2 click on the ‘people’ link to select the users for this rule



In the new window, we can choose the users that will be affected by this rule, click Add, select user(s) and click OK



We’ve just selected the users in the “from people” condition. After that, we will need to tick “sent to people” and select the “target” user for this rule.

Note:
When we have more than one item ticked in conditions, we have a logical 'AND', so it means that the transport rule will be processed only if all the conditions are valid. If not, the rule will not be executed.



ACTIONS:

In the New Transport Rule Wizard page, tick “send rejection message to sender with enhanced status code" With this option selected, when a users (in this example) sends a message to the selected user (in this example), the sender will receive a predefined bounce message.



To customize the message that will be displayed in the return message, we will need to click the link “Rejection Message” in Step 2 and then customize the content for the bounce message



click on enhanced status code and type 5.7.1 or any valid value , valid values are between 5.7.10 and 5.7.999



we have completed the Conditions and Actions; it can be reviewed in below image



Exceptions:
In this case all messages from those users from and to each other will be blocked, except those e-mail messages including the words ticket and case in the subject. To do so, tick “except if with specific words in the subject” and then click on the link in Step 2 and add your exception words on the next screen. After that, we can see the result of configured Exception as in belo image





click new


click finish



Power shell command to do the same:

Exchange Management Shell command :
New-TransportRule -Name 'Blocking suspicious messages between Clark Kent and John Hammond' -Comments 'This rule is to only allow message sthat meet specific criteria ( words in subject line)
This rule blocks messages between Clark Kent and John Hammond
except messages with a subject including the words ''Ticket'' or ''Case''' -Priority '0' -Enabled $true -From '[e-mail]','[e-mail]' -SentTo '[e-mail]','[e-mail]' -RejectMessageReasonText 'You are not authorised to send this message - Blocked by exchange administrator' -RejectMessageEnhancedStatusCode '5.7.10' -ExceptIfSubjectContainsWords 'ticket','case'

In this case we have a warning :
No custom DSN text is configured for the enhanced status code '5.7.10'. You can use the New-SystemMessage cmdlet to customize DSNs.

This is because: If you specify a DSN code other than 5.7.1, you must create a custom DSN message to associate with that DSN code. If a matching DSN code doesn't exist, Exchange 2010 uses the 5.7.0 DSN code.

Note: If you use the Shell to create a transport rule that uses the RejectMessage action, you can create the rule without specifying the rejection message. If you don't specify the rejection message, the following default rejection message is used: Delivery not authorized, message refused. If you use the New Transport Rule wizard in EMC to create the rule, you must specify both the rejection message and the enhanced status code.


Creating Custom DSN Message Association
You use the New-SystemMessage cmdlet to create a custom DSN message for a DSN code. After the custom DSN message is created, Exchange 2010 automatically uses it when rejecting a message with the specified DSN code. If you specify the same custom DSN code in multiple transport rules, the DSN message is inserted in the NDRs that are generated by those transport rules.

Note: If you want to change the default text associated with the 5.7.1 DSN code, you must create a new custom DSN message by using the New-SystemMessage cmdlet. However, if you do this, the new text will be displayed any time that the 5.7.1 DSN code is used, including for messages that are rejected by other components of Exchange transport. Therefore, we recommend that you create a new DSN code for specific transport rule actions.

This example creates a custom DSN message with the DSN code 5.7.10. The DSN message is created in English. The message also includes a link to an internal Web site, which can provide more details about the organization's messaging policies.

New-SystemMessage -DsnCode 5.7.10 -Language En -Internal $True -Text 'Sending certain messages between specific users is prohibited by company policy #123. For more information, see <a href="http://intranet.messagingtechs.com/policy.html#123">Compliance Policy 123</a>.'

The following figure shows the result of entering the preceding command in the Shell.



We can select the rule and all the possible actions are also enabled in Action Panel. There are now some actions to assign to this rule: Disable rule, Edit and Remove

---

Example of an NDR with a Custom DSN Message

After you've created a custom DSN message for the DSN code you specified in the RejectMessage transport rule action, Exchange 2010 can use the custom DSN code and message in NDRs to senders whose messages are blocked by that transport rule.

when try to send message ( For which we have created trasnsport rule to block)


It is blocked and NDR sent


The messages which are as per the exception criteria are delivered.



Received

[Alex]

Restricting users to send and receive external messages

Topics that we are going to cover in this article:

• Block any incoming mail to that user
  
• Block that user from sending outbound messages
  
• Allow that user to send messages to a specific user outside
  
• Allow the user to receive external messages from a specific domain
  
• Allow that user to send messages to a specific domain only
  

Idea here is to provide some possible ways to accomplish this kind of task, for your personal environment or for the entire network. You can also combine more than one of the possible scenarios above to accomplish your requirements.

Managing the inbound traffic to a specific user
There are several ways to manage the incoming traffic to a specific user. We can create Transport Rules, configure Recipient Filtering, change at mailbox level and so on.

The first option is to use Transport Rules. This feature allows us to create a rule to return a NDR to the sender, for example, saying that this specific user does not have permission to receive Internet mail.

Create New Transport Rule


In the Conditions page. Select the from users inside or outside the organization item and sent to people item as well.


Select from 'outside the organization'
and select the to recipient/user



In the Actions page, select the option send bounce message to sender with enhanced status code, you can go to Step 2 box, and change the text of the message and status code as well


Exchange Management Shell command :

New-TransportRule -Name 'Block the incoming traffic to a specific user' -Comments 'the incoming traffic to a specific user - Drew' -Priority '0' -Enabled $true -FromScope 'NotInOrganization' -SentTo '[e-mail]' -RejectMessageReasonText 'delivery not authorised as per company policy' -RejectMessageEnhancedStatusCode '5.7.1'

---

A second option is using Recipient Filtering anti-spam agent, it is enabled by default in an Edge Transport Server. However, if you are using the Hub Transport role to receive internet mail you need to enable the Anti-Spam Transport Agents.Either way, the process to configure the Recipient Filtering is very similar to the previous one

By default on Transport Server we dont have the option as below image:


Installing the Anti Spam agents on a Hub Transport Server

1.Open the Exchange Management Shell.
2.Go to the scripts folder in Exchange Server 2007 installation folder (the default path is C:\Program Files\Microsoft\Exchange Server\V14\Scripts).
3.Go to the Scripts subfolder.
4.Run the script called Install-AntiSpamAgents.ps1, as shown in Figure 10.
5.Restart-Service MSExchangeTransport.




check service status in windows command prompt (not powershell)


Close and open the exchange managemnet console
After that process, we can see a new tab called Anti-spam under Hub Transport icon at Organization level.



Now we can start to work on the Anti-spam to protect our Exchange Server.
How about the Attachment filtering? This feature is only available on the Edge Transport Server role, but we can use Microsoft Forefront Security for Exchange that includes this functionality with extra options to filter attachments, and it can be installed on a single Exchange Server box.


on Hub Transport
Click on Anti-spam tab
Double click on Recipient filtering
Click on Blocked Recipients tab
Check the Block the following recipients option and type in the internal users that you want blocking Internet mail





The result, as you may expect, is that any message sent from the Internet to [e-mail] will return a NDR saying that the user does not exist in our organization.

---

Third Way
Well, sometimes blocking external incoming traffic to a user is not enough and you want to make the restriction a little tighter. Restricting a user to only receive messages from his boss and no other email client is one such example.

Note:
You can also accomplish this requirement by using Transport Rules, however the objective of this article is to give extra options and so, I opted to configure it at mailbox level.

The configuration process is as follows:
Open Exchange Management Console
Expand Recipient Configuration
Click on Mailbox
Double click on the mailbox that you want to restrict
Click on Mail flow settings tab
Click on Message Delivery Restriction and click on Properties
On this page, we are able to restrict the user to accept or reject message from specific users. This user can only accept messages from authenticated users

---

---

---

Managing outbound traffic

To block their ability to send external ( or can be used also for internal) messages.

New Transport Rule



In the Conditions page, select the from people item and from people inside or outside the organization item.
In the Step 2 box you can define the previous items values, make sure that on the first one (from people link) you selected all users that are not allowed to send messages out, and on the second one the value Outside is selected




In the Actions page, select the option 'send rejection message to sender with enhanced status code', you can go to Step 2 box and change the text of the message and status code as well. In this case we are going to change the text to “You are not allowed to send external messages".

Exchange Management Shell command completed:
New-TransportRule -Name 'Block User From sending mails atht meet specific criteria' -Comments 'Block user (Jimmy Shergil) from sending mails to external users
' -Priority '0' -Enabled $true -From '[e-mail]' -FromScope 'NotInOrganization' -RejectMessageReasonText 'You are not allowed to send external messages' -RejectMessageEnhancedStatusCode '5.7.1'

The result will be that any message sent by our test user to external users will generate an NDR on his mailbox and the external end-user will be able to see the information about the internal policy that we have just added in our Transport rule

---

Dealing with exceptions in Rules

To allow an internal user to send messages to a specific external domain. You do have the option to create a contact and specify that contact in the exception but it is not possible to do that when the requirement is an entire domain. Let us say that the requirement is that an internal user is able to send messages to any recipient at either Microsoft.com or live.com, well that is a big deal because if the users has a lot of contacts on those domains the contact creation will be painful and unmanageable.

Let us edit the transport rule that we created to block external messages from our organization, and instead select the item 'except when the text patterns appears in a message header' in the Exceptions page. Click on the message header link; type in TO and click on the text patterns link and finally, type in @domain.com$ (where @domain.com can be substituted by any domain that you have in your requirements).

We are going to use a RegEx expression to match the domain(s) that we want to be accepted from our current transport rule. When you see the expression “@domain.com$”, any text that contains that string will be matched, for example: [e-mail], [e-mail].
However if the user tries [e-mail] it would not work.




Exchange Management Shell command completed:

Set-TransportRule -Identity 'Block User From sending mails atht meet specific criteria' -Name 'Block User From sending mails atht meet specific criteria' -Comments 'Block user (Jimmy Shergil) from sending mails to external users
' -ExceptIfHeaderMatchesMessageHeader 'TO' -ExceptIfHeaderMatchesPatterns '@microsoft.com$','@live.com$' -ExceptIfFromAddressMatchesPatterns $null

Now, using the concept we have just seen, we can create an exception for the Inbound Internet mail by editing the existent transport rule and adding the item except when the text patterns appears in a message header item in the Exceptions page. Then, you need to add the text “FROM” on the message header link, and in the list of the domains accepted using the same pattern that we used before (@domain.com$).

[Alex]

Transport Rules to moderate messages in Exchange Server 2010

let’s create a scenario where we have a small company with some requirements to moderate messages using Transport Rules. In this company for the sake of simplicity we have a Finance department that has 3 mailboxes: User01 (Tim), User02 (Leh) and Manager01 (Alan Grant); and also a Directors Group that consists of all directors of the company. ( Steven Spielberg)

Active directory Groups : "Managers Group" and "Directors Group"

All users have their manager configured properly in their Active Directory attributes




If your company uses the Manager attribute properly it will be easier to control some Transport Rules because they can be based on that attribute.
OR if your company is too big or you don’t have the habit to configure it we can use a fixed address for moderation purposes and in that case you always have to remember to change the Transport Rule when a new moderator is required.

Using Manager Attribute to moderate messages

One of the advantages of using Transport Rules instead of Distribution Groups is that you can moderate any messages based on your Transport Rule conditions.
For example, you can manage messages sent to a member of a specific Distribution Group.
If you are using just Distribution Group moderation then it becomes tougher to control because it will take action only when the message is addressed to the group not to a specific individual.

Example:
Let’s make sure that all messages from Finance department (e.g. Tim or Leh) to the directors group (e.g. Steven) are not sent immediately but instead the messages will be moderated by the current Manager (e.g. Alan Grant) of Finance area.

New Transport Rule
In the Conditions page. We have a couple of options here but based on our scenario we want to make sure that any employee that belongs to the Finance Department when they try to send messages to any member of the Directors then the moderation will occur.



The key point here is to make sure that all Finance guys belong to the Finance group and the same for Directors members into the Directors group.
A simple way to do that is click on the options 'from a member of distribution list' and 'sent to a member of distribution list'





In the Actions page. We have two options which are :
'forward the message to address for moderation' where we can define a specific address and this option can be okay if you don’t change too often the Manager of the department, at least make sure that the Transport rule is updated in case of any change in the department’s manager
Another option is 'forward the message to the sender’s manager for moderation' and this one is that we are going to use.



shell command

Exchange Management Shell command completed:
New-TransportRule -Name 'Message Moderation' -Comments 'Messages from Finance ( Tim or Leh) to Director ( Steven) are not sent directly but needs approval from their Manager (Alan)' -Priority '0' -Enabled $true -FromMemberOf '[e-mail]' -SentToMemberOf '[e-mail]' -ModerateMessageByManager $true

Note: In above rule description we have just mentioned the names of users for understanding as an example, actually its - All users of Finace Group send message to Any member of Directors Group It will go for moderation ( approval) to the manager of the user



Rules with lower priority are applied first. Transport rule priority values range from 0 to n-1, where n is the total number of transport rules.

Lets Test the rule:




Based on the set rule, the message won’t be delivered to the recipient ( director -Steven) but the message must be approved first by its manager ( Alan). In the managers mailbox, either using Outlook Web App or Outlook client a message starting with the subject Approval requested: <Original Subject of the message> will be found in the Inbox. The manager has two main options: Approve which will allow the message to be delivered to the recipient’s mailbox or Reject which can be in silent mode through the option Send the response now or we can give a reason why the message was rejected using the Edit the response before sending option.



Note:
when moderating using Outlook Web App the message must be opened in order to show both options (Approve and Reject), those options do not show up in the message preview.

e.g. If approved - The message ( Approval assistant Message) will be deleted from the managers Inbox. Message will be delivered to the recipient. No notification will go to sender.

If rejected - The Manager can put a comment while rejecting





If the moderator decides to reject the message, the sender who started the mail will receive a message from Microsoft Exchange Approval Assistant saying that it was rejected but the moderator information won’t be displayed, as shown in below image



Now that we have seen how to moderate messages ( above exaples) we can just adapt the conditions to best fit your organization requirements, for example:
If your company requires all messages sent internally to a specific user (for example your CEO) to be moderated by his assistant. Then, just change the Condition to From users that are inside or outside the organization and select inside; and make sure that the assistant mailbox is configured in the moderation;
If your company requires that messages between 2 groups must be moderated, then we can take advantage of the condition between members of distribution list and distribution list and after that select both groups and address for moderation.

[Alex]

Automatically add email signatures/disclaimers in Exchange 2010

Exchange 2010 - Transport Rules : allows organizations to centrally manage email signatures and email disclaimers – it gives a consistent bing on your email communications, and you’re not relying on end users to set them up correctly and keep them consistent.

Applying signatures this way should also save you space in your mailbox databases, due to the fact that signatures won’t be added on to each message in every users “Sent Items” folder.

New transport rule
conditions

actions


To get started with a basic signature, open the Exchange Management Console, and navigate to: ‘Organization Configuration’ >> ‘Hub Transport’, then select the ‘Transport Rules’ tab, finally click the ‘New Transport Rule’ link in the actions pane on the right. The Transport Rule wizard should then start, you’ll need to provide a name for your rule, and then select which user or group of users this rule should apply to. In your first instance, it’s probably a good idea just to apply it to yourself to test with, later you can apply the rule to other individuals, distribution groups etc. Have a look through the options available to you in step 1, they are quite flexible with who the rules can be applied to. In step two of the transport rule wizard, you will need to chose the ‘append disclaimer text’ action, and then enter your text by clicking the appropriate hyperlink in the bottom pane of the wizard.



Dynamic email signatures

The best aspect of adding signatures via Exchange transport rules is the fact that certain attributes from Active Directory can be dynamically inserted into the signatures – just insert the attribute name into the disclaimer text in the transport rule, with ‘%%’ on either side of the attribute name (e.g. %phoneNumber%). Unfortunately not all AD attributes will work, but there are a number of useful ones available, the full list is provided on Microsoft TechNet.

For our next signature, go back and edit the previous transport rule you created, and edit the disclaimer text to include some dynamic attributes. We will also need to add some very basic HTML to format the signature:





Now when a mail matching our criteria is processed by Exchange, it should have our name added in bold, along with our phone number. You could get more creative with the HTML in the signature, inserting company logos, or creating tables.

Text only email signatures

If you’re sending a text only email (Many mobile devices will send these out – including iPhones and Blackberries), Exchange will have to convert your signature to a text only format. It’s always a good idea to check what the converted version looks like – especially if you’ve used a lot of HTML.

It’s also worth noting that a bug in pre SP1 meant that when Exchange converted HTML messages to text only, the signature ended up with <html> and <body> tags at the start of it. This issue was fixed in Exchange SP1.



Before we move on to step 3 of the wizard, you should be aware that signatures and disclaimers can only be appended to the absolute end of emails. If you want to have a signature at the end of each reply, you will need to look into 3rd party solutions. Due to this fact, I always add an exclusion rule, for any email with ‘FW:’ or ‘RE:’ in the subject, in order to prevent a build up of signatures right at the end of an email conversation, which could confuse people. Once you’ve added this exclusion rule, the wizard will confirm your choices, and then create the transport rule. At this stage, if you send an email that matches the criteria in step 1 of the wizard, you should see your signature applied.

New-TransportRule -Name 'Add Signature' -Comments 'Adding Disclaimer / Signature to Messages
' -Priority '0' -Enabled $true -SentToScope 'NotInOrganization' -ApplyHtmlDisclaimerLocation 'Append' -ApplyHtmlDisclaimerText 'Test Exchange signature

%%DisplayName%%
www.messagingtechs.com
' -ApplyHtmlDisclaimerFallbackAction 'Wrap' -ExceptIfSubjectContainsWords 'RE:','FW:'

Chaining email signatures

When you build your signature system up for your organization – you can create multiple transport rules that build up your signature and disclaimer in chunks. For example, one rule could include generic name and contact details, followed by another section with a departmental marketing line, followed by a global disclaimer message. By setting the priority of each transport rule, you can ensure that they will be joined together in the correct order.

To make the HTML more navigable, I got it down to about 1kb!
OK, so we now KNOW we can duplicate a rich text signature - let's see what I can make work from AD. This is far from a complete list, just what I found with some gentle poking. I expect that Microsoft will eventually list a complete mapping of Macros to fields. If that doesn't happen for a long time, I will update this post or make a new one to list more.



Display Name
%%displayName%%
First Name
%%FirstName%%
Last Name
%%LastName%%
Business Phone
%%Phone%%
Title
%%Title%%
Fax
%%Fax%%
Manager
%%Manager%%

You can now not only do disclaimers appended to an email, but you can customize the appended data using macros surrounded by two percent signs… for example %%displayName%% would display your Active Directory AD Display Name.
Do note that for these rules to fire, your outbound SMTP must be Exchange 2010.
Reasons why you want to do this:
1.Rich text sigs currently attach as images to each sent item and each reply. At 5-10k per message, that adds up a LOT under volume. With transport based signatures, these are applied on sending, and not saved in sent items. Since we use an IMG tag to support the image, it can go on an externally hosted web server.
2.Corporate control of signature content based on Active Directory gives a LOT more centralized control. If we allowed marketing the ability to update this transport rule via the new Exchange control panel - they could add/update the marketing line in one place instead of asking employees to comply to a policy

Note: Having the sigature attached by transport cost zero kb in the sent items, but if someone replies will add the 1k of html to the replied to email. Still a decent reduction if you multiply over many users and many emails. Not too shabby, right? Now - other things like the certifications or the second phone number can be applied by either different transport rules based on departments, or by inserting additional desired fields into other attributes. If a marketing department wants to cross sell services more, they can put the top ten technologies on one transport rule, and the Exchange 2010 seminars on another transport rule, and modify the rules to apply by distribution group membership

www.messagingtechs.com [e-mail]

[Paul C]

use HTML code and also Active Directory information in a disclaimer Transport Rule in Exchange 2010

In Exchange Server 2010, we can now use HTML code and also Active Directory information in a disclaimer Transport Rule, expanding the horizon for any organization by, for example, including a global disclaimer based on Active Directory attributes without the use of third-party tools.

Use of HTML:
We can use HTML in the Disclaimer Transport Rule. To cut a long story short, during the disclaimer text we can add HTML tags such as <b>Bold Text </b>, <i> Italic text </i>, <center> Centralized text </center> and so forth. If you did not get what I just described, then it is obvious that you need to learn a little bit more about HTML tags. www.w3schools.com/html/

Using Active Directory fields
Another cool feature that can be used by disclaimer transport rules is the ability to add the user’s Active Directory objects on the fly in the disclaimer. In order to add an attribute we need to use the current syntax: %%AttributeName%%, where attribute name is the attribute that you want to show up in the disclaimer.

How to use HTML and Active Directory attributes in a disclaimer
we can use both of them to create a really cool disclaimer that can be used by the entire organization, using a standard for all users at server level without playing with Outlook/OWA clients.

Let us take a simple scenario as an example: Your Company wants to get rid of the Outlook disclaimer created by their end-users and replace it with a global disclaimer using transport rules. This disclaimer must contain users’ data, such as Full Name, telephone and some other relevant attributes. The company understands that in order to deploy a disclaimer using Active Directory information, the users’ information in Active Directory should be up-to-date, or at least, containing the minimum information required.

Our first step is to create a scratch of the future disclaimer and we are going to use the following template:

---

Lucy Liu
IT Support – MessagingTechs.com
171 1st Street - Toronto – Ontario – X1X Y2S
Telephone: [phone] / Fax: [phone] / Mobile: [phone]

The content of this e-mail (including any attachments) is strictly confidential and may be commercially sensitive. If you are not, or believe you may not be, the intended recipient, please advise the sender immediately by return e-mail, delete this e-mail and destroy any copies.

---

now we need to retrieve the user Active Directory attributes for all fields that we are going to use in our new disclaimer. You can accomplish this task by taking a user with all that information filled out and then use ADSIEdit.msc to retrieve the information, ldap, csvde and etc… However, we are really excited about Exchange Server 2010, especially one of the new management features called view PowerShell Command to help us out.

Let us open the Exchange Management Console, and double click on the designated user that we will use for our tests. Keep in mind that our newly created template, since we are going use it to search for all the information for our test user.

With the user’s properties page opened, for each field that contains data related to our template, we are going to add a letter (in our example, we are going to add a capital X at the end of each field that we want to know the attribute name). We are not going to apply these changes but we will track down all the attributes names using that new feature that we mentioned before.





Finally, on the Organization tab we will find the company name, and after changing the last field that we need in our template, let us click on Show Exchange Management Shell command button that is enabled on the left bottom of the current window, as shown in below image



As soon as we click on that button, the PowerShell command that will be executed will pop up. Since we added one letter for each attribute that we want in our disclaimer, we can easily identify the attribute name that we are going to use in our disclaimer transport rule, as shown in below image



We already have a template, attribute names, and now it is time to add the HTML code to the mix and create our disclaimer using the information collected in the previous step, the HTML code will be similar to the following code:

---

<hr>

<b>%%DisplayName%%</b><br>

<font size=small>

%%Department%% - %%Company%% <br>

%%StreetAddress%% - %%City%% - %%StateOrProvince%% - %%PostalCode%% <br>

Telephone: %%Phone%% / Fax: %%Fax%% / Mobile: %%MobilePhone%%<br><br>

</font>

<h5> <font color=gray>

The content of this e-mail (including any attachments) is strictly confidential and may be commercially sensitive. If you are not, or believe you may not be, the intended recipient, please advise the sender immediately by return e-mail, delete this e-mail and destroy any copies.

</h5>

---

Create Transport rule:

Open Exchange Management Console
Expand Microsoft Exchange on-premises
Expand Organization Configuration
Click on Hub Transport
Click on Transport Rules tab
Click on New Transport rule in the Toolbox Actions
On the Introduction Page. Label the new Transport rule (Disclaimer for example) and click on Next
On Conditions page, tick the item from users that are inside or outside the organization, the default setting is Internal, just click on Next
On Actions Page, tick the item append disclaimer text and failback to action if unable to apply and then click on disclaimer text link on Step 2 of the same page
Copy and paste the code that we have just created above using the Active Directory attributes and HTML content and click on OK and Next

allow regular users to change their information
feature of Exchange Server 2010 is the ability to allow regular users to change their information using a new interface called ECP (Exchange Control Panel). This new interface also has other improvements such as the ability to allow end-users to track messages, join and manage groups and so on. All these features are controlled by a new security model called RBAC (Role Based Access Control), which means that an administrator can control which features and even fields (for example) the user can play with, within their ECP session.

any logged user on OWA can click on Options(see all options) and he/she will receive the ECP page. If he/she then clicks on Edit, a user will be able to change their personal information. This would essentially mean that the user will have some sort of control of the data that is going to be added to the disclaimer.



click edit

[David]

Reject messages with Capitalised Subjects



to create the following transport rule to bounce/reject all messages with only capital letters in the subject, including ignoring the common indicators for replies etc.:

[ps]New-TransportRule -Name ‘All Caps is Bad’ -SubjectOrBodyMatchesPatterns ‘^(R[eE]: )*[^a-z]*$’,'^(F[wW]: )*[^a-z]*$’,'^(Fwd: )*[^a-z]*$’[/ps]

This creates a new transport rule, and any message whose subject (or body) matches any of the following Regular Expressions will be bounced:

•^(R[eE]: )*[^a-z]*$ (eg: “Re: THIS IS IMPORTANT” or “THIS IS IMPORTANT”)
•^(F[wW]: )*[^a-z]*$ (eg: “FW: THIS IS IMPORTANT”)
•^(Fwd: )*[^a-z]*$ (eg: “Fwd: THIS IS IMPORTANT”)
When a user tries to send a message with only capitals in the title, the following is returned. Note the 5.7.111 “Do not use a capitalised” subject bounce message.



This is obviously not something I recommend deploying in production, but it does show how easy it is to evaluate message bodies and subjects using regular expressions.