Microsoft Teams and on-premises mailboxes: Part 2 – Troubleshooting the Teams Calendar App

Posted on by

This blog post is part 2 of the three-part series on Microsoft Teams and on-premises Exchange mailboxes.

Microsoft Teams and on-premises mailboxes: Part 1 – How do Teams and Exchange Server interact?

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
https://outlook.office365.com/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS

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
https://outlook.office365.com/EWS/Exchange.asmx

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
https://autodiscover.varunagroup.de/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS

5. On-premises Exchange Server replies with an external EWS URL of a virtual Exchange Web Services virtual directory
Example: {"Protocol":"EWS","Url":"https://mail.varunagroup.de/EWS/Exchange.asmx"}

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:

  • Open an HTTPS connection to the on-premises EWS URL and perform an OAuth authentication using the registered services principal
  • Send an EWS calendar query
  • Receive the Exchange Web Services response
  • Send the parsed calendar data to the Teams clients’ calendar app for further use

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.

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

PowerShell
Run the Invoke-RestMethod cmdlet with the following Uri-Strings for EWS and REST protocol

Invoke-RestMethod -Uri ‘https://outlook.office365.com/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS‘

Invoke-RestMethod -Uri ‘https://outlook.office365.com/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=REST‘

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.

Browser
You can test and query the AutoDiscover endpoint using the following URLs

https://outlook.office365.com/autodiscover/autodiscover.json?Email=john.doe@varunagroup.de&Protocol=EWS
https://outlook.office365.com/autodiscover/autodiscover.json?Email=john.doe@varunagroup.de&Protocol=REST

For an on-premises mailbox, you receive an AutoDiscover response from your on-premises Exchange Server, like the one shown in the following screenshot.

AutoDiscover response.png

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:

  • The AutoDiscover query terminates with a timeout
    • Is the HTTPS access to your Exchange organization restricted to the remote IP address ranges of Microsoft 365?
    • Maybe the Exchange Server systems have a performance problem and cannot respond promptly?
  • You receive a "User Not Found"-response
    • Is the user account excluded from the Azure AD Connect synchronization and does not exist as a "Mail User" object in Exchange Online?
  • The response does not contain the expected EWS or REST URL
    • The mailbox is an on-premises mailbox, but the response contains the Exchange Online endpoint

https://outlook.office365.com/EWS/Exchange.asmx

Most likely, the user has an additional mailbox in Exchange Online. Resolve the double mailbox situation.

    • The response contains a URL that seems to be an internal URL, i.e.,

https://exch01.varunagroup.local/EWS/Exchange.asmx

The ExternalUrl attribute configuration is not correct for all virtual directories.

    • You use bound namespaces, the user mailbox location is AD site EMEA, but the response contains an URL of a different site, i.e.,

https://mail.apac.varunagroup.de/EWS/Exchange.asmx

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.

  • DNS Name resolution fails for the email address target domain
    • There is no DNS resource record for AutoDiscover in the internet-facing DNS zone

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.

Teams Backend Services.png

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:

  • Can the EWS URL determined by AutoDiscover, is the hostname resolvable in the domain’s external DNS zone, and can it be reached from the Internet via HTTPS?
    • Use a browser to connect to the EWS URL and use Fiddler to identify any connection-based issues
      The EWS endpoint must reply with am HTTP 401 status code
  • Use the Remote Connectivity Analyzer to perform a Teams Calendar Access Tab Test

calendar test.png

http://bit.ly/TeamsCalTest

In the next blog post, we will take a closer look at calendar delegate situations.

Links

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.

Twitter: https://twitter.com/stensitzki
Blog: https://JustCantGetEnough.Granikos.eu
Teams User Group: https://TeamsUserGroup.berlin
Exchange User Group: https://exusg.de

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

https://techcommunity.microsoft.com/t5/microsoft-teams-community-blog/microsoft-teams-and-on-premises-mailboxes-part-2-troubleshooting/ba-p/2232602 https://techcommunity.microsoft.com/t5/microsoft-teams-community-blog/microsoft-teams-and-on-premises-mailboxes-part-2-troubleshooting/ba-p/2232602 2021-03-24 15:00:00Z