Robert's Rules of Exchange: Namespace Planning

Published Nov 22 2010 07:30 PM 27.4K Views


Robert's Rules of Exchange is a series of blog posts in which we take a fictitious company, describe their existing Exchange implementation, and then walk you through the design, installation, and configuration of their Exchange 2010 environment. See Robert's Rules of Exchange: Table of Blogs for all posts in this series.

Namespace planning is a serious topic that must take place relatively early in the Exchange 2010 planning and deployment process. Many companies choose to purchase certificates from a third party certificate authority (CA) rather than deploy a certificate generated from an internal CA, as this ensures the majority of devices have a trusted root certificate. I'll purchase a certificate from a CA for this series. Deploying a certificate with the incorrect namespace values can be costly as you will have to generate a new CSR and thus repurchase a new certificate with the correct namespace values because you didn't plan correctly. Some CAs will allow you to resubmit a CSR and issue you a new certificate at no charge.) In this article, we'll talk about a few of the things you must consider when planning your Exchange 2010 namespaces.

The Big Three

There is some great documentation written around namespace planning for your CAS deployment. For instance:

We're going to go a bit beyond those three namespaces for our deployment, but we do need to start with this list of "big three" namespaces.

For the Robert's Rules scenario, we'll have a single main Internet "Point of Presence" or PoP in the HSV (Huntsville, AL) datacenter, with plans to fail over to a secondary PoP in the LFH (Lightfoot Hollow, Winchester, TN) datacenter if necessary. All client access will come in through the main namespace This includes Outlook Web App (OWA), Exchange ActiveSync (EAS), Offline Address Book (OAB) downloads, and the Availability Service (and all other Exchange Web Services clients). For Autodiscover, we will use And for our legacy OWA redirection, we will use

So that's our "big three" for our namespace planning. I would propose to you that all three of these will be needed in any single forest Exchange 2003/2007 to Exchange 2010 upgrade/coexistence scenario. Obviously, if you're not upgrading from Exchange 2003 or 2007, you won't need the namespace; or, if you're moving between forests, it's quite possible that you'll have a different set of name designs.

Redirect Sites

With the single namespace defined for user access, we can function in a world where we only have a single Internet PoP and we'll always proxy HTTP requests to the secondary datacenter. This is one of the scenarios that I want to demonstrate in this series, so we'll show this and demonstrate how the client experience differs from other scenarios, but it's not really what the Robert's Rules requirements dictate.

Because Robert's Rules requires that we have a secondary PoP for Internet access, even if we won't use it except in cases of a total failure of the primary datacenter, we'll need to have a second namespace for general user access. For this, we'll utilize As you'll see in the next section, we'll utilize this secondary namespace for other reasons as well.

CAS Array Names

The ClientAccessArray (as created with the New-ClientAccessArray cmdlet) is a logical construct in Active Directory designed to group together Client Access servers located in an AD site in a single namespace. This namespace is then applied to the mailbox databases that are hosted in that AD site (the RpcClientAccessServer attribute of the mailbox database), and that name's returned to Outlook and other RPC clients as their MAPI target server. For more details, see Understanding RPC Client Access.

I said above that the namespace planning is important because we need to get our SSL certificate names (the subject name and subject alternative name - or SAN - fields) correct. Wait. What? MAPI doesn't use SSL certs! So why do we care about a name for the "CAS Array"?

The answer is that I'm not talking about the ClientAccessArray object. Yes, it's a bit confusing, but I'm talking about a load-balanced array of Client Access servers, created using the Network Load Balancing feature in Windows Server or by using a hardware load-balancer. The Client Access servers in the load-balanced array may or may not be the exact same servers as those in the ClientAccessArray. During normal operations, both will generally include the same set of servers. The only time that they wouldn't be the same is during maintenance operations, when we may remove one or more servers from the load-balanced array temporarily.

But those Client Access servers need to provide certain other services that may also be load-balanced, and therefore require SSL. Clients will need to find the virtual IP address (VIP) of the load-balanced array, and we'll therefore need a DNS record for that fully-qualified domain name (FQDN) so it can be discoverable. I don't know if there's a proper or accepted name for "the load-balanced array of Client Access Servers", but we're not talking about the ClientAccessArray object, just a name of that array used in DNS, so I choose to call it the CAS Array, and to be very specific and use the object name ClientAccessArray when talking about the object used for MAPI access. Until someone corrects me and provides a better name, I'll stick with it throughout this blog series. (In Windows' Network Load Balancing terminology, load-balanced arrays are called Network Load Balancing clusters -Editor)

I will use OutlookHSV and OutlookLFH for my ClientAccessArray names (we'll need these FQDNs in DNS as well), but for HTTPS-type connections (and therefore our SSL certificate) I will use two names we've already chosen to use in other scenarios: and

FailbackURL Names

In Exchange 2010 RTM (pre-SP1, that is), there's a situation that can happen during a datacenter failure scenario. During the "fail back" scenario when services are being relocated back to the primary datacenter, in some circumstances an OWA client will get a redirect that sends them to the server they just connected to, causing an outage for that user. For instance, let's use our names we just defined above and assume that the datacenter that hosts has failed. We moved all services over to the LFH datacenter, including making some DNS changes to point users trying to find to the VIP that is actually

When we go to "fail back", we reactivate the services in the HSV datacenter, redirect DNS and everything seems to work as expected. But one thing we can't control from the servers is the client browser cache. Browsers can maintain their own DNS cache that is separate from the operating system. Internet Explorer (IE) has a cache that acts similar to the DNS TTL value (note that you can manage this setting on your clients - see KB 263558). If you haven't made these changes, IE will hang on to an IP address for a given URL for 30 minutes before it asks the OS to re-query DNS for a new IP address. You can clear this cache by restarting IE, but that's a poor client experience.

This means that even if we set the TTL on the DNS record for to 5 minutes, we could have up to 25 additional minutes where a client requests information from what it thinks is but is really After you move the databases back over to the other datacenter, replies back to the client, "Hey, welcome back. I see that your mailbox is in the other Active Directory Site and because the CAS in that site have an ExternalURL defined, please use that URL (which happens to be and try to log in." The user takes this redirect (the user is prompted, and the user manually accepts this redirect - meaning that there is no "single sign on" redirect here) and tries to reconnect to "", asking the user to re-authenticate. Problem is that the IE cache is still pointing at the IP address of "". So the client gets in a loop for up to 25 minutes with OWA just prompting for credentials over and over again. Not great — especially if that user happens to be the person who signs your paycheck.

In Exchange 2010 SP1 (which we'll be deploying at Robert's Rules), we added the FailbackURL parameter to the OWA Virtual Directory (we'll set this using the Set-OwaVirtualDirectory cmdlet). When OWA detects that the client is in this looping condition, it'll redirect it to the FailbackURL. Thus, we have a cleaner fail back scenario which provides a better availability stance for our clients.

To implement this, we need our FailbackURL values to be included in our list of SANs. For our environment, I've chosen some equally obvious names: and

Email Delivery and SMTP

Some organizations will have another namespace called SMTP. For instance, if you are supporting a POP or IMAP client base, you might want to have a secured SMTP namespace for the POP/IMAP users to connect. POP3 and IMAP4 are becoming less prevalent in Exchange customers, especially as more mobile devices support the Exchange ActiveSync protocol. I have chosen to not have a separate SMTP namespace for these users because we don't support POP/IMAP at Robert's Rules.

Further, we'll use the namespace for our Domain Secure demonstration. As such, we won't need the namespace in the Robert's Rules environment. This doesn't mean that it would be wrong to use the "smtp" namespace — we just chose not to in this environment.

Putting It All Together

Now we've defined 6 names we need to include in our certificate. It's possible that in some large organizations with Exchange deployed to many sites, you could have dozens, or even over a hundred names that you need to define. There is no rule that says you need to use a single certificate to support all of these various sites. In fact, the use of a wildcard certificate could be part of your plans. But wildcard certificates are sometimes quite expensive, and in my experience, "security guys" don't like wildcard certs and tend to push back on those.

For our purposes at Robert's Rules, we'll purchase a single SAN cert, and include the following subject alternative names:


We'll designate as the Subject Name. We'll talk more about how to order a certificate, the impacts of using a single certificate when using Outlook Anywhere, and many other things related to our namespace decisions as we move through the upcoming posts in this series.

Stay tuned for more!

Robert Gillies

Not applicable
Would be interested to know how this fits if your smtp domain doesn't match your internal domain name. I'm assuming you'd also need to add names in your SAN cert for those too eg and ? I've also read the need to add Netbios names of your Casarray and CAS servers. Is this correct too ?
Not applicable
Same question as AK (good one!)
Not applicable
@AK, if you have a separate domain name inside and out (like at Microsoft - you email to, but internally everything is built on a basis), then you might need to have more names in your list.  You would certainly have to think about that.  I will be using a split DNS so that my users, internal or external, will use the same names to get to OWA (for instance).

As for the NetBIOS names (or short names - meaning names like "CAS01" rather than "")...  You would only need those if users will be accessing services by those names directly.  When Exchange accesses names (through proxy for instance), or tells the users what names to access (through redirection, for instance), it will always you a FQDN, not a short name.  There are some situations that would require the short names on your certificate, but we will not be doing those in Robert's Rules, and you can almost always get away without having to do them anyway.

Thanks for the questions - both very good ones!!
Not applicable
Is the FailbackURL parameter only for OWA ? or also for the ECP ? is it a mandatory parameter or just a best practice ? what are the pros and cons ?

Not applicable
Unfortunately I had to do some trickery when I deployed Exchange 2007 and getting autodiscover, activesync, etc. to work.  Our internal namespace is a domain that we don't own (a legacy carryover from before my time).  The changing of an internal namespace is logistically daunting, and almost equally difficult in validating a business case to do so.  Anyway, I ended up getting a UNC/SAN cert and among my other public FQDN's, adding a simple (non FQDN) name of the internal Exchange server in my SAN cert.  Then, making sure that my Exchange configuration used simple names.  Works in Exchange 2007, but am mindfull that it may not work in Exchange 2010.  
Not applicable
@Pete - not sure, but I wouldn't be surprised if you could get something working in a similar manner.

@newbie - Only for OWA (ECP is generally accessed through OWA).  It is not required, just useful for the scenario described, and will be a best practice for that scenario.  Pros and Cons?  No Con - it is only called upon in the scenario described.  Pro?  You don't get into the looping scenario described if you use it.  ;*)
Not applicable
@Pete - not sure, but I wouldn't be surprised if you could get something working in a similar manner.

@newbie - Only for OWA (ECP is generally accessed through OWA).  It is not required, just useful for the scenario described, and will be a best practice for that scenario.  Pros and Cons?  No Con - it is only called upon in the scenario described.  Pro?  You don't get into the looping scenario described if you use it.  ;*)

Note:  All of the implementation details and functionality described will be tested and demonstrate as we get to the implementation portion of this blog series.  Right now, we are still just planning the environment, talking through the decisions needed to fully implement Exchange.  I'm as impatient as all of you readers - I'm ready to start building servers!  But, we have some groundwork to cover first.  Trust me, we'll get there and I hope to cover all of these implementation questions then!

Thanks again for reading!  Great questions!!
Not applicable
Now to just convince my clients to purchase 2 more names in the SAN cert, when they generally already complain about having to purchase a SAN in the first place. (2003 -> 2010 upgrade clients) ... ;)
Not applicable
Is there any configuration available so I can send email using SMTP even in localhost??? Whenever I am trying to do so I got error message. So pls provide help.
Not applicable
@Buy Seroquel - Thanks!  Appreciate the kind words!!

@DelbertLoweBN - I'm not sure what you are asking here, and this isn't a great forum for technical support.  I would suggest a call to CSS or Premier because you'll get a much more direct answer on a much better timeline.
Not applicable
Useful article indeed...
Not applicable
If you have the capability to also include SSL offloading in your configuration I think it would be very much apprecited.

A quick note about namespace planning for those who are not split-DNS:
If your CAS array will be load balanced and you don't want cas server names in the certificate and you want to prevent certificate mismatch with internal autodiscover - you need to define the internal namspace just like you would external and include those NLB names in your certificate and update the InternalURLs on each CAS server (including the Autodiscover virtual directory and SCP for Active Directory).

If you have 2 sites you will need at minimum 5 SAN names:
Not applicable
@JWarcop - there are a lot of things that can make namespace planning more complex, and therefore harder to plan.  Not having split-DNS can certainly do that.

As for SSL offloading, I think we can add a discussion right after the hardware load balancing discussion.  Thanks for the idea.
Not applicable
Recently I ran into a problem with one our customer. They have a quite unique namespace deployment for Exchange 2010. The OWA is published through URL But the primary email address is I bought a SSL cert with following SANs



- InternalExServerName

- InternalExServerName.companyA.local

The problem comes when users access Exchange from a non-domain joined client with either Outlook2007 or 2010. They will receive cert error as by default it lookup to

Customers can live with this issue as long as they click Yes to confirm the certificate error. I have not tried Outlook Anywhere though, will Outlook Anywhere use or and how about ActiveSync...?

Not applicable
@aha_tom - I think that your problem comes down to the fact that the clients build an autodiscover request based on the email address of the user.  If they put in user @, they will query  It will be the same thing with Outlook Anywhere or ActiveSync, and the problem is that many of the ActiveSync clients will silently fail.  They just won't work.  Unfortunate, but I think that's what you'll see.

To fix, buy another cert that has in the Subject Alt Name list.
Not applicable
Do you happen to have any recommendations for working with clients who have chosen an inappropriate internal namespace, such as company.AD (.AD belonging to some country about the size of Los Angles) thus not being able to get a certificate authorised.  With E2007 I was generally able to create a split DNS and configure most everything to use the external namespace, but a list of all the various powershell settings would be extreamly handy, ie the Internal/External URL for OAB as an example.

Or if you have a better idea that doesn't include renaming the AD environment, I'm all ears.
Not applicable
I have no understanding of web based servers at this time.  I am looking for a way for my husband and I, who work together, to work on the same outlook email interchangeably.  So if he is in one state and I am in another, and I need him to look at my email, in real time, and answer messages for me for a day, if I'm not able to work,  I'd like to know if this is the kind of program we are looking for?  I will not have multiple email addresses, just want to access and use the same account so we can see and access the same emails and keep track of said emails in one place. thanks.
Not applicable
In what scenario would you be able to use a wildcard certificate instead of SAN certificate?
Not applicable
@Korbyn - while it does complicate things, there shouldn't be an issue.  The company should be able to use a public DNS name that does work, that they can get a real cert for, and they should be fine.  Having a non-public internal namespace is not really common, but there are organizations that have that.

@Kimberly - you could use any email service provider that has a web interface and just share the password with your husband.  Think Hotmail or Google or Yahoo.  They are all free.

@rikiros - Hmmm... Thought provoking, as always.  Keep those interesting comments coming!

@Bob - Wildcard certs can be used in just about any situation.  There are some issues with Windows Mobile 5.x clients and wildcard certs, and some non-patched Windows/Outlook versions, but those clients are so old that usually they aren't an issue any longer.  The main problem with wildcard certs is that administrators tend to leave the cert files "laying around" on their servers (I tend to do so in a "c:certs" directory), and the security guys just don't like that.  With the wildcard cert, you can act as any server name in that org that you want.  PLUS, wildcard certs tend to cost a lot more from cert providers...
Version history
Last update:
‎Nov 22 2010 07:30 PM
Updated by: