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.

I have a Windows 2008 Standard server running Exchange 2010 that is hosting OWA. Internal Outlook 2007 clients connect to the primary IP via SSL, which is bound in IIS using the self-signed certificate Exchange creates on its own as exchange.mycompany.local.

In order to publish OWA to the outside world, I have a SonicWall firewall configured to forward HTTPS inquiries to a second IP address via SSL, also bound in IIS, but using a commercial certificate as mail.mycompany.com. This is necessary, of course, because you can't use host headers on SSL.

This second IP address exists on a second NIC in the server, it only has IPv4 bound to it, and the option to auto-register in the DNS is deselected. Nevertheless, every few hours, internal Outlook clients get that certificate error because that second IP address shows up in the DNS. I've been manually deleting the A record as it shows up, but nothing I've done has been able to keep it from coming back.

Any suggestions on how I can make this work? Unfortunately, the "proper" setup of separating the internal and external OWA sites isn't feasible right now.

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

You're seeing something that feels like the as-designed behaviour of the Microsoft DNS Server. By default, the DNS Server itself registers A records for all addresses the server listens for requests on. I'm wondering if this Exchange Server computer also happens to be a DNS server.

If I'm right, and assuming you're not using the second NIC's IP address as a DNS server IP address on any clients, open the DNS Management snap-in, go to the "Properties" on the server, go to the "Interfaces" tab, and choose to listen only on the IP addresses that you want "A" records registered for. Delete the unneeded "A" record and you'll find that it no longer comes back.

share|improve this answer
    
Evan, your suggestion makes perfect sense...I did a workaround before leaving the office yesterday and as a result I can't test your suggestion. I will test it tomorrow and I'll flag this answered if it works. –  Josh Jan 10 '10 at 14:59
    
This seems to have worked perfectly. I had worked around by setting up a dummy zone in the DNS for our public domain which allowed the certificate errors to go away with Outlook, but that had the nasty side effect of preventing anyone from resolving any hostnames that I didn't explicitly set up in that dummy zone. Your suggestion resolves the cert error internally and still lets me use the public cert externally. Thanks a million. –  Josh Jan 11 '10 at 15:09
add comment

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.