Managing Limits in Exchange Server 2010 (Part 3)

by [Published on 8 Jan. 2013 / Last Updated on 8 Jan. 2013]

In this third article the author will run a couple of scenarios to test the organization and connector limits that were configured in the previous articles.

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

Let’s run a couple of scenarios where the organization limits and connector limits are not the same. From there we will see how to manage exceptions and troubleshoot message limits using Message Tracking from the server side.

Issue #01: Organization limits are larger than Connectors

Let’s analyze a common scenario where the organization has a larger limit than its connectors and it may create confusion to the end user. Here is the summary of our limit settings for this scenario:

  • Organization Limit is defined to the default value (10MB for either Send or Receive components)
  • Send Connector to Internet 5MB
  • Receive Connector from Internet 8MB

In this scenario the internal users will be limited to send and receive 10MB among each other, however, when they try to send a message larger than 5MB for external users they will receive the NDR message as shown in Figure 1.  Now, let’s step back for a minute and feel the frustration of the end-user, where he is sending a message for two distinct recipients (an internal and external recipient). The message is not delivered to the external recipient, and to get things worse the external recipient informed our end-user that he is able to receive up to 30MB in his organization.

Figure 1

Figure 1

Based on our previous examples, we can understand what is going on… our Send Connector is limiting the outbound messages which cause this kind of issue to the end-user. In order to solve this common issue you have a couple options, as follows:

  • Increase the Send Connector to match the Organization Limit - this way all users will be able to send messages up to 10MB for internal (which is already working) and also to external recipients
  • Reduce the limit on the Organization Configuration to match the connector – however, if users have been using this limit you may receive some complains.

Issue #02: Organization limits are smaller than Connector limits

In this kind of scenario our organization is configured as described below:

  • Organization for send and receive is set to 5MB limit
  • Send Connector(s) configured to 10MB limit
  • Receive Connector(s) configured to 10MB limit

Using this kind of configuration the organization waste system resources when an external sender sends a message larger than 5MB because the Receive Connector will accept the connection and it will process the message to generate an NDR afterwards, and at the end of the day the message will never be received by our internal user.

Let’s suppose that an external sender has sent a message of 6MB to an internal user in this same organization and using Message Tracking tools (which will be covered in more details in the next section of this article) we can visualize the steps of the message (Figure 2) where it was received and processed and when the organization limit was validated and the message refused.

 Figure 2

Figure 2

If we look closely on the last line of this communication we will find a column RecipientStatus, and if we check the error it will be 550 5.2.3 RESOLVER.RST.SendSizeLimit.Org; message too large for this organization.

The best practice is always terminating the communication as soon as possible in the Transport pipeline to free up system resources. A simple solution for this organization is to limit the Receive Connector and Send Connector to 5MB, this way the message will be discarded right away without consuming system resources. Using this best practice means that the message will be refusedimmediately, and there wouldn’t be any message tracking since the message was discarded before entering the organization

Managing Exceptions at object mail-enable level…

How do we deal with exceptions using Exchange limits? If we are talking about internal message flow we can use the mail-enabled object limit settings to bypass the organization limits because they are coming from authenticated sources, however, we can’t bypass the limits on Connectors because they are unauthenticated.

A good example is when your Board of Directors want to send large files but all other users should use a smaller limit. Let’s use these values to put some perspective in the exceptions topic:

  • Organization for send and receive is set to 5MB limit
  • Send Connector(s) configured to 10MB limit
  • Receive Connector(s) configured to 10MB limit
  • Board of Directors members are configured to 20MB limit at mailbox level

Let’s open Exchange Management Console, expand Recipient Configuration, click Mailbox item on the left, and double click the desired mailbox. Then, click the Mail Flow Settings tab, select Message Size Restriction and click Properties…, then let’s set the Maximum message size (in KB) in both section (Receiving and Sending) to 20MB, as shown in figure 3.

Image

Figure 3

In this new scenario we can perform and check with a message of 15MB

  • Messages exchanged among the users with exception enabled were sent and received properly
  • Messages sent to regular users will be refused
  • Messages sent to external resources will be refused as well
  • External messages sent to these users will be refused right away due the Recipient Connector limit

The mail-enabled object level can also be used to reduce the limits of an object. For example, if you want an organization limit of 5MB, however, you want a specific service account to send messages no more than 1MB, then for this kind of situation you can assign that specific user to 1MB to either Receive and/or Send, and that will be the limit for that user.

Using Message Tracking to troubleshoot limit issues...

If you have a small office and users are not busy all the time you can always go to the user desk and get a couple of coffee breaks and try to understand the issue, run some tests to understand and fix the issue. Unfortunately, this scenario is not common and most of the time the administrator has to identify the issue from the server side and for that we can take advantage of Message Tracking either using Exchange Management Console or Exchange Management Shell to identify and fix limit issues.

When working with message tracking, the administration must be aware of the tools and the basics to track a message. For starters each step of a message in the infrastructure will be logged and from that log the administrator can analyse and troubleshoot message flow and perform several other tasks such as reporting, general analysis and so forth.

Each message has an event associated to it where it could be: Deliver, DSN, Fail, Receive, Resolve and others. I listed just the most common but there plenty more, and there also other fields that can be used to narrow down a message during a query, such as: Source, Sender, Recipient, MessageSubject and so forth.

Using Exchange Management Shell we can use Get-MessageTrackingLog to see what is going on and if your server has tons of activity you may be surprised how much information will be available for your analysis.

Before going for a deep analysis, we can see how it works in a nutshell for a simple message sent between two internal users. In Figure 4, the user sends a message to another internal user and we can see that there is a submit (event) and StoreDriver (Source), then the message flow keeps going until it gets to the final destination which is the recipient of the message. The same applies to an external recipient as shown in Figure 5, however, in this case we have a routing which means our connector will be used after the store receives the message.

Figure 4

Figure 4

Figure 5

Figure 5 

 We can use “| fl” and get detailed information for each line of the Message Tracking as shown in Figure 6, where we can get even which folder on the recipient received the message sent (EventData attribute).

Figure 6

Figure 6

Let’s analyze an external message sent to an internal user, where the Receive Connector was larger than the organization limit. The external sender will receive a NDR message and the internal user will never receive the message. If we look at the message tracking of the operation (Figure 7), we can see that the message was received (Receive-SMTP), then our internal user was found (Resolve, Routing), and an error was generated (DSN,DSN) and the message won’t be delivered to the internal recipient (Fail, Routing).

Figure 7

Figure 7

If we remove the attachment from the equation, a new message will have the following entries in Message Tracking (Figure 8).

Figure 8

Figure 8

Why is it important to see how message tracking is getting information about the messages? Well, if you know how it works in normal conditions you can use that experience to troubleshoot future issues with limits and message flow.

A simple example - a user sends a message to another internal recipient, however, the limit of the recipient doesn’t support the attachment size. The administrator can validate the RecipientStatus value from the Message tracking, as shown in Figure 9.

Figure 9 

Figure 9

You may be thinking that this is just crazy and if you have tons of messages how easy it would be to narrow down the logs to get the required information. Well we do have PowerShell on our side, so here are some key features that can help us out:

  • Use Get-MessageTrackingLog -MessageSubject Attachment <String> where the <String> can be any part of the Message Subject
  • We can use –Start and –End to define date and time to narrow down the results
  • We can use –Recipients and –Sender to narrow down the result by Sender and Recipient
  • We can use -EventID and use some of the pre-defined values, such as FAIL to see all messages that are failing and do some research on the issues
  • We can also use altogether to narrow down the results even more

One last thing, the same concepts that we have just studied can be applied to the Graphical tool called Tracking Log Explorer (Figure 10), which can be found under Tools in the Exchange Management Console. We can see the initial page where we can perform the same queries that we described using PowerShell. I personally like PowerShell because it’s faster than using the tool which requires the administrator to play around with several back and forth between searches.

Figure 10

Figure 10

Conclusion

In this third article of our series, we saw a couple of scenarios where limits can create some confusion to the end-user. We also analysed how to use the Message Tracking log feature to get deep information from the server side and finally, we saw how to use exceptions at mail-enabled object.

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

Featured Links