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

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

Introduction

In part two of this multi-part article series, we spoke about which Outlook clients are supported by the new RPC Client Access service as well as why public folder connections still go directly from Outlook MAPI to the mailbox server. I also showed you how to configure static RPC ports, so you do not have to specify a large range of RPC ports in your load balancer device or in your Windows NLB array.

As you learned in the previous articles in this multi-part article series, with Exchange 2010, the Client Access Server (CAS) has become a true middle tier server. With Exchange 2010, all Exchange clients including Entourage and internal Outlook MAPI clients now connect directly to the CAS role. This also means that making this server role highly available via load balancing technology has become even more important than was the case with previous versions of Exchange Server.

In this part 3, we will take a look at how you provide true high availability for internal Outlook MAPI clients by combining a Client Access Server (CAS) array with Windows Network Load Balancing (NLB) technology.

Let us get moving!

What is Windows Network Load Balancing and how does it Work?

Network Load Balancing (NLB) technology can be used to distribute client requests across a set of servers. Windows NLB is often used to ensure that stateless applications such as IIS-based web or applications servers can be scaled out by adding additional servers as client load increases. Doing so makes sure that clients always experience acceptable performance levels. In addition, it reduces downtime caused by a malfunctioning server as the end-users will never know that a particular member server in the Windows NLB is or has been down for planned or unplanned reasons.

Windows NLB clusters can provide scalability for services and applications based both on TCP and UDP. On top of that you can have up to 32 servers in a Windows-based NLB cluster. Although up to 32-nodes in a WNLB cluster is feasible for some web/application servers, best practice is to have a maximum of 8 Exchange 2010 Client Access Server (CAS) servers configured in a WNLB. If you need to load balance more than 8 CAS servers, it is recommended to use a hardware-based load balancing solution.

Windows NLB is included in both the Standard and Enterprise edition of Windows Server 2008 SP2/R2, and because WNLB is a standard component, it does not require you to use any special or specific server hardware for each member server in the NLB cluster. Seen from the Exchange 2010 perspective though, you should of course follow the CAS server sizing guidelines available in the Exchange 2010 online documentation on Microsoft TechNet.

When a Windows NLB 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 all servers in the Windows NLB array. The client will then be mapped to a particular server and the request to the other servers will be dropped. Having said this, you can use affinity to direct specific client request to particular member servers. You can even configure each member server with a priority, although both are outside the scope of the article.

Unicast or Multicast Mode?

A Windows NLB array can be configured in either unicast or multicast mode. Since WNLB is not something Exchange administrators or consultants deal with on a daily basis, it can be difficult to decide which mode to choose when time comes to load balancing the RPC traffic to the RPC Client Access service on the CAS servers in the Exchange 2010 infrastructure.

So let’s take a look at each WNLB mode:

Unicast Mode

With the WNLB cluster configured in unicast mode, the MAC address of each server’s network adapter will be changed to a virtual cluster MAC address, which is the MAC address that will be used by all servers in the Windows NLB cluster. When unicast mode is enabled, clients can only connect to the servers via the VIP address on the network interface card (NIC) that has been configured with the cluster MAC address.

Multicast mode

With the Windows NLB cluster configured in multicast mode, a multicast MAC address is added to the cluster adapter of each server in the cluster. Note that I write “is added”, as each server will retain their original MAC address.

A Windows NLB cluster, no matter what mode it is configured in, works with just a single network adapter installed in each server, but it is recommended to install a second network adapter in each server, in order to achieve optimal performance, and to separate ordinary and cluster related network traffic.

So what mode should I use for my Exchange 2010 CAS array and how many network adapters should I install in each Client Access server? Well, a best practice recommendation is to install two network adapters and use unicast mode, so that the host and cluster network traffic are separated on their own respective network interface. However, if you only have the option of installing one NIC in each CAS server or if you’re forced to using multi-cast mode because of the switches used in your organization, you should pick multicast mode.

Note:
You can read more about the pros and cons of each NLB mode here.

Windows NLB Arrays in a Virtual environment

Many organizations are virtualizing most of their servers nowadays, and these organizations often also have a demand for virtualizing the Exchange servers within the infrastructure. As many of you know, it is perfectly fine to virtualize all Exchange 2010 server roles (except Unified Messaging) and fully supported by Microsoft, but there are a few things to be aware of when it comes to configuring virtual Exchange 2010 CAS servers in a WNLB array.

VMware ESX Server

When you plan to configure a WNLB array for virtual Exchange 2010 CAS servers that uses VMware ESX Server as the virtualization platform, it is recommend to configure your WNLB in multi-cast mode since you otherwise will expect an issue with the WNLB array not working properly. For details on this issue see this VMware KB article.

If you insist on running in Unicast mode, VMware has an alternative method to resolve the issue. This method is also described in the VMware KB article.

Hyper-V Server

When you plan to configure a WNLB array for virtual Exchange 2010 CAS servers that uses Hyper-V Server or Hyper-V Server R2 as the virtualization platform, you can configure the WNLB array in Unicast mode. But you will face an “expected” issue while you configure the WNLB array. The issue occurs because the MAC address of the NIC you use for the WNLB array is changed when you create the WNLB array. This will make the MAC address that Hyper-V assigned to the NIC different from the one originally assigned when you added the NIC under the Hyper-V settings of the virtual machine. To fix this issue, you need to configure a new static MAC address identical to the one assigned to the WNLB (Figure 1). If you are running the virtual Exchange 2010 CAS servers on Hyper-V Server R2, you should tick Enable spoofing of MAC addresses.


Figure 1: Configuring a static MAC address and enabling MAC address spoofing

The issue is described in more detail in this Microsoft KB article.

Finally if you use two NICs in each NLB node and you don’t have a default gateway specified on the NLB NIC, you should also enable IP forwarding on the NLB NIC. IP forwarding is disabled by default in Windows Server 2008 and Windows Server 2008 R2. To enable it, using the following command:

Netsh interface ipv4 set int "[NLB NIC]" forwarding=enabled

Since many of you probably want to deploy a solution, similar to the one I describe in this article in your virtualized Exchange 2010 environments, I thought it was a good idea to mention these issues.

Configuring the Network Settings

Although not necessary (as explained earlier), we will use unicast mode with two network adapters installed in this setup (this gives us the most optimal performance). To configure the second network adapter in each Exchange 2010 Client Access server, open Network Connections and give each LAN connection a meaningful name such as NLB as shown in Figure 2.


Figure 2: Configuring network connections

Also make sure you change the binding order of the NICs in each server that will be part of the WNLB. The production NIC should be listed first as shown below. You get to Advanced Settings by opening Network Connections and selecting Avanced in the Menu. You probably need to hold down the CTRL key to make the Network Connections menu visible since it is hidden by default.


Figure 3: Changing binding order for the NICs

Installing the Windows Server 2008 NLB component

Unlike previous versions of Windows Server, the WNLB component is not installed by default in Windows Server 2008 and Windows Server 2008 R2. To install the WNLB on Windows Server 2008, you can either use the Server Manager GUI or ServerManagercmd.exe (using ServerManagercmd.exe -install NLB). To install the component on Windows Server 2008 R2, you can also use PowerShell if you like. In this article we will just stick to using the GUI. So open up the Server Manager and select Features followed by clicking Add Features. This brings up the Add Features Wizard, where you simply tick Network Load Balancing and click Install. When the NLB feature has been installed, click Finish and exit the Server Manager.


Figure 4: Installing the NLB feature

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 you 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 5, I used OUTLOOK for the purpose of this specific setup. But using outlook.domain.com is actually a pretty good best practice.

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


Figure 5: 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 idea 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 6: Creating the CAS array object in Active Directory

Creating the Windows NLB array

Okay we have reached the part where we create the actual WNLB array. We can do this using the command prompt or if you have installed the Exchange 2010 CAS server role on Windows Server 2008 R2 we can even use PowerShell. Again I like to include visual representations of what occurs when you configure the solution, so I will use the Network Load Balancing Manager console. So launch this console via Start > Administrative Tools. Now select Cluster in the menu and then New.


Figure 7: Creating a new NLB array

Enter the name of the first node you wish to add to the WNLB array, then click Connect. After a little while, you will see the NICs available for configuring the new NLB array. Select the one named NLB, and click Next.


Figure 8: Specifying the NIC to be used as the NLB NIC

On the Host Parameter page, leave the defaults as is and click Next.


Figure 9: Host Parameters page in new NLB array wizard

It’s time to add the IP address you wish to associate with the WNLB array. Remember this should be the same IP address that you also specified when you created the DNS record (outlook.domain.com) for the CAS array. When the IP address has been added, click Next.


Figure 10: Adding an NLB array IP address

On the next page, we need to specify the FQDN of the WNLB array as well as the operation mode. In this article I will call the WNLB array array01.exchangelabs.dk, but if you have a special naming standard you must follow, feel free to use another name. Unless your Exchange 2010 CAS servers are on top of VMware ESX server or have other requirements for choosing Multicast mode, make sure Unicast mode is selected and click Next.


Figure 11: Specifying the FQDN for the WNLB

On the Port rules page, delete the default port rule.


Figure 12: Default Port Rule

Click Add. On the Add/Edit Port Rule page, untick All and then specify the first port you wish to add to the WNLB array. In this case this would be port TCP 135 endpoint mapper port which is required for the CAS array. Make sure the port rule is set to single affinity and click OK.


Figure 13: Adding new Port Rule for Endpoint mappper

Now create an additional port rule where you specify the RPC ports that are used by the Outlook clients and the CAS array. Since we configured static ports for RPC communication between Exchange 2010 CAS servers and the Outlook MAPI clients, and because we chose to use TCP port 55000 for mailbox connection and port TCP 55001 for directory access connections, these are the ones we will add in this article.

If you chose to use other static RPC ports or just the default dynamic range of RPC ports, you should specify those instead. When you haven’t specified that static RPC ports should be used, you should add TCP port 1024-65535 in the port rule.

Also select single affinity for this port rule and click OK.


Figure 14: Adding new Port Rule for RPC traffic

Since you most probably need to use this WNLB array for other Exchange clients as well you should of course also remember to add port rules for the these clients. In the figure below, I also added port rules required by Outlook Anywhere (TCP/443), Exchange ActiveSync (TCP/443), Outlook Web App (TCP/443), Secure IMAP (TCP/993), secure POP (TCP/995). I also added port 80 since this is used for internal IIS redirection (HTTP > HTTPS).

Also note that best practice is to configure the secure IMAP and PPOP port rules with affinity set to none.


Figure 15: Required Port Rules added

Now select Finish. The NLB array will now be configured and after a little while you should have a WNLB array with one node running.

Note:
Some of you might feel tempted to just use the default port rule for all Exchange client types and services, and although this should work okay for most Exchange clients/services, personally I like to create separate port rules. The reason behind this thinking is that not all Exchange services/clients use same affinity settings etc. For instance the IMAP/POP protocols should be configured with affinity set to none unlike the other Exchange clients/services that should use single affinity. From a security standpoint we of course have the Windows Firewall running on the servers, so separating the port rules are really not in order to gain extra security.


Figure 16: WNLB array created

Now we just need to add any additional nodes to the WNLB array. To do so you can right-click on the new WNLB array and select Add Host to Cluster as shown in Figure 17 below.


Figure 17: Adding host to WNLB array

Now enter the NetBIOS or FQDN of the Exchange 2010 CAS server you want to add to the WNLB array, then click Connect.


Figure 18: Specifying the new WNLB array member

On the Host Parameters, click Next.


Figure 19: Host Parameters page in WNLB wizard

Click Finish on the  Port Rules page.


Figure 20: Port Rules in WNLB array

The WNLB array will now begin adding the extra node(s) and update the configuration as necessarry.


Figure 21: Second WNLB array added with success

We now have a fully working WNLB array that load balances the RPC connections that goes from Outlook MAPI clients to the RPC Client Access services on the Exchange 2010 CAS servers in the Exchange organization. But before Outlook MAPI client will begin to use the RPC CAS array, you must configure any mailbox databases within the AD site where the CAS array was created to use the CAS array’s FQDN (in this 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 22: 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 23: 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 us tick Manually configure server settings followed by clicking Next, so that we can see the new RPC connection point is used.


Figure 24: Outlook 2010 profile created with success

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


Figure 25: 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 mailbox server storing the public folder database. As you learned in part 2 of this articles series, the public folder connection to the mailbox 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 26: Connection status window showing the CAS array is used as the RPC connection endpoint

That was all I had to share with you in part 3, but you can look forward to part 4 which will be published in the near future here on MSExchange.org. In part 4, I show you how to configure an external load balancer to work with a Client Access array.<?

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

Henrik Walther

Share
Published by
Henrik Walther

Recent Posts

Using Storage Accounts in your Automation Accounts in Azure

In this tutorial, we are going to use an Azure Automation Account to create a report of all VMs per…

15 hours ago

Battle of the Kubernetes service meshes: Istio vs. Consul

Istio and Consul have their pros and cons, but both service meshes are equally important in the big picture of…

19 hours ago

IBM Cloud Pak connects users with security tools in any environment

IBM Cloud Pak for Security lets users connect with any security tool, cloud, or on-premises system, without the need to…

22 hours ago

Don’t be a victim: Why MSPs must do an internal security audit

Managed Service Providers are in the crosshairs of hackers because the bad guys know MSPs hold a lot of sensitive…

2 days ago

Azure Quick Tip: Link Azure Automation and Log Analytics workspace

Here’s a Quick Tip that will show you how to link an Azure Automation and Log Analytics workspace even if…

2 days ago

Creating Hyper-V VMs from a CSV file with PowerShell

Expedite the process of creating several virtual machines with a PowerShell script that builds VMs based on the contents of…

2 days ago