Home / server / Questions / 397056
Accepted
Bryan
Asked: 2012-06-09 12:35:03 +0800 CST

Exchange 2010 Internal Auto Discover Migrate away from current .local DNS name

  • 772

We have an Exchange 2010 Server, running within our Active Directory domain, with an internal hostname of server.example.local.

The server is configured for Exchange anywhere, but currently has a self signed certificate with a name of server.example.local installed.

Internally, clients connect and work fine, but externally, we are having certificate errors as you would expect.

I'm about to purchase a UCC SSL Certificate to install on the server with all the relevant SANs on the certificate to correct this, but due to obvious problem obtaining a trusted cert with .local as a subject alternative name, I'm looking to configure clients on the internal network so that they don't use any reference to the .local hostname.

I've configured our external DNS name for the server as exchange.example.com, and have created an CNAME for autodiscover.example.com which also (correctly) points to exchange.example.com. I've also configured internal DNS records for these two hostnames which point to the internal interface of the same server. I don't anticipate any problems here.

I'm now trying to reconfigure Auto Discover internally, so that Outlook attempts to connect to exchange.example.com. I've followed the steps in KB940726 to prepare for this, and this appeared to work fine. No errors were generated and I was able to verify the CAS name in AD using ADSI edit.

I've just tried testing this with a newly created test user account complete with a new Exchange mailbox, and Outlook 2007 connects fine on the internal network, but looking deeper in the Exchange profile, Outlook is still resolving the server name as server.example.local.

Could it be the self signed cert, that is causing Outlook to display the server name as server.example.local, or is there still something wrong with my internal autodiscover configuration?

Edit

I've proven it isn't the certificate that is responsible for outlook returning server.example.local, by installing another self certified certificate with a name of test.example.com. When creating a new outlook profile, I get the mismatch error I'm expceting, but after accepting the cert, and finishing the config of the Outlook profile, again it still shows server.example.local as the server name. This means that if I were to purchase the UCC cert now, that external client would work fine, but internal clients would show a certificate name mismatch.

Any ideas where to start diagnosing this?

domain-name-system active-directory exchange-2010 ssl-certificate autodiscovery

1 Answers

  1. Best Answer

    I believe I've managed to fix this using ADSI edit.

    Despite me running the commands in the KB article I linked in my question, I found two autodiscover entries using ADSI edit.

    • CN=exchange.example.com
    • CN=server

    I've deleted the CN=server entry, and had to make a modify the serviceBindingInformation property of the object CN=exchange.example.com to reflect the correct external URL.

    Now when I set up a new exchange profile, or open outlook for an existing user, I get a certificate name mismatch error. This is expected though, as my certificate is still the self signed cert which only has the name server.example.local. I can clearly see now though that the internal clients are looking for the name exchange.example.com on the certificate.

    I'm going to order the UCC certificate now, with correct SAN names of exchange.example.com and autodiscover.example.com, which I believe will now leave me with a working system.

    Update

    I've now ordered and installed a trusted certificate with a name of exchange.example.com, plus a SAN of autodiscover.example.com, and I can report that outlook anywhere is working great in the following scenarios

    • internally on the example.local corporate network with domain connected PCs.
    • externally with roaming domain connected laptops
    • externally with mobile devices (iPhones & iPads)
    • externally with non domain connected PCs.
    • OWA no longer gives SSL errors.
    • 2