Every Exchange design includes plans for optimal server locations and connections. You plan how to control public folder and directory replication to minimize the amount of messaging traffic that internal server activities generate. However, designers devote a lot less attention to client-generated traffic and reduction of network demand. To accommodate network traffic in production environments, you need to estimate your bandwidth needs, connect clients efficiently, and modify some bad user habits.
Bandwidth Planning
Because they've worked with the Exchange Server product for several years now, most system designers can plan without too much difficulty for the number of servers they need for a deployment. The rules of thumb for configuring servers within a network are now well known. Designs get more challenging when you consider how to connect people who work in offices where you can't justify a local server for one reason or another. You might not have a suitable network connection, the users might not have sufficient technical expertise to manage a server, or the number of users might be so small that you want to connect them to Exchange Server as cheaply as possible.
Network availability drives all discussions about client connectivity. If you have lots of bandwidth, you can connect in several ways. But if you have small network pipes radiating out to several locations in a classic hub and spoke network, you have fewer options.
You need to understand your network's limits so you know all your client connectivity options. Let's assume you have a group of users who work at the end of a 64Kbps network link. Outlook 98 is the preferred client, and the users are accustomed to working online and being connected to their previous email system. You can place a server at the end of the link and connect to either an existing or a new site, using a remote procedure call (RPC), X.400, or Internet Mail Service (IMS) connector. Or you can connect the users into a centralized server. Designers usually try to use as few servers as possible to reduce administrative effort and cost. The question is whether the 64Kbps link is big enough to provide reasonable response to the users at the end of the line.
The answer depends on two factors: the number of users and the type of work they do. Typical guidelines for estimating client demand are to allow
- 3Kbps for each light email user
- 6Kbps for each medium email user
- 10Kbps for each heavy email user
Light users receive no more than 10 messages a day and send even fewer messages. Medium users send up to 20 messages a day, send and receive about an equal number of messages, and perform some scheduling and other activities that create network traffic. Heavy users deal with more than 50 messages a day and are online most of the time. Heavy users tend to maintain distribution lists (DLs), perhaps even large lists that add greatly to the size of messages when expanded into the message header. Heavy users also tend to attach more documents than other users and use client options such as AutoSignatures. Some heavy users might demand more than 10Kbps.
Even the most detailed network analysis doesn't cover all possible situations. Sometimes a network link grinds to a halt because of cumulative user load or an individual's action. Early morning, when many people log on at roughly the same time to read new mail, is often a time of peak demand. Attaching a large file to a message can fully occupy a 64Kbps link for some time. Because the Web is graphically rich, Web browsing often chews up a great deal of bandwidth, especially if users download files from the Internet.
Basic Connectivity
Network connections can also affect traffic flow. Outlook clients connect to Exchange Server through RPCs carried over a suitable network protocol. The most common protocol is TCP/IP, but RPCs can also travel over other common protocols, including IPX/SPX and Banyan VINES. The binding order establishes the list of network protocols that a client attempts to use to connect to an Exchange server. The list of available protocols is in the Registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Exchange\Exchange Provider\ Rpc_Binding_Order.
Screen 1 illustrates the default RPC binding order set on a new PC with a fresh installation of Windows 98 and Outlook 98. You can set the same value on systems running Windows NT (Workstation or Server) and Win95. Table 1 defines the protocol settings you see in the Registry.
The order in which you specify the protocols is important. When a client attempts to connect to the server, it tries each protocol in the specified order. If the connection isn't successful, the connection request eventually times out, and the client uses the next protocol in the list to try another connection. If the client fails to make a connection after trying all the protocols, the client asks the user to either work offline or retry the connection. Some timeouts take a minute or so before the client can go on to the next protocol. Clients that use nonoptimal binding orders experience a very slow connection. The classic symptom of this problem is to have two PCs on the same network segment where one PC can start Outlook and connect to Exchange in a matter of seconds and the other takes minutes to connect.
Incorrect binding order causes many of the client problems reported to Microsoft. However, you can easily prevent or fix binding order problems by putting the default protocol first in the list and eliminating protocols you don't use. For example, I don't use Banyan VINES or Novell NetWare, so I can safely eliminate any reference to ncacn_vns_spp and ncacn_spx from the Registry. You can use tools such as Profile Maker from Automated Profile Management (http://www.autoprof.com) to create profiles with all the necessary settings, including the binding order, to use as you deploy clients.
After you get the binding order right, be sure you've configured each protocol correctly. For example, if TCP/IP is your preferred network, make sure that you've correctly configured TCP/IP on the PC and that the underlying infrastructure required to support a TCP/IP environment (such as DNS and WINS) functions properly.
Reducing Load
The next step is to consider how users work on the link. If you don't educate users to respect the network, they are unlikely to consider the ramifications of easy-to-perform operations such as attaching a large PowerPoint presentation to a message and sending the message to a DL. Here are some bad email habits you need to watch for.
Complex, object-ridden AutoSignature files. AutoSignature files, which first appeared in sendmail-based UNIX email systems, convey information about a message's sender, such as a return email address, telephone and fax numbers, and perhaps some witty thought of the day. Adding small amounts of text doesn't occupy much space; however, when users insert objects into AutoSignatures, the file size can get out of hand.
For example, when I inserted the Compaq Services logo into my AutoSignature, I added 112KB of graphics to every outgoing message. AutoSignature is a useful feature, but keep it under control by eliminating graphics and never using AutoSignatures in replies and forwards.
Voluminous replies. Sometimes I think messaging vendors made the Reply to All function too easy to use. Replying to everyone is easy enough, but when a lot of people add a "Me too" contribution to the discussion and reply to everyone else, they can start a mailstorm. Reply to All causes two bandwidth problems. First, the practice generates a large volume of messages. Fortunately, you can easily delete all the "Me too" responses from your mailbox. Turning on Outlook's AutoPreview function (from View, AutoPreview) lets you quickly scan your inbox and identify candidate messages for instant culling.
The second problem is more insidious. Users tend to accept default options, and by default, Outlook inserts the text of the original message into a reply, so you end up with messages that gently swell as users add replies. If the original text adds context or provides the basis for edits, inserting the original text in a reply is a good idea. However, you don't need to include the original text just because it's there. Practice sensible messaging by taking the time to remove the original text before replying to messages.
Large attachments. When you attach a large file to an email message, neither Outlook nor Exchange does anything to minimize the effect (i.e., high bandwidth usage). To reduce bandwidth usage, you need to take action by using a compression utility, imposing limits, or using public folders or network shares.
Compression utilities conserve bandwidth yet let users send large files. The sidebar "Compression Utilities Help Save Space," page 3, describes some third-party products for compressing attachments.
Many companies impose limits on the Message Transfer Agent (MTA), connectors, or individual mailboxes to prevent people from sending too many large messages. ("Managing Mailbox Quotas," July 1998, describes techniques for limiting mailbox size.) However, administrators often set limits with LAN-type access in mind and don't usually take into account people who connect over an extended WAN or dial-in link. In these situations, setting a 10MB limit on the MTA won't do much good, because even a 9.9MB message takes a long time to download.
An alternative to sending many people a message with a large attachment is to place large documents in public folders or network shares. However, because this solution requires users to do more work, many people don't use this technique.
The best way to encourage more efficient practices is education, and the best time to teach good user habits is the first day you install Exchange. Because changing accepted practices is difficult, you might need some automated assistance if you have an established Exchange system.
HTML and vCards. Advances in technology sometimes add to the network load. For example, Outlook 98 and Outlook 2000 both support HTML as a default format for new messages. This capability is part of the movement away from Microsoft proprietary standards such as Rich Text Format (RTF), the default in earlier versions of Outlook and the Exchange client. Moving to an Internet standard such as HTML seems like a good idea, but the side effect is that HTML message content isn't compressed, whereas RTF content is. If you customarily use the message editor instead of Word to compose long messages, using HTML can make a difference.
Virtual card files (vCards or .vcf files) attached to messages are another example of a technology-imposed load. My routine text-based AutoSignature adds about 1KB to a message; my vCard adds 5KB. Although adding 4KB to every message doesn't seem like much of a burden, if everyone's using vCards, the network has to carry a lot of extra kilobytes.
Message Smartly
Keeping demand for bandwidth under control is always a struggle. Because network costs are steadily decreasing, you can more easily justify upgrading links. However, applications such as Outlook and the Web steadily increase their appetite for bandwidth. User discipline helps to win the fight, but sometimes convincing users to cooperate is difficult and you might need to use automated utilities to compress messages.
