Exchange Queue & A
Load Balancing, Edge Transport, and More
Henrik Walther
Q We have several servers running Microsoft® Office SharePoint® Server deployed in our corporate production environment. Each of these servers needs to relay outgoing messages via the Hub Transport (HT) servers in our newly deployed Exchange Server 2007 infrastructure. Since a SharePoint server only allows us to specify the Fully Qualified Domain Name (FQDN) of a single SMTP (Exchange) server under the Central Administration | Operations | Outgoing E-Mail Settings page, as shown in Figure 1, I was wondering how we can eliminate this single point of failure?
.gif)
Figure 1 Outgoing E-Mail Settings on the SharePoint Central
Administration page (Click the image for a larger view)
A This is a very good question since so many organizations are focused on high availability and therefore won't accept any single point of failure throughout their corporate production environments. This is especially true when it comes to messaging and collaboration services.
Exchange 2007 HT servers are resilient by default. That is, if you have more than one HT server deployed in an Active Directory® site, and an HT server in that Active Directory site is unavailable, the source HT server trying to deliver the message will move on to the next available HT server in the Active Directory site. This is done using round-robin DNS mechanisms (if the first HT server on the list doesn't respond, let's try the next one).
So when it comes to all HT-to-HT and mailbox server-to-HT (that is, intra-org) communication, we don't need to care about high availability (or load balancing, for that matter), since this is native Exchange 2007 functionality. Bear in mind, though, that if you install the HT server role on a computer that also has the mailbox server role installed, the mailbox server role will always prefer the local HT server over any other HT servers in an Active Directory site (even when the locally installed HT server is unavailable) when the Microsoft Exchange Mail Submission service submits messages.
The preceding information is not really useful in regard to SharePoint servers, but it is important to know this before we move on. Since an HT server is resilient by default, load balancing intra-org communication between HT servers in Exchange 2007 using either hardware load balancers or Windows® Network Load Balancing (WNLB) functionality is not supported.
Actually, there wasn't any support for load balancing inbound SMTP traffic to the HT servers based on the Exchange 2007 RTM version. But Exchange 2007 SP1 changes this. With SP1, you still can't load balance intra-org communication using hardware load balancers or WNLB functionality (and why would you do so anyway?), but you can load balance inbound SMTP traffic from non-Exchange sources (such as SharePoint servers) and Exchange clients like IMAP or POP clients that submit outbound messages to the Exchange 2007 organization using the default client receive connector on the HT server.
So in order to configure a SharePoint server to relay messages via an Exchange 2007 SP1 organization, you can simply create a DNS record in your Active Directory DNS and point it to a hardware load balancer that can then distribute the traffic among multiple HT servers, or use WNLB functionality to accomplish this goal. To use the latter method, configure the WNLB cluster with a virtual IP address and FQDN (such as mail.contoso.com) and add port 25 (inbound SMTP traffic from non-Exchange servers) and 587 (inbound SMTP from Exchange clients such as IMAP and POP) under the Port Rules tab. Figure 2 shows what your Port Rules tab will look like with this configuration. You will also want to make sur.e that you assign the specific virtual NLB cluster IP address to both rules instead of selecting all of the IP addresses.
.gif)
Figure 2 Defined port rules (Click the image for a larger view)
When the NLB cluster has been configured, you need to create a new receive connector that should be configured to listen on port 25 and only allow the servers that require it to relay messages using this connector. In addition, make sure this connector uses the virtual NLB cluster IP address that was created earlier.
Q Our messaging infrastructure is based on Exchange Server 2007. In order to make our Exchange 2007 mailbox servers redundant on both the hardware and the storage levels, they are all clustered Mailbox servers based on Cluster Continuous Replication (CCR) technology. Both the active and the passive node in each CCR cluster are located in the same physical datacenter. Now that we have upgraded our Exchange 2007 servers to SP1, we want to leverage service and data availability by replicating Mailbox databases to Mailbox servers at a second site using the new Standby Continuous Replication (SCR) technology included with Exchange 2007 SP1.
We are aware that the SCR sources can be either Exchange 2007 SP1 stand-alone Mailbox servers or Clustered Mailbox Servers (CMS) based either on CCR or Single Copy Cluster (SCC) technology. But what about the SCR target servers?
A The SCR target servers (also known as SCR endpoints) must either be a standalone Mailbox server without Local Continuous Replication (LCR) enabled for any storage groups or a passive node in a Windows failover cluster (formerly known as a Microsoft Cluster Server) with the Mailbox server role installed. This means you can form your failover cluster and then install the Mailbox server role on a passive node in that failover cluster, but you cannot use a clustered Mailbox server as the SCR target.
Q Our organization uses Exchange 2007 as the messaging platform. We even decided to replace our old anti-spam/antivirus solution in the perimeter network with a solution based on Exchange 2007 Edge Transport servers with Forefront™ Security for Exchange installed so that we can benefit from multiple layers of message protection and security. Our plan is to deploy at least two more Edge Transport Servers in the near future.
This leads to my question. How would we go about load balancing inbound SMTP connections to our Exchange 2007 Edge Transport-based message hygiene solution and thereby distribute the load and make it fully redundant?
A If the Edge Transport servers in your perimeter network are the Internet-facing SMTP servers, you can use an approach similar to the one used in the Microsoft Information Technology (Microsoft IT) group. Microsoft IT has deployed six Edge Transport servers (three in Redmond and three in Silicon Valley) that handle more than 16 million inbound messages a day (and more than 13 million messages are filtered as spam).
Microsoft IT has a total of three Mail Exchange (MX) records for the Microsoft.com domain. They are: maila.microsoft.com, mailb.microsoft.com, and mailc.microsoft.com (see Figure 3). Each MX record has been configured with a preference of 10 so it will be picked randomly using a DNS round-robin technique. In addition, two IP addresses (mail hosts) are associated with each MX record.
.gif)
Figure 3 MX records and Internet mail hosts for Microsoft.com (Click the image for a larger view)
Why two IP addresses per MX record? Because some message transfer agents (MTAs) will always pick the same MX record, no matter how many MX records you have configured for a domain. With regard to Exchange Server, this hasn't been a problem for many years (not since Exchange 2000), but unfortunately there're still MTAs out there that have this design flaw. Thus, no matter which MTA tries to deliver a message to a Microsoft.com address, all SMTP connections are distributed using a combination of DNS round-robin and load balancing.
Q Our Active Directory domain is based on Windows Server® 2003 Domain Controllers (DCs). We're currently in the planning phase of transitioning our Windows Server 2003 DCs to Windows Server 2008 and our Exchange 2003 messaging environment to Exchange Server 2007. Can we transition our Active Directory domain to Windows Server 2008 by upgrading all servers running Windows Server 2003 to Windows Server 2008, before we transition the messaging environment from Exchange Server 2003 to Exchange 2007?
A Yes, Exchange Server 2003 SP2 is fully supported in an Active Directory domain consisting entirely of Windows Server 2008 DCs, so you can go ahead with your plan. Just bear in mind that if you plan to use Windows Server 2008 Read Only Domain Controllers (RODCs), you shouldn't configure the Exchange Recipient Update Service (RUS) to use an RODC.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.