SOLVED

Calendar tab is missing in Teams for on-premise users with subdomain as primary SMTP address

Brass Contributor

Hello, dear community!

 

My name is Dmitriy.

Our team got stuck with unavailable calendar (it's just not showing) in Microsoft Teams for users who has subdomain as a primary SMTP address.

We've spent a lot of time trying to investigate why it is not working, so I decided to ask you here before disturbing Microsoft support.

 

What do we have:

  1. Office 365 tenant and in-premise infrastructure.
  2. Verified primary SMTP domain, let's say it is domain.com. And verified subdomain, let's say it is sub.domain.com. Both domains are federated.
  3. Configured Azure AD Connect with ADFS Auth.
  4. Implemented Exchange Hybrid setup, including OAuth between Exchange Online and Exchange Server https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchan...

OAuth is configured for the company's primary domain, which is domain.com. I tried to add the second AuthServer for the sub.domain.com but Exchange told me that server is already exists.

I also tried to get JSON data for both domains - the returned data is the same.

 

     5. Some users:

  • user1@domain.com (lives in Exchange Server)
  • user2@sub.domain.com (lives in Exchange Server)
  • user3@domain.com (lives in Exchange Online)
  • user4@sub.domain.com (lives in Exchange Online)

     6. Domain sub.domain.com exists only in DNS and Exchange Server. It does't exist in Active Directory.

 

User1 and User3 were created with domain.com as a primary SMTP domain.

User2 and User4 were created with sub.domain.com as a primary SMTP domain.

 

SIP Domain is the same for all users.

Currently we don't have Hybrid setup for Skype for Business/Teams.

 

What works as expected:

  1. Mail delivery (through hybrid send/receive connectors):
  • From Exchange on-premise to Exchange online (for both domain and subdomain)
  • From Exchange online to Exchange on-premise (for both domain and subdomain)
  1. Calendar tab exists in Microsoft Teams client (both Web and Desktop) for all users with domain.com primary domain who live either on-premise or online.
  2. Calendar tab exists in Microsoft Teams client (both Web and Desktop) for all users with sub.domain.com primary domain who live online.
  3. Free/Busy sharing is available between all users with both domain.com and sub.domain.com primary domains who live either on-premise or online.
  4. Chat and groups in Teams are available for all users with both domain.com and sub.domain.com primary domain who live either on-premise or online.

 

What does not work:

  1. Calendar is not showing in MS Teams client (both Web and Desktop) for all users with sub.domain.com primary domain who live in Exchange Server on-premise. Previously calendar didn't work for all users in primary domain until we configured OAuth.

 

What we have configured for sub.domain.com domain:

  1. Added sub.domain.com domain as federated verified domain https://docs.microsoft.com/en-us/powershell/module/msonline/new-msolfederateddomain
  2. Added sub.domain.com domain to the Accepted domain in Exchange Server under the mail flow - accepted domains
  3. Added sub.domain.com domain to the Federation Trust in Exchange Server (including successful DNS verification) under the organization - sharing - Federation Trust
  4. Added sub.domain.com domain to the Free/Busy sharing in ECP from both sides (online and server) under the organization - sharing - Organization Sharing

Paragraphs 2-4 were performed manually in ECP (without Hybrid Configuration Wizard).

 

Questions:

  1. Calendar in Teams works perfectly for the main domain, but doesn't work for the subdomain. Am I missed something?
  2. Do I need to configure something else? If so, could you tell me what and where or at least point me to some direction where I can find this information?
  3. Do I need just to wait more time (maybe federation trust updates within 72 hours, for example)?

 

Thank you.

5 Replies

@Shimura512 

 

So, calendar in Teams in Exchange Hybrid is all about OAuth being properly enabled, which of course you have already done. I don't come across the presence of sub-domains too often, and certainly not in this context, so I can't comment to their expected behaviour here.  With ADFS in the mix too, you may be correct that you need to just give it some time?

 

Are you in the process of migrating your mailboxes to Exchange Online?  Teams works best with Exchange Online mailboxes so it may be worth testing a migration of one of the sub-domain mailboxes to EOL and you will very likely find your missing calendar appears.

 

Interested to know how you progress with this one so please do let us know here how you get on.

@PeterRising 

 

With ADFS in the mix too, you may be correct that you need to just give it some time?

Sorry, doesn't help... Calendar tab have not appeared for user2@sub.domain.com (lives in Exchange Server)

 

Are you in the process of migrating your mailboxes to Exchange Online?

Not yet.
We are in the process of setting up a hybrid configuration, so that we can move the testing team to the cloud in the nearest future.
But before that, we must implement the "basic" functionality (mail flow, calendar, s4b/teams federation and interoperability, etc...).

 

Teams works best with Exchange Online mailboxes so it may be worth testing a migration of one of the sub-domain mailboxes to EOL and you will very likely find your missing calendar appears.

Yes, I know. But as for now all our mailboxes homed in Exchange Server. And that's why we need to provide all users with hybrid features. Including the team with sub.domain.com primary domain.

I just tested the user4@sub.domain.com (which has been migrated to Exchange Online on Friday). The calendar works like a charm.

 

Interested to know how you progress with this one so please do let us know here how you get on.

Thank you.

I'll try to post periodic updates here.

Hello, dear community.
JFYI
Finally, we have managed to solve this issue.
I will post solution here in 1-2 days.
best response confirmed by Shimura512 (Brass Contributor)
Solution

Hello again :)

 

As I mentioned before, we have managed to solve issue with missing Calendar tab in MS Teams client for sub-domain users.

The problem was not so much with OAUTH, but with autodiscover DNS record and Certificate on a reverse-proxy.

 

After 4 weeks long conversation with Microsoft support we figured out this exception:

 

Exception:
Microsoft.Exchange.WebServices.Data.AutodiscoverLocalException: Autodiscover blocked a potentially insecure redirection to https://autodiscover.sub.domain.com/autodiscover/autodiscover.xml .
To allow Autodiscover to follow the redirection, use the AutodiscoverUrl (string, AutodiscoverRedirectionUrlValidationCallback) overload.

 

We found this exception after testing Autodiscovery using Test-OAuthConnectivity on Exchange Server against on-premises sub.domain.com mailbox:

 

Test-OAuthConnectivity -Service AutoD -TargetUri https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc -Mailbox "user2@sub.domain.com" -Verbose | fl

 

We had "autodiscover" CNAME record in our DNS for sub.domain.com.

 

These two articles helped us a lot:

  1. https://techcommunity.microsoft.com/t5/exchange-team-blog/configuring-teams-calendar-access-for-exch...
  2. https://docs.microsoft.com/en-us/previous-versions/office/exchange-server-2007-technical-articles/bb...

First of all I added all autodiscover URLs to the OAuth configuration as described here: https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchan...

 

Previously I added all URLs from these cmdlets:

 

Get-MapiVirtualDirectory | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

 

But I feel that was not necessary, because everything worked fine with domain.com even before adding autodiscover URLs.

 

I also tested autodiscover URL using the link from the first article and got insecure connection according to certificate's CNs mismatch.

 

Then, because of the Exception message "Autodiscover blocked a potentially insecure redirection", insecure connection in a previous step and according to the whitepaper (second article) we desided to publish our Exchange server on a separate public IP address and with its own certificate (issued from Let's Encrypt for testing purposes), as we don't have sub.domain.com and *.sub.domain.com CNs in our current certificate on a reverse-proxy.

Also we pointed A autodiscover.sub.domain.com record in DNS to this public IP.

And the Calendar tab appeared in Teams client :)

 

After that, according to MS engineer's comment:

 

There are two supported ways of doing this, either by using a DNS CNAME record or by using a DNS SRV record for _autodiscover._tcp.yourdomain.com.

 

We removed A autodiscover.sub.domain.com record and added SRV record:

 

_autodiscover._tcp.sub.domain.com.    3600   IN SRV  100 1 443 autodiscover.domain.com

 

We checked autodiscover URL for sub.domain.com email address after 4 hours and it worked with redirection to autodiscover.domain.com. Finally, there were no errors about insecure connection.

Calendar tab still existed in Teams client.

 

Then we waited 24 hours. Calendar tab was not disappear.

 

In fact, the problem was much simpler than I thought (misconfigured DNS and/or certificate) but it took 1 month of investigation with Microsoft Support team.

 

I hope this information will help.

 

If you have any questions - please feel free to ask. I'll try to answer :)

1 best response

Accepted Solutions
best response confirmed by Shimura512 (Brass Contributor)
Solution

Hello again :)

 

As I mentioned before, we have managed to solve issue with missing Calendar tab in MS Teams client for sub-domain users.

The problem was not so much with OAUTH, but with autodiscover DNS record and Certificate on a reverse-proxy.

 

After 4 weeks long conversation with Microsoft support we figured out this exception:

 

Exception:
Microsoft.Exchange.WebServices.Data.AutodiscoverLocalException: Autodiscover blocked a potentially insecure redirection to https://autodiscover.sub.domain.com/autodiscover/autodiscover.xml .
To allow Autodiscover to follow the redirection, use the AutodiscoverUrl (string, AutodiscoverRedirectionUrlValidationCallback) overload.

 

We found this exception after testing Autodiscovery using Test-OAuthConnectivity on Exchange Server against on-premises sub.domain.com mailbox:

 

Test-OAuthConnectivity -Service AutoD -TargetUri https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc -Mailbox "user2@sub.domain.com" -Verbose | fl

 

We had "autodiscover" CNAME record in our DNS for sub.domain.com.

 

These two articles helped us a lot:

  1. https://techcommunity.microsoft.com/t5/exchange-team-blog/configuring-teams-calendar-access-for-exch...
  2. https://docs.microsoft.com/en-us/previous-versions/office/exchange-server-2007-technical-articles/bb...

First of all I added all autodiscover URLs to the OAuth configuration as described here: https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchan...

 

Previously I added all URLs from these cmdlets:

 

Get-MapiVirtualDirectory | FL server,*url*
Get-WebServicesVirtualDirectory | FL server,*url*
Get-OABVirtualDirectory | FL server,*url*

 

But I feel that was not necessary, because everything worked fine with domain.com even before adding autodiscover URLs.

 

I also tested autodiscover URL using the link from the first article and got insecure connection according to certificate's CNs mismatch.

 

Then, because of the Exception message "Autodiscover blocked a potentially insecure redirection", insecure connection in a previous step and according to the whitepaper (second article) we desided to publish our Exchange server on a separate public IP address and with its own certificate (issued from Let's Encrypt for testing purposes), as we don't have sub.domain.com and *.sub.domain.com CNs in our current certificate on a reverse-proxy.

Also we pointed A autodiscover.sub.domain.com record in DNS to this public IP.

And the Calendar tab appeared in Teams client :)

 

After that, according to MS engineer's comment:

 

There are two supported ways of doing this, either by using a DNS CNAME record or by using a DNS SRV record for _autodiscover._tcp.yourdomain.com.

 

We removed A autodiscover.sub.domain.com record and added SRV record:

 

_autodiscover._tcp.sub.domain.com.    3600   IN SRV  100 1 443 autodiscover.domain.com

 

We checked autodiscover URL for sub.domain.com email address after 4 hours and it worked with redirection to autodiscover.domain.com. Finally, there were no errors about insecure connection.

Calendar tab still existed in Teams client.

 

Then we waited 24 hours. Calendar tab was not disappear.

 

In fact, the problem was much simpler than I thought (misconfigured DNS and/or certificate) but it took 1 month of investigation with Microsoft Support team.

 

I hope this information will help.

 

If you have any questions - please feel free to ask. I'll try to answer :)

View solution in original post