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

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 https://docs.microsoft.com/en-us/powershell/module/exchange/test-oauthconnectivity?view=exchange-ps 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-exchange-on-premises/ba-p/1484009
2. https://docs.microsoft.com/en-us/previous-versions/office/exchange-server-2007-technical-articles/bb332063(v=exchg.80)?redirectedfrom=MSDN#scenario-4-using-the-autodiscover-service-with-redirection

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-exchange-online-organizations-exchange-2013-help#step-5-register-all-hostname-authorities-for-your-internal-and-external-on-premises-exchange-http-endpoints-with-azure-active-directory

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 🙂