Configuring Autodiscover for Internal DNS

December 20, 2012 170 Comments

The Issue

Ever since Outlook 2016 was released, Autodiscover has been a necessity, rather than an option.

Autodiscover allows any Mail Client that connects to Exchange server to configure the appropriate settings for communication so you don’t have to input everything manually. It’s very handy, but can cause certificate errors if not configured correctly. One issue you may run into occurs most often with Exchange Organizations with non public DNS domains like domain.local. The same problem exists when organizations use a public domain that they don’t own. On an unrelated note, this is one of the reasons that Microsoft has started recommending the use of Public domain names for Active Directory domains.

If you have a domain that isn’t publicly useable on your Exchange AD environment, you will run into certificate errors when mail clients use Autodiscover. This becomes particularly problematic when you use Exchange 2013 or newer and try to use HTTPS for Outlook Anywhere. This is because Microsoft is now enforcing certificate validity with Exchange 2013’s Autodiscover features (Note, though, that Outlook Anywhere will use unsecured HTTP when your Exchange Server certificate is determined to be invalid for modern Exchange deployments). With Exchange 2007 and 2010, you will get a Certificate error every time you open Outlook. This error will state that the name on the certificate is not valid. If you need a primer on Digital Certificates and validity.

The Cause

To solve the issue with certificates, you need to configure your environment so it enforces the appropriate action with Autodiscover. By default, Autodiscover will attempt to communicate with a number of URLs based on the Client’s email address (for external users) or domain name (for internal users). It will take the following pattern when checking for Autodiscover services:

1. Autodiscover will attempt to find the Autodiscover configuration XML file at the domain name of the SMTP address used in configuration. The Active Directory SCP will be picked up first, then a lookup against https://domain.com/autodiscover/autodiscover.xml occurs (Domain.com matches the email domain for this situation)

2. If the autodiscover record is not found at domain.com/domain.local, the server will attempt to connect to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml (replace domain.com with domain.local for internal). This is why the typical recommendation for having an A Record for Autodiscover in your DNS that points to the mail server exists. In addition, you would need to have autodiscover.domain.com as a SAN on the SSL certificate installed on the Exchange server for it to be valid when attempting to connect to autodiscover using this step.

3. If autodiscover information cannot be found in either of the first two steps, Exchange will attempt to use a Service Locator record in DNS to determine the appropriate location of the configuration files. This record points the Autodiscover service to a specific location for getting the configuration it needs.

Because of the way this works, there is some configuration necessary to get Autodiscover working correctly. This usually involves adding Subject Alternate Names to the SSL certificate you use for your Exchange Server to allow the many host names used to be authenticated with the certificate.

The problem though, is that many Third Party Certificate Authorities that provide SSL certificates are beginning to deny requests for Subject Alternate Names that aren’t publicly available (There are valid security reasons for this that I won’t go in to in this post, but maybe later). As a result, you won’t be able to get a valid SSL certificate that allows domain.local as a SAN. This means that the automated steps Exchange uses for Autodiscover configuration will always fail on an Internal domain with a name that is not publicly accessible or not owned.

The Solution

IMPORTANT NOTE: This particular solution only applies to computers on your network that are *not* added to the domain. Domain-joined computers have a different issue to work with. Please read my article on resetting the Active Directory SCP for resolving Autodiscover issues like this on domain-joined computers. Additional problems and solutions can be found here.

There are actually two ways to solve the certificate issues, here. The first would be to prevent Outlook from automatically entering a user’s information when they create their profile. This will result in more work for you and your users, so I don’t recommend it. The other solution is to leverage that last step of the Autodiscover configuration search to force it to look at a host name that is listed on the certificate. This is actually fairly simple to do. Follow these steps to configure the Service Locator record in your internal domain.

  1. Open the DNS manager on one of your Domain Controllers.
  2. Expand out the management tree until you can see your Internal Domain’s Forward Lookup Zone. Click on it, and make sure there are no A records for autodiscover.domain.local in the zone.
  3. Once no autodiscover A records exist, right click the Zone name and select Other New Records.
  4. Select Service Location (SRV) from the list.
  5. Enter the settings as shown below:Image
  6. Hit OK to finish adding the record.

Once the SRV record is added to the internal DNS zone, Outlook and other autodiscover clients that attempt to configure themselves with a domain.local SMTP address will work properly without the Certificate errors on all versions of Exchange.

Other Nifty Stuff

There are some additional benefits to utilizing the Service Locator record for Autodiscover rather than an Autodiscover A or CNAME record, even in your public domain. When you use a SRV record, you can also point public clients to communicate with mail.domain.com or outlook.domain.com, or whatever you have configured your external server name to be. This means you can get away with having a single host name on your SSL certificate, since you wouldn’t need autodiscover.domain.com to get autodiscover working. Since most Third Party CAs charge up to three times more for SANs or wildcards than they do for Single Name SSL certs, you can save a bit of money (you may need to change your Internal and External Web Services URLs in Exchange to match the name you have configured).

Another Problem the SRV record Fixes

There are also some other issues you may run into that are easily fixed by adding a SRV record. One of the most common is the use of multiple Email Domains in a single Exchange Server Environment. If you have users that are not assigned a Primary or secondary SMTP address that matches the domain name listed on the SSL certificate, you’ll discover that those users and the rest of your users will not be able to share calendar data between their mailboxes. You can fix this by adding an Autodiscover SRV record to the DNS zone that manages the additional mail domains. For example, you have domain1.com and domain2.com on the same Exchange Server. user@domain1.com can’t see user@domain2.com’s calendar. The fix for this is to add the SRV record to the domain2.com DNS zone and point it to the public host name for domain1.com’s mail server. Once that’s done the services that operate the calendar sharing functions will be properly configured and both users will be able to share calendars.

More Info on Autodiscover

The following posts and sites will help you learn more about Autodiscover and how to work with it:

Configure Exchange Autodiscover
Exchange Autodiscover – The Active Directory SCP
Configuring Autodiscover for Internal DNS
QuickPost: What do Exchange Virtual Directories Do?
Configuring Exchange Virtual Directories
Fixing Outlook Certificate Errors
Controlling Autodiscover with Registry or GPO
Autodiscover – Microsoft Docs

170 thoughts on “Configuring Autodiscover for Internal DNS”

  1. The pop ids are not prompting the login password in outlook 10 in exchange server but the users having mail alias ids under the main id sterling asking the password in very 5 minutes.

    regards

    1. Unfortunately, that seems like an issue with Smartermail, which is a mail server I’m not familiar with. You’ll have to contact Smartermail’s support team or look through their documentation to resolve any issues you’re having there.

  2. Hello

    after adding the srv record in how much time it will propogated
    as we have add both the records in public dns and exchange server
    and wanted to know in exchange where is the autodiscover.domain.com will be available i mean to say in which path.

    Regards

    1. Right now, if I go to autodiscover.domain.com for the domain you’re using, I get a login for SmarterMail, which is a completely different solution for email than Exchange. It has its own way of handling Autodiscover. https://portal.smartertools.com/kb/a2752/set-up-autodiscover-for-smartermail.aspx explains it a bit, so you’ll need to do some setup on the smartermail server to get it to work with Outlook’s Autodiscover features.

      In addition, the certificate you have installed on the exchange server won’t work with autodiscover.domain.com. You will need to remove any DNS entries for autodiscover.domain.com that you have in public and private DNS, then create a SRV record that points to plesk-1sm.ukdns.biz
      which is where your autodiscover record is acting as an alias for. The SRV record setup instructions depend on who you’re using for your DNS, but you can use the values included in this article to add the record there.

      Once you have a SRV record in place, Autodiscover will work, but you’ll get a different popup that says you’re being redirected. This can be suppressed with the following configuration changes in the registry: https://support.microsoft.com/en-us/help/2480582/how-to-suppress-the-autodiscover-redirect-warning-in-outlook-2010-and

      1. Hello

        you said

        then create a SRV record that points to plesk-1sm.ukdns.biz

        wanted to know this SRV record will create in Public DNS of the domain.com or in
        Exchange server DNS ?

        Regards

  5. Hello

    The website is hosted on linux server hostdime.com
    IP: 66.7.201.36

    The setup is like that a Mail software Pytheas Mail gate download the mails to the
    Local server and distributed it, and when client open its outlook 10 in exchange server it popup autodiscover certificate on view the certificate is showing of Linux server certificate.

    Pytheas Mail gate connects mail.domainname.com to fetch all the mails.
    this setting is working fine before migration to the new server of smartermail 16x.
    after migration to the new server it is prompting the autodiscover certificate window.
    http://prntscr.com/ftk4cu see the printscreen.

    http://prntscr.com/ftk4sn see on click view certificate it is showing linux server certificate where the website is hosted.

    http://prntscr.com/ftk5h4 see more of certificate detail.

    http://prntscr.com/ftjvhm outlook10 setup in exchange

    http://prntscr.com/ftjvuz autodiscover page

    http://prntscr.com/ftjwyr autodiscover output

    http://prntscr.com/ftk1bg Dns record on windows server

    Linux server A record IP 66.7.201.36

    Pls Help to resolve the autodiscover window promting issue in outlook 10 in the exchange server.

    Regards
    Ranjib

    1. Sorry for such a long delay. Your issue is that the autodiscover lookup process is getting hung up with in tries to locate https://domain.com/autodiscover/autodiscover.xml. The only way to fix this is to configure the website to return a 404 error when it attempts to find that file, or configure outlook to skip that part of the lookup. This can be done with the Outlook section of the Office ADMX templates for your version of Office, deployed through a GPO.

  6. Hello

    we have a similar issue on our exchange client prompting the autodiscover certificate window on Outlook 10 Client side. but the certificate is showing is the Linux server certificate, as the emails are working on a Windows 2016 server and A record is on a Linux server. The autodiscover certificate is started after Mail server upgradations from smarterMail 15 to 16x.

    As it is crazy all the user using the Outlook client.

    wanted your help to resolve the issue of autodiscover certificate

    regards
    Ranjib

    1. This can happen if the linux server is hosting a website at http://domain.com or if there is a wildcard DNS record for the domain that points to a Linux web server and no autodiscover record. Wildcard DNS records aren’t really recommended, so if you have one, it’s best to remove it. If you have the other issue, with a linux server hosting http://domain.com, you can configure outlook to ignore that part of the autodiscover lookup process. https://support.microsoft.com/en-us/help/2612922/how-to-control-outlook-autodiscover-by-using-group-policy explains how to do this. Another option would be to create an HTTP redirect on the Linux webserver that redirects https://domain.com/autodiscover/autodiscover.xml to your Exchange server.

      1. Hello

        website is hosted on linux server and mails are on windows server
        we fetch mails using a software pytheas mail gate and it will distributed to exchange server clients using outlook 10

        The autodiscover is showing our linux server certificate where our website is hosted

        Linux server IP 66.7.201.36 the A record is setup in the windows Server DNS zone.

        see the screenshot below

        http://prntscr.com/ftjvhm outlook10 setup in exchange

        http://prntscr.com/ftjvuz autodiscover page

        http://prntscr.com/ftjwyr autodiscover output

        http://prntscr.com/ftjzb7 DNS Record

        Regards
        Ranjib

        1. Autodiscover.domain.com is pointing to your Linux-based Web server on Public DNS. That DNS record should be pointing to the Exchange server. This would need to be done internally and externally.

  7. Great Post!
    i have exchange 2016 on premise. Lately, some users can not connect to outlook due to error 10 – outlook is unable to connect to proxy server. pls i need hep!

    1. hi joshua. This particular error is caused by the internal url value for outlook anywhere being set incorrectly. Run get-outlookanywhere ¦ set-outlook anywhere -internalurl -internalclientsrequiressl $true

      Then run iisreset to fix the problem.

  8. Hello Adam, it is me again, I just want to say a super hyper mega THANKS for your help, you keep helping me during all this time and thanks to your kind suggestions and skills I was able to sort out this problem. you amigo are a genius!!!

    I have to say that nowadays is very difficult to find people keen on do what you do, so kudos to you!!!!!

    thanks again.

  9. fantastic blog sir, thank you very much, finally got that autodiscover malarkey figure it out!!!, 4 days ago I migrated a very old sbs 2003 to a brand new spanky 2012 server with exchange 2016 for 50 internal people and 200 people out and about. Having to rekey and reimport the ssl certificate was one of my worries, so much so that I got as many external devices in just to make sure that the internet ones were all good!!!…surprise, surprise the ones suffering after the migration are the internal people (including a very unforgiving owner) as all of them are getting the “there is a problem with the proxy servers certificate. The name on the security certificate is invalid or does not match the name of the target certificate servername.companyname.local….at the beginning I thought the issue was with servername as servername is the new name of the server and the ssl would not know about it…godaddy to the rescue not!!! as they refused automatically to issue a new san for my servername.companyname.local. at this point all my external customers are pointing to autodiscover.company.com (which is part of the sll) and it is working fine, but my internal customers are not. In my internal primary dns companyname.local there is an autodiscover.companyname.local (A) record entry pointing to my new server. If I understood correctly I must remove that record and instead create a SRV where domain is company.local, service is _autodiscover, protocol _tcp, host offering this service autodiscover.company.com? can you please confirm if this is the soluton and if so, if I will be getting the redirect message as I don’t think any one will be happy to change one message for another? or can I get away from the second message easier than from the first one?

    thanks a million for the help

    1. Go check that one out, since it more than likely applies to your situation. The article here is missing some information on Autodiscover (it’s the first one I wrote, after all, before I really got into figuring that “feature” out). The SRV record method is only necessary when you have an SSL certificate that doesn’t include autodiscover.domain.com, or for additional domains managed by the server itself. It will also fix computers on the LAN that aren’t members of the AD domain if you don’t want to have or want to use internal split DNS. The article in the link here (which is also linked at the start of this blog) will explain another Autodiscover method, the AD SCP, which is the first place Domain Joined Computers will look for the Exchange Server’s name. That setting, by default, is servername.domain.local, so it usually needs to be changed.

      1. Hello, it is me again, finally today I was able to test the certificate issue. What I did was.
        open DNS
        click on the zone
        remove autodiscover which read autodiscover…FQDN autodiscover.mydomain.local
        Ip address…my correct local ip address…

        The I followed your instructions..cretete the srv
        mydomain.local
        service _autodiscovery
        protocol _tcp
        priority 0
        weitgh 0
        por number 443
        host offering this service…myservername.mydomainname.local
        the entry went to the _tcp folder
        restarted DNS
        Restarted the client machine…
        The message “there is a problem with the proxy server’s …..the target site…myservename.mydomain.local

        the valid SSL certificates that I have for the SAN are
        remote.mydomain.co.uk
        http://www.remote.mydomain.co.uk
        autodiscover.mydomain.co.uk
        myserver.mydomain.co.uk
        mydomain.co.uk

        Any ideas what I may be doing wrong?

        thanks a million

        1. The “Host offering this service” needs to match a name that exists on the certificate. But what you need to do is in my other article. Run this in powershell:

          set-clientaccessserver -AutoDiscoverServiceInternalUri myserver.mydomain.co.uk

    2. Also, there’s a group policy option to suppress the redirect notice in the Office GPO templates. Or there’s a registry setting you can push out. Someone left a comment here about it a while back, but I don’t recall what it was off my head. Comment should still be here. It’s one of the older comments.

      1. Hello, for some reason I can not reply to you in the post above. Yes I read your other blog and now my internaluri reads AutoDiscoverServiceInternalUri : https://myserver.mydomain.co.uk/autodiscover/autodiscover.xml I restarted the Internet web service, but still the certificate pop up keeps coming up. After that I removed the srv record and put back the original A record for discover, restart web services but still same result…I really thought that changing the internaluri would work…

        Any help will be appreciated.

      2. Hello, sorry to bother you but I was wondering if you had any more suggestions I can follow, all my intranet users using outlook client still getting the same proxys certifixate error

        1. If you can run the Autoconfiguration test by holding ctrl while right clicking the Outlook icon in the Notification bar (By the system clock in the lower right), send the results of the test to me and I’ll go through it to see what’s failing.

  11. Pingback: exchange server certificate issue « Viral Rathod Exchange 2016 Blog

  12. This is great information, thank you for posting this. I’m currently dealing with a situation concerning a client that I just inherited from a previous company. They were migrated to O365, but started getting an expired certificate notification for “mail.company.com” recently in their Outlook clients. I’m assuming this was the cert for their previous on premises Exchange server, which was not uninstalled cleanly from the environment (Exch services were just disabled, server is still a member server). There are no autodiscover A records in DNS, but there is an autodiscover CNAME record pointing to autodiscover.outlook.com. Could adding a SRV record for autodiscover.outlook.com help with this issue? Anything that could help point me in the right direction would be very much appreciated.

    1. The problem you have is likely due to the old server being listed in the Autodiscover SCP in Active Directory. The first thing that gets checked in Autodiscover is the SCP if the clients are on the domain, so if that isn’t pointing to Office 365, you’ll get an error message first no matter what. I wrote another article about that. http://wp.me/pUCB5-7X should help.

  13. Thank you for this. We recently got a new Exchange certificate and we’re getting the Outlook security alert with the 3rd item X-ed out “The name on the security certificate is invalid…” The popup lists EX2010.xxx.lan as the name. Our certificate is for mail.yyyyy.com. I set up a new SRV with xxx.lan as the domain and autodiscover.yyyyy.com in the Host field. Our Exchange server AutodiscoverServiceInternalUri is https://mail.yyyyy.com/autodiscover/autodiscover.xml

    But I’m still getting the Outlook popup. What do I need to change to fix this?

    1. Check all of the URL settings for your virtual directories. Just getting to Autodiscover is only part of the process. You also need to make sure that Autodiscover is sending the correct URLs. Autodiscover sends whatever URLs are attached to the various Virtual Directories for Exchange to Outlook, and if any of those is incorrect, you’ll get a pop up as well. You’ll particularly want to check the settings for your EWS virtual directory, since that is the one that is most likely to cause pop-ups if autodiscover is set up properly. You can get a better understanding of what’s happening with the autodiscover process by holding down the Control Button, right click the Outlook icon in the Notifications area of the task bar (Lower right, by the click), then select “Test Email Autoconfiguration”. When you run the tests in the window that pops up, it will tell you what information Autodiscover is sending to Outlook, and you can then get a better idea about what’s wrong.

      1. You may be dealing with an issue where the Outlook Profile gets more or less “Tattooed” with the incorrect autodiscover settings. This can usually be fixed by running a Repair on the account in the profile.

        Another option could be Outlook Provider misconfiguration. Run
        get-outlookprovider EXPR
        to see what the CertPrincipalName value is. If you had a Wildcard certificate before, someone may have changed this to match the wildcard certificate, and it would likely need to be changed back to mail.company.com or a host name that is listed on the certificate. You’ll want to do the same thing with the EXCH exchange provider. (get-outlookprovider EXCH)
        You would use
        set-outlookprovider EXPR -certprincipalname msstd:mail.domain.com
        To change it if needed.

  14. im in trouble guys can you help me with this. this is a very helpful blog but i wasnt able to accomplish the resolution based on what we have.

    outook users cant have the new certificate and it doesnt open, i change the SSL with go daddy successfully but he local outlook users suffers after that.

    1. Sorry for the delay…Have you resolved this? If not, could you clarify a little? Are the users getting certificate errors in Outlook, or something else? If they are getting certificate errors, which of the three issues in the Certificate Error box have a red X next to it?

  15. Pingback: Cpanel Dns Wildcard Record | Cloud Hosting Servers

  19. Thank you and sure, We will go for upgrade but this is long procedure but for time begging could you please anyone give us the best solution for windows server 2003 as how can we set up an internal DNS record for the external mail FQDN in windows 2003 by steps. and where we can change this external name in MS Exchange 2007.

    1. The instructions should be similar for Server 2003. You make the changes in DNS on any DC. That said, I’d highly recommend getting off of Server 2003 as soon as you can, since it’s past it’s End of Life.

  21. Do I have to change the webserver, CAS and autodiscover URL/ URI for internal resolution with set command or leave it with XXXX.local instead of changing to xxxx.com.
    I tried the same and removed the internal zones I created for public zones and it has not worked. Though it does work if I create the public zone in internal DNS with certificate error. In test lab I have applied internal CA certificate and the certificate server acts as both root and issuing certificate

    1. There’s actually two parts to this particular blog. The other entry covers the Autodiscover SCP, which is part of where your error is coming from. Domain Joined computers will look at the SCP before going to any other DNS lookups. SRV records are good for making sure extra email domains can use Autodiscover and for getting autodiscover to work with a certificate that has only one host name entry. Configuring it in the internal domain will allow you to redirect non-domain joined computers as well, however, domain joined computers work differently. Setting the Autodiscoverinternaluri and Virtual Directory Internal/external URLs will allow those computer to work properly.

  22. Hi,
    I have create an srv record but after that I cannot open outlook with this error message:
    ” cannot start microsoft outlook. cannot open the outlook window. the set of folders cannot be opened. the attempt to logon to microsoft exchange has failed”
    please HELP 🙁

    1. There are a lot of things that can cause that error to come up, but it isn’t usually caused by autodiscover. I would recommend removing all accounts from the user’s mail profile and recreating them to see if that resolves the error.

  23. Hi guys very nice page I hope you guys can help since I think i’m close to figure it out but need help !

    If I would like autodiscover to use domain2.com instead of domain1.com used by Internal/External URL is that possible ?

    Issue is that when i’m running the MS Connectivity Analyser it always look for autodiscover.domain1.com and not domain2.com that I have assigned using the cmd

    I have used this cmd Set-ClientAccessServer –Identity -AutoDiscoverServiceInternalUri https://domain2.com/Autodiscover/Autodiscover.xml

    Have created a DNS Zone locally named autodiscover.domain2.com with A inside that point to the Exchange server local IP.

    Outlook and everything else look fine internally but externally can’t get iPhone to work.

    Thanks !

    1. Can you clarify a little? Are you wanting to use domain2.com externally only, internally only, or for both?
      Also, is domain2.com the domain in the email address you are using for your users?

      1. Hello !

        Sorry for the late reply and thanks for helping me !

        I’d say both. domain2.com is a valid domain used in my enterprise.

        No domain2.com is no the primary domain in the email address but it exist in my Exchange. It’s an allowed domain + a domain in my address policy.

        1. Okay. I understand a little better now. The powershell command you wrote above will set things up to allow domain joined clients to use domain2.com as their autodiscover address, but that won’t change how things work externally. For this to work the way you want with the connectivity analyzer, you would need to set up a SRV record on your external DNS for domain1.com so that it points to domain2.com, then remove any autodiscover records that exist in domain1.com (autdiscover.domain1.com). You could also use a CNAME record for autodiscover.domain1.com and point it to autodiscover.domain2.com (or whatever is pointing to the exchange server) to get similar results, but it would still look for autodiscover.domain1.com first.

  24. Hi there!

    I’m in a happy situation that I have to create a new Exchange 2013 environment from scratch. The FQDN of my new Active Directory structure is “ad.mydomain.com”.

    I now need to configure the external and internal URLs for Exchange and I’m a bit unsure if I shall use “mail.mydomain.com” or “mail.ad.mydomain.com”. If I go with the first one, I again need Split-DNS, right?

    What is best practice here? If I use mail.ad.mydomain.com, are there any implications with autodiscover?

    Many thanks in advance!!!

    Best regards
    Mischa

    1. The External URL will be whatever your public DNS domain is, so mail.mydomain.com. Since mydomain.com isn’t an internal DNS zone (unless you make one), internal clients will use the DNS info that is published on the public DNS servers. This means that internal clients will use Public IP addresses to communicate with Exchange. As a result, you’ll need to make sure your firewall allows traffic that originates from your internal network to access your public IP addresses. This *also* means that all clients will be considered External clients, so the Internal URL can be left blank (or set to the internal URL to mail.mydomain.com as well).

  25. hi, this may be really simple for you to resolve, i just want to verify this will work.

    single server/domain running sbs2011 and exchange 2010. i want to use exchange online and can setup outlook clients fine using autodiscover but only when these clients are external.

    the internal outlook clients still point to the internal exchange, i can’t get them to see the external exchange because the domain name is the same.

    will an SRV entry in the internal server’s dns (pointing to the external exchange) fix this issue?

    thanks
    ~greg

    1. For this you would actually need to remove the Exchange Autodiscover service connection point or change it to point to autodiscover.outlook.com instead of the internal Exchange. I wrote a follow up post on how to do this.

      1. thanks, i believe i found your follow-up post but the attributes tab isn’t viewable and even though i fired up ADSIEdit as you suggested, i am unable to locate what is required to be changed (since ADSIEdit has no search ability) so i am still trying to figure this out.

        just replying to let you know that i am grateful for your help thus far. hopefully i’ll get this before i go completely grey.

        ~G

      2. update march 23, 2015 6:31am EST- got it to work as per your instructions; i was able to locate the fields using ASDIEdit eventually.

        many thanks.
        ~Greg

  27. The GUID it shows you is the actual mailbox location for that user. It’s a new “feature” for Exchange 2013. So that GUID will be different for each user account.

    As to Certificates, as long as you use SRV records, a single name cert will work fine for you. I don’t think you can do a test cert that is valid by default on client machines, though. You can test by installing the certificate into the trusted root CA store on a client computer with the cert you have now, though.

    1. about the guid i used the “Get-Mailbox mailbox | FL Identity,ExchangeGuid” command

      Btw, i autoconfigured an internal client in which i had to use the INTERNAL domain UPN or it wouldn’t work: user@contoso.local
      the values it configured are interesting:
      the GUID domain pointed to public domain name, but the HTTP proxy used “mail.contoso.local”

      is this ok?, i assume it is as it detected the OA local address but that hostname won’t validate the certificate as it’s the local one(but the correct for internal clients)

      i mean, i have internal and external url confgiured for OA and all services, one points to the local domain, the others to the public, and internal clients whould use the internal one even when the single name cert is only for the external, or do i need to cnfigure the same external url for everything in this case?

  28. 1: Yeah. SCP was probably pointing to the external DNS. You can check that with the instructions in the latest article on here.Once you added the A record, that should have made non-domain computers work as well, but I’d have to see the configuration myself to make sure of that.

    2: Yes. You’ll need split DNS to keep from going out and in the firewall, which is likely blocking that kind of traffic. This is part of the reason for new recommendations on domain naming in AD.

    3: You can use an Internal CA or self-signed certificate and not get errors as long as that certificate is deployed to the Trusted Third Party Root CAs certificate store on any client computer that accesses the Exchange server. Otherwise you’ll get a certificate error no matter what you use for the FQDN on the client.3rd party certs are trusted by default in most OSes, so they will result in less work. Certificate deployment can be a huge pain in the rump.

    4: No, a CNAME won’t work the way you think here. CNAME just allows multiple DNS entries for the same server. SRV record with no autodiscover.company.com will be the way you want to go, because that will configure DNS to point clients to whatever is listed on the certificate you have, if that’s how you want to go. SRV record essentially makes it so Outlook uses whatever you set the SRV record to point to, mail.company.com, xyz.company.com, or however you want to do it, but it’s the last lookup that outlook will use, so if you have any autodiscover.company.com A records or CNAMEs in DNS, those will take precedence.

    5: When you get moving to multiple mail domains, autodiscover isn’t too much more of a pain. The gotchas you deal with have more to do with usernames vs. email addresses, primary SMTP addresses, address policies, and stuff like that. Some of that gets a little too complicated to cover easily in writing, but I can help you out over the phone or with a remote session when you start dealing with that if you are interested. Just shoot me an email at the address in the About section here.

    1. urgh i typed a lengthy reply and it failed….
      Thanks for your detailed responses!

      anyways, i think i got the most of it, now i think my next steps are:

      1) checked the SCP and points to domain.local corectly so i have no idea why non-domain clients where not working.
      non-domain computers still fail

      2) the split-dns will be annoying, specialyl since the website is hosted externally

      3) the idea is not to have to do anything on the client side, deploying a the trust root will be annoying. So far i think i’ll only need a single-name cert since i’m using the same external hostname for everything.
      With the split dns i won’t have to configure firewall rules i take it.
      ¿is there some free test cert i can use before having to buy the real thing?, preferably one that has a public root chain already

      4) So i’ll ask the dns provider to setup a SRV record for autodiscover pointing to mail.externalhost.com

      5) i already have policies based on OUs in place since the current domain is different intenal/external

      the env is pretty simple, using contoso a example:
      the AD domain is “contoso.local”
      the external public domain is “externalcontoso.com”, the others will be “anotercontoso.com” “yetanotheracontoso.com”

      oh, and since the changes i made yesterday, some outlook clients stopped working and autoconfig as well :/ (all i did was finish configuring the internal and external hostname for the different exchange virtual servers).

      and as a side note, checking on one client that DOES work i see that the server uses the “GUID@externaldomain.com”, the usr is the external FQDN and the HTTP proxy is set to “mail.internaldomain.local”
      interesting… if i replicate that on a non-domain computer it keeps failing (extracted the correct GUID previously)

  29. Interesting, so let me get this straight for a customer i’m configuring:

    internal domain is: domain.local
    exchange is: mail.domain.local
    external mail is company.com
    ALL exchange(owa, oab, EAS, etc) use the same external url: mail.company.com

    there’s no certificates, only the autogenerated ones out of the box

    so far i had an A record on the internal DNS and internal domain-joined computers autoconfigure perfectly.
    But i’m having issues with LAN non-domain computers

    so i should delete the A record and geneate an SRV in my domain.local dns that actually points to “mail.company.com”?, wouldn’t the border firewall make a fuss with that?(or this is just “for show” and it actually goes to local but uses that url for the cert validation?).

    As for certificates, do i need a SAN in this case?, or i can get away with a single name cert since i’m using everything on the same external URL?.

    i’m not clear on how would the single name cert interact with the internal URLs?, for example, internal owa is used towards “https://mail.domain.local/owa” and will fail validation(not that i care much since it’s web browser), but what happens with internal outlook clients?

    1. The domain joined computers you have are using the Autodiscover SCP to get their configuration information (the second article I wrote on autodiscover covers that). Non domain joined computers can’t access the SCP and that’s the first check in the Autodiscover process, so there has to be a DNS setting for them to work.

      The DNS setting you use depends on what you need to accomplish. First off, in order to get internal network computers to autodiscover, you *have* to have an internal version of your External DNS zone if you have a border firewall that blocks out and in traffic (not all do this, but it’s a network best practice from what I know). That zone would include the internal IP addresses of the Exchange CAS servers for the A records, rather than the external ones.

      If you have a SAN cert, you can use the autodiscover A record entry (as long as it’s included on the cert) to point non-domain clients to the Exchange server without errors. If you have a single-name cert, you have to use a SRV record for autodiscover if the name on the cert is not autodiscover.company.com. the SRV record is added to the domain.com zone using whatever FQDN is listed on your CAS server Cert. So if the CAS server’s cert is mail.domain.com, you would remove all autodiscover.domain.com A records from DNS (because SRV record is the last lookup Outlook does) and replace them with a SRV record that points the service to mail.domain.com.

      If you have no Internal zone for domain.com, the client will use the information in your External zone, which has public IP addresses in it, and the client will then attempt to connect using that IP address, so it would essentially go out of your firewall to reach the public IP and then come back into the firewall, which will usually result in the firewall blocking it. Make sense?

      1. hmm somewhat makes sense but some question remains

        let’s go by parts:
        1) the domain joined computes where NOT working at all UNTIL i added the autodiscover A record pointed to the exchange internal address, so SCP was not pointing correctly i guess.

        2) so if i configure the SRV in internal LAN as you point i need to have a “company.com” zone in my internal DNS server(doing a split-dns) to prevent local computers from resolving to internet?

        3) I don’t have ANY certificate yet (and honestly customer does not want or care to buy a commercial certificate at all), ¿can the autodiscover be done with a self-issued internal CA?, will this give problems. And SAN certificates are very xpensive, like i’ve said, we’re running ALL the services through a single external hostname.

        4) ¿what should i put for the autodiscover external DNS?, would a CNAME for “autodiscover.company.com” pointing to “mail.company.com” suffice?, or should i also ask the DNS provider to set a SRV ´pointing to “mail.company.com”?

        After solving this THEN i can move to the issue of smartphones….

        AAAND in the not so distant future this same exchange server will host mail for two other completely different external domains (but they’re all in the same internal active directory domain), i wonder the mess i’ll have to do with certificates in that case…

  30. Please help me out! After configuring my office New Server and move all Client to AD DC. All mails in the MS Outlook 2012 on all system can neither send nor receive email. What do I do. This is urgent please. I feel I need to do something on the DNS to make it work bcos. Local domain is exactly the same with the website. (email host domain).

    thnks

    1. If you switched to a new server, you’ll need to make sure that port 25 is properly going to the new server. DNS may also be an issue, but it’s hard to say with the information you have here. Could you give me a little more detail about the environment and what you’ve changed?

  31. Hi,

    Thanks for posting this, i have added the srv record however is till get certificate warning error? The dns record is correct as you have instructed. Any ideas?

    1. Check the second post I wrote on the subject. For systems on the domain, the certificate error is usually due to the settings for the Autodiscover SCP in Active Directory.The link to the second post is at the top of this one.

  32. I am sorry to say that none of the solutions mentioned above have helped in my situation. I have spent the past week with little food, little sleep, and much aggravation. I not only had to rebuild my Exchange infrastructure from scratch twice, but also almost lost my entire AD. I have just about had it.

    I cannot make any internal Outlook 2013 client connect with an internal Exchange 2013 autodiscover service — or any other service — NEVER.

    OWA and ActiveSync are working perfectly, BOTH internally and externally (and external is running through Forefront TMG). No matter what I try (and I have tried all of the solutions mentioned about, read all white papers, reviewed all documentation, etc.), no solution works.

    You can tell I am tired and cranky by the fact that I suspect this all has to do with MSFT changing Outlook for ‘external’ (read Azure) requirements so that we can all go along peacefully to the cloud.

    The errors range from unable to connect to the exchange server, to a complete inability to authenticate with the Exchange 2013 server. Both Outlook 2013 and Exchange 2013 have the latest patches (6 for exchange, and the latest SP for Office). Outlook is running on Windows 7 Ultimate in all cases, and Exchange is running on Server 2012 R2.

    If anyone can explain to me why this process has been made so insanely difficult by MSFT for an insanely simple SMTP conversation, I would truly appreciate it. And if anyone has a simple 3-step answer, or a simple instruction sheet on how to make this work, I would be grateful.

    1. I can appreciate your frustrations, but I’d like to point out a couple things:
      1. Outlook to Exchange communication doesn’t use SMTP at all. It uses MAPI, which is a completely different protocol. And its functions are anything but simple.
      2. When the environment is set up according to best practices, Autodiscover is extremely easy to configure.

      The problem comes in when an environment isn’t set up perfectly, which is the vast majority of IT environments.

      I can’t easily determine what’s causing your problems without looking at your environment, but there are a lot of different things that can cause the errors you’re seeing. I do often assist people with problems like you’re seeing, but not everyone is willing to pay for a consultant to help out.

      At any rate, I’ll give you a suggestion of something to try. https://testconnectivity.microsoft.com/ has a desktop tool that can help diagnose connectivity errors with Outlook. Go there and click on the client tab, then download the Connectivity Analyzer tool. Install it, run it, and see what it comes back with. Of course, that’s assuming you haven’t done so already.

      Finally, I would also like to note here that this solution, and the Part 2 solution I wrote a few months ago, are only meant to address Certificate error messages that pop up when adding a new profile or opening outlook. In the situation where you get certificate errors, you will still be able to connect with Outlook. You’ll just get an annoying pop up every time you do. From what you’re describing, you’re not even successfully establishing a connection to Exchange, so these solutions won’t solve your problems.

      As I mentioned earlier, I’d be happy to assist if you’re tired of beating your head against a wall. If you don’t want help, at the very least take a good 2 or 3 hour break and take your mind off the problem for a while. Almost every time I’ve done that after grinding my wheels on a problem for hours, I’ve come up with a solution almost immediately after a break.

      1. Thank you for the feedback, I do appreciate the response very much.

        First, I understand the difference in the protocols, and in the end the connections between Outlook and Exchange can number between 3-6 at any given time (sometimes DNS connections are made and kept open, sometimes not — it is a mystery what the coding logic behind the ‘when’ and for ‘how long’). In the end, at least with Outlook 2013, the connections are always RPC over HTTP.

        In terms of paying for a consultant, you are preaching to the choir. I left ‘corporate’ america 15 years ago at a very young age, and have not looked back. I’ve had my own consulting company since then, with staff sizes ranging from just me to 18+ consultants, depending on the economy and the market. I have had absolutely no problem with paying for consultants for issues/problems that I cannot resolve myself or within the company. I know (as I am sure you do from your statement) that hiring a consultant saves time and resource, which translates into dollars saved in the end. There is no point in wasting time.

        Today I am very lucky for your suggestion. I took some time, got some sleep, and stepped back from the problem for 10 hours. Looking at it with fresh eyes, I was able to determine the I was mixing/matching authentication protocols, which would determine either a) No connection to Exchange Server or b) Impossibility to authenticate. Once I identified the problem (food and sleep did help in this case), it was resolved in about 30 seconds.

        Again I thank you for you suggestions, for all the help you have provided me, and the help you provide to others. In a world that has turned into a completely cut-throat, hateful IT environment, it is good to see people who are still willing to help.

  34. This resolved my issue.

    Autodiscover was being skewed.by ISA – for internal requests
    I already had an SRV record in public DNS
    and in internal DNS for domain.TLD.

    The additional svr record in DOMAIN.LOCAL was the solution.

    Very well written article.
    Thank you.

  35. I’ve spotted my mistake and did not realise I could just type _autodiscover in the Service box, overwriting one of the pre-selected entries – that’s that sorted now. I will re-read the article and have a play around and see how I get on. Thanks a lot for the help.

  36. Thanks, a very useful article. I’ve just tried your suggestion on creating an internal SRV _autodiscover record on an SBS 2008 server and there is no _autodiscover service available for selection (the first one being _finger). I’m assuming this is something to do with SBS 2008, so when was this service type added?

    We have a number of Exchange installs out there, that, while most are using an external SRV record for autodiscovery, they all have .local internal domains, so when the time comes that we can no longer add .local to the SSL cert / the certs expire, I saw your method as “the workaround” for getting internal clients still being able to connect to the Exchange servers without the certificate errors, or will there still be a problem?

    1. The SRV record goes under the _TCP service type. _autodiscover is actually the name of the record itself, and it is used to define a non .local address. Creating a new SRV record and adding the entries as seen in screenshots will do what you need.

      There are other ways to solve the certificate issue, and the second article I wrote covers a good one for domain joined machines (non-domain machines will still get cert errors if you *only* use that method). Domain Joined machines are usually the ones that will have this problem, though, because they are on the .local domain and will always first attempt to access Exchange using the .local DNS name. Changing the settings for the Autodiscover SCP will resolve the issue for those computers. Externally, a SRV record isn’t usually necessary unless you have multiple domains on the server or want to use a single-name SSL certificate. If you want to spend the extra money on a SAN or Wildcard cert, you can just use a regular A record for autodiscover.domain.com to point clients where they need to go.

  37. Pingback: knowitallnowblog.wordpress.com

  38. We are struggling to solve the mismatched name and certificate security alert using and external hosted Exchange provider and an SBS 2008 server that has never had its copy of Exchange 2007 running.

    The certificate that is referenced by the security alert was issued to sbs.companyname.local by the SBS server itself.

    Following the instructions above, we deleted the autodiscover CNAME record that existed in the internal dns zone (i.e., companyname.local) and pointed to the external hosted Exchange server and substituted an SRV record that pointed to that server. Regardless of whether we set the SRV record to point to the external hosted Exchange server, to autodiscover.companynameinc.com (our FQDN is companynameinc.com and our internal name is companyname.local) or to sbs.companyname.local (the name on the certificate), we still get the security alert.

    We have also tried adding an SRV record to the external dns zone (i.e., companynameinc.com) on the SBS server as suggested in Microsoft KB 940881 and we still get the security alert.

    We have also deleted the autodiscover CNAME record at our domain registrar that pointed to the hosted Exchange server and substituted an SRV record pointing to that server. The security alert still occurs.

    Outlook autodiscover tests successfully in Microsoft Remote Connectivity Analyzer with the autodiscover CNAME record at our registrar pointed to the hosted Exchange server (the connection is successful using the http redirect method). When the CNAME record is replaced by an SRV record, the MRCA test finds the SRV record and resolves the IP address of the hosted Exchange provider, but fails when it tests port 443.

    Outlook autodiscover appears to be working correctly because it says that it has been redirected to the hosted Exchange server for settings and asks for permission to let the hosted Exchange server configure the server settings for the user’s mailboxes.

    Any suggestions for how to eliminate the security alert would be greatly appreciated.

    1. The security alert is probably coming from the Exchange Service Connection Point in Active Directory. I wrote another blog post on that. If you go find the entry outlined in that blog post, you should be able to either change the SCP so it points to the external server, or delete the SCP altogether.

      1. Thanks for your prompt response and for solving my certificate problem.

        By the way, I solved the SRV connection issue, which was occuring because hosted Exchange provider uses a different IP address to listen for autodiscover connections on port 443 than it does for autodiscover connections on port 80. I changed the SRV record to point to the address that listens on part 443 and autodiscover is working. I tested autodiscover externally using Remote Connectivity Analyzer and internally using Outlook’s Test E-Mail AutoConfiguration and both report success with autodiscover. This left me with the original certificate error.

        I followed the instructions in the blog post you referenced and changed the SCP from the default internal location to the hosted Exchange provider and the certificate sercurity alert is gone. Test E-mail AutoConfiguration’s log shows that autodiscover still is working, but is now getting the autodiscover information from the link provided by SCP, rather than from the link provided by the SRV record.

        Thank you very much for pointing me to the solution to an irritating problem.

  39. Hey checked the SCP and it points to correct autodiscover….when i recreate outlook profile in outlook 2013 error goes away….not sure where it could possibly be cached in outlook?

  41. Pingback: Exchange Autodiscover Episode 2: Attack of the Exchange Server | AC Brown's IT World

  43. Great post, i tried this however when starting outlook 2013 i get the error

    “Cannot Start Microsoft Outlook. Cannot open the Outlook windows. The set of folders cannot be opened. The attempt to log on to Microsoft Exchange has failed.

    I have re-done the SRV record 3 times with the same result. My autodiscovery address is correct and i tested it and it works using mydomain.com address….

    1. If the profile setup succeeds but you get this error, you don’t have a problem with Autodiscover. That particular error can be caused by a number of things like connectivity problems with the exchange server, incompatibility with Exchange and the Client, or a server that isn’t set up to use encryption being used by a client that requires it.

  44. Hello, this is an excellent article however I cannot get rid of the Outlook “certificate name mismatch” prompts even with your steps implemented.

    I installed a new SSL SAN cert on their only Exchange server (2007 SP3) yesterday, and today users are receiving certificate name mismatch prompts when opening their Outlook 2007 clients.
    The previous cert had the local host name in the SAN cert, but given the changes around using local host names in certs soon to be implemented, I Ieft these entries out this time around with the new cert.
    I already have a split horizon DNS zone within the local domain, which contains an A record for Autodiscover.

    So, the setup is as follows:-

    New SSL SAN cert:
    CN= mail.domain.co.uk
    SAN= autodiscover.domain.co.uk, owa.domain.co.uk

    Split horizon DNS zone: (within domain.local AD domain)
    autodiscover.domain.co.uk
    A record: autodiscover.domain.co.uk = IP of Exchange server

    The output from an Outlook client auto configuration test are listed below:

    /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=TestUser1
    64a06c34-547e-44d8-8885-aa8fd530e2a1

    email
    settings

    EXCH
    EXCHSRV01.domain.local
    /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHSRV01
    72038053
    /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHSRV01/cn=Microsoft Private MDB
    EXCHSRV01.domain.local
    EXCHSRV01.domain.local
    https://EXCHSRV01.domain.local/EWS/Exchange.asmx
    https://EXCHSRV01.domain.local/EWS/Exchange.asmx
    https://EXCHSRV01.domain.local/EWS/Exchange.asmx
    https://EXCHSRV01.domain.local/UnifiedMessaging/Service.asmx
    http://EXCHSRV01.domain.local/OAB/5642c2e4-e31e-4ab8-89e7-d4590570249b/

    EXPR
    mail.domain.co.uk
    On
    Ntlm
    https://mail.domain.co.uk/EWS/Exchange.asmx
    https://mail.domain.co.uk/EWS/Exchange.asmx
    https://mail.domain.co.uk/EWS/Exchange.asmx
    http://mail.domain.co.uk/OAB/5642c2e4-e31e-4ab8-89e7-d4590570249b/

    WEB

    https://mail.domain.co.uk/owa

    EXPR
    https://mail.domain.co.uk/EWS/Exchange.asmx

    https://EXCHSRV01.domain.local/owa

    EXCH
    https://EXCHSRV01.domain.local/EWS/Exchange.asmx

    As the SCP was originally pointing to the local fqdn of the Exchange server, I have amended the binding in ADSS so that the SCP now points to the autodiscover.domain.co.uk A record instead.

    I took this step because even with the internal URL for Autodiscover’s virtual directory set to https://autodiscover.domain.co.uk/Autodiscover/autodiscover.xml this path was ignored and Outlook defaulted to the fqdn of the local server.

    I thought this might rectify the issue but to no avail.

    The security prompt when opening Outlook still references the fact that the EXCHSRV01.domain.local does not match the CN of the cert mail.domain.co.uk.

    Can anyone assist in troubleshooting this further?

    Regards

    1. One thing I have noticed with Autodiscover is that internally it can end up looking at the AD before it starts looking at the actual domain of the email addresses you put into Outlook. You may need to make sure that when you run the Outlook profile wizard that you completely erase what gets auto-populated and never accept what it puts in by default there, since that may be referencing the local AD and Exchange DN for the mailbox you are trying to add internally. I’m still looking into that problem myself, since I’ve seen it a lot where Exchange looks at the local domain Exchange configuration before it goes to any autodiscover or SRV records in DNS that have more accurate information. This is a normal part of the Autodiscover lookup since it looks at domain.local for information. AD actually holds some information for configuring Exchange so Outlook will pick that info up and attempt to use it for configuration. Like I said, yours is not an uncommon problem and I’m still investigating it. Also, sorry I took so long to response.

      1. I’ve never gotten this to work properly because autodiscover looks at www record first, which is hosted by Business Catalyst and the certs they offer are shared using worldsecuresystems.com.
        So everything I have tried to get the autodiscover to work in the outside world fails – users on first setup get the ceritificate error issue and then occasionally get it on future logons.

        1. www isn’t actually a part of the lookup pattern, so you may be dealing with a different issue there. It will look at domain.com first (to see if there is an SCP configured in Active Directory), then it will look to autodiscover.company.com, then it will check for SRV records. If you’re using a hosted Exchange environment that has a certificate on their CAS servers that doesn’t match your domain, what you would want to do is either create a CNAME record for autodiscover.domain.com that points to the CAS server name on their domain (autodiscover.worldsecuresystems.com) or use a SRV record that defines whatever public host name is available that can readily access their CAS servers. I’d probably have to get a closer look at your environment to really see what the problem you’re facing is, but you should be able to work around the certificate issues and ownership problems you’re facing.

          1. We have an A record that points autodiscover.domain.com to the Internal Mail Server Public IP.
            I have an SRV Record _autodiscover as well that points to @. ahh – maybe that is the issue – or maybe we should have a C-name instead of A record.
            Would love to send you any info that would help diagnose the issue if you are offering in an email offline.

          2. Are you using a hosted exchange provider? That info will help a lot in figuring out your issues. But I should point out that the SRV record is the last thing exchange will look for and if it sees the autodiscover.domain.com entry, it will never reach the SRV record. If you use a SRV, you have to remove autodiscover.domain.com and make sure that there is no autodiscover.xml file available at domain.com/autodiscover/autodiscover.xml.

          3. The mail server is hosted internally – Exchange 2007. Single Server setup.
            Should the autodiscover record be A or C? We have an A right now.

          5. Well internally I did not have a record for it – so I added it to point to the server.
            It asked for credentials – So I gave them.
            Then it presented 600 Invalid Request.
            The “lock” in chrome says “Identity verified”
            IE said it was identified and encrypted.
            From what I understand we have a UC Cert.

          6. Can you email me some more information on your environment? Like the domain name and whatnot? My email address should be in the About page on here.

    2. I had a similar circumstance. To fix it, I had to set up a split DNS (i.e. add all the external urls like mail.exchange.com/owa to my internal windows dns server and point them to your exchange server). I also had to reconfigure the URLs within exchange to point to the URL listed in the SSL Cert instead of the .local address. This site is a good reference on all the url’s that need to be updated if you decide to go the split dns route. http://support.microsoft.com/kb/940726

  45. Great Post. However this only got me half way there…..
    We installed a third party (GoDaddy) ssl cert for the external domain on our SBS 2011 server. Once we did that, Outlook users started getting the the Microsoft Security Alert, “the name on the security certificate is invalid or doesn’t match the name in the cer”t.

    This happened because GoDaddy no longer allows you to include the non-real domains (like .local) as a SAN in the certificate. To fix this, in addition to adding the SVR reocrod for autodiscover, I had to create a DNS Zone on the SBS server for our external domain that included all of our external addresses (e.g. mail.domain.com, remote.domain.com, autodiscover.domain.com) and point them to the local SBS server. (Users outside the firewall would use external DNS servers and be pointed to the external addresses)

    Once that was done, I had to use the Exchange Management shell to point the below internal URLs to the external urls (which were in the new Cert).

    Set-ClientAccessServer -Identity “local-server-name” –AutodiscoverServiceInternalURI https://server.domain.com/autodiscover/autodiscover.xml

    Set-WebServicesVirtualDirectory -Identity “local-server-name\EWS (Default Web Site)” –InternalUrl https://server.domain.com/EWS/Exchange.asmx

    Set-OABVirtualDirectory -Identity “local-server-name\OAB (Default Web Site)” -InternalURL https://server.domain.com/OAB

    Set-ActiveSyncVirtualDirectory -Identity “local-server-name\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://server.domain.com/Microsoft-Server-Activesync

    I also had to flush the dns cache on the server and clients to get it to take affect right away.

    1. Actually, you didn’t need to do all that with a SRV record. A SRV record would be used in a situation where you don’t want to set up split DNS, which is what you set up with the internal DNS zone. What probably kept the SRV record from working for you alone was an autodiscover.company.local DNS record, which has to be removed before a SRV record is able to be used.

  46. Dear acbrownit,
    i exported the Cert from my Exchange server and installed it on a client computer, started the process of configuration for outlook yet nothing happens. Autodiscover.company.com still returns a certificate error message, saying that it cannot be verified. Now, i will like you to show you the picture of my network. Maybe something is wrong on my public domain.

    Local Network side:
    – i have an Exchange server and a DC server (both separate)
    – The Mail server is connected to DC server network on LAN 1 while LAN 2 is connected to the ISP 2 directly.
    – The DC server is connected to the rest of the local network, which is connected to ISP 1 for Internet services.
    – The certificate on the Exchange server shows that the issuer is the DC server, issueing it to “mail.company.com” (External domain)
    – My internal domain is “company.local” and my external domain name is “company.com”.

    PUBLIC DOMAIN SIDE:
    – The records for “Mail.company.com” are pointing to the ISP 2 IP Address.
    – The records for “autodiscover.company.com” point to the same ISP 2 IP address.

    – My public domain is hosted by VODAHOST and i can’t find anywhere in my cpanel where i can create SRV records.

    My suggestion:
    Can it be that the error is because the certificate for autodiscover.company.com cannot verify the issuer, “my DC.local server”? If not the case, what will be the impact if i point “autodiscover.company.com” to the ISP 1 IP address?

    Please guys help me out. I need this done else, i will face sanctions or loose my job. OWA is not as professional as Outlook Anywhere.

  47. Thanks Acbrownit. How do i know if i have an Enterprise Root CA or not? Secondly, do i export the cert from the Exchange server or from the AD DC server?
    Thanks

  48. Hi everyone,
    Please i need help with configuration of outlook out of domain. Everytime i try to configure outlook 2010 clients out of my domain, autodiscover does not succeed. I always have errors relating to ceritificates, but if that same computer joins the domain, autodiscover will automatically configure outlook.

    This problem makes it difficult for even mobile phones to be configured using ActiveSync – Blackberry fails, some Android phones fail too, while others will succeed.

    Please help as this may cause me my job because i am not skilled with Exchange.

      1. Your certificate errors are due to the fact that the Certificate Authority that issued the certificate is not trusted by the devices or computers that are trying to connect to Exchange. Since domain computers don’t have that error, it seems to me like the person who set up your exchange environment used an Enterprise CA to generate the certs. This is fine, but you have to export and import the Root CA cert on each device you want to accept that cert. You might try using a SRV record instead of autodiscover.company.com in your public DNS (Just remove the autodiscover.company.com entry in public DNS and add a SRV record.) I have heard that SRV records will ignore SSL error messages, but have not tested this yet.

        Otherwise, you would need to get an SSL certificate from a valid Third Party CA to get your Autodiscover working without error messages. Run a google search for Exchange third party certificate and follow the instructions from any of the top hits.

  49. Pingback: [MS Office - 2013] Proxy Authentication Prompt

    1. Hi Sir,
      I’ve managed to fool the system. I’ve set the externaluri and internaluri to the exisiting server, but on the outside autodiscover address. That way you can authenticate to the domain instead of the internal no certificate server. Problem solved. Thank you for your time!

  51. Hello sir,

    I’m having an issue with the certificate. What we have is one domain domein.local and I’ve installed a secondary server e.q. dc02.domein.local and installed with Exchange 2013 on it. dc01.domein.local also has Exchange 2013. I’ve got AD replicated as well as Exchange 2013.
    Now the certificate holds only the basics of the Exchange 2013 services, plus the dc01.domein.local. So the certificate for dc02.domein.local is not valid en Outlook users get an error 10 proxy certificate error.
    For our external access we have https://autodiscover.domein.com
    So internally Outlook causes the error 10 certificate is not valid for this domain (host fqdn).

    I’ve tried with CNAME and your SRV records to mislead the client that it’s coming from dc02.domein.local but I must be missing something, or applying it wrong since the outlook client popups with a certificate error once you select new mail.

    Would you be so kind to help me out?

    Best regards,

    Martijn

    1. Just so you know, it’s usually a bad idea to install Exchange on a Domain controller. It’s supported, but Exchange can do some odd things in that configuration. For your situation, what you would want to do is configure your SRV record so it points to autodiscover.domain.com as the service host. This will cause your clients to go out and in unless you have a DNS zone for domain.com in your internal network and A records in it that point autodiscover.domain.com to one of your Exchange servers. You’ll also want to make sure that each of the exchange servers has a certificate that is valid according to the other exchange server. That means that whatever certificate you use on each exchange server should be valid when coming from the other exchange server. This is because the Exchange CAS role will automatically contact and then proxy communication between itself and whichever CAS server is closest to the user’s Mailbox Database server. If there is a certificate problem in that transition, you’ll get certificate errors.

      1. Hi Sir,

        We do have a forward lookup zone autodiscover.domain.com which has A and NS records.

        And as I just stated it was solved, it’s not.

        Furthermore at this moment I do not have a valid certificate for the second server.

        Do you have some more idea’s on how to solve this right now?

      2. To ellaborate, the host A records are added automaticly again, so deleting the host A records have a short effect. After some minutes the AD register again and the certificate is invalid again.

  52. Hoping you can help me out. I’m getting the “your automatic reply settings cannot be displayed because the server is unavailable. Try again later.” error when trying to set up my Out Of Office on Outlook 2013. All other versions are working fine. When I do the AutoConfiguration Test it shows the OOF url as https://mail.domain.com/ews/exchange.asmx. Any suggestions?

    1. It likely isn’t a problem related to autodiscover. Most likely there is a service on the Exchange server that is not running properly. It would be difficult to resolve this issue without looking at things.

  53. OK so my brain is hurting and I intend to read allot about DNS A records and SRV records but I am hoping someone can give me a solution to the following:

    Server1 – Domain Controller
    Server2 – Exchange Server

    Exchange 2013 server setup fresh but clients internally cannot connect to the server using Outlook. So far I can confirm the following:

    I created a self signed cert with loads of entries including:

    owa.myexternaldomain.com
    myserver.myinternaldomain.local
    mail.myexternaldomain.com
    autodiscover.myinternaldomain.local
    autodiscover.myexternaldomain.com
    myserver
    myinternaldomain.local
    myexternaldomain.com

    On running :
    Get-ClientAccessServer :: FL AutoDiscoverServiceInternalUri
    the following is returned:

    https://mail.myexternaldomain.com/autodiscover/autodiscover.xml

    ===========================

    If I ping autodiscover.myexternaldomain.com the IP address is correctly resolved so I can get to the firewall.

    The firewall has a rule that allows HTTP and HTTPS to the domain controller.

    The domain controller has a SRV record within which reads:
    _autodiscover
    _tcp
    0
    0
    443
    Host: autodiscover.mylocaldomain.local

    What am i missing??? Anyone know?

    1. Self signed certificates will always fail authorization unless they are installed in the trusted CA store on the computer. If you open your Exchange server in a web browser, you can view the details of the certificate and install it to remove certificate errors, but you have to do this one every computer that accesses the server. The solution here would be to get a Third Party Certificate from a public registrar.

  54. Nice article.

    I created my certrequest through emc and selected the relevant services to be used with the certificate. I bought my certificate at supplier but now when I run a connectivity test tool, It tells me autodiscover is not working because my certificate is wrong. If I view the details the cert only states my cn=mail.domain.com and I can’t find autodiscover.domain.com in the cert..

    Why would this happen and how can I fix this without buying a new certificate?

    Thanx

      1. So I asked my ISP to create the SRV record for autodiscover.domain.com but for some reason my autodiscover service is still not working. I asked ISP for a SAN UCC certificate but instead they gave me a normal one. Now i’ll have to purchace a new SAN certificate according to them… Think i’ll rather change ISP…

        Anyway, Thanx for the help.

        1. Go to testexchangeconnectivity.com and run some of the tests there. That should help you pinpoint the issue. Your Autodiscover Web Directories may be broken or something like that. That site will help you figure stuff out.

  55. Great Blog, I have used the SRV features for years and ActiveSync has worked with many of our company phones, but recently I notice that I’m experiencing some problems getting ActiveSync to work with Window 8.1 even though autodiscover is enabled using split DNS.

  57. acbrownit :
    How do you mean your autodiscover service isn’t available onthe internet? If your internal and external dns domains are the same, you should just be able to add an A record in your public dns zone that points autodiscover.company.com to your client access server’s public ip address. If you have your Outlook Web Access available on the internet, the ip would be the same for autodiscover. You would need to make these changes on you public dns, not your internal dns, which is what your dcs control.

    Hi,

    Thanks for replying so fast.

    My autodiscover service isn’t available on internet but locally (within our LAN). My internal/external domain have the same name but they use different DNSs.

    My OWA is available in the following URL:

    https://mail.mycompany.com/OWA

    Do I need to add an A record in our external DNS pointing to
    https://autodiscover.mycompany.com or to
    https://mail.mycompany.com/Autodiscover/Autodiscover.xml

    Thanks in advanced.

  58. Hi,

    I need some help, please.

    My Autodiscover service is not accessible via Internet and I want to fix it in order to use Android/IOS devices with Exchange.

    Can I add a SRV record in my DC/DNS to fix it?

    Do I need to define my Exchange Server in the “host parameter” of the SRV?

    It’s important to note that my internal/external domains are the same. In other words:

    My Exchange Server is called: ServerName.MyCompanyName.com.xx
    And my Website is: www. MyCompanyName.com.xx

    Thanks in advanced.

    1. How do you mean your autodiscover service isn’t available onthe internet? If your internal and external dns domains are the same, you should just be able to add an A record in your public dns zone that points autodiscover.company.com to your client access server’s public ip address. If you have your Outlook Web Access available on the internet, the ip would be the same for autodiscover. You would need to make these changes on you public dns, not your internal dns, which is what your dcs control.

  61. Hi, can you add a little more info regarding the multiple domains on a single server? With SRV records in the public dns zone of the secondary domain. Am I adding SRV records for auto discover only?

      1. The way you handle SRV records for multiple domains is to create a record in each of the additional domains that points to the primary domain. So what you have there should be correct, as long as mail.domaina.co.uk is a CAS server.

  62. ACBrown, fantastic post and really easy to read.
    I wondered if i might be able to ask you a direct question as I have tried my best to follow this but I am still encountering an issue mainly due to the learning curve.

    The users suddenly started to encounter an issue with not being able to set out of office. This was quickly followed by a certificate message popping relating to a domain that was unrelated to the domain i was working on. A seperate company in effect.

    I have since found out that a wildcard exists on the public DNS which historically has pointed to this other company and was never tided up by the previous support person.

    Essentially the Exchange connectivity test fail on the server that I recently took over. It is unable to find: https://emaildomain.co.uk/AutoDiscover/AutoDiscover.xml

    Because this does not work, it went of and because of the wildcard entry on the public DNS it pulls back a certificate that is unrelated. This i am pretty sure is the case and I will get this resolved but it now means that all my efforts are going into why the first search fails.

    So the question is why can i not get to: https://emaildomain.co.uk/AutoDiscover/AutoDiscover.xml ??

    If I try this from outside i get: SSL connection error
    If i try this from inside i get: IE cannot display the page

    I followed your guide and added an entry for SRV into DNS as follows:

    Domain.local
    to
    autodiscover.emaildomain.co.uk

    but this does not appear to have had much effect.
    I am probably making a silly mistake but would appreciate your input!

    1. This is a fairly common problem. Unfortunately, there isn’t really a good work around for it. I’ll explain. In the blog post, I mention the order that Outlook checks for Autodiscover information from. This occurs the first time a user attempts to connect to the Exchange server from outlook. What you are running into is a situation where the DNS host entry for emaildomain.co.uk is pointing to a server that does not have a valid certificate for your domain name. This occurs in the first autodiscover lookup. You can safely ignore that certificate error, click yes or no on it and Outlook will attempt to check the next host name in the processing list, which should be your autodiscover.emaildomain.co.uk address.

      The proper way to resolve this error is to look into your public DNS settings and change the value for emaildomain.co.uk so that it points to a server that holds a valid certificate for that host name.

      The exchange connectivity test is failing because emaildomain.co.uk is not a valid Autodiscover Endpoint. That’s fine, as long as you have a valid autodiscover endpoint that the lookup process will find, either by using autodiscover.emaildomain.co.uk or with a SRV record. If you look at the full results of the exchange connectivity test, you should see a successful attempt at connecting to at least one host name. If you do, that means the test is successful and you don’t have to worry about it (The autodiscover connectivity test will fail if any of the processing steps returns a failure, that’s fine as long as one method succeeds).

      Does that make sense?

      1. I managed to solve my issue and having checked and double checked everything i found that I could not browse any sites under my default site with IIS that were HTTPS. However, IIS was returning errors for HTTP so it confirmed that DNS and IIS was working. It took me back to certificates and specifically SSL.
        Within IIS, SSL was firmly in my sights so I deleted the binding for HTTPS and re-created and bingo. Up in came. Everything started to work including out of office.
        Huge amount learned but took allot of detective work.
        Thanks again for your article and for coming back to me. Very much appreciated sir.
        Good luck! 🙂

  63. Thank-you for an excellent blog post. Very informative. I have a SAN certificate now with .LOCAL records for both autodiscover and the servername.local. Although I have time left, I’m going to try creating the SRV record for the internal autodiscover to use the public DNS name as per your article. I believe one other step needed internally on DNS will be to recreate the public DNS zone with an A-record that the SRV autodiscover record points to. The A-record should point to the private IP of the server. Otherwise internal users may be trying to reach server.domain.com and getting directed to the public IP address of the server. Unless there is a loopback NAT in the firewall, they may need to get pointed to the private address. I already have this split DNS in place now for OWA, FTP, and other services to work correctly when on LAN, so this should be easy enough to do.

    Thanks also for the heads up on the registry fix to avoid the redirect prompt. Sounds like I will need that as well.

  64. First of all, thanks for the excellent article.
    We are in the process of migrating from Exchange 2007 to 2013 and running in the certification issue as well. At the moment we have a few users on the new 2013 mail server and all the rest is still on 2007.
    Autodiscover.domain.com points to the external IP address of the old mailserver. What is the best way to progress? Should I first change the IP to the one of the new mail server before creating the internal SRV record? Does this break the autodiscover for mailboxes still on 2007? Or is autodiscover on both servers smart enough to point everyone to the correct mail server?

    1. When you have an environment like you’re explaining, you will want to make sure that your autodiscover records point to one of the *new* CAS servers, rather than the old one. Exchange 2013 will forward users that have their mailboxes on the 2007 server to legacy.domain.com to get connectivity, so you will need to make sure you have an A record for that pointing to the 2007 CAS server, and a valid certificate that includes that name installed on the 2007 server. Basically, once you have a newer Exchange CAS server installed in your environment, all of your client interaction should go to that server as their first interaction. This will be the same for the SRV record as well.

  65. hello. great post!
    I just setup exchange 2013 on a single domain single forest, domain is xx.com.pk. All my internal and external url are the same mail.xx.com.pk .
    I have generated a cert internally. The DNS has an A record, Mx record etc. the outlook analyzer passes all tests. The connectivity test fail as it attempts to go outside and gives a ssl error. web access works no cert error.
    I want to use the server internall. Then configure externally.
    i tried connecting outlook 2013 client but it would give an error (exchange server not present…). I removed ipv6 and desktop connected with auto discovery. I then tried another client with ipv6 removed but it would not connect. I changed setting in security tab to auto negotiate and after a while it picked up the uuid and logged into outlook.
    my question is
    1. will srv allow autodiscovery to work on the intranet.
    2. it seems as if the client goes out of the network before using the dns entries from the local dns server to redirect internally. is this because of ipv6?
    3. i tried getting the second client to use ipv4 over ipv6 but did not get autodiscovery as in client 1 above.

    1. You have kind of an unusual situation there. I apologize for not getting back to you sooner about it. In your situation, a SRV record probably won’t be much use, since both internal and external DNS has the same domain name. You should probably look at troubleshooting your DNS resolution, since your client machines should be looking to internal DNS before going to public DNS for information. I would look at the IP addresses your clients are using for DNS. If they are looking at your External DNS servers before Internal, that may be the cause of your problem.

  66. Great post! I have been calling microsoft to resolve the issue regarding Outlook hangs after few minutes.The problem started after upgrading to new O365. It’s been a week but no luck. I am glad I saw your post and it did fix my problem. Thank you!

    1. Thanks for your reply I’m not sure if its related to the same issue. But now the remote exchange server address cannot be contacted externally only within the domain network .
      I can contact by IP but not by name.
      I was able to contact the exchange server outside the network using a dynamic ip updater.

  68. Hi thanks for your reply,

    The certificate that outlook detects is incorrect it detects a public certificate that from my knowledge has never been purchased. So its not picking up the certificate that was created on the server.

    Will it solve this problem as well?

    thanks

  69. Hey guys i am having a similar problem. When outlook users try to auto discover there settings or even when they already have there exchange accounts already setup in outlook they get an error saying “the name on the security certificate is invalid or does not match the name of the site” and it looks like it tries to connect to autodiscover.xx.com.au. This only happens on domain joined machines.

    What can i do to fix this? This all started in Small Business Server when i had to renew the SSL certificate through one of the wizards in the console.

    I would appreciate your help guys.

    thanks

    1. This sounds like a situation where a SRV record can help out. The error is likely due to a difference in the internal DNS zone and what shows up in your SSL cert. What you can do is remove any autodiscover records in your internal DNS and replace them with a SRV record that points to a host name that shows up on the SSL certificate as explained in this article. There are other ways to solve it, but this is one easy way to do so.

  70. Thanks for the quick reply.
    The Exchange 2007 server is at our corporate office. We have 50 people here and about 200 users remotely using Exchange over HTTP.
    Our web server is businesscatalyst/adobe.

    When users on Outlook 2013 try to do the autosetup, they get 2 ceriticate warning pop-ups.
    See: http://social.technet.microsoft.com/Forums/en-US/outlook/thread/f08ea5e5-5ca2-4712-a654-ab22b00ebb5e
    These also happen sometimes when logging on to Outlook.

    This does not seem to be an issue in other versions of Outlook.

    1. Okay…It looks like what’s happening is you have your Top Level Domain Name americanavc.com pointing to a web server that is using an SSL certificate that isn’t valid for that name. What you will probably need to do is contact your web host and have them either remove port 443 access to your website (if you aren’t using it) or get set up with an SSL certificate on your hosted website that is valid for your domain name.

      Because Autodiscover talked to the straight DNS domain name first, it will attempt to look at https://americanavc.com/autodiscover/autodiscover.xml before attempting to look in other locations. If you were to navigate to that in a web browser you’d get a security error. This is the core of your problem. Ensuring that americanavc.com has a valid certificate tied to it will probably fix this problem.

      1. checking to see if they can disable it. currently they do not allow “custom” certificates. one more reason I would like our marketing department to move to a new hosting platform. 🙂 Thanks for the guidance.

  71. We are having issue with Outlook 2013 getting a cert error from our www server (hosted externally).
    Is there a redirect we can put in place on the webhost to redirect to the autodiscover address wihout this ceritifcate prompt?
    I do not think an Alternate Name will help – unless World Secure Systems added every one of their clients to the cert.

  72. I just need a bit of clarification. In the box above if my internal domain name is xyz.com and the external is xyz-test.com when creating the server record do I put xyz.com in the domain field and autodiscover.xyz-test.com in the host offering this service field? Or just enter the values as you have posted them.

    1. If internal is xyz.com and external is xyz-test.com, you would put the srv record in the xyz.com zone in your internal domain’s DNS servers and point it to the external host name for your CAS server or the external autodiscover record (generally these will be the same IP Address).

  73. Pingback: Active Directory Domain Naming in the Modern Age | AC Brown's IT World

    1. Well, considering the recent changes to best practices Microsoft has made lately, it may be necessary to implement this solution in a production environment. Specifically, MS has started recommending the use of public DNS name spaces for AD domains primarily because of the issues that having a non-public DNS namespace causes with autodiscover and many of the features they are rolling out for much of their future solutions. If companies are on a non-public namespace internal domain name already and can’t feasibly move to a public namespace internal domain, adding the SRV record to the internal DNS Forward Lookup Zone is a very valid and actually recommended way of resolving internal Autodiscover issues. It’s not a best practice to use a single-name SSL cert, but if that’s all you’ve got, that’s all you’ve got.

      In short, Best practices are there as a guide, not as hard rules that can never be broken. It’s always important to understand not only what the best practices are, but *why* they’re best practices.

      2. http://technet.microsoft.com/en-us/library/cc772970%28v=ws.10%29.aspx has an explanation of their recommendations. Basically, they now recommend configuring the Internal domain to be a subdomain of your public domain. So if you have domain.com as a public domain that you own, you would set your internal domain name to be corp.domain.com or internal.domain.com. This can result in a bit more typing to get around, but it helps you to avoid some really sticky issues that exist with having domain.com as an internal domain and also the issues related to having domain.local as an internal domain.

        To be more specific, when you use domain.com as an internal domain, you end up with split DNS issues, where you have to have an internal DNS zone with A Records pointing to resources you have out in Public (for internal users to access those resources) as well as an external Zone that has the same records for external access to resources. Managing two DNS zones that have the same information but can’t actually communicate with one another can become a tremendous headache in a large environment.

        If you use domain.local as your Domain Name, you get a little bit more security, but you run into an issue where you can’t actually obtain certificates from 3rd Party Certificate Authorities. 3rd Party CAs are now refusing to generate SSL certificates that use non-public Top Level Domains like .local for a number of really good security reasons (You can’t verify that you own domain.local, and neither can a potential attacker. If an attacker can get a domain.local certificate that matches yours, they can initiate a man-in-the-middle attack that breaks the SSL secure stream without having to decrypt anything). This is the issue that you run into when dealing with Autodiscover. If the name you use to connect to exchange isn’t on the SSL certificate used to publish services, you’ll get a certificate error every time you open Outlook.

        As I mentioned, there’s a couple ways around that. I personally like the SRV record method, simply because it doesn’t require re-configuration of the Exchange server to work.

  77. Hi,
    great blog, this did help me.
    The only message users will get the first time after adding the srv-record is : Your account is redirected to …. do you trust this ?

    Can this message be hidden, or automatic trust by some GPO or something?

    Thx

Leave a Reply