In "Top Exchange Design Considerations," January 2006, Instant-Doc ID 48307, I presented four key architectural principles—simplicity, integration, cost, and efficiency—and gave you some tips for how to launch an Exchange Server design by documenting your business and design requirements and planning your Active Directory (AD) and hardware requirements. Let's go over six more steps that are invaluable in designing a successful, efficient Exchange Server 2003 or Exchange 2000 Server organization.
#5: Spend Time with Storage-Group and Database Design
In my previous article, I discussed the importance of sizing up your hardware, giving each storage group (SG) a dedicated disk volume and devoting time and attention to planning the disk subsystem. The same advice and cautions that apply to SGs apply to the Exchange databases. From a design perspective, a database serves one of two primary purposes: to support mailbox polices (which are applied at the database level) or to address recovery times. Therefore, your database design should be driven by business requirements, as I explained in the previous article. Spreading mailboxes across many smaller databases can support faster recovery times and limit the impact of a database outage. However, you also need to consider the type of backup and restore you plan to implement, as the example in the sidebar "Recovery Times in Database Design," page 6, explains.
Test SG and database designs in a lab to ensure that your design will meet the business requirements you've identified. For SGs, running Performance Monitor and monitoring the transaction-log volume set is crucial. Use disk-monitoring tools to baseline the disk I/O load and to identify bottlenecks. When reviewing performance data, focus on averages, not just a few high peaks, or you run the risk of over-engineering, thus adding cost and complexity—but little real benefit—to the Exchange environment. Use Microsoft Jetstress to test the disk subsystem's performance and stability and identify any subsystem-related design problems before you introduce the server into your production environment. The good news about Jetstress is that it can perform two types of disk tests: a performance test and a subsystem stress test. The bad news is that the tool only simulates the Exchange environment. (You can find more information about Jetstress at http://www.microsoft.com/downloads/details.aspx?familyid= 94b9810b-670e-433a-b5ef-b47054595e9c&displaylang=en.)
What's the great news? Exchange 2000 and later let you easily move mailboxes, often without an impact to end users. This ability lets you redesign SGs and databases as needed, with little to no production outage.
#6: Identify Server Roles
As companies move toward consolidating and centralizing Exchange servers, routing can sometimes become a performance bottleneck, as the sidebar "Dedicate Your Servers When Necessary" illustrates. Fortunately, you can configure Exchange 2000 and later servers to function in a variety of roles—anything from a dedicated bridgehead server to an all-in-one server. Leverage this flexibility and configure the server to perform a dedicated role if necessary. At the same time, beware of going overboard and designing an environment that will require excessive hardware. Take your time to find the right balance between multifunction Exchange servers and dedicated servers. Again, let the business requirements guide the design (see "Dedicate Your Server Servers When Necessary" for another example).
The front-end/back-end design philosophy is often absent in smaller Exchange deployments. But supporting additional services such as Outlook Web Access (OWA), routing, Secure Sockets Layer (SSL), antivirus, and antispam on a single Exchange server can prove to have so many negative effects that these companies lose the cost savings of deploying only one Exchange server. If you're debating whether this is the case in your environment, I strongly suggest that you consider using a front-end/back-end Exchange architecture to isolate certain services such as OWA, SSL, and routing. Another advantage of using a front-end server is that inbound email is queued for delivery in the event that the back-end Exchange server goes offline. Separating such services can also simplify troubleshooting.
#7: Be Smart About Security
Trying to keep out viruses and spam is a huge resource drain for most companies (another good reason to configure these services on dedicated servers). Installing protection services (e.g., antispam filters) in the demilitarized zone (DMZ) on non-Exchange servers can reduce the load by deleting and removing unwanted content before it reaches the internal network. I worked with one company that reduced the amount of email reaching the internal network from more than 1,000,000 messages per day to less than 100,000 per day by moving its antivirus and antispam service to the DMZ. Previously high utilization and slow mail delivery on this company's Exchange servers disappeared the day it implemented the design change. Should you still run antivirus software on your Exchange servers if you've installed antivirus software on client machines and gateway servers in the DMZ? Yes. Always install an email-based, scanning antivirus product on all your Exchange servers, including front-end, bridgehead, and OWA servers. The benefits of virus and spam protection are well worth the cost when you consider the risk of your Exchange servers becoming infected or letting in a worm that could harvest confidential company information.
Many companies let their Exchange servers accept internal email from non-Microsoft servers (e.g., UNIX servers) running SMTP applications that send email. In this situation, applications or scripts can drop a correctly formatted SMTP text file directly into the Exchange pickup directory (C:\program files\exchsrvr\mailroot\vsi1\pickup, by default), and Exchange will attempt to process and deliver that email. Be aware that this is also an opening for viruses to enter your Exchange environment.
Be sure that whatever antivirus product you install on the Exchange server is an Exchange-aware application that uses the Exchange Virus Scanning API (VSAPI). Using VSAPI negates the need for daily rescanning of the Exchange databases to catch missed messages. If a client requests a message, VSAPI guarantees a scan. Companies that require the best possible protection from viruses can use a multiple-vendor approach. Install one antivirus product on the SMTP relay server in the DMZ; install another antivirus product on the Exchange servers in the internal network. This approach provides a dual layer of protection: If one vendor's product misses a virus or is slow in receiving updates for newly released viruses, the second product might detect the culprit. I've seen this concept work several times with great success. Some companies even use a three-tier approach in an attempt to provide the maximum available protection.
Another common question is whether to install a file-based antivirus product on the Exchange server. The answer depends on how securely and how well the internal network is managed. Do administrators often browse the Internet from Exchange servers? Do they copy files from the Exchange server's CD-ROM or USB drives? If so, than installing protection on the Exchange server is probably a good idea. However, if your design recommends this step, be sure to exclude from the antivirus product and its scans any folders containing Exchange files. Exclude the default Exchange location (C:\ program files\exchsrvr and its subfolders) as well as any drives that support Exchange SGs, databases, transaction logs, SMTP drop locations, and so forth. The primary Exchange-aware antivirus product will protect these locations.