Over the last several months, we have seen many customers adopting Microsoft Teams, even if their mailboxes are still hosted in an on-premises environment. One of the common issues in this scenario is not being able to see the Calendar tab in the Microsoft Teams client.
Would you like to know how to troubleshoot this? Read on!
For cloud users, the Calendar section in Teams is connected to their Exchange Online (EXO) calendar. In other words, when you schedule a meeting in Outlook, it'll show up in Teams (and vice versa). For a great overview of this functionality, see Schedule a meeting in Teams.
To make calendar access work for your on-prem mailboxes, Teams needs access to your Exchange on-prem organization for both Autodiscover and EWS. There are several things to remember here.
- Autodiscover and EWS URLs should be available from the Internet. Pre-Auth is not supported. If you use some sort of publishing system, you will need to configure pass-through. You can verify that external URLs on-prem are accessible, trying to open them from internet directly in web browser. Test with https://mail.contoso.com/EWS/Exchange.asmx and https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml .You can also use http://aka.ms/exrca to test connectivity for EWS and AutoDiscover. But note, that those tests don’t use OAUTH (as of this writing). So, sometimes you might see that those tests pass successfully, but free/busy for on-prem users is not visible from your tenant (see further below for more troubleshooting tips).
- OAUTH authentication should be configured and working between you O365 tenant and Exchange on-prem. To make this work, we highly recommended to run Hybrid Configuration Wizard (HCW) to configure full hybrid mode. For on-premises deployments (newer than Exchange 2010) HCW automatically configures OAUTH between on-premises and EXO. Please make sure to run the latest CUs on-premises as per our Hybrid requirements.
There are some other prerequisites: users with on-premises mailboxes must be synchronized to Azure Active Directory. On-premises mailboxes should be on Exchange 2016 CU3 or higher, as per this article.
If everything is working fine, you should see Calendar tab in your Teams client. When you switch to your Calendar tab, it should be “up to date” (you may need to re-login to the client):
Uh-oh; it’s not working. Now what?
If you used HCW, verify Service Principal Name (SPN) endpoints configured for Azure AD. There should be at least 2 endpoints for EWS and Autodiscover. If you don’t see them, you can connect to AzureAD via PowerShell and check/configure them manually (please see this article for details).
$ServiceName = "00000002-0000-0ff1-ce00-000000000000";
$x = Get-MsolServicePrincipal -AppPrincipalId $ServiceName;
$x.ServicePrincipalnames.Add("https://mail.contoso.com/");
$x.ServicePrincipalnames.Add("https://autodiscover.contoso.com/");
Set-MSOLServicePrincipal -AppPrincipalId $ServiceName -ServicePrincipalNames $x.ServicePrincipalNames;
URL to confirm Autodiscover is available
To test if Autodiscover is available, you can use the following. For an on-premises mailbox, if hybrid is configured correctly, O365 should route back to on-premises:
https://outlook.office365.com/autodiscover/autodiscover.json?Email=admin@contoso.com&Protocol=EWS&RedirectCount=5
After redirect is completed, you should see the following on-premises EWS URL:
Collecting logs from Microsoft Teams client
- To make troubleshooting easier, you need to sign out from Microsoft Teams client and then sign back in. It will force calendar load and it will be easier to find error in log or successful location of user’s mailbox.
- Wait until Calendar app appears (if everything successful) or not (if something went wrong)
- Get the logs from the client: press (CTRL+ALT+SHFT+1) for Windows and (Command+Option+SHFT+1) for Mac from within the client to download logs
- Search for Calendar App. If the mailbox is discoverable, logs will show something like this: UserAppsStore: Added calendar app with isFirstParty as true. isMailboxDiscoverable: true, isFreemiumTenant: false, enableFreemiumCalendar: true
Checking EWSAllow Agent Strings
EWS access can be blocked by EWSAllow Agent settings in your Exchange on-prem organization. These can be configured either at the mailbox level or Organization level. This is not very common, but we have seen some organizations use custom EWS settings on-premises.
Check if any agents are blocked on the Organizational level (the following shows none are – default setting):
Also check the setting for the mailbox you are troubleshooting Calendar access for:
The following agents should NOT be blocked as they are used to access on-prem servers:
- MicrosoftNinja/1.0 Teams/1.0 (ExchangeServicesClient/0.0.0.0) SkypeSpaces/1.0a$*+
- SchedulingService
SchedulingService is used by the Teams middle tier when a delegate wants to plan a Teams Meeting for the manager using the OWA or Outlook Teams Plugin. IIS and protocol logs can be helpful to confirm if things are being blocked.
Additional troubleshooting
If all of the above checks out, troubleshooting interoperability between your cloud tenant and on-premises organization is the next thing to do. Here are several guides that will help with this:
- NEW! The Microsoft Remote Connectivity Analyzer now covers this scenario under Microsoft Teams tests. Please check it out:
- Troubleshoot Microsoft Teams and Exchange Server interaction issues - this article will continue to be updated with new troubleshooting tips.
- Hybrid environment free/busy troubleshooter
- How to troubleshoot free/busy issues in a hybrid deployment of on-premises Exchange Server and Exchange Online in Office 365
- Demystifying Hybrid Free/Busy: Finding errors and troubleshooting
- You can also do the Free/Busy connectivity test using EXRCA (you should have at least one mailbox migrated to cloud to test this)
- For troubleshooting purposes, you can use the article Configure OAuth authentication between Exchange and Exchange Online organizations, this article contains steps to verify SPNs in Azure AD and explains how to verify OAUTH connectivity with Test-OAuthConnectivity cmdlet from on-prem and O365.
- In Exchange 2016, OATH authentication is enabled for EWS virtual directory by default. However, you can verify this setting by using the command below:
Note: if you migrated mailbox from on-prem to EXO, it’s easy to test free\busy availability using Outlook. The above article on manual OATH configuration can be also useful for checking if things are configured properly (but really, you should always use HCW!)
If you are working in Teams calendar directly and you try to invite other on-prem users to a Teams meeting, your users/identities need to be synced with Azure AD Connect to be visible in Teams. While you can type the full email address from an on-prem user to invite them, if this mail domain is an accepted domain in O365 and there is no recipient in O365, mail delivery will fail with unknown recipient as the lookup will be done in O365 Global Address Book. Mailbox itself doesn’t need to be moved to EXO, but the identity should be synced.
Hope this helps in troubleshooting your Teams integration with on-premises mailboxes!
I wanted to thank Rui Andre Tabares, João Loureiro, Ralf Leistner, Nino Bilic and Mirela Buruiana for their review of this post.
and
Microsoft
