Setting up single namespace in Exchange 2013

One of the great changes in Exchange 2013 is the simplification of namespaces. Where you in previous versions needed a handful, you can now stick with two. Well, you CAN do it with one actually.

The documentation on this is a huge ball of misconceptions and old best practices, so I decided it’ll be worth doing a simple tutorial on how to set it up. Once you know how to do it, it actually is fairly simple.

So I’m going to assume you’re running split-brain DNS (essentially meaning you have both you internal and external DNS zones in you internal DNS). If you don’t you’ll just have to make the changes in two different locations.

Your domain name is iloveexchange.com (don’t we all?), and your external domain name will be mail.iloveexchange.com

First off, you’ll need these DNS entries:

  • A-record for mail.iloveexchange.com. This can point to either you CAS(es), or your load-balancer IP. Depending on your setup.
  • A-record for autodiscover.iloveexchange.com pointing to the same as mail.iloveexchange.com OR
  • SRV record for _autodiscover; _tcp on port 443 pointing to mail.iloveexchange.com/load-balancer

Now, the difference between a simple A-record and a SRV record, is the difference between one namespace and two. If you use an A-record (probably most common), when you type in your address (username@iloveexchange.com), Outlook will check for autodiscover.iloveexchange.com. If you use an SRV record, that should override that; and Outlook will detect the service-record and look up whatever you point that to.

This is a failover thing, so if one doesn’t work, it’ll try the other. Still doesn’t matter what you choose. I usually use the A-record because I find it easier to verify (ping autodiscover.iloveexchange.com to see if it’s there). Checking the SRV record is a couple of more keypresses.

So going with the A-record you will need the following in you SSL-certificate:

  • mail.iloveexchange.com
  • autodiscover.iloveexchange.com


Before you assign/request your certificate; you’d better make sure that there are no pointers to other URLs in your Exchange setup.

You can do this with powershell, or using the ECP. I use ECP for the first part here.

Go to Servers and virtual directories, and you’ll get a list of all of them:



For each and every one of them, you need to change so both internal and external urls are the same:



This goes for everything but powershell!! Don’t mess with powershell.

Once you’ve done this, you would think you were done, right? Not a single pointer to you servernames, all to mail.iloveexchange.com.

Not quite. You may have noticed that your autodiscover virtual directory doesn’t have an URL field. If you run Get-AutodiscoverVirtualDirectory in powershell, you will see that the URL fields are infact empty. That is because that the autodiscover URL isn’t actually a property of the virtual directory, but the CAS.

So what you need to do, is run

Set-ClientAccessServer -identity (server) -AutoDiscoverServiceInternalUri https://mail.iloveexchange.com/Autodiscover/Autodiscover.xml

For all of your servers (you can pipe it ofcourse).

If you skipped this step, you clients would get a certificate error on every startup. Saying the server name (internal FQDN) doesn’t match the ssl cert.


Good! Now all you have to do is request a certificate, or assign one if you already have one. I’m not going through that, there are other guides that cover that part; but you names should look like this (just remove everything else):


Fire away if you have questions!

7 Comments + Add Comment

  • Thanks for this awesome post. One question. When I run the Set-ClientAccessServer command with no error and then to verify I run Get-AutodiscoverVirtualDirectory again the InternalURL still shows blank. is this expected behavior. Is this what you see too?

    • Hi there!

      Yes, that’s actually a bit misleading. You can run set-autodiscovervirtualdirectory and set the URL there as well, but it won’t matter. That’s not where Exchange reads this setting. No harm if you’ve done so though.

      But leave it be 🙂

  • Hi – when you say you will need an internal and external zone in your internal DNS zone, how would this look. We already have one zone for our internal dns (e.g. mydomain.org) how would we add the second one for our external zone (would it be mail.mydomain.org)?

    • Hi Stephen,

      Well, ok; say your public address is mailservers.com, and your local domain is mailservers.local.

      the bottom line is that you need to resolve one dns name, wherever you are. So if you want to use mail.mailservers.com; that needs to resolve to your outside address on the outside, and your inside address on the inside. Technically it might work with the outside address either way, but more often than not that’s problematic network-wise, since traffic would go out and then in again on the same firewall (maybe).

      So it’s really not more complicated than that the address you choose needs to be resolvable and accessible from both your inside network and public networks.

      If that makes sense 🙂

  • Thank you for the great post,
    i’ve run the command :
    Set-ClientAccessServer -identity (server) -AutoDiscoverServiceInternalUri https://mail.iloveexchange.com/Autodiscover/Autodiscover.xml
    as Kris mentioned the internal URL is Empty and you said its a normal behaivor.
    however my customers “internal users “getting certificate error .
    Their outlook is connecting with ex.domain.local and not domain.com

    thank you

  • That’s really thinikng out of the box. Thanks!

Leave a comment