Avoiding Server Names in SSL Certificates for Exchange Server 2013

In a discussion about SSL certificates for Exchange 2013 servers the question of whether to include server names in the SSL certificate often comes up.

In this article I’m going to demonstrate how you can deploy an SSL certificate for a simple Exchange 2013 organization without including the server names in the certificate.

exchange-2013-ssl-hostnames-01

But first let’s be clear – including server names in your SSL certificate is supported. For many small organizations, particularly those with a single server, it is probably going to be less effort to just include the server name in the certificate.

However, that is not best practice.

In addition to using as few certificates as possible, you should also use as few host names as possible. This practice can save money. Many certificate providers charge a fee based on the number of host names you add to your certificate.

The most important step you can take to reduce the number of host names that you must have and, therefore, the complexity of your certificate management, is not to include individual server host names in your certificate’s subject alternative names.

As Rajith points out here this best practice is important for larger organizations to reduce costs, reduce administrative overheads, and because in larger scale environments services are configured with namespaces that resolve to load-balanced IP addresses and so on.

Since that last point would likely also apply to any organization that has two or more Exchange servers this is a topic worth covering in more detail.

Namespaces for Exchange Server 2013

In Microsoft’s words:

The host names you must include in your Exchange certificates are the host names used by client applications to connect to Exchange.

More specifically, it is the host names client uses to make TLS/SSL connections to Exchange services. Those services include:

  • Outlook Anywhere
  • Outlook Web App
  • Exchange Control Panel
  • Exchange ActiveSync
  • Exchange Web Services
  • Offline Address Book
  • AutoDiscover

POP, IMAP and UM also have certificate requirements but can be enabled to use separate SSL certificates, whereas the above services all use the same certificate. So for this article I will ignore POP, IMAP and UM.

Sticking to a simple scenario we will plan to use one namespace for all of the services. So the hostnames/URLs to be configured are:

  • Outlook Anywhere – mail.exchange2013demo.com
  • Outlook Web App – https://mail.exchange2013demo.com/owa
  • Exchange Control Panel – https://mail.exchange2013demo.com/ecp
  • Exchange ActiveSync – https://mail.exchange2013demo.com/Microsoft-Server-ActiveSync
  • Exchange Web Services – https://mail.exchange2013demo.com/EWS/Exchange.asmx
  • Offline Address Book – https://mail.exchange2013demo.com/OAB
  • AutoDiscover – https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml

Split DNS for Exchange Server 2013

For many organizations the use of  split DNS for your Exchange namespace goes hand in hand with eliminating server names from SSL certificates.

Split DNS allows your internal clients to receive a different answer to their DNS lookups than an external client would receive. In effect you have your Exchange namespace (in this example exchange2013demo.com) hosted on your internal DNS server, with records configured to point to internal IP addresses.

[PS] C:\>Resolve-DnsName mail.exchange2013demo.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
mail.exchange2013demo.com                      A      3600  Answer     192.168.0.187
mail.exchange2013demo.com                      A      3600  Answer     192.168.0.188

If you’re wondering why mail.exchange2013demo.com has two A records it is because I am using DNS round robin to load balance the name, as demonstrated in this article on Client Access server high availability.

Meanwhile you also have the Exchange namespace hosted on your public DNS servers, with records configured to point to external IP addresses.

C:\>nslookup mail.exchange2013demo.com

Non-authoritative answer:
Name:    mail.exchange2013demo.com
Address:  58.7.203.81

Configuring Hostnames and URLs in Exchange Server 2013

Although some of the hostnames and URLs are configurable using the Exchange Admin Center, some others require you to use PowerShell. So for the sake of simplicity I will use PowerShell to configure all of the services.

Remember we are looking at a simple scenario of two servers in a single site as shown in the diagram above, so you will see me piping commands such as Get-OWAVirtualDirectory into other commands to administer multiple objects at the same time.

Note: If you have multiple servers in different sites then you may wish to configure servers individually instead of in bulk, as different sites may have different namespace requirements in your organization.

Configuring Outlook Anywhere

To review the current configuration use Get-OutlookAnywhere.

[PS] C:\>Get-OutlookAnywhere | Select Server,ExternalHostname,Internalhostname

Server ExternalHostname InternalHostname
------ ---------------- ----------------
E15MB1                  mail.exchange2013demo.com
E15MB2                  mail.exchange2013demo.com

I’ve already configured the internal host name for Outlook Anywhere in my test lab, but you might see your server’s host names in there instead.

To configure the internal and external host names use Set-OutlookAnywhere.

[PS] C:\>Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname mail.exchange2013demo.com -InternalHostname mail.exchange2013demo.com -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod NTLM

Note that in addition to setting the host names you must also explicitly set the SSL requirement for both internal and external clients (default for internal is False, which is fine, but I am enforcing it in this example), and either a default authentication method or an external authentication method (set to NTLM in this example).

Configuring Outlook Web App

To review the current configuration use Get-OWAVirtualDirectory.

[PS] C:\>Get-OwaVirtualDirectory | Select Server,ExternalURL,InternalURL | fl

Server      : E15MB1
ExternalUrl : https://mail.exchange2013demo.com/owa
InternalUrl : https://e15mb1.exchange2013demo.com/owa

Server      : E15MB2
ExternalUrl : https://mail.exchange2013demo.com/owa
InternalUrl : https://e15mb2.exchange2013demo.com/owa

To configure the URLs use Set-OWAVirtualDirectory.

[PS] C:\>Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/owa -InternalUrl https://mail.exchange2013demo.com/owa

WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for
the ECP virtual directory in the same website.

WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for
the ECP virtual directory in the same website.

Configuring the Exchange Control Panel

As you can see when configuring the OWA URLs the ECP URLs must be configured to match. To configure the ECP URLs use the Set-ECPVirtualDirectory cmdlet.

[PS] C:\>Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/ecp -InternalUrl https://mail.exchange2013demo.com/ecp

I needed to perform an IISreset on my servers for this one to take effect properly.

Configuring Exchange ActiveSync

To review the existing configuration use Get-ActiveSyncVirtualDirectory.

[PS] C:\>Get-ActiveSyncVirtualDirectory | select server,externalurl,internalurl | fl

Server      : E15MB1
ExternalUrl :
InternalUrl : https://e15mb1.exchange2013demo.com/Microsoft-Server-ActiveSync

Server      : E15MB2
ExternalUrl :
InternalUrl : https://e15mb2.exchange2013demo.com/Microsoft-Server-ActiveSync

To configure the new URLs use Set-ActiveSyncVirtualDirectory.

[PS] C:\>Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/Microsoft-Server-ActiveSync -InternalUrl https://mail.exchange2013demo.com/Microsoft-Server-ActiveSync

Configuring Exchange Web Services

To review the existing configuration use Get-WebServicesVirtualDirectory.

[PS] C:\>Get-WebServicesVirtualDirectory | Select Server,ExternalURL,InternalURL | fl

Server      : E15MB1
ExternalUrl : https://mail.exchange2013demo.com/EWS/Exchange.asmx
InternalUrl : https://e15mb1.exchange2013demo.com/EWS/Exchange.asmx

Server      : E15MB2
ExternalUrl : https://mail.exchange2013demo.com/EWS/Exchange.asmx
InternalUrl : https://e15mb2.exchange2013demo.com/EWS/Exchange.asmx

To configure the new URLs use Set-WebServicesVirtualDirectory.

[PS] C:\>Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/EWS/Exchange.asmx -InternalUrl https://mail.exchange2013demo.com/EWS/Exchange.asmx

Configuring the Offline Address Book

To review the existing configuration use Get-OABVirtualDirectory.

[PS] C:\>Get-OabVirtualDirectory | Select Server,ExternalURL,InternalURL | fl

Server      : E15MB1
ExternalUrl :
InternalUrl : https://e15mb1.exchange2013demo.com/OAB

Server      : E15MB2
ExternalUrl :
InternalUrl : https://e15mb2.exchange2013demo.com/OAB

To configure the new URLs use Set-OABVirtualDirectory.

[PS] C:\>Get-OabVirtualDirectory | Set-OabVirtualDirectory -ExternalUrl https://mail.exchange2013demo.com/OAB -InternalUrl https://mail.exchange2013demo.com/OAB

Configuring the AutoDiscover SCP

The final configuration is the AutoDiscover service connection point. Unlike the other host names and URLs this is not configured on a virtual directory (don’t be fooled by the URLs shown when you run Get-AutoDiscoverVirtualDirectory).

Instead we need to use Get-ClientAccessServer to see the existing configuration.

[PS] C:\>Get-ClientAccessServer | Select Name,AutoDiscoverServiceInternalURI

Name   AutoDiscoverServiceInternalUri
----   ------------------------------
E15MB1 https://e15mb1.exchange2013demo.com/Autodiscover/Autodiscover.xml
E15MB2 https://e15mb2.exchange2013demo.com/Autodiscover/Autodiscover.xml

To configure the new URI use Set-ClientAccessServer.

[PS] C:\>Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml

Configuring an SSL Certificate

With all of the namespaces configured the next steps are:

  1. Generate a Certificate Request for Exchange 2013 that only includes the minimum required names (in this case mail.exchange2013demo.com and autodiscover.exchange2013demo.com).
  2. Submit the certificate request to your chosen CA to acquire the SSL certificate. I recommend Digicert for their competitive pricing, good support, flexible licensing, and free re-issues if you happen to make an error. Or if you’re using a private CA refer to these steps.
  3. Complete the pending certificate request
  4. Export/import an SSL certificate to multiple Exchange 2013 servers (if you have multiple servers)
  5. Assign the SSL certificate to services in Exchange 2013

Testing the New Configuration

To be confident that the new configuration is working you can run a series of tests.

  1. On a client with no existing Outlook profile launch Outlook and confirm that the profile is configured automatically and without any certificate warnings.
  2. Use the Outlook “Connection Status” dialog to verify that Outlook is connecting only to the namespaces you configured.
  3. Use the “Test E-Mail AutoConfiguration” test in Outlook to verify all services are accessible without error.
  4. Connect to OWA internally and externally and verify there are no certificate warnings.
  5. Within OWA navigate to Options and make a change such as enabling out of office.
  6. Connect to the Exchange Admin Center and verify it works without certificate warnings.
  7. Run external tests using the Remote Connectivity Analyzer website.

 

Comments

  1. Nyro says

    Hi Paul,

    I can’t use the “Internalhostname” Paramter of Set-OutlookAnywhere Cmdlet. It seems it doesnt exist
    (Exch2010SP3UR2)

  2. Nyro says

    What about the Autodiscover process in an AD site? There the Outlook Client looks up the AD for an Connectionpoint first before doing lookups on (eg) autodiscover.domain.com and mail.domain.com/autodiscover.

    The value can be found with help of ADSI within Configuration Partition > Services > Microsoft Exchange > %ORG% > Administrative Groups > Exchange Administrative Group (FYDIBOHF23SPDLT) > Servers > %NAME% > Protocols > Autodiscover | Here you can find the an ServiceConnectionPoint with the Key serviceBindingInformation. Is there a need to change it’s value as well?

    • Nyro says

      Oh my… seems that i’m still not wide awake. The SCP is already explained (didn’t see).

      – Sorry for asking stupid questions –

      Keep up this awesome Blog! You are doing really great work here!

  3. itworkedinthelab says

    Hi Paul
    Thanks for article
    one question:
    cant we avoid the autodiscover.domain.com name on cert?
    (this way we only need one name and no SAN/UC)
    I mean internally its no brainer and external client will use:
    domain.com/bum bam bam/autodiscver….
    and only then autodiscover.domain.com/bumbam/autodiscover….
    ?

  4. Florian says

    Hi Paul,

    Thanks for the article.

    Just wondering what’s involve when changing the external URL name once it’s been setup.
    One of our customer is currently using an address: remote.domain.com which is also being used for pretty much everything else published on the Internet (RD gateway, Extranet…).
    We’d like to update that name to mail.domain.local getting a new SAN cert only for exchange that includes auto discover.

    Are the outlook clients going to detect the new url automatically and update their outlook anywhere settings?
    If not is there a way to get around this so we don’t have to update it manually for each outlook client.

    Thanks,

    Florian

  5. athome says

    Absolut great article! I have lot of small business customers who just love to use only a certificate with a single name. So I create an interenal shadow domain (same as the external name) and create there a SRV Record and an A-Record who points to the same name as external. e.g. “mail.test.com” but with the internal IP Adress.

    Just one question, what is wrong with the following command?: Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory –InternalUrl

  6. J.FT says

    Great article Paul! I certainly appreciate the time you take to share your experiences with us and the knowledge you impart.

    In our envirnoment (mixed Exchange 2010/2007 – 2007 only around as a mailbox host for our voicemail services, no outside traffic to or from that one), when I check the hostnames for the Offline Address Book, both the internal and external URLs are null. Both lines returned are also the primary mailbox server in our production DAG of two servers.

    We’ve been including the local machine name in our SSL certificates for our HUB/CAS combined role servers but I’m not even entirely sure why. When I check the URLs for the other virtual directories, they are all pointing to our external domain URLs.

    Can we really just set the url to match our external domain URL? Is there any negative effect on clients that we should watch out for?

    Thanks!

  7. says

    “…when I check the hostnames for the Offline Address Book, both the internal and external URLs are null. Both lines returned are also the primary mailbox server in our production DAG of two servers.”

    I don’t understand your scenario.

  8. J.FT says

    Sorry Paul… Hope this helps a bit. We have split DNS like many other organizations. So, I went through each of the steps you recommended in the article above. Such as get-owavirtualdirectory, get-oabvirtualdirectory, etc. Essentially, the only directory that returns results that are NOT set to our public domain name is the OAB Virtual Directory, which returns a path for the internal server name(s).

    If we set the virtual directory path for the OAB to the public domain address, like the other resources, does that in itself resolve the issue? I wasn’t involved in the original establishing of the URLs for these Exchange resources so I don’t want to break something else that isn’t broken by fixing that. We just want to remove the local host names from the SSL certificate.

    As far as I understand it, the SSL cert with local host names is being used to secure the OAB directory and Outlook client to server communications as it now stands. Obviously is is securing SMTP, IIS, etc. as well but that’s not the concern here. Would we then need to generate a certificate internally (we have an MS cert server) to secure the OAB directory and Outlook to Exchange communication without errors?

    • says

      All those virtual directories are part of the default website in IIS on the server. There is one certificate bound to IIS (which you can see in Get-ExchangeCertificate).

      So I’m not sure if you’re thinking that the OAB virtual directory needs its own separate cert… it doesn’t. So if you’re switching the URLs for the OAB virtual directory to a name that is already on your IIS SSL cert, then that should work.

      If you then want to provision a new cert to enable for IIS, that has the same names except for the server FQDN, then that would likely work fine. I can’t see your servers and config though so no guarantees :)

  9. Jonathan b says

    Hi Paul,

    Just to clarify something. In your example you mention simplifying the cert to use ONE namespace for all of the services. All of them being https://mail.exchange2013demo.com/

    Even the autodiscover virtual directory is https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml.

    And in your example of the Exchange Management Shell command for Autodiscover, you list the command, changing the URL to “mail.exchange2013demo.com”.

    However at the end you say you always include the “autodiscover.exchange2013demo.com” fqdn in your SSL certs? Why would you do this if you configured everything for “mail”?
    Couldn’t you just have one standard cert for “mail.exchange2013demo.com” for everything and be set?

    Just setting up my first Exchange 2013 server so just want to make sure I’m on the correct track. Otherwise, thanks for the detailed article.

    jonathan

  10. Alessandro Matano says

    Hi Paul,

    another great article, thanks for this!
    Just a quiclk question if you don;t mind. I have two multirole exchange server and I’ve configured them in round robin for HA, as discussed in another article.
    I have both internal and external users, and I’ve configured the same name for both ExternalHostname and InternalHostname? The name I’ve used is the name space configured in RR on the DNS.
    Are you aware if this is against the best practice or simply irreleavant? I’m aware EX2013 has a different behaviour in autodiscovery from 2010, and I run into an issue when I moved mailboxes from 2010 to 2013.
    I’ve descrived in this post of mine: http://social.technet.microsoft.com/Forums/exchange/en-US/f19376ca-9a67-4d0e-a5c4-cec54e36027d/sslmsstd-settings-outlook-anywhere?forum=exchangesvrclients

    I’d appreciate if you could take a look, an advice of yours would be more than welcome!

    Thanks!

  11. ThorstenK says

    you forgot to change the fqdn on the ReceiveConnectors as they would now only find the selfsigned certificate from the setup to match server1.acme.local and use that for SMTP TLS.

    i like to use Server FQDNs in the Exchange Server certificates if the Customer has a local CA, as certificates then dont cost anything and i have easy troubleshooting some scenarios without editing hosts to circumvent the Loadbalancer.
    External Certificates are then only needed on the ReverseProxy if services are published to the internet, that is if all internal clients are trusting the internalCA, which should have been a goal when implementing that.

    • says

      Yes, I left SMTP out of this tutorial. Of course with SMTP we also have the option to bind a different cert to that service, as opposed to all the ones in this article which use the cert bound to IIS instead. The SMTP cert is also not something that will cause client-side issues for most orgs.

      Agreed, an internal CA is a good way to avoid SSL costs.

      • ThorstenK says

        how can you bind a specific cert to SMTP in E2013?
        i’ve tried it via GUI and use Enable-ExchangeCertificate but did not succeed?

        i agree TLS is rarely used internally if you dont have a lot of User with IMAP clients.

  12. Asdert says

    Hello Paul! Thank for this article!
    But I have a little question. As far as I know Microsoft’s best practice for now is to use a subdomain of company’s public domain for AD domain name (local.company.com for example). What names should I use in my certificate in this case?
    Or your recommendation is to use company.com as AD domain name?

    • says

      I make no recommendation about AD domain names and you’re free to follow the established best practices.

      The Exchange namespaces can be the same, a little bit different, or a lot different to the AD namespace. Only the Exchange namespaces need to be on the SSL certificate.

  13. says

    Hi Paul,

    Ive been following your guides for our exchange server 2013 install. We have 2 sites with exchange servers. Our main site has seperated mailbox and client access servers while our secondary site has a single vm running both mailbox and cas. the mailbox servers are setup in a DAG with a witness server at a third location. I was following the above guide and the virtual directory changes were taking a long time to complete about 10 to 15 mins. I saw the same issue when trying to make the same changes through ECP. All of the changes did take effect but after the final change to the autodiscover uri I can no longer open owa or ecp via internet explorer. Also outlook is no longer able to connect but active sync is still working. I changes the values back to defaults and that breaks everything including activesync. Any advice would be much appreciated.

    Thank You,
    Jason Adragna

    • says

      When i run the Get-OutlookProvider command I get no servers listed for EXCH,EXPR, or WEB. Navigating to the autodiscover folder only shows web.config file and no autodiscover file. Please confirm i am looking in the correct location for the autodiscover file?

      C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\Autodiscover

  14. Ken Hall says

    I am building an Exchange 2013 on a server 2012. The Domain is not a tld, it is a .lcl . My question is how do I get the internal e-mails to go to external contacts in other domains?

  15. Paul deVries says

    I am setting up a new Exchange 2013 Server and I followed your article on configuring the internal / external URL’s to a FQDN. I purchased a UCC SSL Cert From Godaddy and installed it on the Exchange server, but whenever i use the browser to connect to the OWA, I get a Certificate Error. The certificate displays the internal host name of my Exchange server instead of the URL. Any thoughs?

    Thanks in advance..

    Paul

  16. Jack Flash says

    Hi Paul

    Thanks for all your write ups, very helpful and informative.

    This may be a stupid question, but if we set both Exchange server virtual directories to all the same url, e.g. mail.domain.com, but only have one DNS record, pointing to one server, then will this not cause problems? So the client will always be directed, via DNS, to the one server? Or will that server redirect the user to the second server if their mailbox is on the second server?

    Also, do you know if there are any problems with doing this on an mixed 2010 / 2013 environment? I am wanting to do a migration from 2010 to 2013 but over a number of days, I only have mail and autodiscover on one SSL certificate, so to avoid certificate errors I thought I could just use the same cert on both servers, and as you have suggested set all the virtual directory URLs to mail.domain.com

    Does this sound like it will work and keep both servers with valid certs, whilst keeping all users connected to the relevant server where their mailbox resides?

    Sorry if this doesn’t make total sense, still trying to get my head around Exchange architecture.
    Thanks

  17. Angel says

    Paul a question from Argentina.
    If I have an installation of 2 servers virtualized Exchange 2013 with 600 mailboxes, is it necessary to install a balancer Netscaler?
    Can I use only DNS Round robin and a space of unique servers?

    What do you think?

    Thanks in advance for the article!
    Greetings, Angel.

  18. Ravikumar says

    Paul, Thanks for the great Article!!!

    I have a small query and this is not related to Exchange 2013 its for Exchange 2010, Apologize that I ask this here.. my question is do I need to include my HUB server FQDN on the SSL certificate if I have multiple AD sites and I have both HT and CAS installed on the same server if I missed to have the FQDN of HT in place will there be any issues on the mail flow, some where I read that email between AD sites are encrypted for which TLS is used and Need to have the HT server name in cert.. kindly suggest me on the same.

  19. Ravikumar says

    Paul, Thanks for the reply, I have one more query, recently I installed a SAN certificate that did not contained names of my HT servers on it and assigned the SMTP service in the service bindings and when it asked me to override the default SMTP I clicked Yes and I have multi role servers so Installed this cert on all the boxes (with SMTP binding )which was required for a recent change I done in the environment with respect to CAS, Also I did not remove the self signed cert installed on the box and it still showed SMTP service as assigned . In this scenario will the client receive any security warning for this HT names not being on cert or the email flow will continue to work without issues, still I was confused on this part. Kindly educate me on the same… Thanks a Bunch!!!

  20. Ravikumar says

    One more point to Add I did the binding for IIS which is required and included POP/IMAP and SMTP when performed the Service bindings and over ride the default SMTP when it prompted me as I said above and just want to ensure that will this cause cert warnings on clients or it will work with out issues.. Thanks once again!!

  21. Ravikumar says

    Paul, Got an answer for my Question.. was bit confused over things… As stated in the article the self signed cert binded with SMTP still exist in the servers and things are working as desired, next time when I renew the certs will address the TLS needs with the new SAN

    http://technet.microsoft.com/en-us/library/bb430748.aspx

    Additionally I reviewed one of the Earlier post of our MVP Paul Robichaux where he insists its better to have a 3rd Party Commercial CA installed which address TLS requirements for secure Mail flow sooner or later

    http://windowsitpro.com/exchange-server-2010/use-tls-smtp-secure-your-email

  22. Mikael Ljung says

    Thanks for this great article. It was really useful. Just two names in the cert makes things a lot simpler especially when you want to add CAS servers.
    But, what about exchange 2010 … can I achieve the same thing there?

  23. Jack Cristi says

    Hi Sir Paul,

    Can you please help me? i don’t know where to start. I just want to set up autodiscover in exchange server 2013. Can you give me a step by step procedure on configuring autodiscover? because when i run microsft exchange analyzer all URLs for autodiscover is connection failed. I setup SRV in domain manager, i created host A for autodiscover pointing to public ip address, i created SRV for autodiscover in DNS manager under forward lookup zones and our domain.

    thank you and more power!!!

  24. Mikael Ljung says

    Hi Jack,
    Can you connect internally to all the virtual directories (owa, ews, ecp …)? I guess that autodiscover.yourdomain.com is not included in your SSL certificate since you are trying srv records.
    If this is the case: remove the A record for autodiscover. The srv record will not work if you have an a record or c name for autodiscover.
    The address record should be there only if you have an ssl certificate with autodiscover.yourdomain.com included. In that case there should be no srv record there.
    Also remember that srv records are not supported by androids and iphones.
    Read Paul´s article thoroughly and make sure that all the names that you get from running his powershell commands are in the certificate. If you have problems internally: do remember that the internal domain name that should be used should be the forest root domain …. so if your domain is a .local you will need to create a second web site with owa and ecp virtual directories. Then you need to install a certificate server and issue your own certificate for the internal names.
    Good luck with this!

  25. Mikael Ljung says

    Hi Paul,
    Thanks for all great articles,
    I was wondering about the Round Robin trick of yours; is there a reason why we should use that instead of Windows built-in NLB. Except for two network adapters there shouldn´t be any additional costs, should there? Or, is there another reason why NLB should not be used?

  26. Mikael Ljung says

    Hi Paul,
    Can I run the two cas servers in an nlb cluster instead of having a round robin solution as in your example?

  27. J-W says

    Hi Paul,

    Got me a situation here. I used a wildcard cert for exchange 2013 sp1. Everything works fine externally but internally Outlook 2010 wines about the cert that mailserver.domain.local is not in the cert.
    I don’t understand where this is coming from. All my virtual directory urls (in- and external) are the public urls (we use spit DNS).
    When I look in the Outlook accountsettings the proxy adres looks good https://mail.domain.com

    Any hints? I have red all internet forums by now.

    Thanks in advance.
    J-W

      • J-W says

        It’s weird. Only Outlook 2010 clients (allmost all client pc’s) got this problem.
        I figured out whats the problem. Proberbly there’s something wrong with the Outlook profiles. Our Exchange 2013 server was in co-exist with a 2007 server. NOTHING points to this old server anymore. Oab, mailboxes, etc is on the new server. However, last month I turned the old server off to make sure everything works fine. All the Outlook 2010 clients got really slow until I turned the old server on again.
        That server is stil on. Yesterday I thought: lets change the internal url of autodiscover on that server to the public one. Now Outlook 2010 doesn’t show the “do you trust the cert Yes or No” error. Only at startup “bla bla cannot connect to the proxy server (error 10).
        This is solved when I make new Outlook profile. So proberbly there’s someting corrupted or something and the 2010 clients were also connecting to the old server. Which is strange in my opinion cause there is no A or Cname records that points to that server.
        I hope I can turn the old one off now when I give everyone a new profile.

        Have you ever heard of this before?

        • says

          It absolutely should not be required to recreate everyone’s Outlook profile to resolve this. I would say that the issue is your oldest server has an autodiscover URI configured with the wrong name. You should probably also check your Outlook providers.

    • Mikael Ljung says

      J-W, why, do you think, do your Outlook machines try to connect to the name mailserver.domain.local? You said you are using split DNS which means that your forest root domain has the same name as the smtp domain name domain.com. Did you by any chance rename your AD domain from domain.local to domain.com in the past?

      If your AD domain is domain.local it is not enogugh to create the domain.com domain on the local DNS Server to get a split DNS Exchange Organisation. Domain joined clients will still try to connect to the Service Connection Point using host names in the AD domain and you will have to get a new certifcate containing the internal names.

      • J-W says

        O, I thought this was called split dns:If your AD domain is domain.local it is not enogugh to create the domain.com domain on the local DNS Server to get a split DNS Exchange Organisation.
        We use this.
        New certificate with internal names is not an options because is 2015 it is not allowed anymore to use local names in certificates.

        • Mikael Ljung says

          J-W, Read Paul’s article about certs for .local domains:
          http://exchangeserverpro.com/ssl-requirements-for-exchange-when-certificate-authorities-wont-issue-certificate/

          There is (in my opinion) no need for you to migrate your .local domain to a public one.
          Since you are using TMG the best solution is to create another web site on your cas server and create new virtual dirs. in that one. Enable forms based authentication on this one and use it for internal access. install Certificate Server and request a certificate with the internal names for the internal site.
          The public cert can be tied to the default web site. Export it to the TMG.
          In this way you get a TMG bridge and forms based authentication enabled both internally and externally.
          I always use two web sites on my cas servers to get FBA both internally and externally

        • J-W says

          Hi Mikael Ljung,
          I don’t have plans of going to migrate my .local domain because I know it could work the way it is now.
          Yesterday I inventoried how many Outlook 2010 had this “Error 10″ problem and found out that not everyone on Outlook 2010 has this issue. So for the users who had the problem I recreated the Outlook profile and the problem was gone.

          I only bumped into a other problem discribed in my last post below.

  28. J-W says

    Outlookproviders are looking good msstd:*.domain.com
    AutodiscoverServiceInternalUri is also pointing to mail.domain.com so that looks good to.

    • J-W says

      And may I ask another question? Since I changed both autodiscover URL’s to the public domain, notebook users who also work externally have a problem that the proxyverification switches back from basic to NTLM. Our TMG server doesn’t do NTLM so you cannot login. If I change the setting in Outlook to basic it switches back after a few hours. Do I need to set the internal verification to negotiate?

  29. chanchal says

    Hi,
    I followed the article and now outlook giving the certificate error.

    information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site’s security certificate.

    Please help

  30. Chris says

    Hello

    I have a question about separating exch 2013 certificates for internal and external urls

    I currently transition drom exch2010 to exch2013. I have configured a ssl certificate from an enter CA (internal domain) for all internal sites, owa ecp ews autodiscover etc.

    I have imported the certificate and everything works fine, I can logon to owa internal url and outlook clients are connecting to exch2013 without any cert errors or a when a new outlook profile is created for a exch2013 user mailbox
    so far so good

    Now I want to configure the external exch2013 urls from getting a certificate from a commercial ca.
    This certificate MUST only be used for the external url.

    The internal urls MUST use the already confgured certificate from the local enterprise CA.

    So I configured the external access domain name on servers -> virtual directories and the process completed successfully.
    I then started the cert request on the exch server to submit the new request to get the certificate.
    In the option “Specify the domains you want to be included in your certificate” under option DOMAIN
    I removed the internal urls from all domains and left only the external url to be used with this certificate so as under domain for the internal url set .

    When I get the new certificate and want to complete the pending request, should I enable iis or both iis and smtp?
    for the smtp transport I use the certificate from the doman CA.

    According to this I suppose that this certificate will be only applied to external urls right?

    The same I did for the internal urls getting the certificate from the enterprise ca. I habe set the external urls
    as not specified and left only the internal urls to be used by the certificate from the local ca.

    Your feedback is very appreciated.
    Chris

  31. Chris says

    Thank You Paul

    we have done somthing different. we installed two cas, cas1 will be used only for the external urls and cas2
    will be only used for the internal clients

    so now I am struggling for more than two hours now to configure the autodiscover scp for the internal clients to use the cas2 but the service is connected to cas1

    how can I change this
    I used the follwoing command

    Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like “Version 15*”) -And ($_.ServerRole -Like “*ClientAccess*”)} | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://cas2.dom.local/Autodiscover/Autodiscover.xml

    and when I run the
    [PS] C:\Windows\system32>Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like “Version 15*”) -And ($_.ServerRole -L
    ike “*ClientAccess*”)} | Get-ClientAccessServer | Format-Table Name, AutoDiscoverServiceInternalUri -Auto

    Name AutoDiscoverServiceInternalUri
    —- ——————————
    CAS1 https://CAS2.dom.local/Autodiscover/Autodiscover.xml
    CAS2 https://CAS2.dom.local/Autodiscover/Autodiscover.xml

    but the outlook client wants to connect to cas1

    how I can change it to connect to cas2

    Thanks alot for your feedback

  32. Chris says

    because the urls for external access are not the same as internal.
    internal we use servername fqdn,cas2.dom.local and external url mail.etc…
    one can not interna server fqdn names for commercial certificates and we must keep separate urls
    for external owa and internal owa

    is the process I have described before to configure the internal autodiscover scp url to the second cas server
    or do I have to do something else?

    I have read it in exchange deployment assistent

    my problem will be resolved if I get to configure the autodiscover service to only the cas

    I know you see that as a complex senario but I really have no other way to implement it.

    that is why I asked you those few questions.

    I really appriciate your feedback

    • says

      But you aren’t locked in to that solution are you? You can change the internal URLs to anything you like, they don’t need to match the server FQDN or even the internal domain FQDN. It is even quite common to use split DNS and have matching internal + external URLs.

      Autodiscover is just one part of the picture too. Autodiscover tells the client the URLs for other services like Exchange Web Services, Outlook Anywhere.

      If you’re dead set on this internal vs external split I would suggest moving the internet-facing CAS into a separate site and using Autodiscover Site Affinity to control where clients get their Autodiscover information from.

      Another option is to put a reverse proxy in front of Exchange that can handle the public facing SSL connectivity with just the public names on the cert, then you can still use your own CA to provision the cert for Exchange that has both internal and external names on it.

      • vadim says

        Is not the Site Affinity option depreciated for Exchange 2013? It looks like due to certain ‘decoupling’ of CAS and Mailbox servers it would not work the same way as in 2010, if at all.

        • vadim says

          Yes, I guess so. I really need the feature to be able to associate users in one area with their closest mailboxes servers. But googling for Site affinity only brings articles related to Exchange2010. Considering the change of client access architecture in 2013 I have concerns if the feature still works or if changes in functionality change its meaning.
          And I don’t see any other way to enforce users, say, in Atlanta to connect to Atlanta site instead of, say, to NewYork site while both sites are healthy and still have the site redundancy (for cases when one of the sites is down).

        • says

          If you want to control which users go to specific sites *and* have site redundancy for that namespace then you’ll need to deploy geo-DNS and/or geo-load balancing.

          More complex. More expensive.

          If the bandwidth is sufficient between Atlanta and New York to be doing site redundancy anyway (ie stretching a DAG across those sites) then why does it matter who connects where?

          Simpler. Less expensive.

  33. Randy says

    I have setup my main Internet-facing site with one namespace for both internal and external urls.

    My question is on my remote non-internet-facing sites that have Exchange servers:

    Do I set the Internal URLs to the local server names ( I want local clients to connect to that server in their site)
    or
    do I set the Internal URLs to the single name space which DNS resolves to the Exchange servers in the main site (via a F5 with main site servers only configured). If I do this then all the traffic will be going across the WAN.

    • says

      If you want to guarantee clients connect to that local server then you’ll need to plan namespaces for that site.

      I don’t recommend leaving them as the server FQDN.

      An example might be:

      – primary site uses namespaces mail.domain.com and autodiscover.domain.com
      – secondary site uses namespaces mail-sydney.domain.com and autodiscover-sydney.domain.com

    • says

      Problematic if you’re using different auth schemes for the internal and external URLs. The same namespace means the client will always use the internalURL settings (including the auth settings), which may fail if the externalURL auth settings are different.

      So the solution is to use a different external OA namespace if you have different internal/external auth requirements. This doesn’t prevent you from using split DNS though. The two namespaces can still be in the same domain (eg outlook.domain.com and outlookex.domain.com).

      As Ross says, the end users don’t need to worry about two namespaces because Outlook is configured automatically for them via Autodiscover anyway.

  34. vadim says

    In the article you run ‘Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://mail.exchange2013demo.com/Autodiscover/Autodiscover.xml‘ to set autodiscover service point to ‘mail.exchange2013demo…. ‘ But on certificate you say you add ‘autodiscover.exchange2013demo.com’. Is it mistyping? Could you please clarify how would it work, whats the meaning? Should not name on certificate match what you set up as autodiscover (or any other service, for the matter) for internal and externtal uri?

    Thanks

    P.S. Besides – that would make it two names, not one, on the certificate, which implies buying SAN certificate, anyway. Since it seems usually SANs certificates are incrementing in set packs (minimum to my knowledge is 5 names) it makes it kind of a mute point – if you get 5 names cert then you have enough names not to worry about minimizing them, that should be enough for most cases, right?

    • says

      Some non-domain clients (such as smartphones) will automatically search for autodiscover.domain.com when trying to find the Autodiscover service. So it pays to add that record to DNS, and include it on the SSL cert as well.

      • vadim says

        That makes sense, understandable.
        But then is it really important to what AutoDscoverServiceUtnernalUri is pointing to for Autodiscover service to work properly? Any website is capable of binding multiple host names to the same IP (and after all all the Exchange services access points are web based).
        That is it seems that Autodiscover.domain.com web access point will work regardless of what is set up with set-clientaccessServer applet. Is it not the case?
        In fact, should not other client access points (like OWA or OA) respond to more than one name if you bind IIS corresponding sites to more than one name, as well?

        • says

          What you set the internal URI to is up to you. It can be any name you like. Domain joined clients look up that name in Active Directory.

          Non-domain joined clients can’t look it up in Active Directory, so they will try autodiscover.domain.com (as well as domain.com).

  35. Len says

    Hi Paul, after executing the command to change AutoDiscoverServiceInternalUri from server name to public (https://mail.mydomain.com/Autodiscover/Autodiscover.xml) I am getting authentication prompt as i open outlook 2013. So i had to change autodiscover back from public name to the exchange server name. Now i can open outlook without it being prompting for password but i am back to the certificate error prompt. This is some kind of infinite loop… Please advise Thank you

    • says

      It really depends on how all your other namespaces are configured. I assume changing the autodiscover URI got you past that hurdle but the next thing Outlook tried to connect to wasn’t configured correctly.

      You really need to review your entire set of namespaces, your certificate, your DNS (ie where the namespaces resolve to) and the auth settings configure for services like Outlook Anywhere.

      Also it depends if you’re in a co-existence with a 2007/2010 server. The auth settings on the legacy server for Outlook Anywhere need to be correct in a co-existence otherwise endless auth prompts appear as Outlook tries to connect to legacy resources like shared mailboxes or public folders.

  36. geddyleefan says

    Thanks for the article. I’m finally getting to upgrade to 2013 from 2007. I went through all this, exported my cert from the 2013 server and imported it to a 2007 CAS, and Outlook started throwing errors because server.domain.local was not listed in the cert. After some further digging, I fixed with Set-UMVirtualDirectory because one of my CAS boxes has a local server name there, even though we don’t use UM or have it installed on any of our servers. Hope that helps someone else who might run into the same issue.

  37. Jorge says

    Hi,

    One quick question: If you are using mail.exchange2013demo.com for all services (OWA, ECP, Active Sync etc), including AutoDiscover, to where should autodiscover.exchange2013demo.com point to?

  38. wagdi says

    I want to use split DNS to avoid adding server name to SAN certificate .my question is :
    after creation of forward lookup zone called mail.ab.com, what kinds of records must be create inside this forward lookup zone? is it only A record? . Is MX and CNAME records are necessary to be created in my private DNS server ?. and is it necessary to create this new forward lookup zone or I can add these records to the existing zone of my domin ?

    thanks for your patience and cooperation

  39. Vic says

    Hi Paul,

    I’m migrating a small business from Ex2010 to EX2013. The 2010 server is configured to use local URLs for internal access. I want to set 2013 to use external URLs for all queries and I have added a public zone in my internal DNS to point mail.domain.com to the server’s internal IP. Three questions:
    1) Will there be issues during the migration as the outlook clients switch to the new server?
    2) My current SAN Certificate lists internal and external names for autodiscover and mail as well as the 2010 server name. If all I will need for the new server is the mail.domain.com and autodiscover.domain.com names listed on the SAN cert, can I export the existing cert out of 2010 and import into 2013?
    3) If ok to use the existing cert, what is the general order of migration tasks regarding the cert? Configure the new server, move the mailboxes, change DNS to point to the new IP and then do the cert?

    I appreciate your willingness to answer questions and thank you for the help

  40. Vic says

    So I did the migration and here is what I figured out. The Exchange server deployment Assistant will lead you to success. Exporting a certificate is a copy, not a move. Yes, if you configure for all external access to the virtual directories, you can use a cert that listed the internal name of the old server on your new 2013 server. 2013 exchange connecting to outlook clients in cached mode may ask for authentication because of a public folder query that times out. You can work around the issue with a registry tweak or disable cached mode. (http://blogs.technet.com/b/johnmak/archive/2012/03/26/how-to-stop-outlook-from-using-public-folders.aspx)
    Most questions are answered somewhere in the exchangeserverpro site.

  41. wagdi says

    Dear Paul
    * I installed exchange 2013 on win 2012.
    * my SAN certificate is assign to only IIS & SMTP services
    * Outlook Anywhere configured external and internal host name are the same and the Allow SSL offloading check box is unchecked.
    * Internal and external URL for OWA virtual directory is configured as https://mail.ad.com/owa ( this name is exist in SSL certificate )
    * I can access owa from internal network , but when I try to access it from out side I faced the message says Internet Explorer cannot display the webpage.

    your help is greatly appreciated

  42. Charlie says

    Hi Paul,

    Just want to confirm…

    webmail.domainname.com > all web services
    autodiscover.domainname.com > autodiscover

    do any of the fqdn’s specified on any of the receive connectors (internet or application) or fqdn on the send connector need to be specified on the SSL cert? What would you normally set for a fqdn on your send connector?

    Thanks,

    • says

      You can add SMTP namespace(s) to the same cert, or a different cert. SMTP is enabled separately to IIS, so it can be the same cert or a different cert.

      The second connector FQDN should resolve in DNS and also ideally match the reverse DNS lookup for the public IP address.

      • Charlie says

        Thanks Paul.

        In Exchange 2013, the CAS/MBX roles are combined and setup is as follows:

        Default Frontend Receive Connector
        FQDN = ServerName
        SMTP Banner = mail.domainname.com

        Send Connector
        FQDN – mail.domainname.com

        mail.domainname.com resolves in DNS and reverse lookup works fine.

        SSL certificate has the following san names:
        webmail.domainname.com
        autodiscover.domainname.com

        Question: Is mail.domainname.com required on the SSL certificate for successful mail flow?

        Thank you for your time, much appreciated.

        • says

          If you do nothing with the SMTP certificate everything will work fine. If you add SMTP aliases to a certificate and enable that certificate for SMTP you are enabling the use of TLS to encrypt mail in transit (this already happens within your org).

          http://windowsitpro.com/exchange-server-2010/use-tls-smtp-secure-your-email

          So not required, but as Paul says at the end of the article: “Because this is such a simple change to make, and because it provides an immediate privacy benefit, I encourage you to do it sooner rather than later. There’s no downside.”

        • Charlie says

          Thanks heaps Paul.

          So with that in mind, if we leave the self signed SSL certificate assigned to SMTP and our receive/send connectors are either $null or using the server FQDN, then all email, both internal and external, will be sent using TLS (if selected) and mail flow will work as normal? However, if we wish to use a custom alias then we will need a 3rd party cert with that alias on it

  43. Wagdi says

    Thanks for your interest Paul
    please tell me more about this and what I need to do
    ((Have you added a DNS record to your public DNS zone for the OWA name?))
    what kind of records I need to add If my OWA name is https://mail.ab.com/owa?

    regards

    • says

      In your ab.com DNS zone you would add an A record for “mail” that points to the public IP address of your Exchange server (ie, the IP on your firewall or router that NATs to your Exchange server).

  44. Richard Lane says

    Hi Paul,

    Great article thanks for the write up.

    I’ve followed your guide using split DNS so we don’t need internal certs..

    I have the CN of:

    mail.domain.com (outlook anywhere, webmail, exchange control panel, exchange web services, offline address book)

    and the SAN CNs of:

    autodiscover.domain.com (auto discover)
    async.domain.com (exchange active sync)
    autodiscover.domain2.com (auto discover)
    autodiscover.subdomain.domain.com (auto discover)

    for some reason the CSR file generated wants to include

    domain.com

    I don’t think I need this though. Would you see a reason for having the certificate cover the base domain?

    Cheers

    Rich

    • says

      Some clients (like Outlook) do a domain lookup as part of the Autodiscover process. It’s silly, since almost nobody points their domain name at their Exchange servers, usually it is pointing at a web server hosting a website. This behaviour will probably be changed in later versions of Outlook as it is the source of some frustrating issues that need workarounds put in.

      There’s no harm in including it. I do, just to be sure.

Leave a Reply

Your email address will not be published. Required fields are marked *