If you would like to read the other parts in this article series please go to:
In part one of this multi-part article, we began with a nostalgic look at how the business logic worked back in the Exchange 2000/2003 days, where we had the concept of front-end and back-end servers. We also had a look at the improvements that were delivered with the introduction of the Client Access server role in Exchange 2007. From there we moved on to and had a look at new RPC Client Access Service as well as the new CAS array functionality included with Exchange 2010.
In this article we will talk about supported Outlook clients and why public folder connections still hit the mailbox server directly from the Outlook client. Finally I will show you how to configure static RPC ports, so you do not have to specify a large range of ports in your load balancer device or in your WNLB cluster.
Let’s get moving.
You might think that the new RPC Client Access service only supports newer Outlook clients. Well, actually all Outlook clients supported by Exchange 2010, that is Outlook 2003, 2007, and 2010, can connect to the RPC Client Access service on an Exchange 2010 CAS server no matter if it’s a single CAS server or an array of CAS servers.
Whether Outlook clients older than Outlook 2003 can connect to the RPC Client Access service is unknown as this has not been tested by either the Exchange Product group or myself during the writing of this multi-part article.
Although Outlook 2003 clients are supported and can connect to the RPC Client Access service, there is one thing you should bear in mind. One of the default settings of the RPC Client Access service is that it requires encryption for RPC connections. You can check this setting using the following command: Get-RpcClientAccess | fl
Figure 1: RPC encryption set to true by default
This is not an issue if you use Outlook 2007 or Outlook 2010 since these Outlook versions have RPC encryption enabled by default when you create a new Outlook profile (see Figure 2).
Figure 2: RPC encryption enabled in Outlook 2007/2010
But guess what? Yes the old Outlook 2003 version behaves differently. When you create a new Outlook 2003 profile, RPC encryption is disabled by default (see Figure 3).
Figure 3: RPC encryption disabled in Outlook 2003
This means that if you migrate an Exchange 2003 or 2007 mailbox to Exchange 2010, or try to create a new Outlook 2003 profile against an Exchange 2010 mailbox, you would not be able to connect to the mailbox. After authenticating, you will instead receive a dialog box similar to the one shown in Figure 4.
Figure 4: Warning when RPC encryption is enabled on server and client has RPC encryption disabled
The issue can be resolved in two ways. You can either enable RPC encryption in the Outlook 2003 profile (if you have many, you could do so via a GPO) or disable the RPC encryption requirement on the Exchange 2010 Client Access server. Enabling RPC encryption on the client is of course the recommended approach, but if you insist on disabling this setting server-side, you can use the following command:
Set-RpcClientAccess –Server <CAS server> –EncryptionRequired $false
Figure 5: Disabling RPC encryption requirement on the server side
When you have disabled the RPC encryption requirement on relevant CAS servers, verify that this setting has been set to false by running:
Get-RpcClientAccess | fl EncryptionRequired
If this is the case, your users can now connect to an Exchange 2010 mailbox using Outlook 2003 clients that do not have RPC encryption enabled.
If you choose to disable RPC encryption server-side, remember that you must do so both on the Exchange 2010 Client Access and Mailbox servers. This results from the public folder connections which still go directly to the RPC Client Access service on the back-end Mailbox servers. See the next section for more information about this.
That all MAPI connections now occur against the Client Access servers in the middle tier layer is not exactly true. You see there is still support for public folders in Exchange 2010 and for public folder connections; Outlook will still connect to the Mailbox server when accessing public folder databases. However, an important detail is that while you connect to the Mailbox server role for PF connections, at the service level, the RPC Client Access service will still be the answering RPC endpoint as the RPC Client Access service also exists on a Mailbox server (see Figure 6).
Figure 6: RPC Client Access Service in the Services MMC snap-in on a Client Access server
The RPC Client Access service on a Mailbox server is not used by the RPC Client Access service on the Client Access server. In fact, all requests coming from the RPC Client Access service on a Client Access server to a Mailbox server is ignored as it otherwise could result in loops. Also, if both the CAS and Mailbox server roles are installed on the same machine, then the RPC Client Access service will only be registered once on that machine.
Why don’t PF connections go through the new RPC Client Access service? Public folders have their own replication mechanisms and having PF connections go through RPC Client Access service on the CAS would require a lot of additional complexity due to the way PFs replicate data. The Exchange Product group would have to re-implement legacy functionality that they are trying to drop. Public folders work the same as in Exchange 2007 and you do not really lose anything with this design, so don’t expect that the Exchange PG will change this business logic in a future service pack.
In Figure 7, we see the Connection Status window on an Outlook 2010 client opened by a user who has a mailbox on the Mailbox server named E2K10EX02. But because MAPI for mailbox access now goes to the CAS server, you will only see the FQDN of the CAS server, not the Mailbox server. The reason why you see E2K10EX02 listed once is because public folders are used in this organization and as I just explained above PF connections goes directly to the RPC Client Access service on the Mailbox server.
Figure 7: Public Folder connection occur against the Mailbox Server
Since you now connect directly to the RPC Client Access service on the Client Access server for mailbox access or the RPC Client Access service on the Mailbox server for public folder connections, and that clients for directory access connects to the NSPI endpoint, it also means that you by default need to open the TCP 135 EndPointMapper and the dynamic RPC range TCP 1024-65535 between your internal client network and the Client Access servers or arrays and your Mailbox servers.
Luckily you can still configure static port mappings just like it has been possible in versions earlier than Exchange 2010. But you have to do so both on any CAS as well as Mailbox servers that are accessed by Outlook MAPI clients.
On the CAS servers, for Mailbox connections, you need to use add a DWORD registry key named “TCP/IP Port” under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRpc\ParametersSystem
Figure 8: Adding the required DWORD key on CAS server to configure a static port number
Set the value to the port number to be assigned. In this article we use port 55000, but you are free to choose whatever port you want to use, just remember it should not conflict with other applications using the port. It is recommend you choose a port within the dynamic RPC ranger (1024-65535).
To use a static port for public folder access, you need to do the same on the mailbox servers:
First open the registry editor. Then add a DWORD key named “TCP/IP Port” under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
It’s fine to use the same port that you specified on the CAS server.
Figure 9: Adding the required DWORD key on Mailbox server to configure a static port number
Finally you need to limit the port usage for clients that connect to the NSPI endpoint for directory access. Unlike MAPI access to mailboxes and public folders this is done by modifying a file more specifically the Microsoft.exchange.addressbook.service.exe.config configuration file located in the Exchange Bin folder.
Figure 10: Microsoft.exchange.addressbook.service.exe.config
Open the file in Notepad and then change the “RpcTcpPort” value from the default assignment of “0” to the port you want Outlook clients and Exchange to use for the directory access via the NSPI EndPoint. In this article we use port 55001.
Figure 11: Setting a static port for the NSPI EndPoint
When you have done the above changes, you should reboot the Mailbox and Client Access on which you performed the above changes.
Now that we have rebooted the relevant servers, let us verify that Outlook actually connects to Exchange 2010 using the static RPC ports we just specified. To do so first connect to your mailbox using Outlook, then open a command prompt window and type Netstat –na
Figure 12: Verifying that Outlook connect to the static RPC ports on the Exchange 2010 servers (client-side)
As you can see in Figure 12 above, our Outlook client connects to 192.168.2.238 (Client Access Server) and 192.168.2.239 (Mailbox Server) using port 55000 (MAPI) and port 55001 (DSAccess).
Let us also try to run netstat on the Client Access server. As you can see, the client with IP address 192.168.2.198 connects to both port 55000 (static RPC port) and 55001 (static DSAccess port).
Figure 13: Verifying that Outlook connect to the static RPC ports on the Exchange 2010 servers (server-side)
That was all I had to share with you in part 2, but you can look forward to part 3 which will be published in the near future here on MSExchange.org. In part 3, I show you how to configure a WNLB and 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:
In this second article in our series, we will work on the Ansible Automation Engine…
Microsoft Build 2020 included several announcements aimed at developers and the IT community. Here are…
Using Azure Active Directory Identity Protection will boost your security. This step-by-step guide shows you…
COVID-19 is not going away anytime soon, and as Microsoft researchers have discovered, neither are…