Updated: 08.06.2013: The original post had some errors regarding RPC over TCP and the RPCClientAccessServer namespace. You would never want to move this namespace to CAS 2013 as the new CAS does not understand RPC over TCP.
Welcome back, this is the second part of my series on migration to Exchange 2013. I covered prerequisites, installation and a little bit of management in the first post, now we’ll have a look at namespaces and certificates.
Namespaces in Exchange 2013
After installing Exchange, it’s time to start getting into the planning phase :) Ok, just kidding, I’ll use the newly installed Exchange server to walk through some planning steps, though.
First of all, let’s make some assumptions. We do have an Exchange 2010 server and a CAS array with the RpcClientAccessServer endpoint configured to outlook.tomt.local. For OWA, EWS, OAB, EAS and Outlook Anywhere there is only one namespace, mail.tomt.it. Outlook Anywhere is configured with NTLM authentication, more on that later. Internal Outlook clients would connect (via MAPI) to outlook.tomt.local, external clients would use Outlook Anywhere (HTTPS) and connect to mail.tomt.it. The certificate on Exchange 2010 has a Subject of CN=ex14.tomt.local and the following SANs: ex14.tomt.local, mail.tomt.it.
Ok, so far so good. Now when migrating to Exchange 2013, it is recommended that the new server takes over the namespace and deals with all incoming client connections. For incoming connections with a mailbox homed on Exchange 2013, our new CAS would simply proxy the request to the mailbox server hosting the mailbox. For mailboxes hosted on Exchange 2010, though, the 2013 CAS would act as HTTP proxy and connect the client with the Outlook Anywhere endpoint (/rpc) of the Exchange 2010 CAS. So what does that mean? First of all, this does not apply for internal, RPC over HTTP clients, the RPCClientAccessServer namespace is not moved to CAS 2013. If you are in the unfortunate situation to have the RPCClientAccessServer namespace match your OutlookAnywhere namespace, there is a very good post over at the Exchange Team Blog.
For RPC over HTTP connections, OutlookAnywhere must be enabled on the Exchange 2010 CAS before Exchange 2013 CAS can take over the namespace, and the IIS Authentication methods must include the NTLM. The Exchange 2013 CAS is authenticated by Exchange 2010, this does not work with basic authentication. To make sure Outlook Anywhere is configured, and the IIS Authentication method includes NTLM use the following cmdlet on Exchange 2010.
Get-OutlookAnywhere –Server ex14 | fl ExternalHostname, ClientAuthenticationMethod, IISAuthenticationMethods
To add NTLM as an IIS Authentication method, use the following cmdlet. Note that the ClientAuthenticationMethod does not matter in this case.
Set-OutlookAnywhere –Identity ex14\rpc* –IISAuthenticationMethods Basic,NTLM
Nice, now Exchange 2010 CAS is ready and we can start thinking about the certificate request for Exchange 2013. We want the new CAS to take over the namespace, so we do already know which name to include: mail.tomt.it, but is that enough? Well, the answer is, it depends ;)
Protocol specific names
Exchange 2013 introduces some radical changes, including how client connections are handled. In 2010, client affinity was everything. Clients would always need to be redirected to the same CAS for a specific session, if that CAS would become unresponsive or if the client would connect to another CAS, re-authentication would occur. When talking about load-balancing, an expensive Layer 7 capable load-balancer was required. The load-balancer would intercept the traffic and make sure client A would always reach server A for a particular session. This had one clear advantage, though, because the load-balancer was L7 aware (knows which endpoint the client asked for), it could check if a particular endpoint was reachable on a CAS, and if not redirect the client to a CAS where it was reachable.
This is not the case in 2013 anymore, client to CAS sessions are stateless and a less-expensive Layer 4 load-balancer (or DNS round-robin) could be used with 2013. A L4 load-balancer, on the other hand, would have no idea of what endpoint the client was looking for, it would only see and forward encrypted (https) packets. Protocol specific namespaces are here to solve that problem. If we created a virtual IP and a distinct name for each endpoint on the CAS (OWA, EWS, EAS…) the L4 load-balancer would be aware of what endpoint the client was looking for.
So, long story short, we are going to include more names in that certificate. The subject is CN=ex15.tomt.local and the SANs are: ex15.tomt.local, oa.tomt.local, mail.tomt.it, owa.tomt.it, eas.tomt.it, ews.tomt.it, oab.tomt.it. In the DNS configuration we need a CName for all of these names pointing to our new CAS, or an A record pointing to the load-balancers virtual IP. Next, we’ll use the Exchange Management Shell to update the ExternalUrl properties of the virtual directories.
Set-OwaVirtualDirectory –Identity ‘ex15\owa (Default Web site)’ –ExternalURL https://owa.tomt.it/owa
Set-EcpVirtualDirectory –Identity ‘ex15\ecp (Default Web site)’ –ExternalURL https://owa.tomt.it/ecp
Set-OabVirtualDirectory –Identity ‘ex15\oab (Default Web site)’ –ExternalURL https://oab.tomt.it/oab
Set-WebServicesVirtualDirectory –Identity ‘ex15\ews (Default Web site)’ –ExternalURL https://ews.tomt.it/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Identity ‘ex15\microsoft-server-activesync (Default Web site)’ –ExternalURL https://eas.tomt.it/Microsoft-Server-ActiveSync
And last, but not least we configure Outlook Anywhere on the new Exchange 2013 CAS.
Set-OutlookAnywhere –Identity ‘ex15\rpc (Default Web site)’ –InternalHostname oa.tomt.local –InternalClientAuthenticationMethod NTLM –InternalClientsRequireSsl:$true –ExternalHostname mail.tomt.it –ExternalClientAuthenticationMethod NTLM –ExternalClientsRequireSsl:$true –IISAuthenticationMethods Basic, NTLM, Negotiate
Now that Outlook Anywhere command was pretty long, let’s break it into smaller pieces. First we are setting the InternalHostname, as Exchange 2013 uses Outlook Anywhere for all client connectivity (internal and external) we don’t use the RpcClientAccessServer anymore. Along with that we set the authentication method for internal clients as well as the requirement for SSL. Next we set that same pieces of information for external clients, and the last property is configuring the supported authentication methods by IIS.
Wow, now we should finally be able to take over that namespace with our brand new Exchange 2013 CAS. I updated the DNS records for mail.tomt.it to point to the new CAS and created a new CName oa.tomt.local for the internal OutlookAnywhere used in Exchange 2013.
Nothing really changes for Outlook when it connects to an Exchange 2010 mailbox from inside the network, it will still use the RPCClientAccessServer endpoint to connect to the mailbox using RPC over TCP.
If the mailbox is on Exchange 2013, though, Outlook will use RPC over HTTP and connect to the internal OutlookAnywhere endpoint:
From a OWA point of view, all users do log on using the new CAS now:
Exchange 2010 mailboxes get proxied to the Exchange 2010 CAS for OWA.
After this text heavy post we have a nice little overview of CAS in Exchange 2013, I wanted to cover mail routing in this post, given the length I reckon it be better to save that for the next one.
I hope this has been informative for you as the reader, at least it was extremely so for me :)
so long,
tom