CAS ARRAY Names, Certificates and Load balancers

CAS Array’s may be a bit confusing

  • What are they
  • What do you call them?
  • Do CAS Array names need to be included in your certificate names
  • What about load balancers

 

What are they?

A CAS array is a logical Grouping of CAS servers within an AD site represented by a single DNS name, and not much more. Creating a CAS array doesn’t switch on a bit of magic and client requests stat heading to the CAS array automatically – what it DOES do, is create a logical – note logical – grouping of CAS servers – the physical grouping still needs to be achieved using a load balancing mechanism of some sort.

 

What do you call them?

It depends. You don’t want to call you array a name that you can reach from the outside – like mail.company.com – why? Outlook will expect to create an RPC (MAPI) connection to mail.company.com and fail. CAS Arrays don’t have much significance in your name space planning from the outside, so call them something that makes sense from a  name space perspective from the inside.

 

 

What about names on the certificate?

So you’ve created your CAS array, and now you want to rush out and buy a certificate for it. But why would you want to do that? MAPI doesn’t require a certificate. If you have internal services like OWA or OA (RPC over HTTP) that connect via an internal load balanced name, then it may make sense to add the name on a certificate, however that may be an internally trusted (note I didn’t say Exchange self signed certificate) certificate, and as such doesn’t need to reflect on your external certificate.

 

 

What about load balancers?

What about them? lets go back to the previous point. If you understand what protocols you’re publishing and where you’re publishing them to then understanding if you need a load balancer or not becomes easy. Lets look at MAPI and HTTP protocols:

IF you have a CAS array, then you’re probably using internal MAPI clients to over several CAS servers. You need a load balancing mechanism.

If you’re publishing HTTP based protocols to the outside (EWS,  OWA, ECP, OA, etc) then you may be publishing those protocols and load balancing via ISA/TMG/other (“other’s” always an interesting discussion 🙂 )  There’s a few ways of satisfying the load balancing requirement depending on which client you’re balancing.

Should HTTP based clients feature in your certificate naming? Yes they should, but remember what you’re publishing and where to (inside/outside) and your certificate names may become a lot more obvious.

 

In summary – if all you’re doing with your CAS arrays is providing  MAPI, then you don’t need a certificate, however if you’re doing ANYHTING else, like OAB, EWS, Availability Service (AS), etc, then

yes – you should have a certificate for those name spaces

no – that certificate doesn’t have to be an externally sourced certificate, but it may well be if it makes your planning easier.

so to answer the question  – should your CAS array name reflect on your external certificate ? If you don’t want to roll out internal PKI (certificate) infrastructure, and you only have one site and that site is internet facing and you’re publishing http based name spaces then the answer may well be yes.

If you have more than one internet facing site, or have several load balanced names or have your own PKI, or don’t want to give away your internal name spaces – then the answer is – it depends. If the answer isn’t immediatelly obvious, then you may want to start by

  • understanding the name spaces you want to address
  • understand which protocols you’ll use in those name spaces
  • understand if they’re internal or external facing or both

and take it from there.

Nicolas Blank

Nicolas is an Architect, author, and speaker focused on all things Exchange and Cloud at NBConsult. With over 16 years of experience on Exchange, Nicolas consults to customers globally on cloud based and on-premises Exchange as well as ISVs building Exchange focused products. Nicolas has extensive experience using Azure to create public and private Azure based offerings leveraging cloud based principles and common sense. Nicolas currently holds status of MCM Exchange 2010, Office 365 (Microsoft Certified Master), MCSM Exchange 2013, and has been awarded Microsoft MVP (Most Valuable Professional) for Microsoft Exchange since March 2007. Nicolas has co-authored "Microsoft Exchange Server 2013: Design, Deploy and Deliver an Enterprise Messaging Solution," published by Sybex. Nicolas blogs regularly on Exchange and messaging topics at blankmanblog.com, tweets at @nicolasblank, and is the founder of and a contributor to IT Pro Africa itproafrica.com and @itproafrica

nicolasblank has 99 posts and counting.See all posts by nicolasblank

Pin It on Pinterest