Many factors play a role in the speed of your network: the basic speed of the network card, the infrastructure of the overall network, the amount of traffic on the LAN, the protocol(s) in use, and collisions. I won't spend a lot of time on the details of optimizing an NT Server for network use—for that kind of discussion you should visit my colleague, L.J. Johnson, the Windows NT/2000 Pro—but what I will do is look at how network performance can affect Exchange servers and what you can do to optimize them accordingly.

Measuring Performance Levels
First of all, you want to use your friend, Performance Monitor, to see what the actual performance levels on your server are. Using Performance Monitor to check your networking performance is a little trickier than what you've seen so far. To collect and analyze the network traffic properly you need to add other services to your NT server. The first service you want to add is the Network Monitor Agent, which you can do by selecting Control Panel | Network and using the Add button to add it to the list of services.

Once you have it installed, you will find the Network Segment object on Performance Monitor. Add the %Network Utilization counter to see what percentage of your bandwidth is in use. As a general guideline, anything over 40 percent indicates too much usage; chances are good that you're seeing a lot of collisions on the network.

There are two things to keep in mind with this:

• This object only monitors the network segment that the server is on. If you're using routers or switches, then the amount of network utilization shown on this segment won't tell you anything about the utilization on the other segments. Because we're only interested, at the moment, in the network activity at the Exchange server, that's OK, but for a more thorough analysis of your bandwidth usage you should try to get measurements on all of your network segments.
  
• The Network Monitor Agent works by putting your network card into "promiscuous mode." That doesn't mean it's staying out late on Saturday nights; it means that the system is catching and reading every packet that passes through, rather than the usual "only packets intended for me." As you might imagine, this can have a detrimental effect on server performance, so don't leave the Network Monitor Agent installed and running after you're done monitoring.

Once you've installed the network interface, or tested an existing card's performance, compare the results in the Network Interface Object, Bytes Total/Sec counter in Performance Monitor. The higher the number, the better. Compare it to the rated speed of your card.

NOTE: To see the Network Interface object in Performance Monitor you have to add the SNMP service to your server and be running TCP/IP.

Standardizing Protocols
Another tactic that helps reduce the load on your network is minimizing the number of protocols in use. The more protocols operating on your network, the more traffic there will be as those protocols carry out their business. By standardizing on just one or two protocols, you can help to make your LAN as efficient as possible. In our site, for example, we've standardized on TCP/IP and completely phased out IPX/SPX.

Using Routers, Switches, and Cards
Perhaps the most effective way to reduce the traffic on your network is to segment it using routers or switches. If you have ten machines sharing a 10Mbps hub, for example, they all have to share the same aggregate 10Mbps. Traffic to or from any one machine also has to be transmitted through to the other machines, thus increasing the chance of a collision if that other machine is broadcasting its own traffic.

If those workstations share a 10Mbps switch, however, each port is a separate segment. That means that each machine gets its own 10Mbps channel to the switch. Traffic to or from any one workstation will only be sent from or to the workstation or server that it is communicating with; the other workstations never see those packets and the incidence of collisions can drop dramatically.

The benefits are even greater if you have 100Mbps switches, with Category 5 (or better) cabling and 100Mbps capable network cards, for your machines. It's happy news that the prices of such devices, at least at the low end, have recently fallen to reasonable levels. Even the thinner IT budgets can often afford at least a backbone 100Mbps switch to connect the servers at higher speeds.

Another solution to help alleviate network traffic on the server is to add a second network card to the server and separate off a group of workstations to access the server through that card. This is especially effective if you determine that your LAN is handling the load just fine, but the network card in the server is just getting overrun with data. A second card can help offload some of that burden.

Avoiding Collisions
To see if collisions are a problem on your LAN, take a look at the Redirector Object's Network Errors/Sec counter in Performance Monitor. Don't be concerned if some errors are recorded; a certain number of errors is perfectly normal, especially during busy times, and if the rest of your network is running well, collision counts are not much more than a gauge of general network health. Still, anything you can do to reduce those errors and collisions will help to make your network (and by extension your Exchange server) more efficient. Again, segmenting your LAN is generally the best way to reduce network collisions.

Reducing Broadcasts
Another Performance Monitor counter you may want to look at is Broadcast Frames Received/Second. Because broadcast frames have to be read by every machine on the segment, the fewer the broadcasts you have, the more efficient your LAN is. Broadcasts can be generated from any number of places, including DHCP, name resolution, or NetLogon, to name just a few.

Reducing broadcasts may be difficult, depending upon the nature of the broadcasts. If they are DHCP requests, then there is not much you can do about them, except perhaps increasing your lease durations. If they are name resolution requests, however, you may find that implementing WINS helps to reduce them significantly, because the clients will contact the WINS server directly for name resolutions—only falling back to broadcasts if that method fails to locate the machine they want.

NOTE: There's another good reason to implement WINS on your network. Without it, your workstations will not be as efficient in locating the Exchange server. Some networks utilize HOSTS files on the workstations as a substitute for WINS, but if you get beyond a small number of clients, this can quickly become difficult to administer. Imagine what would happen if you had to change the IP address of your Exchange server and had 200 workstations at three locations running HOSTS files that you now needed to update.

Use the Broadcast Frames Received/Sec counter to find out how many broadcasts you're experiencing now. If you implement any adjustments aimed at reducing broadcasts, you can check it again to see if you were effective.

Considering the System Layout
When considering your network infrastructure, consider the layout of your system. It's like building a city: where do you want to build highways and where do you want to build smaller streets and roads? Although conventional network design often advocates building fast backbones between servers and smaller channels out to workstations, that's actually the opposite of what you should do for an efficient Exchange deployment. Replication of data between Exchange sites is not as bandwidth-intensive or time-sensitive as getting data from the server to workstations. Accordingly, if you have to allocate your resources carefully, make sure to give the maximum bandwidth to your clients, even if that means you have to skimp a little on the connection between Exchange sites.

I tend to like to avoid placing artificial limits on my users, but in a case where bandwidth is severely constricted, you might consider imposing message size limits to keep bandwidth usage down. Message size limits can be set on the Limits tab of the Mailbox properties in the Exchange administrator.

Additionally, if you have Exchange servers located at different sites, you might give some thought to public folder usage. If many of your users at Site A need to access a public folder at Site B, you should replicate that folder to the server in Site A so that it's available locally without having each user trying to access it across the (presumably) slower wide-area links. If Site A has fewer, or only occasional, needs to access that folder, don't replicate it to the local server (because the replication traffic may not offset the rare usage) and simply configure your system to give Site A's users access to the folder on Site B's server directly.

Adjusting the Workstation's Registry
There's a step you can take at the workstation level to improve your system efficiency as well. By adjusting the workstation's RPC binding order, you can help control which protocol the client uses first to try and contact the Exchange server. This setting is adjusted in the workstation's registry and can be found at HKEY_Local_Machine\Software\Microsoft\Exchange\Exchange Provider.

CAUTION: As always, take extreme care when editing the registry. If you change the wrong thing it can cause serious problems with your system. Be sure to have a good backup of your system before you begin.

What you'll see when you get to that registry key is an entry that looks like this:

RPC_Binding_Order=ncalrpc,ncacn_spx,ncacn_ip_tcp,netbios

Note that you don't have to restart your machine in order for the changes to take effect. The Exchange client (including Outlook) reads the registry key each time it starts up. Simply (re)starting your Exchange client is sufficient.

If you delete the RPC_Binding_Order key from the registry entirely, the default order will be used automatically. Incidentally, that's a neat troubleshooting trick if you're experiencing mysterious connection problems with your Exchange server and you want to eliminate an incorrect binding order as the cause.

Now we've looked at your memory, storage system, CPU, and network. If you've optimized your system in these four key areas, you should be getting optimum performance and reliability from your Exchange server.