Exchange 2013 streamlined the connectivity between servers with the “every server is an island” design philosophy. The intent was to remove the strict version dependency hooks which existed in the previous versions of Exchange. For example, the Exchange 2007 HUB Store Driver can only communicate with the Exchange 2007 Mailbox role. Conversely, the Exchange 2010 HUB Store Driver can only communicate with the Exchange 2010 Mailbox role. This is due to the fact that RPC is used to communicate between the servers and is coded to only work with the relevant version. This is why you must maintain 2007 Hub and CAS servers as long as you have 2007 mailboxes. From a networking perspective layer 7 of the OSI model is talking to a different layer which is not something network folks expect to see!
The Client Access Server (CAS) role in Exchange 2013/2016 will proxy or redirect the incoming user’s connection to the correct place depending upon the topology of the environment and version of Exchange their mailbox is on. This leads to an interesting discussion point when it comes to managing the connections to down-level versions of Exchange.
Exchange 2010 Load Balancing
Initially the Exchange 2010 organization would have looked something like this from a networking perspective.
The client connections will traverse a load balancer, virtual or hardware based appliance, to get to the Exchange 2010 servers. The Exchange 2010 CAS namespaces are all pointing to one or more VIPs on the load balancer. The exact details will depend upon the load balancer type and required configuration. In the simple example here Mail.TailspinToys.ca is used for all HTTP protocols except for Autodiscover which has its own namespace of Autodiscover.TailspinToys.ca. A dedicated namespace is used for internal RPC Client Access traffic to the Exchange 2010 CAS Array, which is Outlook.TailspinToys.ca. This dedicated namespace is required to prevent the ambiguous URL issue which will block an Exchange upgrade project.
Exchange 2013 & 2016 Load Balancing
After following the Exchange Deployment Assistant guidance when migrating to Exchange 2013, the networking flow would be adjusted to something similar to the below. Note that the same will apply for Exchange 2016 also doing the down level proxy to Exchange 2010
The HTTP protocols have all been moved over to Exchange 2013. This means that Exchange 2013 is the client contact point for OWA, EAC, EAS, EWS, OAB and Autodiscover. Since there is no Outlook RPC endpoint in Exchange 2013, clients must connect to Exchange 2013 using Outlook Anywhere or MAPI/HTTP. For mailboxes still on Exchange 2010, CAS 2013 is unable to proxy RPC requests, since it does not listen for those requests and Outlook needs to connect to the existing RPC endpoint on Exchange 2010 CAS. This is why the Outlook.TailspinToys.ca namespace must remain and point to CAS 2010. Until the 2010 mailbox is migrated, the Outlook client will connect to CAS 2013 for HTTP requests and to CAS 2010 for RPC Client Access. The RPC Client Access is indicated by the purple line above.
Now that we have the background, to the question of how do we control access to the Exchange 2010 servers in this mixed environment.
Controlling Access to Exchange 2010 In A Mixed Environment
We can break this down into two main sections:
-
RPC Client Access
-
Proxied HTTP connections
RPC Client Access
For RPC Client access, we can control the connections to the Exchange 2010 CAS server in much the same was as before the Exchange 2013 upgrade. Namely this is done by marking servers up or down on the load balancer. Note that this is the required way to take an Exchange 2010 CAS server in and out or service. If an Exchange 2010 CAS server is restarted without first removing client connections you will most likely get authentication prompts in Outlook for users connected to that CAS.
Proxied HTTP connections
Exchange 2010 mailboxes will connect to Exchange 2013 CAS, which will then proxy to Exchange 2010 on behalf of the user. The target of these proxy requests is NOT the load balancer. The target is the Exchange 2010 server FQDN. One exception to this rule is the proxy target to Exchange 2007 EAS, that will use the internalURL of the server’s virtual directory.
Since the proxy target is the sever FQDN, the traffic is not using the load balancer. Thus servers are NOT removed from serving HTTP requests by marking them down on the load balancer (as we can with RPC Client Access). In order to ensure that the proxy target is functioning, Exchange 2013/2016 Managed Availability will test the health of Exchange 2010 servers and react accordingly. So if we want to tell Exchange 2016 that it should not use a particular Exchange 2010 server as a HTTP target, how do we do that?
We use an Exchange 2010 cmdlet.
Yes, really.
Exchange 2010 SP3 is required when coexisting with Exchange 2013 or Exchange 2016. There are multiple reasons which include authentication changes made to Exchange 2010 SP3 OWA virtual directories and also the Exchange 2010 Set-ClientAccessServer cmdlet. This Exchange 2010 cmdlet was extended in SP3 to include the IsOutOfService parameter. Interestingly the parameter is set on Exchange 2010, but is ignored by Exchange 2010 and is only relevant for up level versions of Exchange.
The default setting is for the IsOutOfService flag to be $False which meas the Exchange 2010 server will accept the proxied traffic.
Get-ClientAccessServer Exch-2010 | Format-List Name, IsOutOfService
To modify:
Set-ClientAccessServer Exch-2010 -IsOutOfService $True
Sample Exchange 2010 IIS Log
The below shows an excerpt from an Exchange 2010 server's IIS log. You can see the entries here for the HttpPing.
One thing to note is that the expected behaviour is not that all entries will have a 200 HTTP success code. As long as 2013/2016 CAS receives a 200/300/400 response, that service is considered valid for traffic.
A 502, 503 or 504 error indicates a failure.
Cheers,
Rhoderick
