Troubleshooting and Introduction for Exchange 2007/2010 AutoDiscover - Details about “Test E-mail AutoConfiguration” RRS feed

  • General discussion


    AutoDiscover is a new feature in Exchange 2007, to provide access to Microsoft Exchange features (OAB, Availability service, UM) for Outlook 2007 clients or later.

    We can determine whether problems related to AutoDiscover via OWA.

    For example:

    OOF is not working in Outlook Client but it is working in OWA.

    When we realized this issue is not related to Outlook Client side and network side after performing some troubleshooting steps, it should be something abnormal on AutoDiscover.

    There is a common tool to check AutoDiscover in Outlook, Test E-mail AutoConfiguration.

    Today, we will introduce AutoDisocver and “Test E-mail AutoConfiguration” in details. Hope it is helpful for AutoDiscover troubleshooting and self-learning.

    1. Differences between “Test E-mail AutoConfiguration” and other tools

    The “Test-OutlookWebServices” cmdlet allows us to test the functionality of the following services:


    Exchange Web Services

    Availability Service

    Offline Address Book

    When we run “Test-OutlookWebServices”, it returns all the web services’ states.

    However, some information are useless for some scenarios.

    For example:

    We just want our Exchange 2010 Server working internally. So it is unnecessary to enable Outlook Anywhere.

    However, when we run “Test-OutlookWebServices”, it returns Outlook Anywhere errors because the Outlook Anywhere does not need to been enabled.

    In contrast, using “Test E-mail Autodiscover” is more intuitive.

    If there is any problems, it will return error code from the test result, like 0x8004010F etc. We can do some research from TechNet articles or MS KBs.

    Although it is difficult to say where the specific problem is just via the error codes, we can combine with IIS logs to perform troubleshooting and find the root of problem.

    2. How to use “Test E-mail AutoConfiguration” Tool

    a. Open Outlook, we can find there is an Outlook Icon at the right bottom of System tray. Holding down “Ctrl” button and right click the Outlook Icon, we will see “Test E-mail AutoConfiguration” option. Please see Figure 01.

    Figure 01

    b. Click “Test E-mail AutoCofiguration” and input user name, uncheck the “Use Guessmart” and “Secure Guessmart Authentication” checkboxes, then click “Test”. Please see Figure 02.

    Figure 02

    c. “Test E-mail AutoConfiguration” result panel and log panel. Please see Figure 03 and Figure 04.

    Figure 03

    Figure 04

    3. How to understand “Test E-mail AutoConfiguration” result

    According to the Figure 03, we found there are many URLs in the “Test E-mail AutoConfiguration” result panel. Let us understand the details of these URLs.

    If we these URLs are not the correct ones, we can re-setting or re-creating them via commands.

    - Internal OWA URL:

    OWA internal access.

    - External OWA URL:

    OWA external access.

    Availability service URL:

    Free/Busy, OOF and meeting suggestions.

    - OOF URL:

    Out of Office access.

    - OAB URL:

    OAB access.

    - Exchange Control Panel URL:

    ECP access.

    4. AutoDiscover Tips

    - AutoDiscover Service itself is a web application running on the AutoDiscover virtual directory (not a server service) designed to provide connection information to various clients.

    - The AutoDiscover service is automatically installed and configured when CAS role is added to any Exchange Server.

    - AutoDisocver virtual directory is created in IIS within the Default Web Site.

    - A Sercive-Connection-Point (SCP) object is created in AD.

    - The SCP contains a URL to the AutoDiscover service. This is for intranet clients so they do not have to use DNS to locate the AutoDiscover service.

    - In AD this object is located at the following location:

    DC=<domain>, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=First Organization, CN=Administrative Groups, CN=Exchange Administrative Group, CN=Servers, CN=<CAS Name>, CN=Protocols, CN=AutoDiscover, CN=<CAS Name>

    - Setup creates the AutoDiscover URL based on the following structure:


    - If a PKI certificate is not already present, a self-signed certificate is installed on the Default Web Site. 

    To help allow this certificate pass the Issues to test it is set up with a Subject Alternative Name containing urls.

    If a PKI certificate is present, that certificate is utilized and configured for use in IIS.

    - The Outlook Provider is used to configure separate settings for the Exchange PRC protocol (internal to network), Outlook Anywhere (Exchange HTTP protocol), and WEB:


    The EXCH and EXPR setting are vital for the proper configuration of Outlook.

    5. AutoDiscover Workflow

    General Process flow:

    There are various components surrounding the AutoDiscover Service and all are necessary to complete a request. Including IIS, AutoDiscover service itself, the provider, and AD.

    a. Client constructs service URL and submits Autodiscover Request. First attempt to locate the SCP object in AD. So, DNS is not needed.

    b. IIS Authenticates User.

    c. Is the Autodiscover service in the appropriate forest?

    + If YES.

        1) Parse/Validate Request

        2) Is there a provider that can service the Request?

        ++ If YES

          a) Config provider processes request and returns config settings.

          b) Return config setting to client

        ++ If NO

        Inform client we cannot process request

    + If NO.

    Redirect client to Autodiscover service in the appropriate forest.

    Methods to find Autodiscover services: SCP and DNS


    a. Find SCP first.

    • The SCP contains the URL to the AutoDiscover service.
    • URL:’ FQDN)/AutoDiscover/AutoDiscover.xml
    • If more than one SCP object is found in AD (it means there are multiple CAS servers in the Exchange organization), Outlook client will choose one of the SCP entries that are in the same site to obtain the AutoDisocover URL.

    b. If we cannot find SCP object, then Outlook client will use DNS to locate AutoDiscover.

    • Outlook parses out the domain (SMTP suffix) via your EmaiAddress, then attempts to connect to the predetermined order of URLs via the suffix.
    • For example: If my email address is

    Outlook tries POST commands to the following order of URLs:

    NOTE: The URLs above is by design, hardcode and cannot be changed.

    c. If those fail, Outlook tries a simple redirect to another URLs in IIS:

    If none of these URLs work then DNS is most likely not set up correctly.

    • We can test that by pinging one of the above URLs.
    • If that is successful, we must ensure the URLs or are actually pointing to the CAS server.
    • If the ping fails then there is a chance that DNS is not set up correctly so be sure to check that the URLs are even registered.

    NOTE: If is a non-CAS server, we should add a Host record with just AutoDiscover. And point that entry to your CAS server that is running AutoDiscover.

    d. If still failed, we can use DNS SRV lookup for, then “” returned. Outlook will ask permission from the user to continue with AutoDiscover to post to


    It first tries to locate the Autodiscover service by looking up the SCP object in AD. However the client is unable to contact AD, it tries to locate the Autodiscover service by using DNS.

    Then, same as step b, c, d in Domain-joined scenario.


    6. How to change the AutoDiscover service location order forcibly?

    By default, Outlook client locates AutoDiscover service in that order above.

    We can also change the order forcibly.

    a. If we want to locate AutoDiscover service via one of the autodiscover URLs, please running following command in EMS:

    Set-ClientAccessServer -identity <servername> -AutodiscoverServiceInternalUri that you want)


    b. If we want to locate AutoDiscover service via SRV record, please follows this KB to set up SRV:

    7. How to check AutoDiscover Healthy

    a. We should make sure the AutoDiscover is healthy before using AutoDiscover to perform troubleshooting.

    b. We can browse following URL in IE explorer:

    If it returns “code 600”, that means AutoDiscover is healthy.

    Screenshot as below:

    c. AutoDiscover itself returns errors to the requesting client if the incoming request does not contain the appropriate information to complete a request.

    The following table explains the possible errors that could be returned.

    Error   Value



    Mailbox not found and a   referral could not be generated.


    Address supplied is not   a mailbox. The provided email address is not something a client can connect to.   It could be a group or public folder.


    Active Directory error.



    The 600 “Invalid Request” error is returned because a user name was not passed to the service. That is OK for this test because this does confirm the service is running and accepting requests.

    d. If AutoDiscover service is not working well, I suggest re-building the AutoDiscover Virtual Directory for testing.

    Steps as below:

    1) Running following command in EMS to remove the AutoDiscover VD (we cannot delete it via EMC):

    Remove-AutodiscoverVirtualDirectory -Identity "CAS01\autodiscover("

    Please refer: 

    2) Running following command in EMS to verify whether we have removed the AutoDisocver VD successfully:

    Get-AutodiscoverVirtualDirectory | FL

    Please refer:

    3) Running following command in EMS to re-creating a new AutoDiscover VD:

    New-AutodiscoverVirtualDirectory -Websitename <websitename> -BasicAuthentication:$true -WindowsAuthentication:$true

    Please refer:

    8. Common issues

    a. Outlook Disconnection

    Issue and Troubleshooting


    Sometimes the Outlook clients cannot connect to the Exchange server after migrating to a new Exchange server or changing to new CAS. The Outlook clients always connect to the old CAS server.

    To solve this issue, we should change the SCP via following command:

    Set-ClientAccessServer -Identity <var>CAS_Server_Name</var> -AutodiscoverServiceInternalUri’FQDN)/autodiscover/autodiscover.xml


    b. Autodiscover Certificate issue

    Tips on Certificate:

    Exchange requires a certificate to run an SSL protocol such as HTTPS. We can use the certificate that supports subject alternate names (SAN) in Exchange. This is to allow the certificate to support resources that have different names, such as Outlook Anywhere and the Autodisocver Web application.

    Issue and Troubleshooting


    We receiver the Certificate Principal Mismatch error when we use a SAN certificate.


    1) Please determine the FQDN that the client uses to access the resource. Steps as below:

    OutlookàToolsàAccount SettingsàE-mailàclick the Exchange accountàChangeàMore SettingsàConnectionàExchange Proxy Settingsànote the FQND that list in the Only connect to proxy servers that have this principal name in their certificate box.

    2) Please using EMS to determine the value for the CerPrincipalName attribute: Get-OutlookProvider

    This command returns the result for the EXPR name.

    3) Please re-setting the CertPrincipalName attribute to match the FQDN via following command:

    Set-OutlookProvider EXPR –CertPrincipalName: “msstd:<FQDN the certificate is issued to>”


    9. Resource for reference:

    Autodiscover and Exchange 2007

    White Paper: Understanding the Exchange 2010 Autodiscover Service

    Certificate Principal Mismatch

    Please click to vote if the post helps you. This can be beneficial to other community members reading the thread.

    • Edited by ForumFAQ Wednesday, February 19, 2014 9:02 AM
    Wednesday, February 19, 2014 8:05 AM

All replies

  • WOW Nice Information
    Wednesday, August 13, 2014 11:32 PM
  • HI,

     I get following?  when run the test?  user is login to Domain A but accessing exchange in Domain B?

    Monday, August 18, 2014 1:03 AM