This blog post is part 2 of the three-part series on Microsoft Teams and on-premises Exchange mailboxes.
Teams Backend AutoDiscover
The Teams Backend Services use AutoDiscover Version 2 to find a user's Exchange mailbox on behalf of a Teams client. This AutoDiscover V2 call is an anonymous call for performance reasons to determine the Exchange target URL for the mailbox sought as quickly as possible. As already mentioned in the previous blog post, the Teams Backend Services query the AutoDiscover endpoint of Exchange Online first. If Exchange Online does not host the mailbox, the services receive an HTTP redirect to search for the local Exchange organization's endpoint.
The detailed steps are:
1. The Teams Backend Services query the Exchange Online AutoDiscover endpoint for the URL for the EWS protocol using an AutoDiscover V2 JSON query
2. Exchange Online verifies the recipient type for the email address contained in the JSON query and replies with one of the following options:
a. RecipientType: Mailbox
The mailbox is an Exchange Online mailbox. No further steps are necessary. The Teams Services have the information they need to access the users' calendar.
b. RecipientType: MailUser
Exchange Online determines the AutoDiscover endpoint based on the ExternalEmailAddress attribute; in this example autodiscover.varunagroup.de
3. Exchange Online replies with an HTTP 302 redirect to autodiscover.varunagroup.de
4. The Teams Backend Services send an AutoDiscover V2 JSON query for the URL for the EWS protocol
5. On-premises Exchange Server replies with an external EWS URL of a virtual Exchange Web Services virtual directory
6. The Teams Backend Services use the received URL to establish a connection to the on-premises Exchange organization
But what do the Teams Backend Services exactly, after receiving the EWS URL? The services perform the following steps:
As you can see, accessing the calendar of a user mailbox hosted in an on-premises Exchange organization is complex. This complexity can lead to errors.
How can you now perform an error analysis for the AutoDiscover process and the subsequent calendar access? Let's start with AutoDiscover.
Since Microsoft Teams Backend Services perform all AutoDiscover and other client accesses, there are no viable troubleshooting steps on the local Teams client. The client itself must have access to the internet and proper DNS name resolution working.
Because AutoDiscover V2 uses anonymous access, you can test it for any email address. This self-test helps you as an IT administrator check AutoDiscover for a users' email address that might not work correctly. You can check the AutoDiscover response using PowerShell or with the help of a browser.
Run the Invoke-RestMethod cmdlet with the following Uri-Strings for EWS and REST protocol
Out-of-Office information and calendar-based presence status requests use the on-premises REST-endpoint.
Ensure that there are no unsupported characters in the Uri.
You can test and query the AutoDiscover endpoint using the following URLs
For an on-premises mailbox, you receive an AutoDiscover response from your on-premises Exchange Server, like the one shown in the following screenshot.
Perform a Fiddler trace for a more detailed error analysis when executing the HTTPS queries. The trace results help you to identify other possible sources of error, i.e., a failed TLS handshake.
If an error occurs while determining the AutoDiscover information, this does not automatically imply a problem. Check the following options:
Most likely, the user has an additional mailbox in Exchange Online. Resolve the double mailbox situation.
The ExternalUrl attribute configuration is not correct for all virtual directories.
Expected URL: https://mail.emea.varunagroup.de/EWS/Exchange.asmx
Until March 2021, AutoDiscover V2 is not AD site-aware. The March 2021 cumulative updates for Exchange Server 2016 and 2019 fix this issue. Read more about the updates in this blog post.
The next steps to identify connection problems lead us to the on-premises Exchange servers. With a local network trace, you can determine whether there are TLS handshake errors. Please note that your Exchange Server systems must be configured correctly for TLS 1.2. The TLS 1.2 configuration might require manual steps if you use Exchange Server 2016 or Exchange Server 2013.
If there are no errors in the TLS handshake, you must check the Exchange server's log files. Checking the log files on the local Exchange servers requires several steps. Depending on your local Exchange organization's size and the number of Exchange Servers, this check can be very complicated.
The following diagram shows the participating Exchange Server components of a single Exchange Server for incoming connections from the Teams Backend Services to the Exchange Web Services endpoint.
The IIS Default website receives the incoming HTTPS connection from the Teams Services and passes it to the Frontend Proxy component, i.e., EWS or REST. You find information about those two connections in the W3SVC1 (1) and the HttpProxy logs of the targeted protocol (2). The Frontend Proxy component proxies the connection to the Exchange Backend website of the Exchange Server, where the active database copy containing the user mailbox is mounted. This is not necessarily the same Exchange Server accepting the Frontend connection. You find information about this proxied connection in the W2SVC2 IIS logs (3) and the queried Exchange service (4). Depending on the Exchange protocol you want to troubleshoot, you must check the AutoDiscover, EWS, or REST log files.
Troubleshooting Calendar App
Now that you know how to deal with the AutoDiscover process's errors, it's time to take a look at the Teams Calendar app.
Suppose the access to AutoDiscover works without errors. There is a high probability that the access to the Exchange Web Services will also work, and therefore the calendar app in the Teams client will show calendar information.
However, if the Teams client does not display the calendar, check the following:
In the next blog post, we will take a closer look at calendar delegate situations.
Thomas Stensitzki is a leading technology consultant focusing on Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG. He is an MVP for Office Apps & Services and an MCT Regional Lead. As a user group organizer, he hosts the Microsoft Teams User Group Berlin and the Exchange User Group DACH.
To write your own blog on a topic of interest as a guest blogger in the Microsoft Teams Community, please submit your idea here: https://aka.ms/TeamsCommunityBlogger
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.