15 Ways to Optimize Microsoft Exchange by Robert Shimonski & Chad Conrow In today s high-speed, fast-paced environment whether it be business or technology it is essential to pay close attention to detail. It s those finer details that can make the difference and can sometimes be what make you stand out. When it comes to your company s e-mail system, it s imperative to ensure it works the best it can. Most senior engineers also pay close attention to finer details the ones that make any Microsoft Windows Exchange 2003 deployment a cut above the rest. Broken down here, you ll find 15 important tips to cover when assessing your current Exchange environment. The article covers optimization techniques that were used in a real-world deployment, such as offloading to a front-end server, using a dedicated server or appliance to filter out spam, viruses, server sizing, memory and disk configuration, and much more. 1. Use Bridgehead Servers Applying optimization techniques will most likely equal better performance. Systems administrators and engineers should always seek better performance. They know that demand will increase, load will increase and hardware is fixed. By optimizing, you get to fine-tune your environment to provide a better return on investment. To optimize your Exchange environment, consider what sort of tasks can be offloaded to a front-end server. A Bridgehead server is a Microsoft Exchange Server computer that acts as the endpoint of a connection between two sites and is responsible for routing messages through that connection. Typical uses for front-end servers are to offload Outlook Web Access (OWA), Internet message access protocol v4 (IMAP4), post office protocol v3 (POP3) and simple mail transfer protocol (SMTP) relaying from your internal mailbox servers. Offloading OWA has the added benefit of enabling the use of forms-based authentication, which improves security by allowing session time-outs. Also consider moving any public folders or resource mailboxes that have event syncs associated with them to a dedicated back-end server. This way, your users will not be impacted by problems that may arise out of the event service using excessive resources. 2. Use Dedicated Security Devices Dodging the responsibility of spam and virus protection is not a good way to run your e- mail system, especially since most malware and viruses target Microsoft products. When you do deploy them, it is imperative to consider the impact that these added services and resources will have on your systems. Every time you add a software package on a system, you inevitably take a bite out of what that system can handle normally you are asking it to do more. It s very important to consider sticking with what Microsoft is a distributed software model and deploy a distributed design when considering security and protection. To shortchange the budget in this area is a mistake. You will impact the performance of the whole deployment because you try to run too much on one system that is already taxed by its own services. An Exchange Server has to run Active Directory. Therefore, between the base NOS install and Exchange, you really shouldn t consider running too
much more on that system. Think about when you have to turn on logging then what? You are asking for problems if you are running a firewall, virus protection, anti-spam software and everything else on the same system you are running your e-mail on. Consider using a dedicated server or appliance to filter out spam and viruses before they enter the Exchange environment. This alone can reduce the number of messages being processed by the system by as much as 80 percent. If you can t remove the load, find devices to help share it, and you will regain performance power. 3. Size Servers With the Right Hardware Despite servers and operating systems that support 32 GB or more RAM, Exchange 2003 is still a 32-bit application that is limited to utilizing 4 GB of RAM, so building servers with more than 4 GB of RAM on an Exchange server is a waste of money. With this limitation, the sweet spot for processors is four. Any more than four CPUs, and you re likely to hit a RAM bottleneck long before the CPUs become a problem. Therefore, buying eight- or 16-processor servers will not gain much performance over a four-cpu system. Thus, a four-processor server with 4 GB of RAM is the practical limit for a high-performing Exchange server. Always consider doing research on your hardware, especially when it comes to Exchange. You need to consider how to get every ounce of power you can out of your system. In addition, always use the proper hardware, ensuring that you purchase approved hardware for your vendor (e.g., make sure that if you run your system on Dell, you check Dell s site or your vendor for exact matching) and checking the Microsoft Hardware Compatibility List. (For more information see www.microsoft.com/hcl.) 4. Use Hyper-Threading Hyper-threading technology allows multi-threaded software applications to execute threads in parallel. When a system has the ability to switch between multiple threads of execution to give the user the appearance that it s all happening at the same time, this is called multithreading. Hyper-threading technology allows for a new level of performance for evolving enterprise software applications that require more and put higher demands on processors. This need will only continue to grow. Be sure to turn hyper-threading on. This will give you an instant CPU gain of 15 percent to 25 percent with no additional cost. This is true whether you have a single- or quad-processor server. 5. Run Windows Server 2003 Exchange 2003 and Windows Server 2003 were designed together, and memory tuning, processor optimization and several other performance aspects of Windows Server 2003 are all utilized by Exchange 2003. You can do the deployment in other ways, but the best gains can be yours if you plan to keep Windows Server 2003 and Exchange Server 2003 together. 6. Verify and Set Your Memory Configuration Exchange 2003 does much of the memory tuning that was manual under Exchange 2000. One of the few remaining memory configurations that you need to tune manually with Exchange 2003 is the boot.ini if your system has more than 1 GB of RAM. On a Windows 2003 server, you need to modify the c:\boot.ini file with the addition of the /3GB and /USERVA=3030 settings.
Sample boot.ini for Windows 2003 servers: Boot Loader] Timeout=30 Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [Operating Systems] multi(0)disk(0)rdisk(0)partition(2)\winnt="microsoft Windows Server 2003" /fastdetect /3GB /USERVA=3030 For Windows 2000 Advanced Server, the /3GB switch is used, but the /USERVA=3030 switch is invalid. For Windows 2000 Standard Server, no switches can be used at all, Exchange will be limited to 2 GB of usable RAM, and the remaining RAM will be allocated to the OS or other processes running on the system. 7. Network Configuration and Performance Network configuration on LAN segments will rarely be an issue for modern hardware with the efficiency of current LAN adapters. With users connecting across a WAN, however, bandwidth and latency are both important factors to consider in overall Exchange performance. With Exchange 2003 and Outlook 2003, Microsoft has introduced Cached Mode Exchange, which greatly reduces the impact of latency and bandwidth issues across a WAN. In real-world deployments, Cached Mode Exchange against an Exchange 2003 server can average as little as 1 Kbps per user at peak usage. In this case, a T-1 that is dedicated to Exchange traffic could handle as many as 1,500 users a vast improvement. Other improvements include compressed data streams and an optimized RPC protocol that requires significantly fewer round-trips per operation, resulting in better end-user insulation from bandwidth and latency issues commonly experienced with Exchange 5.5 and Exchange 2000. 8. Disk Configuration Disaster is always unexpected, and when it happens to your e-mail system it only feels worse. You can try to avert catastrophe (or plan to recover from it) with a good disaster recovery policy. If you do not have one, the next step would be to consider clustering or high availability. If that is not possible, you should at least have a Redundant Array of Inexpensive Disks (RAID) set ready. Hard drives have a mean time between failure (MTBF) set, and the drives will eventually fail. It s imperative that you have all these forms of disaster planning in place, but in its simplest form, you should really have RAID running. RAID can also improve read and write speeds to and from your hard disk, as it also utilizes striping. When choosing a RAID configuration, consider RAID 1+0 as the first choice and RAID 5 as a compromise if your budget won t allow for the additional disks needed for RAID 1+0. SAN environments with the additional cache and processing power can often significantly narrow the performance gap between RAID 1+0 and RAID 5. There also are benefits in performance and monitoring via most vendors SAN software and hardware. 9. Disk Geometry When formatting the volumes for use with Exchange, be sure to use the diskpar utility that comes with the Windows 2000 Server Resource Kit to correctly align the physical disk geometry. Before you mount a new RAID volume through disk manager, open a
command prompt and run diskpar.exe i * to get a list of available disks, then run diskpar.exe s to format the disk with a 64 Kb off-set. If using a SAN, consult your SAN vendor for the proper off-set. Also, make sure that you use NTFS for best performance and security. 10. Disk Performance An average disk read performance to work from is between 0.5 and 0.75 IOPS (I/Os per second) per active user for the data store volume. A good rule of thumb for I/O ratios on Exchange stores is three reads for every write. A typical 10,000 RPM Fibre Channel drive delivers approximately 100 IOPS. A 15,000 RPM Fibre Channel drive delivers approximately 120 IOPS, which means that you re often better off buying more 10,000 RPM drives rather than upgrading to 15,000 RPM drives. The RAID configuration also will have an impact on the overall performance of a set of spindles. The impacts on IOPS for using RAID 0 (no data protection) on a typical exchange system is none, so the RAID multiplier is 1.0, but RAID 1 or RAID 1+0 doubles the number of I/Os required for each write, so the multiplier is 0.8 (i.e., you will get roughly 80 percent of the overall performance of a RAID 0 array with RAID 1). For a RAID 5 array, which requires four I/Os per write, the factor is 0.57, or 57 percent of the overall performance of a RAID 0 array, which means you often need fewer disks when implementing with RAID 1 than you need with RAID 5 due to the performance constraints. If you are using a SAN, check with your SAN vendor to see what the impact of the various RAID levels is on the effective IOPS of the system, as advanced caching techniques can increase RAID 5 performance significantly. The overall calculation for the number of spindles you need to achieve a certain number of IOPS can be summarized in the following equation: # Disks Required = (# IOPS/user desired x Number of Users)/(IOPS/disk x RAID Level Factor) For example, a server to handle 1,000 users at 0.5 IOPS/user with RAID 1 would use the following equation: N = (0.5 x 1,000)/(100 x 0.8) = 6.25 or eight total disks (after rounding up to the next even number). If RAID 5 were used, however, N = (0.5 x 1,000)/(100 x 0.57) = 8.9, or nine total disks. Moving to 15,000 RPM disks changes these numbers to six and eight, respectively. To determine the IOPS per user on an active system, monitor the physical disk/disk transfers/sec perfmon counter over a period of time, looking for your peak activity, and then use this equation: IOPS/user = (peak disk transfers/sec)/(number of users at peak). If your system is flatlining with a consistently high disk transfers/sec counter, you probably need to add more disks and/or change the RAID level of your array. 11. Global Catalog Servers Your domain controllers will be doing a lot of the address book lookup work that Exchange servers did under Exchange 5.5. For this reason, it is important to monitor and design your Active Directory environment with Exchange in mind, and understand that overloading your domain controllers can have a direct impact on your Exchange system
performance. Be sure to have global catalogs located in the same sites as your Exchange servers and avoid multi-purpose domain controllers if at all possible. 12. Performance Monitoring One of the most important things to know about tuning a server is what counters to watch for. Microsoft has simplified this greatly by releasing the Performance Monitor Wizard, available for download at www.microsoft.com/downloads/details.aspx?familyid=31fccd98-c3a1-4644- 9622faa046d69214&DisplayLang=en. This tool will automatically set up monitoring for the most important aspects of Exchange. Run the wizard, select Advanced Configuration and on the next screen, check the Exchange Server box. (See Figure 1.) Continue through the wizard, selecting the names and locations of the log files and frequency for updates. Finally, you will be presented with a screen to select the aspects of the system that you d want to monitor. Figure 1: Performance Monitor 13. Perform Load Testing Be sure to validate the performance metrics that you predict for your system by using jetstress, loadsim and medusa (aka, Exchange Stress and Performance) tools, available for free download from Microsoft s download center. Jetstress is a good way to evaluate a single server s disk I/O performance and really helps evaluate RAID or SAN controller performance and the impacts of using various configurations. Loadsim emulates actual users sending e-mail messages across your system by opening active MAPI sessions. It can be used to perform end-to-end performance testing of your overall system. Be sure to turn on perfmon prior to starting your loadsim tests, so that you can identify whether your bottlenecks are memory, disk I/O or CPU-based limitations. Medusa is similar to loadsim, but adds the ability to test and tune IMAP, POP-3, LDAP, WebDAV and a slew
of other non-mapi type connections into your Exchange environment, allowing for a more realistic performance test, particularly when combined with MAPI calls from loadsim. 14. Exchange Best Practices Analyzer Microsoft has released the Exchange Best Practices Analyzer tool to help administrators find problems in their configurations and to make suggestions on ways to improve their Exchange systems. A very straightforward wizard looks at your environment and pinpoints any of several possible problems with your system. While it s not a perfect tool, the feedback is very useful, and Microsoft is upgrading the tests and checks that the tool performs on a regular basis. To download the tool, visit www.microsoft.com/exchange/downloads/2003/exbpa/default.asp. 15. Document the Environment and Keep a Change Log As your last and final tip, make sure that you document and log your environment. You can learn a lot from a log and some documentation. Make sure you keep a constant look at your Event Viewer logs as well you can take proactive steps toward handling potential problems or issues. Summary It is essential to pay close attention to detail when attempting to make a great Exchange deployment even better. When rolling out and managing your Exchange deployment, remembering these details will ensure a better-performing system. A final note: Make sure to back up your systems before applying any patch or fix, complete all tests in a lab segment and always have a back-out plan for your production systems. Robert Shimonski and Chad Conrow are currently involved in a global Exchange 2003 deployment spanning hundreds of sites around the world. The 15 tips were provided from a real-world deployment and are important when assessing your current Exchange environment. For any questions or comments, e-mail the authors at rshimonski@certmag.com. This article originally appeared in Certification Magazine, www.certmag.com.