Configuring Teams calendar access for Exchange on-premises mailboxes
Published Jun 23 2020 09:15 AM 178K Views

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 and .You can also use 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;



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:  

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/ 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:


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.

Viktoria Gindosova and Dmitry Chernikov


one additional thing, if you are using a reverse proxy such as a KEMP load balancer then you have to ensure that auth to autodiscover is delegated to the exchange server, otherwise the OAuth will not work.

There is one more, which can block Teams and Exchange ONPrem calendar

  • You have many Exchange Domains OnPrem
  • You use "autodiscover redirect" to handle that (menas, the does resolve to a HTTP-only (no certificate, no port 443)-Server which issues a "302 Found" with the target url als payload.
  • Teams Online does not use "AutodiscoverV1". it uses AutodiscoverV2 against the OnPremises Server but does not handle a "302 redirect" propertly.
    So you have to publish AutodiscoverV2 with a certificate for every domain (Think about traeffik with let's encrypt if you cannot add all names into an SAN-Certificate

Some other thinks to check

  • Check the teams Mode. It should be Island, TeamsOnly or SfbwithTeamsCollabandMeeting to see an calendar tab
  • Also Admins can use AppPolicies to remove the calendar 
  • And make sure, that the "Exchange hybrid"-Checkbox is enabled in ADSync. Otherwise EXO only knows the Mail address but has no information, that there is an OnPremises Mailbox available.

All four are common issues at my helpdesk. 

New Contributor

@Viktoria and @Dima, thanks a ton for the post. This is priceless.



This is great. Only for hybrid or Exchange on-prem customers, what about organisations that use HEX (hosted Exchange) mailboxes? Yup there are still thousands of HEX mailboxes.


Granted, they should be planning to migrate to EXO but for now, they don't have a Teams calendar tab.


@David Bargna Hi! Do you mean, you have pre-auth configured on your KEMP load balancer and you delegate credentials (in Kerberos, NTLM... ?). Formally, pre-auth is not supported for Autodiscover and EWS. 

 Hi, in this instance for autodiscover we have no pre-auth, we delegate authentication directly to the exchange server. Basically drill a hole in the firewall direct to exchange. For other services mapi, owa, ews etc we have some level of pre-auth happening on the kemp servers. 



Hi @Frank Carius  With Auto Discover V2, which was introduced with Exchange 2016 CU3, the autodiscover request is a non-authenticated request using JSON. This is why we support V2 from middle tier and have best effort support for now with V1. This is a little bit confusing and in 99% cases AutoD v2 is working. So we decided not  to create confusion and removed reference to a version from article. Thanks a lot for sharing your opinion, it make sense for customers with configuration like yours. 


Good day @Matthew Levy ! Initially we planned the cover most important steps you need to take into account while configure Teams Calendar with Exchange on-prem. We don't rule out creation of additional article if we have enough of demand and content :) Can I ask you, what exactly do you mean by "hosted" Exchange environment in your situation? 


Thanks,  @David Bargnanow it's clear enough!

Occasional Visitor

Hello, very nice article.

I would like to add one observation :

it seems that autod v2 is not AD site aware. So it means that Ews externalurl need to be setup also on non internet facing mbx. For example in multiregion datacenters EU, NA and APAC and only EU are internet facing, ews externalurl need also be setup on NA and APAC mbx also otherwise the autodiscover.json file retrieved may contains internal url when a non internet facing mbx reply.




Well this has highlighted one important fact for me.  The on-premises mailbox must be hosted on Exchange 2016 in order for this to work.  Very handy to know. Unfortunate for those customers relying on the free hybrid licence key which stiplulates that no mailboxes must be hosted on that server.  This would represent the vast majority of my customers. 


Thanks for posting this. :smile:


Good day, @Vinam799, Yes. AutoD V2 is not site aware. That would be great to have separate article on AutoD v2  in the future, as this topic is not covered very well. unfortunately, we cannot do this here. Thanks for addition!

Senior Member

great post.

i have one question can i limit the connection to Exchange on-primes autodicover and EWS only from Microsoft Exchange online IP address , or it must be published to all internet ?


Regular Visitor

How often and when does MS Teams check if the on-premises mailbox is discoverable?
In our environment, we see strange behaviour. The calendar can be visible for some users and can't for others at the same time. The calendar may disappear unexpectedly and return in 2-3 days without any actions. Mailboxes of users are in Exchange on-premise.
In Debug logs we see "calendarSyncService: User mailbox is not discoverable. Skipping sync UserAppsStore: Skipped calendar app with isFirstParty as true. isMailboxDiscoverable: false"
All recommendations in the article were implemented and double-checked.

New Contributor

One more thing worth to mention here is ensure that /API/* from your Exchange Farm is properly published by your Load Balancer - which is the REST API used by the Teams backend services for Out of Office / Presence Updates against your mailbox. The current config templates from F5 for example are not covering this subdirectory correctly under all conditions and you may end up with missing this on your public endpoint. Thanks to Premier Support for uncovering this little detail - thought it's worth to share here as we just ran into this issue.

Senior Member

@Vinam799 The site awareness for AutodiscoverV2 is something we're looking into.

Senior Member

After configuring OAUTH on-prem users (with PTA SSO) can't save meetings - it disappears from Teams calendar after showing progress bar for couple of minutes.

Everything else works fine, users can see availibilty, rooms and manage personal calendar from Teams until they add a channel (team mailbox in EXO) to the meeting details.


@Mikhail your issue should not be related to OAUTH or Exchange but to mail flow.


When you create a meeting in Microsoft Teams and your mailbox resides on-premises, MS Teams backend service will send an appointment e-mail to your on-premises mailbox. If that e-mail can't be delivered, because of not properly configured mail flow between Exchange Online and Exchange on-premises, the meeting will not be scheduled. The effect that you see in that case is that in MS Teams client the user creates the meeting and sees the meeting to be grayed out for a certain time. After around 30 seconds, the meeting disappears as the MS Teams backend service didn't receive any response from your on-premises mailbox.. 


Please have a look and let me know if that could help you solve your issue


Kind regards


Senior Member

Calendar Tab appear but keep loading and it didn't show any data i check logs Calendar App was there and isMailboxDiscoverable: true but i see below error , any idea ?

i used new HCW ver17.xx without any issue.

{"errorCode":"ErrorNonExistentMailbox","message":"Error while fetching appointments from EWS. ResponseCode: NoError, ErrorCode: ErrorNonExistentMailbox, ErrorMessage: Mailbox doesn't exist"}
Senior Member

@Spiros Karampinis thank you very much! Meeting requests from team mailbox were rejected by bounce verification on Cisco ESA, so I created outbound and receive connectors to bypass the antispam appliance.


@khalednafea please check the autodiscover of the primary domain of the users that are willing to have their calender in Microsoft Teams. 

Also check the connectivity with the Microsoft Connectivity Analyser :


MS Teams backend services are using Autodiscover v2 to find the mailbox on-premises. So Autodiscover should work properly, some times not properly configured DNS entries, load balancers, reverse proxies or even certificate issues could lead to a not properly working autodiscover for your Exchange infrastructure. 


Please let us know your progress


Kind regards



@Mikhail you are more than welcome sir, glad that you could solve your issue.


Have a great day



Established Member

Hi Exchange Team,

thank you so much for these insights. Finally, some official info’s on this topic.

I have so many customers using HTTP redirect for AutoDv1 to handle multiple domains without purchasing certificates for each domain.

I found (by accident :suprised:) that your AutodiscoverV2 redirect also honors SRV records. If the on-premises Exchange has valid SRV records for those domains the redirect works and AutodiscoverV2 is successful.

For example:

  • Primary Autodiscover is:
  • 2nd Domain has: with SRV Record target:


  1. I test:
  2. Get redirected to:
  3. Teams integration works fine without publishing Autodiscover for each domain.


Question: Is using SRV records supported for production? Why is SRV working and HTTP redirect not?

Has this something todo with: "This is why we support V2 from middle tier and have best effort support for now with V1."






As of June 2020 Teams middle tier no longer supports fallback to AutoDiscoverV1 and only AutoDiscoverV2 is being used.





Hi @khalednafea,

Hope you're doing well. Sorry for delay, workshop deliveries take a lot of time :) In case, you would like to configure calendar for Teams, you can provide access for EXO\TEAMS address. In case , you have access from internet to your on-prem mailboxes, of cause, you will need to provide access for other addresses.



Unfortunately, no option to reply to specific comment now.  @khalednafea  - answering your question "Calendar Tab appear but keep loading and it didn't show any data i check logs Calendar App was there and isMailboxDiscoverable: true but i see below error , any idea ?" 


Unfortunately I cannot tell what's wrong, as i don't have any information regarding your environment. Please, try to check all the settings according to the article on How to configure OAUTH. In pervious versions of HCW we had some issues, when we needed to configure some setting manually. I don't have opportunity to verify specific build that was used,  last time it worked for me. If you will have some more info from test-oath... and exrca, you can share it with us, if it's OK for you. have a nice day!

Senior Member

@ViktGin Thanks for your reply , my issue already solved. the firewall was blocking Teams IP Address which needed as you mention, after allowing traffic from Teams IP Range teams calendar working fine.

New Contributor

Hi, Thanks for this article.  

my exchange hybrid server is exchange 2016 just about all my users are on 2016 but i  still have a 2010 present.  My namespace (CAS) are all pointint go exchange 2016 servers.  


if i re-run the HCW will it create the oauth or will this not work with exchage 2010 still present in the environment?


thanks for you time


@Joester80 , HCW will not configure OAUTH as long as you have Ex2010 coexistence.
You need to configure it manually:
However, an Exchange hybrid deployment is strongly recommended. 

Senior Member

Hi @Slava25 ,

Did you find a solution?

We are facing the same problem only with some users.


In Debug logs we see "calendarSyncService: User mailbox is not discoverable. Skipping sync UserAppsStore: Skipped calendar app with isFirstParty as true. isMailboxDiscoverable: false"

Everything from the config side seems correct.



Hi @Slava25 , Hi @Blertin 


Discoverable mailbox are refreshed in 3 days however undiscoverable mailboxes are refreshed in just one hour. We have recently published troubleshooting article that might help troubleshooting this problem - If that doesn't help please open support ticket so we can help addressing root cause issue as some additional data will be required like affected users UPN/mailbox.

Occasional Contributor

Hello All -

I am unable to connect my on premise mailboxes with Teams.  In the Teams log, the mailbox is not discoverable.  I have run the Hybrid Configration Wizard without error and can verify the OAuth seems correct.  In reading the trouble shooting guide, I find reference to a "Partnership Application for Skype for Business".   We installed the Teams Exploratory before we installed the Exchange Hybrid Setup. Are there steps in Teams that I need to take to set up the Partnership?  I have found an Exchange Power Shell Script to do it, but I want to make sure there aren't other issues with the sequence.  For Example, most users have a Teams calendar that shows up in Exchange online.  What will happen when the apps are connected?


Thanks for any input!


Hello @LJJohns925 


We have recently published a troubleshooting guide available at - Troubleshoot Microsoft Teams and Exchange Server interaction issues. I suggest to follow these steps and check if that helps addressing the problem.




Occasional Contributor

Thank you Joao.


That is the document that I have been following.  It mentions the Partnership record, but doesn't give any information about when and how to install it.



Is it possible to configure Teams Calendar access for on-prem Exchange server mailboxes without implementing Hybrid Mode?

We do have AAD configured but do not want to implement Exchange Hybrid mode.




@LJJohns925  There is a reference in that document pointing to article with detailed instructions how to configure partner application (...)To complete the integration, follow Steps 1-3 in this article. (...)  You just need to follow steps mentioned at Please note that this is only required for scheduling services which means that users should still be able to visualize calendar despite no partner application being configured. This requirement only applies to teams delegation scenario.


@HarishSolanki  Hybrid is a requirement. Discovery process relies on autodiscover v2 and there is no fallback to autodiscover v1.

Occasional Contributor

Thanks @João Loureiro !  I re-read the document and found my error.  OAuth is NOT handled by the HCW.  I set it up, per the instructions and now have Calendar access.


Hello  @LJJohns925 , 


this is true, HCW configure not the OAUTH if you have normally a Exchange 2010 in your environment, otherwise HCW should configure automatically the OAUTH authentication.


Do you have a Exchange 2010 or we have here another scenario where OAUTH will not be auto-configured?


Kind regards



HCW doesn't configure OAuth in the following scenarios:
1) There is a legacy Exchange Server Version (Exchange 2013 pre-SP1) in the Exchange Organization

2) You have selected Minimal /Express instead of Full Hybrid

3) You are running HCW version 16.0.3149.4.  Always use latest version of HCW from 

4) You have an issue in your environment and needs to be addressed manually. 

Occasional Contributor

@Mirela_Buru  @Spiros Karampinis 


I think the culprit may have been an existing pre 2016 server.  It doesn't host mailboxes, but I believe that it still appears on the system.  I was installing Full Hybrid on the latest version.  The wizard completed without warning, but OAuth was not configured.


Thank you to all that assisted!


Regular Visitor

Great Article..

Having Exact issue. Team Calendar not available

HCW failed to configure Oauth For Hybrid Full deployment- Exchange 2016
1. Manually Configured Oauth successfully using

2. Test EWS and AutoD successfully. Freebusy working...RCA test pass successfully 
3. Team Calendar icon was visible for On-prem mailbox but was getting "cannot loading calendar error"-  Teams log shows isMailboxDiscoverable: true  but FW logs was showing drops from Microsoft IP address for Team.
4. Teams IP address were added FW rule but now Calendar Icon disappeares and Team logs now shows mailbox  isMailboxDiscoverable: false

5 FW logs is no longer showing any request coming from Microsoft IP Team address when using TEAMS..

6. Cannot figure out how to get back Teams Calendar Icon for on-prem mailboxes.  Followed documentation - pass all check. 

Anyone knows the exact list of Microsoft Ip address that need to be allowed in FW for TEAMS ?


@Kosstar Info related to Office 365 URLs and IP addressed required to be open in firewall is available here - Please note that some addresses are IP address range.

Occasional Contributor

@PeterRising - the second article linked shows that EX2013 mailboxes are supported for the delegate access. Seems like the requirement is around AutoDiscover v2 support: 


How Exchange and Microsoft Teams interact - Microsoft Teams | Microsoft Docs


Teams Scheduling add-in for Outlook when scheduling a meeting on behalf of someone requires Exchange 2013 CU19 or later. This is to support the unauthenticated discovery of the mailbox by our service to check delegate permissions against the delegator mailbox. The delegate and delegator location could be Exchange 2013 or later, or Exchange online, but Autodiscover must resolve to Exchange 2013 CU19 or later


Trying to test in the lab.

Regular Visitor

This issue seems to be still existent. I have a customer with EX2019, Full classic hybrid configured, OAUTH tests pass with success both ways. All other tests (exRCA) pass as well. OWA on-line can see free/busy for on-prem mailboxes, however teams calendar app does not want to cooperate. The error we see in teams client is CalendarService: Error while fetching the meeting type None: Error {"response":{"errorCode":"ErrorNonExistentMailbox"},"status":400,"_codeEnum":0,"_code":"ErrorNonExistentMailbox","_message":"Unknown service error."}



@BNalepa I suggest to follow all steps described at Troubleshoot Microsoft Teams and Exchange Server interaction issues - Microsoft Teams | Microsoft Do... and confirm Autodiscover V2 is redirecting to exchange on-premises as expected.

Senior Member



Can anyone provide some troubleshooting tips for Presence detection in Teams for mailboxes that are hosted on-premise? 


My issue is that the presence does not change based off of a users calendar, they are always "Available" unless they actually join a meeting, then it updates to "In a call". I am looking to have it update to "In a meeting" based off the calendar entry or "Busy" etc. I know it can do this because I have another test environment where this behavior works... I'm thinking I maybe haven't set something up quite right in my live environment. 


OAuth is configured correctly using the HCW and Free/Busy is working fine, both ways... 365 to on-prem and on-prem to 365. 


Exchange version is 2016 CU16. 


Many thanks

Occasional Contributor

@dankitchen - are you running in TeamsOnly mode? It seems like any other coexistence modes have conflicts between Skype & Teams when running in coexistence as both Skype & Teams provide independent statuses. 


Coexistence with Skype for Business - Microsoft Teams | Microsoft Docs


I can't find anything about how Teams handles presence with on-prem calendar integration with coex in place.


@dankitchen Previous troubleshooting article I have previously provided in scope of previous replies also includes a section for presence troubleshooting. The main difference is that relies on Rest endpoint:


Troubleshoot Microsoft Teams and Exchange Server interaction issues - Microsoft Teams | Microsoft Do...


Issue 3: The Teams presence status is stuck on Out of Office or doesn't display 'In a meeting' when the user is attending an Outlook calendar meeting
A user whose mailbox is hosted on an on-premises Exchange server turned off the Outlook client automatic replies but the Teams presence status displays 'Out of Office' to all Teams clients from the same organization. This may last a few days.

A user is attending an Outlook calendar meeting but the Teams presence status doesn't update to 'In a meeting'.

Senior Member

@João Loureiro , wish I had found this sooner because I think I have narrowed it down to this bit:


Step 1: Verify that the URL for the on-premises Exchange REST API has been published on the public network

Run Step 2 in the Common Troubleshooting Steps above against the user's mailbox to locate the on-premises Exchange EWS URL, and change the URL format (replace "/EWS/Exchange.asmx" with "/api") in this manner: to

Try to access the REST API URL from a browser in the external network. If you get a 401 response from the on-premises Exchange environment, the REST API URL has been published. Otherwise, contact the local network team to get the URL published.


In my test network I get a 401 response and a prompt for a username and password but in my live network I do not. 


Now I did not configure the network for either of these environments but I must admit, the following phrase "Otherwise, contact the local network team to get the URL published." is pretty vague? Do we need to do anything in IIS? 


@KevinCallanan yeah, checked and it is TeamsOnly. 


Many thanks, 




@dankitchen You just need to publish externally Rest API endpoint through reverse proxy similar to what has been done to make EWS externally available. 

Please refer to Use REST APIs to access mailboxes in Exchange hybrid deployments (preview) - Microsoft Graph | Micro... for additional details.

Version history
Last update:
‎Dec 14 2020 07:03 AM
Updated by: