Knowing how to build fault tolerance and redundancy into your Exchange Server 2007 computers and supporting services is only the first step in designing a highly available Exchange
system. You also need to understand the various Exchange Server 2007 roles, how they operate, and the appropriate method for adding redundancy or fault tolerance to each role.

Implementing Redundancy for Hub Transport Servers Exchange Server 2007 breaks functionality into separate server roles.

All message flow in Exchange Server 2007 requires the Hub Transport server role. Thus, if your Hub Transport server is down, then you cannot send messages to anyone: Not even to users on the same Exchange Server 2007 Mailbox server. Not even to users whose mailboxes are in the same mailbox database. Not even to yourself! Therefore, unless you are deploying Exchange Server 2007 on a single server in an environment that doesn't require high availability,you need redundancy for the Hub Transport server role.

Hub Transport Redundancy within the Site

More. That's all it takes. Nothing fancy, nothing challenging. To provide redundancy for Hub Transport servers within an Active Directory (AD) site, you simply install more of them.
When a message is placed in a Mailbox server's submission queue, the Mailbox server notifies a Hub Transport server in its AD site that the message is ready to be processed. If the Mailbox
server doesn't reach the first Hub Transport server it tries to contact, then it just tries another Hub Transport server in the same site. If the Mailbox server can't reach any Hub Transport servers in the same AD site, then the message just sits in the submission queue until a Hub Transport server in the same AD site is available.

Hub Transport Redundancy between Sites

Likewise, for site-to-site message-routing redundancy, you just need multiple Hub Transport servers in each AD site. If a Hub Transport server in one site needs to route a message to another site, then it retrieves the list of Hub Transport servers in the target site. If the first server on the list is unavailable, then the sending Hub Transport server just tries the next one on the list. If the second one isn't available, it tries the next one and so on. If none of the Hub Transport servers in the target site are available (if, for example, the WAN link to that site is down), and if another route to that AD site is available for transferring messages, then the sending Hub Transport server will attempt to route the message through an intermediary site. In that case, the sending Hub Transport server in the originating site retrieves the list of Hub Transport servers that exist in the intermediary site and tries to route the message to the first server on the list and, if that server is unavailable, then the sending Hub Transport server tries each listed server until it finds an available Hub Transport server or exhausts the list. If that happens, then the sending Hub Transport just looks for the next-higher-cost route to the original destination site.

Implementing Redundancy for Client Access Servers

As with previous versions, Exchange Server 2007 supports a variety of clients. The preferred client is Microsoft Office Outlook 2007, but all versions of Outlook will work with Exchange Server 2007. Outlook relies upon the messaging application programming interface (MAPI). Other clients include Microsoft Office Outlook Web Access (OWA), which is a web-based client; any Internet client that uses Post Office Protocol 3 (POP 3) or Internet Message Access Protocol 4 (IMAP 4), such as Windows Mail and Outlook Express; and Windows Mobile clients that use Exchange ActiveSync (EAS).
In Exchange Server 2007, Client Access servers are required for any non-MAPI client. Thus, if you're using any client other than Microsoft Office Outlook and the Client Access server fails, the non-Outlook users will be unable to access their mailboxes. Additionally, several Outlook 2007 features, such as Autosiscover and the Availability service, require the Client Access server as well. So, if the Client Access server fails, Outlook 2007 users may have difficulty using their mailboxes or using all features of Outlook.Implementing redundancy for Client Access servers is a little more complicated than for
Hub Transport servers, but not much. The first step is the same: install multiple servers in each AD site with a Mailbox server. However, the Client Access servers installed in each site should be load balanced. One option for load-balancing your Client Access servers is to use thirdparty load-balancing hardware. Another option is to implement Windows Network Load Balancing (NLB). NLB lets an administrator add a shared IP address to the network interface cards (NICs) of all members in the NLB cluster. Because, from the client perspective, all Client Access servers appear to be servers with identical content, NLB can be used for both high availability and scalability.

Implementing Network Load Balancing

NLB is supported on Windows 2000 Advanced Server, Windows 2000 Datacenter Server, and all editions of Window Server 2003. NLB is implemented at the NIC level. To implement NLB,
you enable NLB in the properties of the NIC and configure the NLB properties, such as the shared IP address and the fully qualified domain name (FQDN) of the cluster, and the dedicated
IP address this cluster member will use when communicating with other cluster members. All members of an NLB cluster must be a member of the same IP subnet. (The shared IP address must also be one of the IP addresses configured for the NIC in the IP properties.) Additionally, you should attach your NLB cluster members to a hub rather than a switch. Because switches filter packets based on media access control (MAC) address, it is highly possible that attaching your NLB cluster members to a switch would interfere with the proper filtering/forwarding decision for packets addressed to the virtual MAC address assigned to the shared IP address. Because hubs do not filter packets, connecting your NLB cluster members to a hub then connecting that hub to a switch eliminates this problem. While you could use a virtual LAN (VLAN) to implement an NLB cluster by using cluster members that are in different physical locations, few Exchange deployments would benefit from such a configuration. Further, implementing an NLB cluster on the Internet-facing side of cluster members that reside in different locations and have different Internet connections would not load-balance across the Internet connections. Instead, all traffic would need to be routed through one of the Internet connections and then directed internally to the NLB cluster
members in the other locations.

Round-Robin DNS

You could attempt to load-balance across Internet connections by using round-robin Address (A) records in DNS. In fact, some might suggest using round-robin records instead of NLB
clustering for Client Access server high availability. While using round-robin for balancing across Internet connections is fine, using round-robin in place of NLB for Client Access servers
in the same AD site is not preferred, for two reasons:

- Round robin entries are rotated only by the authoritative DNS server; any DNS server that caches a round-robin response will provide the IP address list in the same order until the time to live (TTL) for the cached entry expires.

-Round-robin records do not truly balance load; instead, round-robin records, at best, balance the initial contact, and they don't take into account the variety of factors that can disrupt the balance, such as DNS caching and offline servers. NLB, does a somewhat better job of distributing load based on actual requests (as opposed to initial contact) and rebalances whenever cluster membership changes.

Implementing Redundancy for Unified Messaging

If you implement Unified Messaging, then you are using Exchange Server 2007 to manage phone calls, voicemail, and faxes. Thus, if your Unified Messaging server, or any other component, such as a Voice over IP (VoIP) gateway, fails, then your voice and fax services could be unavailable. This scenario is arguably even worse than losing email. So, if you're going to implement Unified Messaging, you must build redundancy into your Unified Messaging components. Fortunately, implementing redundancy in your Unified Messaging isn't very difficult. First you should have multiple Unified Messaging servers in each site where you deploy Unified Messaging servers. But beyond that, you must have multiple paths for the calls to reach the Unified Messaging servers. This means you must have redundancy in your VoIP gateways.

In corporate phone systems, calls are typically delivered by trunk lines to a private branch exchange (PBX). A PBX is a device that works like a phone-company switching system but it is located in the corporate office and is often owned and managed by the business rather than the phone company. In traditional PBX phone systems, each office extension is directly wired to the PBX, and the PBX routes calls from extension to extension or between an external trunk line and an internal extension. In VoIP phone systems, extensions are not directly wired to a PBX but are, instead, configured
as clients on an IP-based network. A VoIP gateway or hybrid IP-PBX device routes calls to extensions by using IP. PBX hunt groups are used to associate the PBX to a VoIP gateway. If you deploy multiple VoIP gateways, you can create multiple hunt groups to balance call volume between your VoIP gateways. VoIP gateways locate Unified Messaging servers by using dial plans. When trying to
hand off a call, a VoIP gateway will try each Unified Messaging server in the dial plan until one accepts the call. If you've deployed multiple VoIP gateways, then configure a single dial plan on each VoIP, and configure each dial plan to include all available Unified Messaging servers. That way, your inbound calls will not be affected by the failure of either a Unified Messaging server or a VoIP gateway.

Unified Messaging servers need to have high-speed, reliable connections to the VoIP gateway, which, in turn, require high-speed, reliable connections to the PBX. While Unified Messaging servers require a connection to Mailbox servers, Unified Messaging servers do not necessarily require high-speed, reliable connections to all supported Mailbox servers.

Discuss/Post to digWin