Uncovering the new RPC Client Access Service in Exchange 2010 (Part 4)

If you would like to read the other parts in this article series please go to:

 

 

 

Introduction

 

In part three of this multi-part article series, I explained how to provide true high availability for internal Outlook MAPIs by load balancing the RPC Client Access service (RPC CA) using a combination of a Client Access Server array (CAS array) and Windows server network load balancing (WNLB) technology.

 

In this part four, we will take a look at how to provide true high availability for internal Outlook MAPI clients using a combination of a CAS array and a redundant external hardware-based load balancer solution.

 

Lots of folks seem to think that a hardware based load balancer solution is an expensive luxury of LORGs (large organizations) with just as large IT budgets at their disposal. But you know what? A hardware load balancer solution does not necessarily need to cost thousands of dollars. You can actually get sophisticated, high performance devices at a very affordable price (you just need to find the right vendor). This means that even though you work with/for a SMORG (small or medium organization) with a very limited IT budget, it does not mean they can not afford to invest in a hardware load balancer solution. Personally, I have recommended different hardware load balancer solutions from different vendors to my customers over the years, but for Exchange 2010, I really like the low cost devices from KEMP Technologies. Their smallest device (LoadMaster 2000) has a price tag of $1,590 dollars which even includes one year of support. This means that you can get a redundant hardware load balancer solution for approximately $3,000 dollars! On top of that, the LoadMaster 2000 device has the same rich feature set as the LoadMaster 2500, 3500, and 5500 models, which means that it has full support for fancy features such as load balancing using layer 4 and 7, automatic failover cluster (active/hot standby with failover time of less than 3 seconds in my test environment), SSL offloading, layer 7 persistence (stickiness), up to 256 virtual services (with a total of up to 1000 real servers!) and server/application health checking etc. These are features you typically only see listed when looking at expensive load balancer devices from the more well-known vendors on the market.

 

By the way, if you are on the virtualization bandwagon (who isn’t?), KEMP Technologies also has a virtual appliance with a feature set identical to the hardware based devices.

 

Because I have very good experience with the devices from KEMP Technologies and because they are affordable even for the SMORGs that typically are planning to deploy a fully redundant Exchange solution consisting of two multi-role Exchange 2010 servers, I’ve used two LoadMaster 2000 devices configured in a cluster (one active and one hot standby) as the basis for this article.

 


Figure 1: Topology

 

Note:
I’m in no way affiliated with KEMP Technologies. In addition, I am not being paid to point readers at hardware load balancer devices they provide.

 

Alright enough shameless promotion, let us get moving.

 

Why use a Hardware Load Balancing solution over Windows NLB?

 

With the architectural changes in Exchange 2010 that amongst other things introduces the new RPC Client Access service (which moves Outlook MAPI mailbox connections from the back-end Mailbox servers in the data tier to the Client Access servers (CAS) in the middle tier) providing both a load balanced and highly available Client Access Server (CAS) is more important than ever before.

 

Windows Network Load Balancing (WNLB) technology can be the right choice for organizations that do not plan to deploy multi-role Exchange 2010 servers with both DAG protected mailbox databases and a load balanced/highly available CAS server service. In addition, using WNLB can be a valid approach for organizations that do not have more than 8 nodes in a WNLB based array (the Exchange Product group does not recommend more than 8 nodes in a WNLB based cluster due to scalability and functionality limitations).

 

However, if you plan to deploy multi-role Exchange 2010 servers with both DAG protected mailbox databases and a load balanced/ highly available CAS server service, you cannot use WNLB due to Windows Failover Cluster (WFC) and WNLB hardware sharing conflicts (see this KB article for more information). Also, depending on your environment and network topology the persistence (affinity) settings provided by WNLB may not be sufficient. For instance it is recommended to use a hardware-based load balancing solution when you cannot use the Client IP settings for session persistence (affinity).

 

When a hardware-based load balancer CAS array has been properly configured, all servers in the array are represented by a single virtual IP (VIP) address and a fully qualified domain name (FQDN). When a client request comes in, it will be sent to an Exchange 2010 CAS server in the CAS array using DNS round robin distribution method. Of course we have options to prefer one or more CAS servers over other etc.

 

What Persistence (affinity) type should I use for the RPC CA Service?

 

Persistence (aka affinity, stickiness etc.) is the ability of a load balancer to maintain a connection between a client and a server. Persistence can make sure that all requests from a client are sent to the same server in a NLB array or server farm.

 

For the RPC CA service, it is recommended to use client IP session (source IP address) based persistence. When using client IP session based persistence, the session requests from an individual client are directed to the same CAS server based solely on the source IP of the client of a packet.

 

I will not dive into the details of persistence in this article. I will instead save this topic for a future article which will focus on how to load balance not only the RPC CA, but all services living on the CAS server (including OWA, ECP, EAS, OA, EWS etc.). It’s just important you understand that the recommended persistence type for Outlook MAPI clients connecting to the RPC CA on the CAS server is “Client IP” aka “Source IP address”.

 

Creating the CAS array host record in DNS

 

If you have not already done so, it is time to create the CAS array record in DNS. I explained how to do this back in part one of this multi-part articles series.

 

Basically, you simply log on to a domain controller in your Active Directory forest, then open the DNS manager by clicking Start > Run and type dnsmgmt.msc. Now you expand the Forward Lookup Zones container and right-click on the respective forward lookup zone for your Active Directory. On the context menu select New Host (A), then type the name you want to use. As you can see in Figure 2, I used OUTLOOK for the purpose of this specific setup. Using outlook.domain.com is good best practice.

 

When you have entered the name for the host record, type the IP address you plan to use for the virtual services that we create in the next section.

 


Figure 2: Creating DNS record for the CAS array

 

If you did not create the CAS array object in Active Directory, now would also be a good time to do that. This was also explained in part 1, but I can just as well include the command here:

 

New-ClientAccessArray –Name “name of CAS array” –Fqdn <fqdn of CAS array> -Site <name of AD site>

 


Figure 3:
Creating the CAS array object in Active Directory

 

Configuring the Hardware Load Balancer to work with the CAS array

 

It is now time to configure our hardware load balancer solution. With a LoadMaster HA pair (one-armed) this is very simple and only requires a few steps.

 

Important:
The LoadMaster device (no matter what model we are talking about) does not support specific port ranges for a virtual service as of this writing. This is being added to a future firmware build though. This means that in order to use LoadMaster devices to load balance traffic going to an Exchange 2010 CAS array, it is a requirement to set static RPC ports. Please refer to part 2 of this multipart article for specific steps on doing so.

 

When we have logged into the web-based GUI, we need to click Virtual Services > Add New.

 


Figure 4: Opening the Add News Virtual Service page

 

On the Add a new Virtual Service page, enter the IP address of the Exchange 2010 CAS array. This is the VIP we specified back in Figure 2. Then enter the port number and protocol type. The first port we need to create is port 135 which is the TCP End Point Mapper. Now click Add this Virtual Service.

 


Figure 5: Specifying IP address, port, and protocol type of the virtual service
We will now be directed to the Basic Properties page which is the place where we configure the persisence settings etc. Here we enable Force L7 and L7 Transparency and specify Source IP Address under Persistence Options. The Scheduling Method (aka distribution method of client traffic going to the CAS servers) should be set to round robin. When we have configured the different options, we can move on by clicking Add New in the bottom of the page.

 


Figure 6: Property page of the virtual service
This is the page where we specify the IP address of the real servers (Exchange 2010 CAS servers).

 


Figure 7: Add the real servers to the virtual service

 

When we have added each CAS servers participating in the CAS array, we can move on and create the next virtual service using similar steps and configuration options.

 


Figure 8: List of real servers added to the virtual service

 

Besides port 135 you also need to create a virtual service for the static port set for RPC connections to the mailbox servers and the static port set for the address book service. Again refer to part two for details on how to configure these. In this multipart article I use port 55000 for mailbox connections and port 55001 for the address book service, so I end up with the list of virtual services shown in Figure 9.

 

If the real servers are reachable on the specified ports, you should see a green indicator.

 


Figure 9: List of required virtual services

 

We now have a fully working CAS array that load balances the RPC connections that goes from Outlook MAPI clients to the RPC Client Access service on each Exchange 2010 CAS server using a hardware-based load balancer solution. But before Outlook MAPI clients will begin to use the CAS array, we must configure any mailbox databases within the AD site where the CAS array was created to use the CAS array’s FQDN (outlook.domain.com).

 

To do so, open the Exchange Management Shell, and enter the following cmd:

 

Set-MailboxDatabase <name of DB> -RpcClientAccessServer “outlook.domain.com”

 


Figure 10: Specifying the FQDN of the CAS array on the Mailbox databases

 

Connecting to the CAS Array with an Outlook MAPI Client

 

Okay it’s time to test that we can connect to an Exchange 2010 mailbox and that the new CAS array (aka RPC connection point) is used when a new Outlook profile is created.

 

So let’s launch Outlook 2010 on a domain joined client machine. This brings up the Add New Account wizard, where the e-mail address of the user logged on to the client machine is automatically entered in the e-mail address field as shown below.

 


Figure 11: Launching Outlook 2010 in order to create a new profile

 

When clicking Next Outlook will create the new profile automatically. When it has finished let’s tick Manually configure server settings followed by clicking Next, so that we can see the new RPC connection point is used.

 


Figure 12: Outlook 2010 profile created with success

 

As we can see in Figure 13, the new CAS array is used as the RPC endpoint is used. Click Finish.

 


Figure 13: New CAS array FQDN used as RPC connection endpoint

 

Outlook is launched and a local copy of the mailbox is being created. Now hold down CTRL while right-clicking on the Outlook icon in the systray in the lower right corner. Select Connection status in the context menu. As we can see in the connection status window, we have two mailbox and two directory connections against the CAS array FQDN and a single public folder connection against a mailboks server storing the public folder database. As you learned in part 2 of this articles series, the public folder connection to the mailboxs server is expected, since public folders still happen directly against the mailbox server (more specifically the RPC Client Access service on the mailbox server role).

 


Figure 14: Connection status window showing the CAS array is used as the RPC connection endpoint

 

This concludes this article series. Hope you enjoyed it!

 

 

If you would like to read the other parts in this article series please go to:

 

 

 

 

About The Author

1 thought on “Uncovering the new RPC Client Access Service in Exchange 2010 (Part 4)”

  1. This is an awesome read. Do you have an article on how to setup a best practice implementation of CAS and DAG across Data Centers?

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top