What is RPC CA service?
Among the architectural changes made in Exchange Server 2010 is the introduction of the new RPC Client Access service which changes the client access business logic as we know it. This new service moves Outlook MAPI mailbox connections from the back-end Mailbox servers and directory access from domain controllers/global catalog servers in the data tier to the Client Access servers in the middle tier.
The primary reason why the MAPI endpoint was moved to the CAS server role was to make database failovers and switchovers (aka *over’s) more transparent to the end users. Another reason was to provide a single common path for all Exchange clients and allow a higher number of concurrent connections per server as well as a higher number of mailboxes per mailbox server role.
For details see my comprehensive article series on the subject here.
What is a CAS array?
A CAS array is a collection of CAS servers in an Active Directory site. By creating a CAS array all CAS servers in an AD site are represented by a single Active Directory object, which provides a single MAPI endpoint name (i.e. outlook.domain.com). This makes it easier to associate mailbox databases with a set of CAS servers instead of a single CAS server (by specifying the FQDN of the CAS array in the “RpcClientAccessServer” database property). By specifying the FQDN of the CAS array you ensure that a client will use a set of CAS servers instead of one and thereby eliminate a single point of failure. A CAS array works in conjunction with a load balance solution. For the details again see my comprehensive articles series on the subject.
Is it true that Outlook clients no longer make any connections directly to the Mailbox server in Exchange 2010?
Well not 100% true actually as Outlook clients still connect directly to the Mailbox server role when it comes to public folder access. However it is also the RPC CA service that is being utilized. Both mailboxes and the address book service are accessed via the CAS server role though.
Is Outlook 2007 or Outlook 2010 required in order to be able to connect to the RPC CA service or CAS array?
There used to be a doc bug in the Exchange 2010 documentation that indirectly stated that you could not connect to the RPC CA service or a CAS array using Outlook 2003. However, as I just mentioned, this was a 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, I recommend that you enable RPC encryption in the Outlook profile. You can do this using a group policy. For steps on how to do this see this KB article.
Do I need four Exchange 2010 servers if I want to both use the Database Availability Group functionality to protect mailbox databases and at the same time load balance traffic Client Access server traffic using Windows Network Load Balancing (WNLB) technology?
Yes this is a requirement since you cannot use both WNLB and Failover Clustering on the same machine. This is due to potential port sharing conflicts. However you could deploy two servers with all Exchange 2010 server roles and then use an external software or hardware based load balancer solution. I covered this in more detail in a previous MSE newsletter. I also touched the subject last month, see here.
Would I need to include the CAS array FQDN in the certificate installed on the Client Access servers?
This is a question I have seen very often, and the answer that I give is no. You do not need to include the FQDN (outlook.domain.com) in the SAN/UC certificate as internal Outlook clients connect to Exchange via MAPI over RPC. Although all communication is typically encrypted, a certificate is not used. Just like previous versions of Exchange server, the story is different when it comes to Outlook Anywhere, which connects to the CAS server via HTTPS (more specifically RPC is encapsulated in HTTPS packets).
When using WNLB to load balance Client access server traffic, does the FQDN of the WNLB need to match the FQDN of the CAS array?
This is not a requirement at all. Personally when using WNLB to load balance CAS server traffic, I call the FQDN of the WNLB something like casarray01.domain.com and the FQDN of the CAS array outlook.domain.com and this works just fine for me, as well as being fully supported. As long as the internal DNS record for the CAS array points to the VIP of the WNLB things should super-duper.
Should I use the same FQDN to load balance internal Outlook clients and external Exchange clients (OWA, EAS, Outlook Anywhere etc.)?
It is actually recommended that you do not use the same FQDN for all Exchange clients. I recommend you use something like mail.domain.com for external Exchange clients and outlook.domain.com for internal Outlook clients. Why? Because if you use mail.domain.com for both internal and external clients, if a user for instance takes his laptop to a customer site or with him home, then there will be quite a delay when Outlook tries to connect via RPC over HTTPS. This is because the mail.domain.com FQDN which is resolvable in the DNS will result in Outlook trying to connect via MAPI over RPC before failing over to HTTPS.
When should I change the RpcClientAccessServer property on a mailbox database?
If possible, it is highly recommended that you create the CAS array and specify the FQDN of the CAS array on the mailbox databases (if the CAS array exists it will be used automatically for databases that are created afterwards) before mailboxes are moved to Exchange 2010. If you let Outlook clients connect to let’s say; cas01.domain.com, a similar scenario will occur because you do not know which server FQDN is specified in the RpcClientAccessServer property of a mailbox database, then when you change the property to outlook.domain.com (FQDN for CAS array), Outlook 2007 (and even 2010 in some cases) clients would not change the connection endpoint in the Outlook profile to outlook.domain.com if the old end point is still accessible or even resolvable (which is typically the case as the CAS server still exist in the AD site). Outlook will get the updated information from AutoDiscover but unfortunately will not apply it.
MessagingSolutions 