Internal DNS and Exchange Autodiscover

Update

Hey folks! This has been a very popular blog post and as such I decided to delve a little deeper into autodiscover in a new 100,000 view commemorative post called Exchange Autodiscover Episode 2: Attack of the Exchange Server. If the solution here doesn’t work for you, go over there and take a look at that post. It’s full of adventure, plot twists, damsels and…uhh…dudesels in distress, and space wizards! Okay, not really. It’s just me blathering on about the Exchange Autodiscover Service Connection Point. As a note, the solution below will help you use a SRV record to redirect autodiscover to an address that exists on an SSL certificate if you forget to (or don’t want to) put an autodiscover entry in your SSL cert. The link above will take you to a post that tells you how to fix certificate errors in an environment where you have a Private DNS name for your Active Directory domain and you use that domain to configure outlook clients, or if you have Outlook use login credentials to configure profiles automatically. So, keep reading and fixing those certificate errors!

The Issue

By now, anyone who has managed, deployed, or worked with an Exchange 2007 or later environment should be familiar with Autodiscover. If you aren’t yet, I’ll give a short Explanation of what it is and how it works.

Autodiscover is a feature that allows any Mail Client that supports Autodiscover to configure the appropriate server settings for communication so you don’t have to input everything manually. It’s very handy. Unfortunately, you can end up with a lot of headaches related to Autodiscover when you start having to deal with Certificates. The issues you may run into are specifically limited to Exchange Organizations that have a Domain Name that uses a non-public TLD like domain.local, or a public domain name that they don’t actually own and can’t use externally as well. 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 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 be configured to use HTTP only when your Exchange Server certificate is determined to be invalid in Exchange 2013). With Exchange 2007 and 2010, you will get a Certificate error every time you open Outlook. Generally, this error will state that the name on the certificate is not valid.

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 (because internal domain computers configure themselves automatically by default, this matches the Internal Domain. For example, the first place autodiscover looks is https://domain.com/Autodiscover/autodiscover.xml for external addresses. Change domain.com with domain.local for what Exchange looks for on Internal clients.

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 lately, 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

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 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 a bit more for SANs than they do for Single Name SSL certs, you can save a bit of money (for this to work, though, 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 Environment. If you have users that are not assigned a Primary or secondary SMTP address that matches the domain name listed on your 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.

About these ads
    • Pete Grimshaw
    • February 26th, 2013

    Great post on Auto Discover, will help me in future!

      • El Khiyati
      • October 16th, 2014

      Thank very match, great post

    • mvd
    • March 14th, 2013

    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

      • sysintegrity
      • March 15th, 2013

      There isn’t a default Group Policy setting that will change this for you, but if you have a Windows 2008 or Higher Domain Controller you can deploy a registry modification that will suppress that prompt by adding the redirected server as an approved Autodiscover server. A blog post from Terry Lau has more information for you: http://terrytlslau.tls1.cc/2011/10/how-to-suppress-autodiscover-redirect.html

    • Mvd
    • March 15th, 2013

    Thx. that looks great!
    This procedure is off cource NOT a best practice. But this working well for test-environments!

      • sysintegrity
      • March 20th, 2013

      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.

        • Mvd
        • March 20th, 2013

        Thx for your answer.
        Do you have an urlfor me where MS recommends the use of public-dns names for internal use?

        Thx

        • sysintegrity
        • March 20th, 2013

        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.

    • Mvd
    • March 20th, 2013

    Great,
    thx for your answer and nice post!

  1. Good explanation.

  2. 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.

      • acbrownit
      • May 16th, 2013

      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).

    • Craig
    • June 4th, 2013

    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.

      • acbrownit
      • June 4th, 2013

      Can you clarify what you mean? What is the setup here? Is your Exchange hosted externally, or is it just the Web Server that’s hosted Externally?

    • Craig
    • June 4th, 2013

    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.

      • acbrownit
      • June 4th, 2013

      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.

        • Craig
        • June 4th, 2013

        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.

    • joe
    • June 5th, 2013

    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

      • acbrownit
      • June 5th, 2013

      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.

    • joe
    • June 6th, 2013

    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

    • acbrownit
    • June 6th, 2013

    You may have a problem similar to Craig above if it’s bringing up a certificate you haven’t seen before.

      • Joe
      • June 7th, 2013

      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.

    • Tiger-JG
    • June 12th, 2013

    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!

    • Raza
    • June 26th, 2013

    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.

      • acbrownit
      • July 10th, 2013

      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.

    • Bram
    • July 15th, 2013

    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?

      • acbrownit
      • July 16th, 2013

      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.

  3. 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.

  4. 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!

      • acbrownit
      • August 22nd, 2013

      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?

      • 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! :)

    • Colin
    • August 23rd, 2013

    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?

      • Colin
      • August 23rd, 2013

      I currently have a recorded of _autodiscover._tcp.autodiscover.domainb.co.uk in SRV 0 0 443 mail.domaina.co.uk

      Is this correct?

        • acbrownit
        • August 23rd, 2013

        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.

    • Colin
    • August 23rd, 2013

    Sorry by CAS do you mean client access server or certificate authority server?

      • acbrownit
      • August 23rd, 2013

      Client Access Server. Certificate Authority Servers are referred to as CA (For info)

        • Colin
        • August 24th, 2013

        Many thanks for your help and very prompt replies.

    • Dan
    • August 29th, 2013

    Thanks a million. I had this problem in my production environment and this certificate popup drive users nuts. With srv records it went away

    • MON
    • October 13th, 2013

    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.

      • acbrownit
      • October 13th, 2013

      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.

    • MON
    • October 14th, 2013

    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.

      • acbrownit
      • November 6th, 2013

      You can do either way. If your certificate only has mail.company.com on it, use a srv record in your external dns to point clients to the existing host name.

    • Mat Kilby
    • October 16th, 2013

    Excellent blog and exactly the issue I had. Many, many thanks.

    • EMan
    • November 5th, 2013

    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.

    • Fhilliph
    • November 6th, 2013

    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

      • acbrownit
      • November 6th, 2013

      If you didn’t request a SAN certificate, you can only have one host name on the cert. If you create a srv record for autodiscover that points to mail.domain.com, it should fix your problem.

        • Fhilliph
        • November 14th, 2013

        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.

        • acbrownit
        • November 14th, 2013

        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.

    • DNSache
    • November 13th, 2013

    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?

      • acbrownit
      • November 14th, 2013

      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.

    • Michael Finley
    • November 20th, 2013

    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?

      • acbrownit
      • November 21st, 2013

      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.

    • Martijn
    • November 21st, 2013

    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

      • acbrownit
      • November 21st, 2013

      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.

        • Martijn
        • November 21st, 2013

        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?

        • Martijn
        • November 21st, 2013

        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.

    • Martijn
    • November 21st, 2013

    I’m sorry sir, read it a couple of times, the issue is solved, except for mailtips can’t be retrieved. Any suggestions?

      • Martijn
      • November 25th, 2013

      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!

    • Stanley
    • January 13th, 2014

    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.

      • Stanley
      • January 13th, 2014

      Since i cannot paste the output of the Autodiscover test using Miscrosoft Remote Connectivity Test, please click here to download:

      https://www.dropbox.com/s/xtcdwuo753pp951/Autodiscover_Test.txt

      Thank you

        • acbrownit
        • January 13th, 2014

        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.

    • Stanley
    • January 22nd, 2014

    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

    • Stanley
    • January 23rd, 2014

    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.

  5. 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.

      • acbrownit
      • January 27th, 2014

      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.

    • MattP75
    • February 12th, 2014

    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

      • acbrownit
      • March 31st, 2014

      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.

      • 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.

        • acbrownit
        • March 31st, 2014

        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.

      • 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.

        • acbrownit
        • March 31st, 2014

        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.

      • 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.

        • acbrownit
        • March 31st, 2014

        Out of curiosity, if you were to navigate in a web-browser to https://autodiscover.company.com/Autodiscover/Autodiscover.xml
        Do you get a certificate error in the browser? If so, what host names are on the certificate that shows up when you do that?

      • 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.

        • acbrownit
        • March 31st, 2014

        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.

    • 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

    • SysIT
    • March 11th, 2014

    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….

      • acbrownit
      • March 11th, 2014

      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.

    • Awais
    • March 26th, 2014

    Thank you very much for this informative blog.It fixed my issue.

    • AL
    • May 22nd, 2014

    Thanks! this worked well with resolving Cert Warning in Outlook 2010 but outlook 2013 still comes up with this warning…any ideas?

      • acbrownit
      • May 23rd, 2014

      Check the part 2 post I wrote. You may need to modify the SCP in AD.

    • AL
    • May 23rd, 2014

    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?

      • acbrownit
      • May 23rd, 2014

      There are some registry entries that control Autodiscover caching. Do a google search on autodiscover cache for outlook. That should give you something.

    • rz
    • May 26th, 2014

    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.

      • acbrownit
      • May 26th, 2014

      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.

        • rz
        • May 28th, 2014

        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.

    • Adrian
    • June 30th, 2014

    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?

      • acbrownit
      • June 30th, 2014

      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.

    • Adrian
    • June 30th, 2014

    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.

  6. 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.

    • Ahmed
    • September 1st, 2014

    Thank you. I migrated from sbs 2008 to exchange 2013 and the dns autodiscovery fix helped me fix the outlook autodiscovery mismatch. Well done and simple.

    • czaste
    • September 12th, 2014

    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.

      • acbrownit
      • September 13th, 2014

      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.

        • czaste
        • September 13th, 2014

        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.

    • Jason
    • October 22nd, 2014

    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?

      • acbrownit
      • October 23rd, 2014

      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.

  1. April 15th, 2013
  2. January 6th, 2014
  3. April 4th, 2014
  4. June 21st, 2014

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: