Exchange 2013/2016: CAS Namespace Planning
There has been a lot of discussion on the CAS namespace planning to know how many namespaces are required for your Exchange 2013 deployment.
In reality it depends on your high – availability requirement and your infrastructure. Here I am highlighting some more facts around the namespace which was originally explained by Ross Smith IV here.
Exchange 2013 brings some great changes in CAS proxy and redirection which helped us in reducing the namespaces and eventually helped us in reducing SSL certificate cost.
Reduced Namespaces
Until today we always recommended on a design of reduced name spaces to maximum 2 namespaces in only Exchange 2013 & Exchange 2010 + 2013 Coexistence and 3 namespaces in Exchange 2007+2013 Coexistence.
To recap we focused and recommended to configure the following names spaces to reduce the cost of the Certificate
AutodiscoverServiceinternalURI: Autodiscover.domain.com
Exchange 2013(all)/2010(all)/2007(except OWA and EWS): mail.domain.com
Exchange 2007(OWA and EWS): Legacy.domain.com
This configuration will surely work as expected and shown in the diagram, 4 Node DAG(CAS+MBX) spread between 2 AD sites with 4 DB copies:
Green User is connecting to the internet facing New York Site which will proxy the request to Los Angeles AD Site Exchange server where the mailbox is located
Best High Availability
Now we are thinking towards the best High – Availability in reducing the manual effort in case of multiple datacenter with multiple DAGs. One of my customer has 7 datacenters and we are going with the 4 DAG design due to the separate geographical location and connectivity requirements. But today I am taking an example of 2 datacenters to easily explain it with the below diagram. 4 Node DAG(CAS+MBX) spread between 2 AD sites with 4 DB copies:
Here the requirement is the High – Availability and connectivity to the local AD Site Exchange servers Directly. So in this case we assign the Regional Name spaces which will ensure local client connections does not use unnecessary WAN traffic.
Imagine you have an org and you have any 2 datacenters 1 in New York and other is Los Angeles. Your Requirement is New York Users to connect to the New York Exchange Server and Los Angeles Users to connect to the Los Angeles Exchange Server in this situation we will use the following namespace.
AutodiscoverServiceinternalURI: Autodiscover.domain.com 2 DNS Records – 1 for each location.
Los Angeles AD Site Exchange 2013: LA.domain.com
Los Angeles AD Site Exchange 2013: NY.domain.com
Now there can be following 2 Disasters which may occur.
-
1. Any of the Datacenter goes down.
In our example we simulated AD Site Los Angeles has Power Grid Failure and all UPS could not resist so this data center goes down.
Exchange is configured in 3 datacenter DAG mode which has FSW in the 3rd datacenter which is not part of the diagram. End state is Los Angeles Databases activated at New York AD Site.
This means Orange Users mailbox moved to NY.
Orange user will query for SCP and Auto discover will give NY namespace because his mailbox is in NY.
Hence Orange user directly connects to NY.
-
2. Any of the internet link down.
In our example we simulated AD Site Los Angeles has ISP internet outage which means internet is down but WAN link is up.
Exchange is configured in 3 datacenter DAG mode which has FSW in the 3rd datacenter which is not part of the diagram. End state is Los Angeles Databases continued to remain activate at Los Angeles AD Site because WAN link is UP.
This means Orange Users Mailbox stays in LA.
Orange user will query for SCP and Auto discover will give NY namespace because NY is connected to the Internet.
Hence Orange user connects to LA via NY Redirection.
I hope this adds name space High Availability open in your design as and where it is required.
Microsoft MVP | Office Servers and Services
Team@MSExchangeGuru
September 16th, 2016 at 7:15 am
hi,
what if there is no WAN connectivity betn the LA and NY?
September 16th, 2016 at 12:39 pm
Redirection/Proxy will not work