Outlook 2007 can now use DNS SRV records to find the location of the Exchange Autodiscover Service


EDIT 10/4/2007: Since this post has been published, we have updated the Exchange 2007 Autodiscover Service whitepaper to include this information. Please consult the whitepaper for most up-to-date information.


Previously customers who wanted to deploy Autodiscover for Internet clients had to use one of three methods:





















Method



Pros



Cons



1 SSL Certificate that is valid for multiple DNS names (or Subject Alternative Names)



– Simple configuration



– Requires only one Certificate.



– Requires only 1 website and 1 public IP.



– Cost of additional DNS names for SSL Certificates can be more expensive.



2 single-name SSL Certificates (one specifically for autodiscover).



– 2 single-name certificates may be less costly than a certificate with multiple names.



– Complex configuration. 



– Requires 2 websites and 2 Public IP’s.



– Difficult to load balance 2 sites.



1 single-name SSL Certificate with a second HTTP redirection website.



– Only requires 1 single-name SSL certificate.




 



– Complex configuration. 



– Requires 2 websites and 2 Public IP’s.



– Difficult to load balance 2 sites.



– Additional dialog is displayed to the Outlook users asking if they trust the redirected URL.




 



For a few customer groups (primarily very small customers and hosters), these methods provided a less than perfect solution. Many of our smallest customers can’t afford the additional cost that certificates with multiple names can incur nor do they have 2 public IP addresses available to dedicate to Autodiscover. Many of our larger hosting organizations don’t want to deal with the complexities of load-balancing multiple web sites or incur the cost associated with Certificates with multiple names for every company they host.


This new method of location Autodiscover using DNS Service Location (SRV) records satisfies both of these requirements.













Method



Pros



Cons



1 single-name SSL Certificate with DNS SRV Lookup.



– Simple configuration



– Requires only 1 website and 1 public IP.



– Only requires 1 single-name SSL certificate



– Not all DNS hosting providers support DNS SRV records.



– Additional dialog is displayed to the Outlook users asking if they trust the redirected URL.



– Requires Outlook 2007 client-side hotfix.




 



To obtain this feature, you must apply Outlook 2007 Hotfix KB 939184. This feature is also scheduled to be included in Outlook 2007 Service Pack 1. For more information on how to implement this feature see KB 940881.


Brad Hughes

Comments (35)
  1. yotu says:

    yep…how can i download the hotfix?

  2. Flemming Riis says:

    Yotu , you should be able to get the hotfix from

    https://support.microsoft.com/contactus2/emailcontact.aspx?scid=sw;en;1410&WS=hotfix

    tried now so we see if it shows up.

  3. AdamX says:

    Hi Brad,

    After I installed one single-name SSL certificate with common name e.g. "mail.contoso.com" on a CAS server, I start to see Outlook 2007 clients within the intranet receiving "security alert" saying "The name on the security certificate is invalid or does not match the name of the site". The Outlook 2007 clients are looking for e.g. "autodiscover.contoso.com" and "cas01.contoso.com". I want to avoid such security alerts. I understand the certificate that supports Subject Alternative Name is an option. But as you mentioned, it can be expensive for some customers. I want to know if there is any way to avoid such security alert for intranet Outlook client by using one single-name certificate installed on one web site (the Default Web Site) of the CAS server.

    Thanks,

    Adam

  4. Elan Shudnow says:

    Adam,

    This occurs because since you are using a new cert, you have to make the InternalURL URLs match the CN of the certificate.

    Read here for more information:

    http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/

    Hope this helps,

    Elan

  5. AdamX says:

    Elan,

    I have updated all the internal URLs on all the necessary virtual directories, including Autodiscover, EWS, OAB, OWA, etc. But the Outlook 2007 clients still get the security alert. On the top of the security alert pop-up, it looks for i.e. "cas01.contoso.com" and "autodiscover.contoso.com". These names are different from common name of the certificate i.e. "mail.contoso.com". I guess that’s why I still see the security alert. Is there something I missed?

    Thanks,

    Adam

  6. DarrenE says:

    Would this hotfix mean that DNS SRV records could also be used internally for load balancing/resiliance of the CAS’s, rather than using a hardware load balancer?

  7. Brad Hughes says:

    Elan – The most comment missed URL is probably getting you.  Check to see if your autodiscover SCP is set incorrectly.  By default it is set to the server FQDN and once you replace your default certificate with a 3rd party (single-name) cert, you will need to modify it.  Get-ClientAccessServer | fl AutodiscoverServiceInternalURI.  This URL is only used for domain joined clients.  For Non-domain clients you can use the SRV lookup method mentioned in the post (that also involves removing any CNAME or A records for autodiscover.<smtpdomain>, so make sure you’ve also done that).

  8. Elan Shudnow says:

    Brad: I’m not the one having an issue.  Also, if you were referring to my article, the AutodiscoverInternalURI URL is actually specified in my article.

    Adam: One thing I would try is doing enabling the new certificate for services.  I also show how to do this on that article I linked to earlier.

  9. Brad Hughes says:

    Sorry Elan,

    I did mean that for AdamX.  If he is getting a cert warning from cas01.contoso.com (which I assume means the machine name), then some of his URLs have to still be wrong in AD.  I was just trying to point out ones he might have Missed.

    Brad

  10. DarrenE says:

    DarrenE,

    This doesn’t provide any load-balancing functionality whatsoever.  ISA 06, Windows NLB, or Hardware NLB should still be used for all servers in the same site.  This method simply provides an advantage to the HTTP redirect method because it only requires one web site and therefore you don’t have to worry about load-balancing two of them.

    Brad

  11. AdamX says:

    Brad and Elan,

    Thanks for the helpful thought. I checked AutodiscoverServiceInternalURI and all the URLs and found them correctly set to use i.e. "mail.contoso.com". Then, I realized there was no DNS entry for it yet. After I added a host record for i.e. "mail.contoso.com", Outlook clients stops showing that security alerts. I tried with restarting Outlook client, send/receive, download OAB, check availability, etc. All seem work well now.

    One more question for you guys. If I have multiple sites, and use the same certificate for CAS servers at different sites, I will need to add one DNS entry i.e. "mail.contoso.com" for each of CAS servers, right? If I do this, will the DNS round robin cause problem when clients accessing the CAS services? What I don’t want to see happen is clients in one site are pointed to CAS servers in other remote sites, or it causes lots of proxying between the CAS servers. Is there a built-in mechanism that will limit the internal clients to access their local CAS servers in this case? I’d like to hear your thoughts on this.

    Thanks,

    Adam

  12. Brad Hughes says:

    AdamX,

    You should not use the same certificate/url for servers in multiple sites.  As a general rule, you should consider that you have 1 URL per-site.  If you have multiple CAS’s in an Internet-facing site, you should load-balance them.  If the second site will be Internet-facing (meaning you will have a separate URL entry-point) then you should get a second SSL certificate for the separate URL.  If it will be non-internet facing, you will be quite alright to simply leave the default URL’s and self-signed certificate in place.  Information similar to this is covered in a blog post on my site (http://blogs.msdn.com/brad_hughes/archive/2007/09/10/cas-load-balancing-certificates-autodiscover-and-webservices.aspx)

    Hope this helps,

    Brad

  13. ross says:

    so I’m having this wierd problem where autodiscover works on my PC, but no one else’s.  On my PC I can see free/busy info no problem.  On each PC I try it on, other than mine, it immediately gives the slashes for free/busy.  But, If I try the "test autoconfiguration"
    thing, it always works foreach PC, finding
    https://autodiscover.company.com/autodiscover/autodiscover.xml correctly.  Its as if outlook is set up wrong or something, but I have no idea how that could be.  Any ideas?

  14. AdamX says:

    Brad,

    You well answered my question. Very informative. Thanks!
    Now, I have "restored" the self-assigned certificate to the CAS server that resides in a non-internet facing site. But the Outlook 2007 clients in that site starts to see security alert again, but a different one. "X The security certificate was issued by a
    company you have not chosen to trust…" This only happens after clicking the Scheduling Assistant to look up free/busy information of another user. And it only happens for the first time checking free/busy after Outlook 2007 is launched. Subsequent checking
    free/busy will not trigger such security alert. To reproduce the alert, I have to re-launch the Outlook client. I have tested this on two different computers. Both got the same issue. The interesting thing is answering Yes or No at the security alert does
    not seem to affect setting up and sending out the meeting request at all. Also, the Outlook clients have no problem doing send/receive, downloading OAB. None of these tasks would trigger that security alert. New Outlook clients in that site can also be automatically
    configured.

    I also checked all the internal URLs, including the EWS, to ensure they are using the host name of that CAS server, such as

    https://cas01.contoso.com/ews/exchange.asmx

    I wonder if I have missed something after I put the self-assigned certificate back. Or, is it expected for the Outlook 2007 client to see that security alert in that "unique situation", when using self-assigned certificate?

    Thanks,
    Adam

  15. AdamX says:

    Brad,
    You well answered my question. Very informative. Thanks!
    Now, I have "restored" the self-assigned certificate to the CAS server that resides in a non-internet facing site. But the Outlook 2007 clients in that site starts to see security alert again, but a different one. "X The security certificate was issued by a
    company you have not chosen to trust…" This only happens after clicking the Scheduling Assistant to look up free/busy information of another user. And it only happens for the first time checking free/busy after Outlook 2007 is launched. Subsequent checking
    free/busy will not trigger such security alert. To reproduce the alert, I have to re-launch the Outlook client. I have tested this on two different computers. Both got the same issue. The interesting thing is answering Yes or No at the security alert does
    not seem to affect setting up and sending out the meeting request at all. Also, the Outlook clients have no problem doing send/receive, downloading OAB. None of these tasks would trigger that security alert. New Outlook clients in that site can also be automatically
    configured.
    I also checked all the internal URLs, including the EWS, to ensure they are using the host name of that CAS server, such as

    https://cas01.contoso.com/ews/exchange.asmx
    I wonder if I have missed something after I put the self-assigned certificate back. Or, is it expected for the Outlook 2007 client to see that security alert in that "unique situation", when using self-assigned certificate?

    Thanks,
    Adam

  16. AdamX says:

    Brad,

    You well answered my question. Very informative. Thanks!

    Adam

  17. AdamX says:

    Brad,

    This comments area seems to have a limit. So, let me post my question in two parts.

    – Part One –

    Now, I have "restored" the self-assigned certificate to the CAS server that resides in a non-internet facing site. But the Outlook 2007 clients in that site starts to see security alert again, but a different one. "X The security certificate was issued by a company you have not chosen to trust…" This only happens after clicking the Scheduling Assistant to look up free/busy information of another user. And it only happens for the first time checking free/busy after Outlook 2007 is launched. Subsequent checking free/busy will not trigger such security alert. To reproduce the alert, I have to re-launch the Outlook client. I have tested this on two different computers. Both got the same issue. The interesting thing is answering Yes or No at the security alert does not seem to affect setting up and sending out the meeting request at all.

    Adam

  18. AdamX says:

    – Part Two –
    Also, the Outlook clients have no problem doing send/receive, downloading OAB. None of these tasks would trigger that security alert. New Outlook clients in that site can also be automatically configured.

    I also checked all the internal URLs, including the EWS, to ensure they are using the host name of that CAS server, such as

    https://cas01.contoso.com/ews/exchange.asmx
    I wonder if I have missed something after I put the self-assigned certificate back. Or, is it expected for the Outlook 2007 client to see that security alert in that "unique situation", when using self-assigned certificate?

    Thanks,
    Adam

  19. Elan Shudnow says:

    Adam,

    Did you do the whole:
    Get-ExchangeCertificate
    Enable-exchangecertificate -services serviceshere

    I’m assuming there’s an A record for that server?

    I’m also assuming the AutodiscoverURI is set for that server to be:
    https://cas01.contoso.com/Autodiscover/Autodiscover.xml

    Make sure that in IIS on cas01, that these services are using SSL and the InternalURLs are also set to SSL.

  20. AdamX says:

    Elan,

    I did not do the Get-ExchangeCertificate and Enable-ExchangeCertificate commands. But I did the "old" way on IIS, by importing the certificate (.pfx). Are the two commands supposed to make any difference from the standard IIS certificate import?

    I just ran the two commands above on tha CAS server anyway. And I confirmed the AutodiscoverURI value is set correctly. But I did not notice any difference they made. I even rebooted the CAS server, as well as the Outlook client, but still got the same security alert at the same spot. Please note that this security alert is not the same as what I got when those URLs were not set correctly. It is about not trusting the self-assigned cert on that CAS server. Is there anything else I should look into?

    Thanks for your time!

    Adam

  21. AdamX says:

    Forgot to add this. I confirmed all those services are using SSL in IIS. And I use the Get-… command to verify all of them are using https, except for the OAB which does not work with https when using self-assigned certificate.

    Adam

  22. Brad Hughes says:

    AdamX,

    I may know what you’re hitting here.  When exactly are you seeing the prompt?

    – On Launch

    – Using OOF

    – Using Availability

    Thanks,

    Brad

  23. Brad Hughes says:

    AdamX,

    Nevermind, I see your answer "This only happens after clicking the Scheduling Assistant to look up free/busy information of another user".

    I believe I know what this issue is.  Can you open a support case on this?

    Brad

  24. AdamX says:

    Brad,

    Let me know how I should open a support case and get to work with you?

    I also tried to download the update rollup for Outlook 2007, but it is currently not available somehow. I went to

    https://support.microsoft.com/contactus2/emailcontact.aspx?scid=sw;en;1410&WS=hotfix to submit my request. Then, I received this in email.

    "Currently the hotfix described in 939184, x64 platform (Description of the update rollup for Outlook 2007: June 27, 2007) is unavailable."

    Are you able to provide me a timeline of when this update will become available?

    Thanks,
    Adam

  25. AdamX says:

    Brad,

    FYI. I received the hotfix, after I indicated I need one for x86 platform…

    Adam

  26. AdamX says:

    Brad / Elan,

    This DNS SRV method works pretty well for autodiscover, as I have just tested. I’m glad you guys made it available.

    Thanks,

    Adam

  27. Dennis says:

    Brad,

    We’ve deployed autodiscover using the DNS SRV records as described in this article.  An interesting question has come up about the associated hotfix.  Have you encountered this, or do you know the answer?  

    After you install the hotfix, the first time your not connected to the local LAN, outlook prompts you to accept redirection to get the settings from autodiscover.xml.  We’ve instructed our users to check the box (don’t ask me about this website again) and click accept.  So the question is:  What if a user check’s the box (don’t ask me about this website again) and clicks cancel?

    Thanks,

    Dennis

  28. Brad Hughes says:

    AdamX,

    Can you email me offline? We’ll work together on how to get a case opened for this issue.  

    Thanks,

    Brad <Brad.Hughes@microsoft.com>

  29. Ruddy says:

    I am having one issue with this. Do any of you know the proper syntax to enter the proper SRV record on a UNIX server DNS zone?

    Our domain joined clients.  are using Windows DNS servers (DCs), but our Non-domain clients are using external DNS servers using UNIX.

  30. xrionx says:

    To Anyone that can help (sorry if this is the second time reading this I’ve posted elsewhere):

    I have Exchange 2007 running on Server 2003 R2 x64 edition trying to get Outlook Anywhere to work. I am trying to connect to it externally on a pc that is running Outlook 2007 on Vista Ultimate.

    I am getting an error when connecting that says ""Outlook cannot log on. Verify you are connected to the network and using the proper server and mailbox name. The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action" when trying to connect. The funny this is I can use the repair feature in Outlook 2007 Account properties and I get all the green checks when it checks the connection and it even prompts me to allow the redirection to the autodiscover service. But when I open Outlook it will give me the above message again.

    So here are the steps I took:

    I used the method described in the new white papers scenario 2 (Outlook 2007 can now use DNS SRV records to find the location of the Exchange Autodiscover Service).  I purchase a single-named certificate from go daddy and made it x64server.<domain>.com and followed all the instructions listed in scenario 2. I also removed the ssl from the owa site under default websites because we have users using owa.<domain>.com/owa and they were getting errors from the cert because it did not match.

    Please let me know what additional information I can provide to get any help with this, I would really appreciate. This is absolutely driving me crazy, one would think it would be an easier process.

    Ryan

  31. Richard Butler says:

    Hi all,

    Wondering if anyone would be prepared to help me with an issue we are having. We are a subsiduary of a larger company who has an e-mail domain of "company.com" (not real obviously). Our e-mail domain is "subsiduary.com". We have our own separate AD domain and Exchange 2007 server and all our users are configured with a primary (reply) address of user@company.com and secondary addresses of user@subsiduary.com. Any e-mail sent to us are sent to the company.com mail servers and then forwarded on to our subsiduary.com addresses. If we reply to e-mails they are stamped with user@company.com. All users have Outlook 2007. We have a Thawte certificate installed on the Exchange 2007 server which is registered for http://www.portal.com (not real again), this certificate is also used for many other uses and my boss has told me he doesn’t want to buy another one. I have set up all the virtual directories both internal and external to point to http://www.portal.com and created the necessary DNS entries to resolve these to the CAS server. I’ve also set the internal URI on the CAS (why can’t we set an external one in the same way rather than letting Outlook generate it’s own?), and I’ve enabled the certificate for the services required.

    The issue we are having is that our users keep getting certificate prompts, especially when they are on the outside of our network. It would appear Outlook is trying to resolve the autodiscovery URL to addresses involving company.com, unfortunately, I am not able to add DNS entries for our server to these DNS zones as we do not own them and the parent company has said no way.

    Is there anyway of changing the way Outlook handles autodiscovery and specifying what domain should be used in the autodiscovery process. Or, does anyone have any other ideas how we might get round this problem?

    I tried logging a support call with Microsoft in Australia, but they were not interested since we run our environment on VMware ESX Servers. Yes, I know it is not supported but this issue is hardly caused by the Virtual Infrastructure, plus we can’t be the only people in the world who work in this way.

    I am finding autodiscover a real step back from Exchange 2003 which just worked perfectly without any hassle.

    Any assistance would be greatly appreciated.

    Regards,

    Richard

  32. Brad Hughes says:

    Hi Richard,

    Only one comment on the VMWare part of this.  You say: "plus we can’t be the only people in the world who work in this way"

    I will tell you from my experience that I have seen several customers attempt to use VMWare to virtualize Exchange 2007. Every one I have talked to ran into performance problems that resulted in a largely unsuccessful deployment.  Exchange 2007 is demanding enough on physical hardware;  when you try to virtualize it, you are simply imposing additional bottlenecks.

    That aside, to your issue:

    To implement autodiscover you MUST have access to the external DNS zone that your users use for a primary SMTP address.  You also needed to have access to this zone to receive inbound SMTP mail in the first place (MX record).  You need to work within your oganization to get the necessary records added to that zone – OR – change the users primary smtp addresses.

    To avoid having to aquire a new certificate, you can certainly use this DNS SRV record deployment technique but you will need to be able to add the _autodiscover._tcp record to the zone that corresponds to the users Primary SMTP address.  At that point, you can simply point the service location to http://www.portal.com.

    Hope this helps,

    Brad

  33. Richard Butler says:

    Hi Brad,

    Thanks for your comments. I hear what you are saying about VMware and performance, however, I work in New Zealand and most of our customers have less than 50 users on their Exchange Servers. We’ve been running 3 Exchange 2007 Servers on our VMware ESX servers (for various hosted customers) with no issues in terms of performance for the last 8 months. Admitedly the VMs do require a lot of RAM (4GB minimum) but otherwise it runs like a dream.

    As for the rest of what you say. There’s going to be no way I can get round this. Our parent organisation runs Exchange 2007 as well and they already have the DNS records for autodiscover configured for themselves. I’ve told my boss our employees are just going to have to get used to clicking on the certificate button when it comes up. It only happens when they are outside the network anyway so not a major issue.

    Thanks for your response.

    Regards,

    Richard

  34. Brad Hughes says:

    Hi Richard,

    There are actually ways co-exist with autodiscover in a multiforest scenario, but there are some requirements.

    1. There must be a trust between the parent company forest and yours.

    2. You must have MIIS or another process to synchronize your Global Address List with that of the parent company.  This allows for contact objects for your users to be created in the AD in the parent company forest.

    Configuration:

    Each contact in the parent company forest has a targetAddress atrribute that points to a secondary SMTP domain (specific to your forest).

    Parent company CAS are configured with valid SSL certificate for autodiscover.parentcompany.com.  Your cas is configured with a valid SSL certificate (or SRV record method) for autodiscover.yourcompany.com

    DNS points autodiscover.parentcompany.com to the parent company CAS’s.

    -Request comes in from the client to the parent company CAS

    -CAS looks in AD and sees the email address it was sent is a contact object in AD

    -Based on the targetAddress of the contact object, the parent cas issues a "Domain Redirection" so that your client will query for an autodiscover service for yourcompany.com.

    – Using the normal autodiscover process, the client will seamlessly find your CAS’s based on the secondary yourcompany.com adddress and autodiscover will work successfully.

    This is really a complicated topic for a blog post reponse so I’m sorry if it is confusing or I’ve misstated or left something out.

    The short of it is that it can actually be done.

    Brad

  35. Pete Monfiletto says:

    FYI, I run a multi-State, multi-Site organization with over 400 mailboxes on Exchange.  It runs on Vmware with zero performance issues and has so for two years.  I also run an Enterprise SQL server in my Vmware farm and have no performance issues.  Proper configuration of VmWare enterprise systems can giove excellent performance

Comments are closed.