Share via

Robert's Rules of Exchange: Namespace Planning

  • Article

Copied from https://msexchangeteam.com/archive/2010/11/22/456992.aspx. Many thanks for Robert Gillies

Overview

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 mail.robertsrules.ms. 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 autodiscover.robertsrules.ms. And for our legacy OWA redirection, we will use legacy.robertsrules.ms.

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 legacy.robertsrules.ms 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 mail.robertsrules.ms 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 mailLFH.robertsrules.ms. 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: mail.robertsrules.ms and maillfh.robertsrules.ms.

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 mail.robertsrules.ms has failed. We moved all services over to the LFH datacenter, including making some DNS changes to point users trying to find mail.robertsrules.ms to the VIP that is actually maillfh.robertsrules.ms.

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 mail.robertsrules.ms to 5 minutes, we could have up to 25 additional minutes where a client requests information from what it thinks is mail.robertsrules.ms but is really maillfh.robertsrules.ms. After you move the databases back over to the other datacenter, maillfh.robertsrules.ms 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 mail.robertsrules.ms) 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 "mail.robertsrules.ms", asking the user to re-authenticate. Problem is that the IE cache is still pointing at the IP address of "maillfh.robertsrules.ms". 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: FailbackHSV.robertsrules.ms and FailbackLFH.robertsrules.ms.

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 mail.robertsrules.ms namespace for our Domain Secure demonstration. As such, we won't need the smtp.robertsrules.ms 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:

  • mail.robertsrules.ms
  • mailLFH.robertsrules.ms
  • legacy.robertsrules.ms
  • autodiscover.robertsrules.ms
  • failbackHSV.robertsrules.ms
  • failbackLFH.robertsrules.ms

We'll designate mail.robertsrules.ms 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.