Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
at first blush, it looks ok. Would the outlook client simply be resolving the name of the server to the internal IP and then subbing in the DNS entry in its place? for instance, if you ping the IP of the internal server, what does the windows client think the name of the machine is? –  MikeAWood Jun 8 '12 at 20:42
    
I don't believe it is getting it from DNS, as internally exchange.example.com is an A record pointing to the same IP that server.example.local points to. There is no reverse DNS record for the IP address either. nslookup exchange.example.com (or ping) doesn't resolve the name to server.example.local. –  Bryan Jun 8 '12 at 20:51
    
if the machine is registering with DNS, then it will resolve to the host name. try "ping -a <ip>" and see what it says. –  MikeAWood Jun 8 '12 at 20:59
    
Yes, that resolves to server, no mention of example.local, but I guess that could be implied. –  Bryan Jun 8 '12 at 21:02
    
I think its just a side effect of the way Windows DNS works. But I know your focus was on the external resolution for autodiscovery. Did you add the autodiscover.domain.com to you SANs as well as an A/CNAME record for that to your external DNS? –  MikeAWood Jun 8 '12 at 21:04

1 Answer 1

up vote 1 down vote accepted

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.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.