CAS Namespace planning is frequently an issue with Exchange deployments. Why? For the simple reason that it is either totally skipped or glossed over.

Any Exchange design worth its salt must have careful attention applied to the CAS role. While it is possible to drop in the HUB role, and it works well in the default configuration this is not also true for CAS. Unless your organisation is a very small single Exchange server build, then chances are that you will need to do some work here!

Typically one common design fault is to focus exclusively on the mailbox role. Don’t get me wrong, mailbox must also be properly planned out, but CAS cannot be overlooked. This typically manifests itself as a design where:

The DAG has been lovingly planned, and CAS was simply thrown on top.
There are 6 Mailbox servers in a DAG, and a single CAS. That’s great to have the redundancy at the mailbox level, but there is no redundancy at CAS.

What good is having the database mounted if the users cannot get to it? OK, rant over!

This is very relevant to Exchange 20007 onwards.

What Do I Need To Plan

Firstly we need to consider the types of services that are in scope, since clients connect to a name to access these services:

RPC Client Access (Exchange 2010)
Outlook Anywhere
MAPI/HTTP (Exchange 2013 SP1 onwards)
Autodiscover
ActiveSync
ExchangeWebServices
SMTP
Failback (Exchange 2010 only)
Unified Messaging (Exchange 2007 Only)
OWA
Legacy OWA

One point to mention is about RPC Client Access. In Exchange 2010 the endpoint for RPC Client Access should be a CAS Array. Even if you have a single server, it should still be a CAS Array. Because if the RPCClientAccessParameter on the database is updated once clients have been migrated to Exchange 2010 there can be issues getting this updated. But that’s a blog post still in draft! Being even more anally-retentive CAS Array is just a logical object in Active Directory that is created using New-ClientAccessArray in PowerShell. There is no GUI option. This allows a non-Exchange server name to be shimmed into the database’s RPCClientAccessServer property. This points to a load balancer. I will talk about the load balancer and CAS Array being separate.

In addition to the names that are in use, we also have to consider the authentication schemes that are required. This will vary depending if you want to do cross site proxy/redirect or if you have publishing devices that impose particular limitations on the authentication mechanisms that they support.

What Influences My Plan

In short – lots of things!

Topology

TechNet discusses how regional topologies influence CAS Namespaces.

Consolidated Datacenter Model This model consists of a single physical site. All servers are located within the site, and there's a single namespace, for example, mail.contoso.com.
Single Namespace with Proxy Sites This model consists of multiple physical sites. Only one site contains an Internet-facing Client Access server. The other sites aren't exposed to the Internet. There's only one namespace for the sites in this model, for example, mail.contoso.com.
Single Namespace and Multiple Sites This model consists of multiple physical sites. Each site can have an Internet-facing Client Access server. Or, there may be only a single site that contains Internet-facing Client Access servers. There's only one namespace for the sites in this model, for example, mail.contoso.com.
Regional Namespaces This model consists of multiple physical sites and multiple namespaces. For example, a site that's located in New York City would have the namespace mail.usa.contoso.com, a site that's located in Toronto would have the namespace mail.canada.contoso.com, and a site that's located in London would have the namespace mail.europe.contoso.com.
Multiple Forests This model consists of multiple forests that have multiple namespaces. An organization that uses this model could be made up of two partner companies, for example, Contoso and ContosoOnline. Namespaces might include mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.contosoonline.com, and mail.europe.contosoonline.com.

This has been updated in the current Exchange product to reflect the bound and unbound model. This is due to the removal of the CAS array and the introduction of the proxy model where every Exchange server is an island.

Depending on your architecture and infrastructure you have two choices:

Deploy a unified namespace for the site resilient datacenter pair (unbound model).
Deploy a dedicated namespace for each datacenter in the site resilient pair (bound model).

Unbound Model

Note that connections can go to either of the two datacentres.

Bound Model

In the bound model, users go to their specific endpoint in their assigned location.

Internet Publishing Devices

Depending on how Exchange is being published to the Internet, there can be some requirements which drive the design. For example:

Your load balance firmware does not support using NTLM authentication so Basic authentication is required. This is also applicable to ISA Server.
SSL offload must be documented and tested
Client Based Authentication (CBA)

Load Balancer

Since Exchange typically requires a load balancer device to provide service aware balancing of traffic the make and model of load balancer can also influence how CAS namespaces are designed.

For example, if you have a simple load balancer that can only do session affinity at Layer 4 (TCP), then that can influence your CAS namespaces in a couple of different ways.

Option 1 is to use a single name for all internal namespaces and all traffic will flow to the same VIP. This is a simple configuration on the load balancer and is easy to implement. What is not so good is that service availability can be compromised. If all protocols are directed to a single VIP, which one will be used as the canary, i.e. the one to state if the server is up and healthy? Other complications can arise if a NAT device is on the path between Exchange and the clients. This can cause an inequitable load distribution as the load balancer sees all the traffic coming from a single IP.

Option 2 is to split the traffic and user multiple names, and thus different VIPs. This would mean you have multiple names owa.tailspintoys.ca, m.tailspintoys.ca, smtp.tailspintoys.ca and each of which can be separately monitored The downside is that there are now more names for you and your users to deal with, these names are typically on a certificate so cost and complexity is increased and more configuration is needed on the load balancer.

If layer 7 load balancing is used, then the load balancer can inspect the traffic and determine what the traffic is OWA/ECP/ActiveSync and determine server health and availability. Layer 7 load balancing also allows for other load balancing options as the load balancer can take action based on the traffic. For example cookie based persistence becomes an option or the basic auth header can be used. These options come with increased deployment complexity and reliance that the load balancer will correctly deal with the client traffic and not cause any issues. Unfortunately this is not always the case…..

Exchange 2010 Reference CAS Namespaces

As discussed by Ross Smith IV in his introduction to Exchange 2013 CAS post, Exchange 2010 CAS Namespace planning typically requires multiple namespaces. Ross gives the below example for a multi site Exchange 2010 deployment:

Primary datacenter Internet protocol namespace (mail.tailspintoys.ca)
Secondary datacenter Internet protocol namespace
Primary datacenter Outlook Web App failback namespace
Secondary datacenter Outlook Web App failback namespace
Primary datacenter RPC Client Access namespace
Secondary datacenter RPC Client Access namespace
Autodiscover namespace
Legacy namespace
Transport namespace (if doing ad-hoc encryption or partner-to-partner encryption)

Simplifying this to a single site deployment changes this to:

Primary datacenter Internet protocol namespace (mail.tailspintoys.ca)
Autodiscover namespace
Legacy namespace
Transport namespace (if doing ad-hoc encryption or partner-to-partner encryption)

Some customers with only a single version of Exchange have deployed with even fewer names

Primary datacenter Internet protocol namespace (mail.tailspintoys.ca)

Configuring Exchange 2010 External URLs During Setup

Exchange 2010 did introduce the concept of entering the external Namespace during setup, but this is not a silver bullet. If you entered the wrong name, or you want to change the name for whatever reason we still need to understand what’s going on. The GUI option to enter the CAS external domain is shown below:

If you want to do this using command line setup then use: /ExternalCASServerDomain:<domain>. This specifies the external domain for the Client Access server to configure the external URL for OWA/ActiveSync/Web Services/OAB virtual directories. For example:

Setup.com /Roles:ClientAccess /ExternalCASServerDomain:Mail.Tailspintoys.com.

Configuring Exchange 2010 External URLs After Setup

External URLs can be changed after setup has completed for a multitude of reasons. Some can be changed in the Exchange Management Console, but some are only exposed in Exchange Management Shell. For the sake of completeness let’s review the PowerShell options. Note that the –identity parameter is omitted.

Set-OWAVirtualDirectory –ExternalURL "http://mail.tailspintoys.ca/owa"

Set-ECPVirtualDirectory –ExternalURL ht"tp://mail.tailspintoys.ca/ECP"

Set-ActiveSyncVirtualDirectory –ExternalURL "https://mail.tailspintoys.ca/Microsoft-Server-ActiveSync"

Set-OABvirtualDirectory –ExternalURL "https://mail.tailspintoys.ca/OAB"

Set-WebServicesVirtualDirectory –ExternalURL "https://mail.tailspintoys.ca/EWS/Exchange.asmx"

Note that we are NOT setting the AutodiscoverVirtualDirectory URLs as they are not used.

Configuring Exchange 2010 URLs After Setup

It will be a requirement to update the initial internal URLs on Exchange once setup has completed. This should be done ASAP to minimise the time that incorrect URLs are present in the environment. By default the internal URLs are the server FQDN and with a self signed certificate. Neither are good.

Set-OWAVirtualDirectory –ExternalURL "http://mail.tailspintoys.ca/owa" -InternalURL "http://mail.tailspintoys.ca/owa"

Set-ECPVirtualDirectory –ExternalURL "http://mail.tailspintoys.ca/ECP" -InternalURL "http://mail.tailspintoys.ca/ECP"

Set-ActiveSyncVirtualDirectory – ExternalURL "https://mail.tailspintoys.ca/Microsoft-Server-ActiveSync" -Set-ActiveSyncVirtualDirectory –InternalURL "https://mail.tailspintoys.ca/Microsoft-Server-ActiveSync"

Set-OABvirtualDirectory –ExternalURL "https://mail.tailspintoys.ca/OAB" –InternalURL "https://mail.tailspintoys.ca/OAB"

Set-WebServicesVirtualDirectory –ExternalURL "https://mail.tailspintoys.ca/EWS/Exchange.asmx" –InternalURL "https://mail.tailspintoys.ca/EWS/Exchange.asmx"

Set-ClientAccessService -AutodiscoverServiceInternalURI "https://Autodiscover.wingtiptoys.ca/Autodiscover/Autodiscover.xml"

Exchange 2013 and Newer Cmdlets to Configure URLs

Exchange 2013 and newer have a very different architecture compared to Exchange 2007/2010. To reflect this change, the cmdlets have different names. Additionally MAPI/HTTP also has a virtual directory which needs to be configured.

The initial commands are the same, then the new/updated ones are listed. I also personally prefer to do the Get cmdlet piped to the Set cmdlet as it allows an easy way to add the -Server parameter.

Set-OWAVirtualDirectory –ExternalURL "http://mail.tailspintoys.ca/owa" -InternalURL "http://mail.tailspintoys.ca/owa"

Set-ECPVirtualDirectory –ExternalURL "http://mail.tailspintoys.ca/ECP" -InternalURL "http://mail.tailspintoys.ca/ECP"

Set-OABvirtualDirectory –ExternalURL "https://mail.tailspintoys.ca/OAB" –InternalURL "https://mail.tailspintoys.ca/OAB"

Set-WebServicesVirtualDirectory –ExternalURL "https://mail.tailspintoys.ca/EWS/Exchange.asmx" –InternalURL "https://mail.tailspintoys.ca/EWS/Exchange.asmx"

Get-ClientAccessService -Identity SERVER | Set-ClientAccessService -AutodiscoverServiceInternalURI "https://Autodiscover.wingtiptoys.ca/Autodiscover/Autodiscover.xml"

Get-MAPIVirtualDirectory -Server SERVER| Set-MAPIVirtualDirectory -InternalURL "https://mail.wingtiptoys.ca/MAPI" -ExternalURL "https://mail.wingtiptoys.ca/MAPI"

Get-OutlookAnywhere -Server SERVER | Set-OutlookAnywhere -InternalHostName "mail.wingtiptoys.ca" -ExternalHostName "mail.wingtiptoys.ca" -SSLOffloading $False -ExternalClientsRequireSsl $True -InternalClientsRequireSsl $True -ExternalClientAuthenticationMethod Negotiate -InternalClientAuthenticationMethod NTLM

Also note that you should be using Get-TransportService in the current versions of Exchange. Get-TransportServer was soooo Exchange 2007/2010.

Exchange Hybrid CAS Namespaces

In most cases, it is possible to use the existing CAS design when deploying Exchange hybrid. This assumes that the Exchange hybrid deployment requirements have been met with the initial layout. This is not always the case though.

Cross-Premises SMTP

Secure SMTP between EOP and Exchange on-premises must be permitted. Placing a 3rd party SMTP appliance in path of this traffic is not supported. The public MX record can continue to resolve to 3rd party mail appliance or solution, that is a separate flow from the mail between your on-premises mailboxes to your mailboxes in your tenant.

In order to achieve this cross-premises mail flow, it may be necessary to add a SMTP namespace. Not technically CAS, but worth mentioning here.

MRS

Certain network devices do not play nicely with MRS mailbox moves. This may due to an issue with the device or its configuration. For example, in order to work around IPS devices that are currently in path of the traffic it is possible to create a new MRS endpoint and leverage that to move mailboxes to Exchange Online. This needs to be published to the Internet, name is on a 3rd party trusted certificate and an external DNS record is created.

At scale you may also want additional MRS endpoints in a single location to increase your migration throughput if your servers are resource constrained.

For geographic situations, it may make sense to have additional MRS endpoints in your different offices. For example, there is no point back hauling MRS data over your private WAN over the Atlantic. You could create an additional MRS endpoint and tell Exchange Online to retrieve those mailboxes over the Internet directly from the remote location.

Cheers,

Rhoderick

Exchange CAS Namespace Planning