• "Managing Limits in Exchange Server 2010 (Part 4)"
  Published by Anderson Patricio on 24 Jan. 2013
  http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/managing-limits-exchange-server-2010-part4.html

If you would like to read the other parts in this article series please go to:

• Managing Limits in Exchange Server 2010 (Part 1)
• Managing Limits in Exchange Server 2010 (Part 2)
• Managing Limits in Exchange Server 2010 (Part 3)

Managing limits by attachment…

Besides managing message size limits on different components of the transport architecture, the administrator can also control the limit per attachment using Transport Rules. This kind of limit is only per attachment and doesn’t impact the overall message size that will be dealt by the Organization’s Send and Receive connectors based on what we have seen in this article series so far.

A good example is a company that may have a 5MB limit for either Send or Receive but does not allow any single attachment to be larger than 1MB. The user can attach 5 files of 1MB before reaching the message size limit, however, if he tries to send a single attachment of 1MB+ the message won’t be processed.

In order to create a Transport Rule to limit the single attachment size the following steps can be used:

1. Open Exchange Management Console
2. Expand Organization Configuration
3. Click on Hub Transport item
4. Click on Transport Rules tab
5. Click on New Transport Rule... item located on the Toolbox Actions
6. On the Introduction page. Let’s name the new Transport Rule and description, and keep the default setting which is Enable Rule, and click Next.
7. On the Conditions page. Let’s select the condition when the size of any attachment is greater than or equal to limit and in the Step 2: Edit the rule description by clicking an underlined value, click on the link to define the limit. In our scenario let’s set it to 5120 (5MB), as shown in Figure 01. Then, click Next.

Figure 01

1. On the Actions page. Let’s select send rejection message to sender with enhanced status code and in the Step 2: Edit the rule description by clicking an underlined value section, let’s click first the rejection message link, and add a text (Please, use FTP for attachment(s) larger than 5MB) and in the enhanced status code link we can add any number between 5.7.10 and 5.7.999. In our case let’s use 5.7.666 and finally click Next (Figure 02).

Figure 02

1. On the Exceptions page. In this page we can create the exception for the rule. For example, a special group or a special message to create more flexibility for the rule. You can always use the exception for any special requirements in your organization. A good recommendation when creating Transport Rules is to start simple, so in this case let’s start with just the basics and after testing we can start improving. Let’s click Next.
2. On the Create Rule page. A summary of all settings defined so far will be displayed, let’s click New to start the creation process.
3. On the Completion page. The results of the cmdlet New-TransportRule using the parameters that we defined during the wizard will be displayed and the result should be similar to the one shown in Figure 03.

Figure 03

Now, that we have created the Transport Rule, let’s start our testing phase. Before starting make sure that the organization and connectors are using default settings all over the place which is 10Mb.

Test #01: Sending a single attachment of 7MB internally

Logged as Administrator, let’s send a message to another user with a single attachment of 6MB, as shown in Figure 04.

Figure 04

The sender will receive a message from the system informing him/her that the message couldn’t be delivered. If we look at the Diagnostic information of the message, we can see the text that we entered in the Transport Rule as depicted in Figure 05.

Figure 05

Test #02: Sending multiple attachments but none of them larger than 5MB internally

The Transport Rule enforces the limit per attachment however, it’s always good to test, right? Let’s send another message (Figure 06) with a total of 9MB using 3 attachments (2 attachments of 4MB each, and the third one of 1MB).

Figure 06

The result is that the recipient of the message will receive the message just fine because none of the attachments exceeded our Transport Rule limit threshold of 5MB.

One last question that you may have about this topic is what if you send a message with 3 attachments and only one is larger than 5MB. In this case the entire message will be refused and the reason for that was our definition of the Transport Rule action in the previous steps. Unfortunately, out-of-the-box setup does not include a pre-defined Action to remove only a specific attachment.

Test #03: sending from outside

Let’s try to send a message from an external sender with an attachment larger than 5MB (Figure 07). Since the Receive Connector is set to default settings, the message will be accepted in the organization. However the Transport Rule will take action when the message enters the organization.

Figure 07

The result will be that the recipient won’t receive the message and an undeliverable report will be generated to the sender, as shown in Figure 08. This can be seen in the properties of the message in the Queue Viewer. In this scenario the system will return the message to the sender, however, the message has 8561KB and the system will return that amount of data to the sender which is not good at all.

Figure 08

Configuring NDR message size limits…

The ideal scenario is to discard the message as soon as possible. In some cases the messages may enter our organization and we can reduce the system usage by discarding it. A good option is to reduce the amount of data returned in a NDR message. By default, the NDR may have up to 10MB and we can change that using Set-TransportConfig –ExternalDsnMaxMessageAttachSize as shown in Figure 09.

Figure 09

Now, we can check the first message of 6MB that we sent originally using the default settings, and a second message with 6MB but sent when the NDR attachment size was reduced to 512KB (Figure 10).

Figure 10

Conclusion

I know that Exchange Server is enhanced with so many features with each new version, but it’s always important to keep an eye on some basic features such as, limits which may cause a major headache to end-users and administrators. The main goal of this series was to show you how limits may impact end-users, and how an administrator can troubleshoot and apply restrictions using some of the scenarios that we created in this article series.