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.
#8: Be Ready to Recover
Most companies have a solid backup strategy in place and do a great job backing up Exchange server data. However, many companies' backup plans are designed to meet business and recovery requirements that are several years old (and thus outdated). Business requirements change over time, so if you're working on a design that refreshes (rather than launches) an Exchange organization, be sure to review the existing backup policies to ensure that they meet current business needs. Be sure to include restore times as a part of the decision. In most circumstances, the time needed to restore Exchange is more important than the time needed to back up Exchange.
Specify that test restores are to be performed as part of a regularly scheduled, proactive process. Backing up an Exchange server involves both software and hardware technology, one or both of which can fail from time to time. Performing regular test restores will provide a greater chance of a successful real-life restore and will ensure that administrators know how to restore Exchange data after a disaster.
Exchange 2000 introduced multiple SGs and databases; Exchange 2003 added the Recovery SG (RSG). These enhancements brought us more decision points in meeting Exchange recovery requirements. Multiple recovery points now exist within a single Exchange 2003 server that hosts mailboxes, and you must ensure that your backup methodology addresses each one. The most common recovery scenarios are
- restoring a single item or mailbox,
- restoring a single database,
- restoring multiple SGs and databases on one server,
- performing a Messaging Dial Tone recovery (typically for a corrupted database), and
- performing a total server recovery (i.e., bare metal recovery).
Which of these considerations will apply to your design will vary depending on the company's recovery requirements. What was considered a disaster for an Exchange Server 5.5 system is often a simple restore of a single database in Exchange 2003.
The new functionality of the RSG, along with disk-to-disk backups, has allowed some Exchange environments to implement a simplified backup-and-restore strategy that uses only NTBackup. Like other backup products, NTBackup can be used to back up an Exchange server by using a disk-to-disk then disk-to-tape process (the entire process is referred to as disk-disk-tape). This simplified implementation has many benefits:
- disk-to-disk backups can use less-expensive, slower disks as backup (or secondary) disks
- disk-to-tape lets you roll the offline backup to tape or other offline media at your convenience
- this implementation requires less-expensive hardware
- this implementation requires less software on Exchange servers
- this implementation requires a less-complicated environment to support and administer
- restores that use disk-to-disk backups can be completed remotely, without physically mounting a tape
Ultimately, service level agreements (SLAs) determine the appropriate backup strategy. With new and updated features in Exchange 2003, businesses have many configuration options available to meet their Exchange backup, restore, and disaster-recovery requirements while still allowing an easily supported Exchange environment. Evaluate these options carefully during the design process.
#9: Secure Internet Connectivity
With Exchange now qualifying as a mission-critical application for most companies, you need to give serious consideration to the implementation of Internet-facing services such as SMTP relay servers, antivirus servers, content filtering, and firewall options such as Microsoft Internet Security and Acceleration (ISA) Server 2004. As I mentioned earlier, placing antivirus, antispam, and content-filtering services in the perimeter network protects your Exchange infrastructure from unwanted traffic and adds a security barrier between the bad guys and your Exchange infrastructure. Administrators sometimes believe they've secured the Exchange environment simply by placing an SMTP relay server in the perimeter network or by forwarding ports 25, 80, and 443 through firewalls to the Exchange servers on the internal network. Not so.
The best protection I've found is the installation of an ISA Server solution in the perimeter network. It took me awhile to say "Microsoft" and "firewall" in the same breath, but I have to admit that Microsoft has done a great job designing ISA Server to protect the Exchange environment. ISA Server completely authenticates OWA users before letting them on the internal network, inspects every email before delivering it to Exchange, and provides another level of security for Remote Procedure Call (RPC) over HTTP, to name just a few features. These capabilities alone make ISA Server worth consideration.
#10: Take Advantage of ExBPA
No discussion of successful Exchange design would be complete without a mention of the Exchange Server Best Practices Analyzer Tool (ExBPA). Running ExBPA after the installation and configuration of an Exchange server usually finds configuration parameters that have been missed or that should be reviewed. Running the tool at different times can produce different recommendations. For example, running ExBPA when only a few mailboxes are on a new Exchange mailbox server will produce one set of recommendations; running the tool again after adding several hundred or thousand mailboxes will produce an updated set of recommendations that take the new load into consideration. ExBPA provides an easy-to-read report along with working links that provide quality verbose information. I recommend that your design specify a regularly scheduled run of this tool on all Exchange servers. You can download the most recent ExBPA version at http://www.microsoft.com/exchange/downloads/2003/exbpa.
The Benefits of Good Design
Every Exchange installation is different and requires a unique solution that's tailored to fit the company's business requirements. Those requirements will change over time, as will available hardware and software features. Common sense is still the best weapon in the fight against an overly complex Exchange environment. A key architectural question is, "What is the business benefit from the technical decision being implemented?" Asking that question at every step and remembering the four key architectural principles of simplicity, integration, cost, and efficiency will help ensure the success of any Exchange design.
Mark England (mark.d.england@hp .com) is a senior solutions architect in HP's Americas Messaging Team. His focus is on complex messaging architecture and design. Mark is a frequent speaker at industry events and is a contributor to Exchange & Outlook Administrator and Windows IT Pro.
