Jun 05 2020 08:07 AM - edited Jun 05 2020 08:19 AM
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:
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:
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:
What does not work:
What we have configured for sub.domain.com domain:
Paragraphs 2-4 were performed manually in ECP (without Hybrid Configuration Wizard).
Questions:
Thank you.
Jun 06 2020 11:15 AM
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.
Jun 09 2020 01:45 AM - edited Jun 09 2020 02:31 AM
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.
Jul 20 2020 03:54 AM
Jul 21 2020 11:24 PM
Jul 22 2020 03:10 AM - edited Jul 22 2020 04:08 AM
SolutionHello 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:
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 :)
Jul 22 2020 03:10 AM - edited Jul 22 2020 04:08 AM
SolutionHello 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:
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 :)