Dear Exchange team,
very recently I worked with Microsoft Support on the SR 2302201420001122.
Scenario:
- customer uses Teams via M365. Users are manually added through admin portal
- users use the UPN suffix of onmicrosoft.com tenant
- customer adds his primary domain (no other settings, such as Exchange MX, DKIM, SPF etc.)
- adding the alternate domain is necessary to reflect changes for VLSC moving to admin.microsoft.com
Problem:
Adding an alternate domain to a M365 tenant (DNS TXT @ ms=xxxxxx) causes side-effects, when customer has not deployed AAD Sync and using Exchange 2019 on-prem ONLY. with the same domain suffix as registered in the admin portal.
Scenario:
- customer uses Teams via M365. Users are manually added through admin portal
- users use the UPN suffix of onmicrosoft.com tenant
- customer adds his primary domain (no other settings, such as Exchange MX, DKIM, SPF etc.)
- adding the alternate domain is necessary to reflect changes for VLSC moving to admin.microsoft.com
Problem:
Adding an alternate domain to a M365 tenant (DNS TXT @ ms=xxxxxx) causes side-effects, when customer has not deployed AAD Sync and using Exchange 2019 on-prem ONLY. with the same domain suffix as registered in the admin portal.
Disregarding existing MX and autodiscover configuration, Outlook 2019 or 365 will always try to contact Exchange Online, disregarding it is deployed or setup in the domain, and unrelated to users using the @domain.onmicrosoft.com in their UPN.
Internally we even received reports, that email from M365 Exchange Online customer will be routed through the M365 tenant after purely adding the alternate domain, again with no Exchange Online and settings deployed, if the UPN matches the alternate domain. (I cannot vouch for that, as this was not part of my SR).
Internally we even received reports, that email from M365 Exchange Online customer will be routed through the M365 tenant after purely adding the alternate domain, again with no Exchange Online and settings deployed, if the UPN matches the alternate domain. (I cannot vouch for that, as this was not part of my SR).
Both are unwanted behaviours, that do not follow the usual configurations for Outlook and Exchange.
Effects we have seen:
- users will receive a sign-in request to Microsoft, everytime they're starting Outlook.
- Policies to prevent online services exist and were applied > After this, the sign-in message still comes up with a "disabled by your administrator", at every start of Outlook.
Each of the messages could be dismissed, but these are iritating to users (new behaviour, security awareness when unexpectably asked to enter credentials).
- users face issues to open certain calendar entries.
- Policies to prevent online services exist and were applied > After this, the sign-in message still comes up with a "disabled by your administrator", at every start of Outlook.
Each of the messages could be dismissed, but these are iritating to users (new behaviour, security awareness when unexpectably asked to enter credentials).
- users face issues to open certain calendar entries.
- users receive an error when trying to access the Exchange 2019 on-prem global address book (GAL) in some reproducible circumstances. They will receive an error message that the GAB is not available, while seeing internal user list at the same time.
Proposal:
The design decision for the default setting in Outlook should be questioned and reviewed.
Adding a txt to a domain should not interfere with valid settings for on-premises infrastructure such as autodiscover and / or DNS MX settings.
Solution:
Disable Office 2016 or later autodiscover for Exchange Online
GPS: Disable AutoDiscover (gpsearch.azurewebsites.net)
Resultant Setting
Best regards,
Karl