This is a question that comes up so frequently in forums and I have seen threads where the answers are wrong. Most Exchange admins are confused about this topic and end up adding it as part of the certificate to cover a “just in case” scenario.
Now, the answer to the question is that you DON’T need to add your CAS array URL to the certificate, if you have followed Microsoft recommendations. Only the urls that are used by the clients (via HTTPS) are needed on the SAN cert. Since a CAS array is MAPI only and doesn’t use SSL, it shouldn’t be part of the SAN cert. Below are the Microsoft recommendations around this topic.
- The CAS array url should be different to OWA, EAS, OA and EWS urls.
- Split-DNS is used (A general recommendation, not related to the CAS array issue though)
- You should use a url that isn’t resolvable from the internet as your CAS array.
In small environments or one with split-DNS model, Exchange admins configure the CAS array to be same as the OWA url and in that case, it becomes part of the SAN certificate anyway. From this “experience”, people start to answer in forums that the CAS array url SHOULD be part of the certificate. Microsoft recommendation to have the CAS array url to be completely different to any other urls will make you think as to whether it is needed 
If the CAS array url is resolvable from the internet, Outlook Anywhere users will experience significant delay while connecting. Why? Outlook will try to use RPC to connect first as the url is resolvable, then waits for the timeout to kick in as the connection won’t be possible before establishing the connection using RPC over HTTPS. For a small shop or ones that doesn’t have Outlook Anywhere configured, this won’t be a big issue.
So, it is good to have your CAS array url to be something internal, like outlook.hew.local and configure an “A” record in the internal DNS pointing to the load balanced IP address.
Now, the next question that confuses admins is whether the NLB cluster name and SAN array name should be the same. NO, it doesn’t have to be. This means that the NLB cluster name and CAS server NETBIOS/FQDN doesn’t have to be part of the SAN cert as well. Make sure that the Exchange web services url and Autodiscoverserviceinternaluri are configured properly.
In short, the following is what you need on an Exchange 2010 SAN certificate (single site solution).
- OWA/EAS/OA/EWS url (like mail.domain.com, some companies go for one url per service).
- Autodiscover.domain.com, where domain.com is the email domain part of your user’s email address.
- Legacy.domain.com, if you are co-existing or thinking of co-existing Exchange 2010 with earlier versions.
No need for CAS array urls, NLB cluster names, CAS server NETBIOS or FQDNs! Hope this clears some confusion.
Hi Rajith,
Question if you don’t mind. In a EX2013 setup with NLB across 2 CAS boxes, when you state to have the internal web services and autodiscoverinternaluri configuration set correctly. Are you stating the internal NLB addresses should be used for these configurations?
Cheers,
Matt.
Yes, that is correct so that you have resilience.
for uc certificate do we need to include cas server fqdns in uc certificate
Microsoft recommendation to have the CAS array url to be completely different to any other urls will make you think as to whether it is needed
Can you send me MSArticle for recommandation
Hi Reda,
Technically, you can use the CAS array url as the same as your other urls. But, the recommendation is to use a non-routable url (from internet) for CAS array. Otherwise, it causes a delay in Outlook Anywhere connection.
CAS array url is not needed in the cert, as it doesn’t use HTTPS.
Thanks.
Hi Turbomcp,
In the Technet article, please look the section titled "Proxying with NLB". It clearly says that internal and external urls should point to NLB.
There will be scenarios where these general rules for OWA doesn't apply.
Thanks.
dont think so man:)
check here:
http://blogs.technet.com/b/exchange/archive/2011/01/17/configuring-multiple-owa-ecp-virtual-directories-on-exchange-2010-client-access-server.aspx
and also here:
http://www.msexchange.org/articles_tutorials/exchange-server-2010/high-availability-recovery/load-balancing-exchange-2010-client-access-servers-using-hardware-load-balancer-solution-part2.html
and technet says same thing:
http://technet.microsoft.com/en-us/library/bb310763.aspx
those two specific directories should never point to nlb(not internal ones anyway)
Thanks Turbomcp.
Your internal OWA and ECP should point to the HLB/NLB, especially if you have split-DNS model (something that Microsoft recommends for having a simple model). There are companies who cannot have this for one reason or the other and may need additional names in the SAN cert.
Hi
First i am big time fan of your site
second regrading this last sentence "CAS server NETBIOS or FQDNs"
i think there might be a need for fqdn of the cas for ecp.
ill explian why, since those names(owa internal and ecp) should not point to hlb or nlb names if a user using outlook 2010 does message tracking and is directed to ecp web site(internal name/names) and the name is not on the cert it will get a prompt for security(name doesnt match the cert…)
Thanks again for your hard work