Scott Barr / / Categories: Microsoft Teams

Microsoft Teams external access issue following tenant migration

During a recent Microsoft 365 tenant to tenant migration project we ran into the following issue when troubleshooting external access (federation).  


  • External access (federation) not working after migrating to new Microsoft 365 tenant 
  • External Teams user tries to add contact or chat with a user in new tenant - user appears as Skype for Business user 

Microsoft Teams admin center shows Org-wide settings | Teams upgrade | Coexistence mode as Islands 

Machine generated alternative text:
Teams upgrade 
Teams upgrade lets you set up your upgrade experience from Skype for Business to Teams for your users. You can the 
default settings or make changes to the coexistence mode and app preferences to fit your organizational needs. 
Coexistence mode 
Coexistence mode 
Notify Skype for Business users that an upgrade to 
Teams is available. 

 Attempt to assign in PowerShell yields more info about why you cannot change: 

The important part of the screenshot:  

This organization cannot be upgraded to TeamsOnly at the tenant level because there is an on-premise deployment of Skype for Business detected in 1 or more of it sip domains”  

 Ah! While this tenant DID NOT have an on-premises deployment it did have several vanity (accepted) domains. Upon further review, some of the domains did not have the existing external DNS records - specifically 'lyncdiscover' as noted here: 

 In this note: 

Machine generated alternative text:
O Important 
TeamsUpgradePoIicy can be assigned to any Teams user, whether that user hase an on-premises account in Skype for Business 
Server or not. However, TeamsOnly mode can only be assigned to a user who is already homed in Skype for Business Online. 
This is because interop with Skype for Business users and federation as well as Microsoft 365 Phone System functionality are only 
possible if the user is homed in Skype for Business Online. In addition, you cannot assign Teamsanly mode as the tenant-wide 
default if you have any Skype for Business on-premises deployment (which is detected by presence of a lyncdiscover DNS record 
that points to a location other than Office 365. To make these users Teamsanly you must first move these users individually to the 
cloud using moue-Csuser Once all users have been moved to the cloud, you can hybrid to complete migration to the 
and then apply Teamsanly mode at the tenant level to ensure future users are Teamsanly by default.

Specifically, "you cannot assign TeamsOnly mode as the tenant-wide default if you have any Skype for Business on-premises deployment (which is detected by presence of a lyncdiscover DNS record that points to a location other than Office 365.  

In reality, if the lyncdiscover record does not exist you cannot assign TeamsOnly mode as the tenant-wide default. Remember, in this case there were several vanity domains, and some did not have the corresponding lyncdiscover DNS record in external DNS  


Adding the lyncdiscover DNS record where it was missing resolved this issue.   

Additional info: 

O Note 
Any new tenants created after Sept 3, 201 9 are created as TeamsOnly tenants unless the organization already has an on-premises 
deployment of Skype for Business Server. Microsoft uses DNS records to identify on-premises Skype for Business Server 
organizations. If your organization has on-premises Skype for Business Server with no public DNS entries, you will need to call

This may not be exactly true since this tenant was created in September 2020 and initially only had the default domain. The vanity domains were previously associated with a different tenant. During the migration cutover event the vanity domains were moved to the new tenant.   

Did the Teams coexistence mode change then? I cannot say since I did not check until after the vanity domains were added. 


Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.