To create an Exchange deployment that can hold up to the rigors of everyday use 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. 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.
Windows Server 2003 and Exchange will run on just about any x86-based server—or PC, for that matter. However, I recommend you use Microsoft’s Hardware Compatibility List (HCL) and only Microsoft-certified hardware. Plan Your Deployment The most important part of any Exchange deployment is the planning stage. Because full coverage of Exchange planning would require a decent-sized book, let’s focus on how to plan for fault tolerance and disaster recovery. 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, 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. And remember that clustering a database server protects you only from database-server failure. Your Exchange organization has several 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 address these potential points of failure.
Firming Up AD. Remember that Exchange is completely dependent on AD, which can also be a point of failure. If AD were to fail or 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). But you must also consider AD’s dependencies. For example, 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.
Firming DNS and GC. 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. If a DC that’s hosting these various roles irreparably fails, the roles can be seized and assigned to another DC. However, if the first DC in the domain fails, you have a nightmare on your hands unless you’ve planned for such a failure. The GC server is also important. 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).
Don’t let a DNS server or GC server 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.
After you’ve planned your Exchange deployment, you can test our proposed design. Microsoft offers the System Center Capacity Planner, a great tool for determining whether a proposed design will be adequate for your organization’s needs. The System Center Capacity Planner isn’t available for download from the Microsoft Web site, but it’s included with TechNet and MSDN subscriptions.
