Delays or errors when configuring user profiles, accessing a shared mailbox, room mailbox, public folder or shared calendar from the Outlook client

  • Article

By default, whenever we try to access or configure a new profile from the Outlook client we make an Autodiscover request to the Client Access Server, in order to obtain the information on where the mailbox is located.

In this case we have two major scenarios:

  • Scenario 1 - autodiscover.contoso.com is pointing to Office 365 (autodiscover.outlook.com)
  • Scenario 2 - autodiscover.contoso.com is pointing to on-premises Exchange server (hybrid deployment)

Scenario 1.

Regardless of scenario the Outlook client has the same steps when performing the Autodiscover lookup.

For example if we configure or access the mailbox user@contoso.com the lookup will be made as per below.

  1. SCP – Only when accessing from a domain joined machine and have an on-premises Exchange.
  2. https://contoso.com:443/Autodiscover/Autodiscover.xml
  3. https://autodiscover.contoso.com:443/Autodiscover/Autodiscover.xml
  4. Local XML
  5. https://autodiscover.outlook.com/Autodiscover/Autodiscover.xml where it will receive a HTTP 302 redirect to https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
  6. Cached URL in the Outlook profile (new for Outlook 2010 version 14.0.7140.5001 and later versions)
  7. Direct Connect to Office 365 (new for Outlook 2016 version 16.0.6741.2017 and later versions)

ISSUE 1

In this scenario the issue comes at STEP 2, when contoso.com is pointing to a Public IP that responds to port 443 or 80. Normally a webserver or other network device like router or firewall.

If the webserver is not properly configured to redirect or drop the requests, it will try to respond to the HTTP Get request for Autodiscover/Autodiscover.xml.

Autodiscover is an IIS Virtual Directory on Exchange so it is normal for Outlook to make HTTPS and HTTP requests. Please check this.

However, it is not normal for a webserver to try and locate a resource which it don't have. In this case Autodiscover/Autodiscover.xml.

This will cause delays as Outlook will enter into a timeout state until it will move to the STEP 3 and lookup for https://autodiscover.contoso.com.

After that, the request will be forwarded as per the CNAME record to autodiscover.outlook.com which redirects it to autodiscover-s.outlook.com.

How to see if you are facing this behavior?

  1. Log on to your Windows machine

  2. Start Registry Editor.

    • In Windows 10, Windows 8.1, click Start, on the Search Box type regedit, and press Enter
    • In Windows 7, click Start , type regedit in the Search programs and files box, and then press Enter.
    • In Windows Vista, click Start, type regedit in the Start Search box, and then press Enter.

  3. Locate and then select the following registry sub-key:x.0NOTE*: x.0 in the above registry path corresponds to the Outlook version (15.0 = Outlook 2013, 14.0 = Outlook 2010, 12.0 = Outlook 2007)*   HKEY_CURRENT_USER\Software\Microsoft\Office\ \Outlook\AutoDiscover

  4. Create a D-WORD (32-Bit) Value key with the name of ExcludeHttpsRootDomain and the Value Data of 1: diagram 1

  5. Reproduce the behavior.

    Now the root domain will be excluded from Autodiscover and if this is what is causing the issue, you will not experience it anymore.

    IMPORTANT*: Excluding the HTTPS root domain is not a long-term solution for this issue, and it is not recommended. This workaround is provided as immediate relief for the issue. As soon as the web service provider or web hosting provider resolves the issue, the Outlook registry key must be removed.*

    For reference please check also the below articles:
    https://support.microsoft.com/en-us/kb/2212902
    https://support.microsoft.com/en-us/kb/2612922

    NOTE: If you are in an Active Directory environment and you had an Exchange server, you can try also to remove the SCP lookup.For this you will have to perform the same steps but for the registry key ExcludeScpLookup

    ISSUE 2
    There is another issue that could arise at STEP 3, and it is caused by the internal Firewall.

    1. Outlook will do https://autodiscover.contoso.com:443
    2. The DNS will resolve autodiscover.contoso.com to autodiscover.outlook.com, based on the CNAME you have created
    3. So Outlook will do actually https://autodiscover.outlook.com:443/Autodiscover/Autodiscover.xml
    4. DNS will resolve autodiscover.outlook.com to the corresponded IPs based on it's region location But is autodiscover.outlook.com designed to respond on port 443?NOSTEP 5What is GEO DNS?What is the issue with this?STEP 5How to see if you are facing this behavior?
    5. First check your Firewall logs and check for Resets from the IPs behind autodiscover.outlook.com
    6. Perform the same steps from ISSUE 1, but this time for the registry key ExcludeHttpsAutoDiscoverDomain Scenario 2.So how will Autodiscover knows to locate a mailbox located in Office 365?
    7. The former user mailbox becomes a "Mail User" with a Remote Mailbox in Office 365
    8. In Exchange the Remote Mailbox will have the parameter Remote Routing Address set to user@contoso.mail.onmicrosoft.com
    9. In Active Directory the attribute TargetAddress will have the address set to user@contoso.mail.onmicrosoft.com user@contoso.mail.onmicrosoft.com
    10. The user mailbox or the shared mailbox were created directly in Office 365 and thus it will not have the Remote Routing Address of user@contoso.mail.onmicrosoft.com.
    11. A user is created only the local Active Directory and does not exists as a recipient in the on-premises Exchange server. It exists only on Office 365 as you will be allowed to assign a license to in order for the mailbox to be provisioned.NOTE: In a hybrid deployment it’s recommended that all the management of both on-premises and cloud recipients be made from the on-premises Exchange server.https://technet.microsoft.com/en-us/library/ff625227(v=exchg.141).aspxhttps://technet.microsoft.com/en-us/library/ff607313(v=exchg.150).aspxError: Unable to expand the folder. The set of folders could not be opened. The operation failed.Error: Cannot expand the folder. The set of folders cannot be opened. Microsoft exchange is not available. Either there are network problems or the exchange computer is down for maintenanceError: You Don’t have permission to view this calendar
    12. For more information, please check the below articles:
    13. - Exchange 2010
    14. - Exchange 2013
    15. For example, when you will try to expand such shared mailboxes, user mailboxes or public folders from Outlook you could receive two distinct errors.
    16. The Autodiscover requests is delayed or dropped by Load Balancers, Firewalls etc.
    17. In this case a deeper investigation has to be done, and we will not address it in this article.

  6.  

  7. Now the root domain will be excluded from Autodiscover and if this is what is causing the issue, you will not experience it anymore.

  8. For reference please check also the below articles:

  9.  

  10. There is another issue that could arise at

  11. , and it is caused by the internal

  12. .

  13. By design as said Outlook will always perform the above steps, because Outlook is design for both On Premise users and Office 365. You cannot go to Outlook and say, for Office 365 users go directly and perform the Autodsicover for

  14. So Outlook will always try to do https://autodiscover.contoso.com:443/Autodiscover/Autodiscover.xml.

  15.  

  16. . The answer is

  17. .

  18. This is where the

  19. from the Autodiscover proccess, HTTP redirect, comes in place.

  20. By design autodiscover.outlook.com responds only on port 80 as it is used for Geo DNS.

  21. The issue comes when the internal Firewall ignores the repeated Connection Resets coming from the IPs behind autodiscover.outlook.com due to the fact that port 443 is not opened.

  22. A Firewall should acknowledge the Connection Resets and drop the connection, allowing Outlook to pass to

  23. from the Autodiscover process.

  24.  

  25. In a hybrid environment the autodiscover.outlook.com will always be pointing to the on-premises Exchange server.

  26. Whenever you migrate a mailbox from your on-premises Exchange to Office 365 some changes are made also in the on premises environment.

  27. So when an Autodiscover request will be made to the on-premises Exchange server it will be forwarded to Office 365 based on the address

  28. .

  29. In this type of scenario, the issue comes when: