Exchange Queue & A: CAS Arrays - Server Roles, Client Creation, Load Balancing and More

Henrik Walther

Make Sense of Server Roles

Q: I’m planning to upgrade our environment from Microsoft Exchange 2007 to Exchange 2010. This implementation has to be fully redundant on all levels. Because our organization has about 3,000 users, I plan to install Exchange on two machines initially. Each will have the Hub Transport (HT), Client Access Server (CAS) and Mailbox (MB) server roles. Both will also be members of a Database Availability Group (DAG), so the servers will replicate databases between themselves.

From our experience with the current Exchange environment, I know that if the HT and MB roles are on the same machine, the Microsoft Exchange Mail Submission service always prefers the local HT server. It doesn’t use other HT servers in the Active Directory site in a round robin fashion, as do MB servers that don’t have the HT server role.

If this is the same in Exchange 2010, we have an issue. Keeping the transport dumpster on a DAG member doesn’t make sense. If the member server becomes unavailable and mailbox databases fail over to the other DAG member, the messages in the transport dumpster can’t be resubmitted.

A: I understand your concern. First, let me assure you that the Exchange product group has considered this kind of scenario. Early on in Exchange 2010 development the team made a design change. If the Exchange Mail Submission service detects that it’s running on a mailbox server part of a DAG, it won’t prefer the local HT server. Instead, it will load balance across other HT servers in the same Active Directory site. If it doesn’t find any, it will fall back to the local HT server.

The Exchange Mail Submission service living on the MB role wasn’t the only thing the developers changed. They modified the HT role to reroute a message to another HT server in the Active Directory site if the HT role is installed on a server that also has the MB role and is part of a DAG. The group made both changes to ensure high availability when HT and MB roles coexist on a server that’s also a DAG member.

Client Access Design

Q: We’re designing our Exchange 2010 solution and must determine how many Client Access Server (CAS) arrays to create. We’ll have two data centers, each with its own Active Directory site. Should we create one per site or does it make sense for each to have multiple arrays?

Also, we’ll use DAGs to protect the mailbox databases and will have copies of each database split across the two sites. Does a failover or switchover to a copy on the other site, which has users connected, require us to manually reconfigure the DNS to point clients to that other site’s CAS array?

A: The decision about the number of CAS arrays should be easy—you can’t create more than one per Active Directory site. If you try, you’ll get the error message shown in Figure 1.

Figure 1 The error message you’ll see if you try to create a second CAS array in an Active Directory site.

Because you can access a mailbox database through any CAS array in your environment, there shouldn’t be a need for more than one. Even if you could create more, only the first would be used.

Regarding your other question, as long as at least one CAS server in the CAS array in site 1 is available, you won’t have to reconfigure DNS so clients are pointed to the other site’s array after a switchover or failover. Available CAS servers in site 1 will talk directly with the Mailbox servers (which store the active databases for users in site 1) using RPC.

Client Creation

Q: Do you have any best practices to share for creating an Exchange 2010 CAS array in an Active Directory site?

A: I’d advise you to create the CAS array before you make any Mailbox databases or move any mailboxes to an Exchange 2010 Mailbox server in a site. Exchange 2010 Mailbox databases have an attribute called RpcClientAccessServer. If there’s no CAS array in the Active Directory site when the database is created, this will be populated with the server FQDN of an Exchange 2010 CAS server in the Active Directory site. If you create the CAS array before any Mailbox databases, this attribute will instead be given the FQDN of the CAS array as shown in Figure 2.

 Figure 2 RpcClientAccessServer attribute on a Mailbox database.

Why is this a good idea? The Outlook client (whether Outlook 2003, 2007 or 2010) won’t pick up the change automatically. If you use Outlook 2007 or 2010, you can have the profile updated by making the old RPC endpoint unavailable or by performing profile repair. But Outlook 2003 can’t change the endpoint and doesn’t include a profile repair feature. That forces you to go in and manually change the profile by removing the username, adding it back and then clicking the “Check name” button). This isn’t ideal by itself, and it also involves end users, so you really should create the CAS array beforehand.

Load Balancing CAS Arrays

Q: We’re planning to use a hardware load balancer instead of Windows NLB for our CAS array, so we’re wondering if it’s possible to set static ports for the new Exchange 2010 RPC Client Access service. The vendor from which we got the hardware load balancer recommends that we not use dynamic ports. If we can set static ports for this service, do you then recommend any specific ones?

A: As with previous versions, in Exchange 2010 you can set static ports for the RPC CA service. You need to do so for it and the Exchange Address Book Service, because Outlook communicates with both of these via MAPI. Public folder connections still occur against the Mailbox servers as well.

To set a static port for the RPC CA service on a CAS server, you need to open the registry on each CAS server in the CAS array and navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC. Create a new key named ParametersSystem, and under this key create a REG_DWORD named TCP/IP Port. The Value for the DWORD should be the port number you want (see Figure 3).

There’s not a best practice with regards to the static RPC ports other than the recommendation that you use an unassigned and unused port on your corporate network. Microsoft IT chose to use TCP/IP port 7575 in the company’s corporate network. You should use whichever suits your situation.

To set a static port for the Exchange Address Book service, open the file microsoft.exchange.addressbook.service.exe.config located in C:\Program Files\Microsoft\Exchange Server\V14\Bin in Notepad. Then change the value to the TCP/IP port you want to use. You can’t use the same TCP/IP port for the RPC CA and the Exchange Address Book Service.

Figure 3 Configuring a static port for the RPC CA service on a CAS server.

When you’ve configured the port, you need to restart the Microsoft Exchange Address Book and the Microsoft Exchange RPC Client Access service. To set a static port for public folder connections, follow the same steps you carried out for changing the TCP/IP port used for the RPC CA service. The only difference is that you must also do so on the Exchange 2010 Mailbox servers, because public-folder connections occur against the RPC CA service on the Mailbox server role. When the port has been set for public folder connections, you need to restart the Microsoft Exchange RPC Client Access service on each Mailbox server.

Outlook Connections

Q: I’ve heard that only Outlook 2007 and 2010 can connect to an RPC CA service or a CAS array. Is this really true?

A: In the past, the Exchange 2010 documentation incorrectly stated that you couldn’t connect to the RPC CA service or a CAS array using an Outlook 2003 client. This was a so-called doc bug. Outlook 2003 clients are fully supported. You just need to make sure you either enable RPC encryption in the Outlook profile or disable the RPC encryption requirement on the CAS servers. From a security standpoint, Microsoft recommends that you enable RPC encryption in the Outlook profile. You can do this using a group policy. For the steps, see the KB article “Outlook connection issues with Exchange 2010 mailboxes because of the RPC encryption requirement.”

Load Balancing with Windows NLB

Q: When using Windows Network Load Balancing (WNLB) to load-balance traffic to an Exchange 2010 CAS array, does the FQDN of the WNLB need to match that of the CAS array?

A: This isn’t a requirement at all. For instance, when using Windows NLB to load-balance traffic going to the CAS array, you could specify an FQDN for the Windows NLB of, say, casarray01.contoso.com and assign the CAS array outlook.contoso.com. This would work just fine and is fully supported. As long as the internal DNS record for the CAS array points to the virtual IP of the WNLB, things should be fine.

Henrik Walther* is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a Technology Architect for Timengo Consulting (a Microsoft Gold partner in Denmark) and as a technical writer for Biblioso Corporation (a U.S. based company that specializes in managed documentation and localization services). You can e-mail Walther using *
v-henwal@microsoft.com.

Related Content

• Exchange Queue & A: February 2010
• Exchange Queue & A: September 2009
• Exchange Queue & A: July 2009