Reduce Exchange Server's Bandwidth

Exchange Server is a bandwidth hog. Because Exchange Server usually shares network lines with other client/server applications, it might use more bandwidth than most administrators realize. For example, in addition to generating traffic when it transfers clients' email messages, Exchange Server also uses the network wire for directory synchronization, site affinity, and replication of directory and public folder hierarchy and content.

Anything you can do to limit the message size without crippling the overall usefulness of the system is worthwhile. Exchange Server and Outlook contribute to keeping message size as small as possible by automatically compressing text in the message body. A 10KB message compresses to about 6KB on the client before it travels to the server. Messages larger than 100KB typically compress to less than half their original size. However, the Messaging API (MAPI) client doesn't compress attachments. To control large attachments, the systems administrator must set and enforce message size limits.

In this article, I'll show you how to configure Exchange Server to strike a balance between usability and responsible network management. I'll describe what you and users can do at the client and at the server to keep mammoth-size mail from eating up bandwidth. Finally, I'll give you some tips for consolidating servers and managing distribution lists to optimize network performance. Except where I've noted, I've based all examples on the Exchange client or Outlook 97.

Message Limits from the Client
Any action that you and users can take to reduce message size from the client improves server performance. For example, users can stop including unnecessary bitmaps, compress attachments, add distribution lists to the Bcc field, and change their Reply message format. Meanwhile, you (or another public folder owner) can limit the size of messages in public folders.

Bitmaps. Users need to refrain from inserting bitmaps into their AutoSignatures. Often, these bitmaps are the company logo, which people at the same company don't need to see. Attachments, too, are bitmaps, and Exchange Server doesn't compress attachments. (Tony Redmond's sidebar "User Habits Affect the Message Store," July 1998, offers other suggestions for routinely keeping down the size of messages.)

Attachments. Users need to compress large attachments with a compression utility (e.g., Nico Mak Computing's WinZip). You can usually compress word processing files between 70 and 90 percent and graphic files even more. The Eudora mail client (a Post Office Protocol 3—POP3/Internet Message Access Protocol 4—IMAP4—client) offers a built-in utility called Stuffit that zips attachments. Users simply click a key on the toolbar, as Screen 1 shows. An alternative is new third-party clients that compress attachments at the server.

Distribution lists. Users need to add large distribution lists to the Bcc field rather than the To field. This action prevents recipients from using Reply All to send a message to everyone on the distribution list.

Reply messages. Users can change their Reply option so that the original message is not included in replies. To change this option, click Options on the Tools menu, and select the Reading tab. In the When replying to a message drop-down list, select Do not include original message.

Public folders. You might want to conserve bandwidth by limiting public folder message size. From the client, go to the Administration tab of the public folder's property sheet, and define a Folder Assistant (which works like an Inbox Assistant). From the Folder Assistant, click Advanced to define a message size limit. This operation isn't intuitive, though, because you must define the message size limit from the At least field instead of the At most field. As Screen 2 shows, you can define a rule to prohibit users from submitting messages larger than 400KB. If a user tries to post a message that exceeds the limit, the user receives a notice that the message is too large, and Exchange Server purges the message from the public folder. Instead of deleting the message, you can create another rule (or in Exchange Server 5.5, use a Scripting Agent) to trigger further actions, such as returning the message to the user.

By default, in a LAN environment, the MAPI client automatically begins uploading attachments as soon as the user inserts them into the message body (even before the user clicks Send). So although you have defined a message size limit on the public folder, the client still generates network traffic. You can observe this activity by turning on Network Monitor (a Microsoft software sniffer) at the server and, from a remote client, by attaching a large file to a message. Even before the client can click Post, Network Monitor records the number of bytes transferred.

In this case, the client uses network bandwidth in spite of the Folder Assistant rule, but you're still better off with the rule in place. The reason is that remote clients in the site can download only those messages that made it through the Folder Assistant filter. So, for example, if you've set a message size limit of 400KB and configured site affinity to let sites share public folders, a remote client can download only messages smaller than 400KB, because the client won't post any messages above this limit.

Message Limits from the Server
On the server, you can define several settings to conserve bandwidth. You can restrict public folder content during replication, and you can set message size limits on the Message Transfer Agent (MTA), mailboxes, and connectors.

Public folders. As I described earlier, from the client side, you can prevent users from posting large messages to public folders. From the server, you can control the public folders' replication schedule. During replication, public folders communicate changes between replicas via mail messages. By default, every 15 minutes Exchange Server replicates any new posts to a public folder to the other instances of that folder throughout the organization.

An easy way to restrict network traffic is to change the replication schedule of public folders case by case, so that the schedule is appropriate. For example, you might want public folders that contain time-sensitive information to replicate at 15-minute intervals and folders that contain policy information (which typically change infrequently) to replicate once a day. To change the schedule, open Exchange Administrator, and go to Folders, Public Folders. Select the folder for which you want to change replication. Go to File, Properties, select the Replication Schedule tab, and make the changes you want.

You also can modify the message size limit on all public folder contents that Exchange Server replicates. You set this restriction on the Advanced tab of the Public Information Store's (IS's) property sheet, as Screen 3 shows. This setting is global for all public folders. Also, note that Exchange won't divide an item in a public folder that exceeds this limit into several replication messages and send them. Therefore, Exchange Server won't send any message if it exceeds the size limit you set.

If you plan properly, this message size limit matches the limit you set in the Folder Assistant at the client. The result will be that all replicas are mirror images. (By default, Exchange Server sets the other field, Replicate always interval, on the Public IS's Advanced tab to 15 minutes. If you want to set different replication intervals, override this interval folder by folder using the process I described earlier.)

Limiting message size is useful when Exchange Server is replicating across a messaging connector that doesn't have size limit restrictions. For example, you can't set size limits on messages transmitted over the Site Connector. If you set the size limit on the Public IS, Exchange Server won't submit public folder contents to the Site Connector for delivery. If a connector (e.g., the Internet Mail Service—IMS) imposes size restrictions, you still gain a performance advantage, because the MTA won't submit a message to a gateway that will ultimately reject that message.

MTA. From a global perspective, you can stop Exchange Server from transferring large messages to other servers by enacting a size limit on the MTA. You can access the MTA property page via the General tab of the MTA for a specific server, as Screen 4 shows. Regardless of the messaging connector you use, Exchange Server enforces the size limit. However, if both the originator and the recipient reside on the same server, Exchange Server doesn't use the MTA to transfer messages. In this case, you can use mailbox limits to restrict message size.

Mailboxes. You can impose message size limits on individual mailboxes from the Exchange Administrator program. On the Limits tab on the target mailbox's property, define outgoing and incoming size limits. By default, Exchange Server imposes no size limits. You can also use the Message size option to limit a mailbox to either inbound or outbound messages. For example, as Screen 5 shows, Juli Nimitz has a 0KB outbound message size limit, so her mailbox can only receive messages.

To impose automatic message size limits on mailboxes, you can use a Template mailbox that includes defined limits. When you use Exchange Administrator to create a new mailbox, select the Template mailbox. From the drop-down menu that appears, select File, Duplicate. After you fill in the mandatory fields, the new mailbox will inherit the size restrictions. You can use the Template to create new mailboxes with size limits only when you create a mailbox from Exchange Administrator; you can't use a Template when you create new mailboxes from User Manager for Domains.

As an alternative to individual mailbox limits, you can impose a global limit on all mailboxes by setting storage limits on the Private IS property sheet. You can configure the restriction to have Exchange Server issue a warning or to prohibit the mailbox from sending or sending and receiving messages when the mailbox reaches a storage limit. (See Tony Redmond, "Managing Mailbox Quotas," July 1998, for an explanation of how to set storage limits.)

Connectors. You can set message size limits on the Remote Access Service (RAS), X.400, IMS, Microsoft Mail, and Lotus cc:Mail connectors. For X.400 connectors, size limits apply only on outbound messages; Exchange Server will accept inbound messages, regardless of their size, using an X.400 connector. You configure size limits for X.400 connectors on the Advanced tab of the connector's property sheet.

The IMS supports message size limits for both incoming and outgoing mail. The IMS blocks outbound messages that exceed the limit and sends a nondelivery receipt (NDR) to the originator. The IMS rejects inbound messages above the size limit after they travel over the connection. When you use the dial-up functionality with the IMS, setting message size limits can ensure that Exchange Server can deliver the messages during the connection interval.

You can also configure the Internet News Server (INS) for inbound and outbound message limits independent of one another. Because of the potential for a large number of newsgroup messages, message limits can save large tracts of real estate on your server.

Optimizing Network Traffic
Consolidating servers can improve network performance. Having a few servers with a large number of mailboxes is more efficient than having many servers with fewer mailboxes. Exchange Server's huge IS (16TB in Exchange Server 5.5, Enterprise Edition) lets you have 2000 or more mailboxes. Having fewer servers offers several benefits:

Whatever you can do to reduce the number of hops that a mail message takes during delivery is also a step in the right direction. Depending on the network topology, reducing the number of hops can substantially reduce packet traffic over routers. Follow the rule of installing servers on the same subnet as the mailbox owners to shorten delivery times and improve system performance.

Distribution List Management and Traffic
If you plan your distribution list (DL) expansion servers carefully, you can limit traffic between sites. An expansion server expands the DL (i.e., names all the mailboxes in the list) and distributes the message to all members of that DL. The MTA of the originator's home server usually performs this function.

However, in certain cases, letting the original server of the DL expand the DL works better. For example, suppose a DL created in Site 1 includes 500 recipients from Site 1. If a client in Site 2 sends a message to this DL, the client's home server expands the DL and routes the message to Site 1 by default. This process generates additional network traffic, because a message sent to a large DL can have a recipient list that is larger than the message contents. A better approach is to deliver the DL to Site 1 and let the DL's original server expand it. This process generates only minimal network traffic, because this sequence passes only one DL and one instance of the message. If a DL includes members from both sites, the best approach is to expand it locally, because expanding the DL in a remote site and then sending it back to the recipients in the other site is inefficient.

Configuring remote expansion of DLs is a two-step process. First, go to the property sheet of the local server's MTA, and clear Expand remote distribution lists locally, as Screen 4 shows. (This choice isn't the default.) On the General tab on the DL in the Recipients container, define the expansion server where the DL originated, as Screen 6 shows.

Another option for large (1000+ users) DLs that span several sites is to post messages to a public folder instead of using a DL. When you use a public folder, Exchange Server posts the message only once, overhead is lower, and you can control the replication schedule.

Finally, to prevent outsiders from sending unsolicited commercial email (UCE) to the distribution list and generating nonbusiness-related traffic, you can specify approved senders to the DL. On the DL's property sheet, go to the Delivery Restrictions tab, and add the DL to Accept Messages From.

Limit Size, Improve Performance
By imposing message size limits, you can increase system performance and keep your network pipes at an acceptable utilization rate. In this article, I've presented a few ways to control the quantity of packets that the network wire must support. If you use these suggestions wisely, you can save time and money. If you need motivation to restrict message size, think about how much time you spend using remote mail to download your messages over a 28.8Kbps modem when you run into a few 1MB messages that take 15 minutes or so to download. Banish those huge messages from your system; the people you send mail to will appreciate it.