Skip to main content

Use transport rules to create disclaimers in an Exchange Server 2007 Organizations


The new architecture of Exchange Server 2007 allows administrators to use many features to manage the messages in transit using transport rules. In this article we will discuss a scenario in which we deploy some transport rules to use disclaimers based on a company’s needs.
The objective of this article is to explain how we achieved a disclaimer solution using Exchange Server 2007 and the transport rule feature.

Our example environment will consist of a company with 1,000 mailboxes and our solution must meet the following requirements:

  • All of the internal messages sent through the Internet must have a company disclaimer within the footer of each message. Messages between internal users do not need to have a disclaimer.
  • Internal messages must have information about the company security policy advising the users about security in the header.
  • The support team will need to have an additional disclaimer, which contains all the support numbers.

Based on these requirements, we are going to create three transport rules to meet them.
Where do we need to create the transport rules? On the Edge or the Hub transport roles?
The transport rule feature exists in both roles: Edge and Hub Transport. Some actions are found in both roles, but the disclaimer and message classifications actions are only found in the Hub Transport role. So, we are going to work on this role to implement a Disclaimer.
Creating a disclaimer for the Exchange organization

  1. Open the Exchange Management Console
  2. Expand Organization Configuration
  3. Click on Hub Transport
  4. In the Toolbox Action click on New Transport Rule
  5. Introduction. We must type the rule name and an optional description. We can also enable or disable the rule. Click Next to continue. (Figure 1)

Figure 1: Initial screen to create a transport rule

  1. Conditions. In this window, we will begin defining the conditions for our transport rule. For the purposes of this example, we will select the “from users inside or outside the organization” checkbox and in the box below (Step 2) we will get the value associated with that condition. We will leave the Insideoption. (Figure 2)

Figure 2: Defining the first rule condition

  1. Conditions. We must also select the “sent to users inside or outside the organization”checkbox. Then, we can click on the Inside option of the second condition to change the Insidevalueto Outside. (Figure 3)

Figure 3: Adding a second parameter in the conditions of the transport rule

  1. Select Scope. On the Select scope window, we can change the scope for the second parameter. We are going to select Outside and then we will click OK to continue. (Figure 4)

Figure 4: Changing the value for Outside

  1. Conditions. Now we can review the condition that we set for our new transport rule. This new transport rule will be applied to all messages from “Inside the organization” to “Outside the organization”. (Figure 5)

Figure 5: Verifying the conditions of our new transport rule

  1. Actions. In this window, we have to click on the “append disclaimer using font, size, color with separator and fallback to action wrap if unable to apply” checkbox. In step 2, we can see many links for each setting that we can use for our disclaimer. Click on the Disclaimer text link.

By default, the disclaimer is already complete with standard values, but we can change them according to our preferences. We will review the available options:
Location: We can define the position where the disclaimer will be added inside the message. The possible values are append and prepend;
FontSize: Single value with the choices of Smallest, Smaller, Normal, Larger, or Largest
FontColor: Single value with the choices of Black, Blue, Fuchsia, Gray, Green, Lime, Maroon, Navy, Olive, Purple, Red, Silver, Teal, White, or Yellow
Separator: If we plan to use separators, we can configure them here. The possible values are with separator and without separator
FallBackAction: Single value with the choices of Wrap, Ignore, or Reject
Wrap: If the disclaimer cannot be added in the original message, a new one will be created and the original message will be attached to the message
Ignore: If the disclaimer cannot be added in the original message, the message will not be modified, and the disclaimer will not be added.
Reject: If the disclaimer cannot be added in the original message, Exchange Server will not deliver that message. The sender will get an NDR message explaining the reason why that message cannot be delivered.

Figure 6: Defining the actions to take in the disclaimer transport rule

  1. Specify the disclaimer text. We have to complete this dialog box with the text that will be used in our disclaimer. (Figure 7)

Figure 7: Adding the text message for all of the messages that will be sent through the Internet

  1. Actions. This will be the final screen of our Action section in the Transport Rule. We can review (and if needed, redefine) some settings. Then click Next to continue. (Figure 8)

Figure 8: Changing some settings in the disclaimer of this new transport rule

  1. Exceptions. We can define exceptions based on conditions. These exceptions are useful if some people do not need to send or receive message with disclaimers. Select the desired option and click Next to continue. (Figure 9)

Figure 9: Seeing Exceptions that we can add to the rule

  1. Create Rule. This is the summary window, with all the defined settings for our new disclaimer. Review the options and click New. (Figure 10)

Figure 10: Configuration summary of the new transport rule

  1. Completion. The new rule was created with the New-Transportrule command-let with all the associated parameters already defined.

Figure 11: Completion window for our disclaimer

  1. We can see that a new rule was created in the Exchange Management Console (Figure 12)

Figure 12: Our first transport rule
After rule creation, we can check if the rule is working as expected, with a couple of tests:
Test #1: Send a message between two internal users (inside the organization)
Expected result: the disclaimer will not be added in the message
Test #2: Send a message to an external user (outside the organization)
Expected result: the external recipient will receive a message with a disclaimer at the footer of the message.
Adding an internal disclaimer

Some companies require that all the internal messages must have a security code. We can also do this with Transport Rules.
To add an internal disclaimer, follow these steps:

  1. Open the Exchange Management Console
  2. Expand Organization Configuration
  3. Click on Hub Transport
  4. In Toolbox Action click on New Transport Rule
  5. Introduction. Type a rule name, a comment and click on Next.
  6. Conditions. We will add a disclaimer for internal users. To do so, we will select the following checkboxes:

    Check From users inside or outside the organization and select Inside

    Check To users inside or outside the organization and select Inside
  7. Actions. Now we have to define the internal disclaimer. We will put the disclaimer within the header of the message and change the color of the text to red. (Figure 13)

Figure 13: Defining actions for our internal disclaimer transport rule

  1. Exceptions. Click Next to continue.
  2. Create Rule. Click on New.
  3. Completion. Click on Finish.

Now we can send a message between two users inside the Exchange Organization, and check if the message sent has our new internal disclaimer (Figure 14).

Figure 14: Internal message with internal disclaimer
Creating a disclaimer for the support team

In this scenario, we have to add a special disclaimer for everyone who belongs to a group called Grp-Support. To add the disclaimer, follow these steps:

  1. Open the Exchange Management Console
  2. Expand Organization Configuration
  3. Click on Hub Transport
  4. In Toolbox Action click on New Transport Rule
  5. Introduction. Type a rule name, a comment and click on Next.
  6. Conditions. In this section we have to select our support group that sends messages to internal users. Then, we have to do it as follows:

    Click on From a member of ,after that click on the Distribution Group link and choose the grp-support group, which contains all the support team members.

    Click on To users inside or outside the organization and select Inside
  7. Actions. Now we can define our Disclaimer, we can fill this out with support phone number information. (Figure 15)

Figure 15: Disclaimer for the Support Group
We can now test our new transport rule by sending a message from a user who belongs to grp-support, to another internal user. We can see the final result in Figure 16.

Figure 16: Verifying the Support Disclaimer Transport Rule
Verifying the order for Transport Rules

We can use many disclaimers through transport rules, and we can use more than one in a single message.

Figure 17: All of the transport rules at Hub Transport level
In Figure 17 we can see all the transport rules for our Exchange Organization. The order that those rules are applied will be based on Priority. If the “Condition” of more than one rule applies to a message, those rules will be applied to the message.
Q&A About Disclaimer

Here are some answers to common questions about disclaimer transport rules and how they can help you in day-to-day tasks:
If we want to send a message to external and internal recipients, how does that work?
Very Simply! For the internal client, the Internal disclaimer will apply, and for the external recipient the external disclaimer will apply to his/her message (External Disclaimer Transport Rule)
How can I manage transport rules with the Exchange Management Shell?
It is easy. Here are all the cmdlets that we can use to manage the transport rules from the Exchange Management Shell.

  • Get-TransportRule: Get all the transport rules
  • New-TransportRule: We can use this cmdlet to create a new transport rule
  • Set-TransportRule: We will use this cmdlet when we want change something in an existing transport rule
  • Remove-TransportRule: Removes an existing transport rule

I work for an outsourcing group that cannot use the company disclaimer. How can I manage this issue?
You can add all the outsourced employees to a group. Then add this group to the exception of the rule.
I have different locations and languages. Can I use different disclaimers?
Sure. You can create a disclaimer for each language that you have, and then put all users of that language together. Then, create a transport rule for this issue.

In this article we reviewed how the transport rules can help an administrator manage disclaimers in Exchange Server 2007. We can use transport rule resources to create disclaimer rules in the organization and adjust them to meet the organization’s requirements.


Popular posts from this blog

Recreating a missing VMFS datastore partition in VMware vSphere 5.x and 6.x

    Symptoms A datastore has become inaccessible. A VMFS partition table is missing.   Purpose The partition table is required only during a rescan. This means that the datastore may become inaccessible on a host during a rescan if the VMFS partition was deleted after the last rescan. The partition table is physically located on the LUN, so all vSphere hosts that have access to this LUN can see the change has taken place. However, only the hosts that do a rescan will be affected.   This article provides information on: Determining whether this is the same problem Resolving the problem   Cause This issue occurs because the VMFS partition can be deleted by deleting the datastore from the vSphere Client. This is prevented by the software, if the datastore is in use. It can also happen if a physical server has access to the LUN on the SAN and does an install, for example.   Resolution To resolve this issue: Run the  partedUtil  command on the host with the issues and verify if your output

ما هى ال FSMO Roles

  بأختصار ال FSMO Roles هى اختصار ل Flexible Single Operation Master و هى عباره عن 5 Roles فى ال Active Directory و هما بينقسموا لقسمين A - Forest Roles 1- Schema Master Role و هى ال Role اللى بتتحكم فى ال schema و بيكون فى Schema Master Role واحد فى ال Forest بيكون موجود على Domain Controller و بيتم التحكم فيها من خلال ال Active Directory Schema Snap in in MMC بس بعد ما يتعمل Schema Register بواسطه الامر التالى من ال Cmd regsvr32 schmmgmt.dll 2-Domin Naming Master و هى ال Role المسئوله عن تسميه ال Domains و بتتأكد ان مفيش 2 Domain ليهم نفس الاسم فى ال Forest و بيتم التحكم فيها من خلال ال Active Directory Domains & Trusts B- Domain Roles 1-PDC Emulator و هى ال Role اللى بتتحكم فى ال Password change فى ال domain و بتتحكم فى ال time synchronization و هى تعتبر المكان الافتراضى لل GPO's و هى تعتبر Domain Role مش زى الاتنين الاولانيين و بيتم التحكم فيها من خلال ال Active directory Users & Computers عن طريق عمل كليك يمين على اسم الدومين و نختار operations master فى تاب ال PDC Emu

Unlock the VMware VM vmdk file

  Unlock the VMware VM vmdk file Kill -9 PID Sometimes a file or set of files in a VMFS become locked and any attempts to edit them or delete will give a device or resource busy error, even though the vm associated with the files is not running. If the vm is running then you would need to stop the vm to manipulate the files. If you know that the vm is stopped then you need to find the ESX server that has the files locked and then stop the process that is locking the file(s). 1. Logon to the ESX host where the VM was last known to be running. 2.  vmkfstools -D /vmfs/volumes/path/to/file  to dump information on the file into /var/log/vmkernel 3.  less /var/log/vmkernel  and scroll to the bottom, you will see output like below: a. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)FS3: 130: <START vmware-16.log> b. Nov 29 15:49:17 vm22 vmkernel: 2:00:15:18.435 cpu6:1038)Lock [type 10c00001 offset 30439424 v 21, hb offset 4154368 c. Nov 29 15:49:17 vm22 vmkernel: gen 664