Ask 10 administrators how many Exchange Server mailboxes a given server can hold and you'll probably get 11 different answers. Designing Exchange systems so that they scale well is tricky because so much depends on users' work profiles. For example, 1000 users like me (averaging 200 to 300 inbound messages and 40 to 75 outbound messages per day) impose a lot more load than 2000 users who each send and receive only 10 to 15 messages per day. The amount of RAM; the number and speed of CPUs, disks, and network interfaces; and the interface to Active Directory (AD) Global Catalog (GC) servers all influence the overall performance of your Exchange servers—and knowing which factors are most important in a given environment is difficult without a lot of trial and error (or baseline monitoring).
In an attempt to demystify performance and scalability, the Exchange team last week released the new (and free) "Exchange Server 2003 Performance and Scalability Guide" ( http://www.microsoft.com/downloads/details.aspx?familyid=62fb1297-4c6b-4d84-84cc-060989f2f305 ). The guide is about 100 pages long, so I've picked out a few highlights that might help you plan and implement your Exchange systems to get maximum performance and scalability.
Exchange 2003's scheduled online maintenance process has to make a barrage of AD queries to locate deleted mailboxes so that the Store can decide whether to free the mailboxes allocated storage according to your Deleted Item Retention settings. If your Exchange operations span multiple time zones, one location's 1 a.m. maintenance window can cause a surge in directory traffic during another location's busy time. Take time zones into account and stagger your maintenance schedules accordingly.
Exchange always writes data in 4KB chunks (one Extensible Storage Engine--ESE--page is 4KB and writes to the .stm file can occur in 4KB to 32KB runs). Windows creates disk partitions in such a way that the logical disk format can often be misaligned with physical tracks on the disk, slowing performance. By using the Diskpar utility (part of the "Microsoft Windows 2000 Server Resource Kit") to change the alignment, you can improve overall disk performance, at the cost of having to reformat your disk. It isn't clear whether the performance gain for smaller servers will be worth that hassle, but it might be worth considering the next time you build an I/O intensive system such as a large mailbox server or SMTP bridgehead.
If you see event ID 9665 in the event log, Exchange has decided that its running on a server that doesn't have the optimal memory configuration, based on the amount of physical RAM, the settings in boot.ini, and a couple of registry keys that control heap page allocation. Keep an eye out for this event; if you find it, follow the recommendations in Chapter 4 of the guide.
When you run Exchange 2003 on Windows Server 2003, backups can be slow because the way in which the ESE backup API uses the Store cache can lead to the Store unnecessarily freeing memory for the OS. You can fix this problem by following the procedure in the Microsoft article "Jet Database Does Not Work Correctly During a Backup or During a Content Indexing Operation" ( http://support.microsoft.com/?kbid=822894 ), which details how to set the minimum size of the Store cache by adjusting the msExchESEParamCacheSizeMin value on the server's Information Store (IS) object in AD.
Every time you add or remove a routing group, your Link State Table needs to be updated. When you remove a routing group, the group doesn't disappear from the Link State Table until the group has been removed from the last active server. To permanently get rid of a removed routing group, you have to simultaneously shut down or reboot all the Exchange servers in your organization. The moral of the story: Don't create or remove these objects unless you really need to.
The longstanding rule of thumb for allocating GC resources has been that you should have one GC CPU for each four Exchange CPUs of equivalent speed. In other words, for four 4-way Exchange servers, you'd need one four-processor, two dual-processor, or four single-processor GC servers. That rule still stands, but Microsoft now recommends starting with the 1:4 ratio and fine-tuning as necessary (rather than treating the ratio as an absolute).
Generally, SMTP gateways work fine with 256MB or 512MB of RAM. The real bottleneck is typically either the disk or the CPU, depending on how much additional load is imposed by virus scanners, spam filters, or other tasks.
The guide also includes several other interesting tidbits and recommendations that I don't have the space to cover here. The guide makes for interesting reading even if you think you've already optimized your Exchange servers. Check it out. You'll be surprised what you might learn about your environment.
