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.
Previous
Register
