The Keys to a Robust Exchange Implementation - 28 Nov 2006

Anyone can run Exchange Setup on a server and install Exchange Server. However, there's a big difference between simply installing Exchange and creating an Exchange deployment that can hold up to the rigors of everyday use. Deploying Exchange in a production environment requires intensive planning. You need to consider everything from the hardware that you use to the demands of ongoing maintenance and server monitoring once the deployment is complete. As you'll see in this article, the secret to a stable, robust Exchange deployment involves a reliance on some external Exchange-related utilities that Microsoft offers, as well as extremely careful planning.

Verify Hardware Compatibility
Windows Server 2003 and Exchange will run on just about any x86-based server—or PC, for that matter. Even so, Microsoft's Hardware Compatibility List (HCL) exists for a reason; it contains a list of hardware that Microsoft has thoroughly tested and deemed 100 percent compatible with the Windows Server OS. I recommend that you use only Microsoft-certified hardware. Doing so not only avoids compatibility concerns but will probably let you more easily obtain technical support, should you need it.

As you shop for server hardware, you need to understand Microsoft's policy about HCL-listed hardware. Although the HCL lists individual components (e.g., system boards, SCSI controllers, video adapters), Microsoft certifies only complete systems. Even if you were to build a server out of Microsoft-certified components, the server would be unsupported. Microsoft does, however, let you start with a certified server and add other HCL-listed components to that server.

Plan Your Deployment
The most important part of any Exchange deployment is the planning stage. Laying out everything you need to know about planning your deployment would require the space of a decent-sized book, so let's focus on how to plan for fault tolerance and disaster recovery. After all, no matter how much planning you put into your Exchange organization, some type of failure will eventually occur. During the planning process, you need to decide what level of failure is acceptable to your organization.

Clustering. If email is a mission-critical application in your organization, and you won't accept any level of failure, you should consider clustering your database servers. That way, if a database server fails, another server in the cluster can take over. Having a cluster in place also lets you take servers down for maintenance without affecting email availability.

There are two clustering models: active/active and active/passive. In the active/active model, all servers are simultaneously in use, whereas in the active/passive model, at least one server is standing by in case of failure. The active/passive model is preferred; if a failure occurs in an active/active cluster, no spare server is available to take over the workload. It's up to the remaining cluster node to perform both its own workload and that of the failed server. At best, performance will be diminished, but it's also possible that the workload will completely overwhelm the remaining cluster node. Keep in mind that an active/passive cluster can have more than two cluster nodes. Therefore, the percentage of cluster hardware that remains unused decreases as the number of cluster nodes increases—unless you designate multiple nodes to be passive.

New Exchange administrators mistakenly believe that clustering database servers will protect them from any sort of failure. However, clustering a database server will protect you only from database-server failure. Your Exchange organization has plenty of other single points of failure—for example, a DNS server, a Global Catalog (GC) server, a front-end Exchange server, or even a WAN link. The good news is that you can use redundancy to overcome all these obstacles.

Just as you can cluster an Exchange database server, you can also cluster an Exchange front-end server. In this case, however, the active/active and active/passive models don't apply because a front-end Exchange server is actually just a Microsoft IIS server that happens to be hosting Outlook Web Access (OWA). You would therefore cluster a front-end Exchange server by using the Network Load Balancing (NLB) service, similar to the way you would cluster any other Web server.

Firming Up AD, DNS, and GC. Remember that Exchange is completely dependent on AD, which can also be a point of failure. If AD were to fail, or if AD were to become inaccessible to Exchange, Exchange would also fail.

You might assume that your AD implementation is protected against failure because you have multiple domain controllers (DCs). That's a good start, but you have to also look at AD's dependencies. Probably the best known of these dependencies is that AD can't function without a DNS server. Therefore, it's vital to have at least one secondary DNS server so that should your primary DNS server fail, AD can continue to function. Many large organizations go so far as to place DCs and secondary DNS servers in every branch office so that if a WAN link fails, the systems within the branch can still communicate with each other. Of course, placing DNS servers and DCs in branch offices causes replication-related traffic to flow across the WAN link that separates the branch office from the main office. You would need to consider whether you have sufficient bandwidth to support the additional traffic.

When you create the first DC in a new forest, Windows makes the new DC a DNS server—assuming you don't already have a DNS server—and it also assigns various AD roles to the server. Most of these roles can be assigned to only one server in the entire forest (for forest-level roles) or to only one server in each domain (for domain-level roles). If a DC that's hosting these various roles were to irreparably fail, the roles can always be seized and assigned to another DC. However, if the first DC in the domain fails, you've got a nightmare on your hands unless you've planned for such a failure ahead of time. By default, this DC holds all the operations master roles for the forest and for the domain of which it's a member. The server is also usually acting as a DNS server and the GC server, neither of which Exchange can function without. I have personally dealt with a situation in which such a server failed and no secondary DNS server or GC server existed. It wasn't pretty.

The GC server is important for several reasons. For example, if no GC server is available, the administrator is the only user who is permitted to log on. Also, an Exchange server must be able to query a GC server to resolve the email addresses of message recipients. The GC server is also vital when Microsoft Outlook clients open the Global Address List (GAL).

My point is that you shouldn't-allow a DNS server or GC server to become a single point of failure on your network, particularly if these two servers are the same server. The good news is that designating a server as a secondary DNS server is simple, and you can configure any DC to act as a GC server. However, you don't want to configure every DC in your organization to act as a GC server—unless your network consists of one domain.

Generally, you'll want to place a GC server into any AD site that contains an Exchange server. The exception to that rule is a site that contains fewer than a hundred mailboxes and you have a reliable WAN link to another site that contains a GC server. Of course, if the WAN link fails, no GC server will be accessible. When you're planning GC server placement, you'll also want to make sure that you have at least one GC server for every four Exchange CPUs. Doing so ensures that no single GC server becomes overloaded.

Of course, you must remember that the simulation is based on simulated users and on simulated hardware rather than on real-world performance data. The simulation won't be completely accurate because, in the real world, servers don't always perform at anticipated levels, and users don't typically conform to anticipated usage patterns. Therefore, to allow for a margin of error, I recommend adding 10 percent to the anticipated workload.

Obviously, the System Center Capacity Planner is a great tool for determining whether a proposed design will be adequate for your organization's needs. The tool also lets you plan for the future. After you've tested your model, and you're confident with what you've planned, you can play with various "What if?" scenarios. For example, you might want to see the effect of adding a hundred mailboxes to a particular server. If your network uses redundant WAN links, you can even see the effect of a link failure on network performance. The System Center Capacity Planner isn't available for download from the Microsoft Web site, but it's included with TechNet and MSDN subscriptions.

Test Your Plan
Now that you've given some thought to your Exchange deployment, you need to put your proposed design to the test. Microsoft offers a tool called the System Center Capacity Planner that's perfect for testing a potential deployment.

The tool lets you create a virtual model of the deployment. Not only can you model your Exchange organization's topology and server placement but you can also include such factors as proposed hardware for individual servers and network-link speeds. Then, you can run simulations against the model, taking into account such concerns as the number of users with mailboxes on each Exchange server, the types of activities that the users engage in, and the anticipated level of activity for each user. After completing the simulation, the System Center Capacity Planner shows you any areas in which your proposed design might not be able to reliably handle the anticipated workload.

Of course, you must remember that the simulation is based on simulated users and on simulated hardware rather than on real-world performance data. The simulation won’t be completely accurate because, in the real world, servers don’t always perform at anticipated levels, and users don’t typically conform to anticipated usage patterns. Therefore, to allow for a margin of error, I recommend adding 10 percent to the anticipated workload.

Obviously, the System Center Capacity Planner is a great tool for determining whether a proposed design will be adequate for your organization’s needs. The tool also lets you plan for the future. After you’ve tested your model, and you’re confident with what you’ve planned, you can play with various “What if?” scenarios. For example, you might want to see the effect of adding a hundred mailboxes to a particular server. If your network uses redundant WAN links, you can even see the effect of a link failure on network performance. The System Center Capacity Planner isn’t available for download from the Microsoft Web site, but it’s included with TechNet and MSDN subscriptions.

Fine Tune It
Even after you devote all this effort to planning your new Exchange deployment, you'll probably have to do some fine-tuning after the deployment is complete. You'll need to make sure that everything is performing as expected and that your configuration conforms to Microsoft's recommended best practices. Fortunately, Microsoft offers a free tool that's perfectly suited to this task: the Microsoft Exchange Best Practices Analyzer (ExBPA).

The ExBPA gathers configuration and performance data from various sources, such as the Windows registry, AD, Performance Monitor, and the metabase. After it collects this data, the ExBPA compares it with various best-practice rules. In doing so, the ExBPA can produce a report that details the steps you need to take to achieve better performance, stability, and security.

Maintain It
After you've fine-tuned your Exchange deployment, you'll turn your attention to its ongoing monitoring and maintenance, which is essential for several reasons. First, your Exchange organization will inevitably change over time. Even if you don't plan on adding servers or rearranging the deployment (although both scenarios are possible), the level of usage will change. Databases will grow, and you'll probably create additional mailboxes. The amount of spam that your Exchange implementation receives will likely fluctuate over time. All these factors will have some kind of effect on your Exchange organization's performance.

Second, regular maintenance is vital to ensuring ongoing reliability. A server's performance metrics and event logs often contain clues about situations that aren't yet problematic but that will become so if you don't act upon them. Keeping tabs on this type of information lets you correct various concerns before they can disrupt service.

Many organizations used to simply neglect the task of monitoring their Exchange servers. Performing comprehensive Exchange monitoring is a full-time job, and to properly interpret the data, the person in charge of reviewing the log and performance-metric data needs a high-level understanding of both Exchange and Windows, so many companies just crossed their fingers and hoped everything was OK. A few years ago, Microsoft Operations Manager (MOM) changed the scene by automating the task of server monitoring. MOM monitors both performance metrics and the event logs to gauge a server's health. MOM also proactively takes corrective measures in many situations, should the data point to a condition that could become problematic. It's worth noting that the System Center Capacity Planner is also designed to assist in a MOM server deployment.

Focus on the Key Areas
I can't overemphasize the importance of careful planning and testing in the quest for a robust Exchange deployment. I don't pretend to have the space here to address every aspect of growing a brilliant Exchange organization, but I hope I've shed light on the particular areas in which studious preparation will make the most difference to your organization's long-term stability.