TeamsOnly Tenant

Microsoft schaltet Skype for Business Online derart ab, dass der "Tenant Default" von "Island" auf "TeamsOnly" umgestellt wird. Diese Seite beschreibt, was dabei noch alles passiert und zu beachten ist. Dies gilt in den nächsten Wochen für Firmen, die immer noch "Skype for Business Online" nutzen aber auch danach ist die Seite für "Hybrid-Umgebungen" interessant. Der Fokus liegt aber auf der Abschaltung.

Beachten Sie dazu auch die Seite TeamsOnly Tenant Umstellung

Ende von SfB Online

In meinem Tenant habe ich am 22.9.2021 folgende Anzeige gesehen:

Per PowerShell ist der Stichtag dann schnell errechnet. Ihr Zeitpunkt kann abweichend sein.

PS C:\> (get-date).adddays(47)

Montag, 8. November 2021 11:08:03

Die automatische Migration

Aber was passiert an dem Tag und welche Auswirkungen hat es? Kurz gesagt: Der "Default" ihres Tenant wird von "Island" auf "Teams Only" gestellt.

Das ist nicht ganz richtig, denn Microsoft setzt ein eigenes Feld "TeamsUpgradeOverridePolicy", was z.B. eine Migration der Buddy-Liste aus Skype for Business Online bewirkt. Wenn Sie als Admin den Mode hier auf "Teams Only" setzen, werden KEINE Buddylisten oder Besprechungen durch den Teams Meeting Migration Service (MMS) migriert.

Diese Feld können Sie selbst aber nicht schreiben, sondern nur lesen:

PS C:\> Get-CsTenant | fl domains,teams*

Domains                          : {uclabor.de, fcarius.mail.onmicrosoft.com, fcarius.onmicrosoft.com}
TeamsUpgradeEffectiveMode        : Islands
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       : None
TeamsUpgradePolicyIsReadOnly     : None

Was dabei passiert, beschreibt Microsoft auch schön auf der folgenden Seite:

Wir nehmen also mit, dass es NUR die Benutzer betrifft, die in Skype for Business Online gehostet sind. Alle Benutzer, die in einer Hybrid-Umgebung noch auf ihrem lokalen Skype for Business Server liegen, werden nicht angefasst.

Homeserver Aktueller Mode Nach der Umstellung Status

Online

<default> (Island)

Online <default> (TeamsOnly)

User informieren

Online

SfbOnly

Online TeamsOnly

User informieren

Online

SfbwithTeamsCollab

Online TeamsOnly

User informieren

Online

SfbwithTeamsCollabandMeeting

Online TeamsOnly

User informieren

Online

TeamsOnly

Online TeamsOnly

Keine Änderung

On-Prem

SfbOnly

OnPrem SfbOnly

Keine Änderung

On-Prem

SfbwithTeamsCollab

OnPrem SfbwithTeamsCollab

Keine Änderung

On-Prem

SfbwithTeamsCollabandMeeting

OnPrem SfbwithTeamsCollabandMeeting

Keine Änderung

On-Prem

TeamsOnly

Nicht möglich

Nicht möglich !

Sie müssen natürlich nicht darauf warten, dass Microsoft das "überraschend" macht, sondern sie können diesen neuen Default auch selbst geplant umstellen.

Besser kontrollieren

Sie wissen nun, dass es einige Benutzer in der Cloud betreffen könnte. Am einfachsten starten Sie dazu eine Teams PowerShell und werden ihren aktuellen Bestand aus. Interessant sind dabei alle CSOnlineUser, gruppiert nach dem HostingProvider und der TeamsUpgradePolicy.

# Bei bedarf installieren
Install-Module MicrosoftTeams
# ggfls in die Session laden
Import-Module microsoftteams
# Verbinden
Connect-MicrosoftTeams

Get-CSOnlineUser -resultsize unimited | group TeamsUpgradePolicy,hostingprovider -NoElement | ft -AutoSize

Count Name
----- ----
   10 UpgradeToTeams, sipfed.online.lync.com
   27 sipfed.online.lync.com
    1 SfBWithTeamsCollab, sipfed.online.lync.com
   23
   30 SRV:
    1 SfBOnlyWithNotify, sipfed.online.lync.com
    1 IslandsWithNotify, sipfed.online.lync.com
    1 SfBWithTeamsCollabWithNotify, sipfed.online.lync.com
    1 SfBWithTeamsCollabAndMeetings, sipfed.online.lync.com
    2 SfBOnly, sipfed.online.lync.com
    1 SfBWithTeamsCollab, SRV:

Mein Demo- und Test-Tenant ist also durchaus gemischt unterwegs.

  • 23 Objekte ohne eine Informationen
    Das sind Benutzer die nicht aktiviert sind aber dennoch gelistet werden.
  • 30 Elemente mit SRV:
    Hier finded Get-CSOnlineUser Exchange Health-Mailboxen, die eigentlich nichts mit Teams und SfB zu tun haben. Sie haben interessanterweise eine SIP-Adresse, weil vermutlich der lokale Exchange Server per RecipientPolicy eine SIP-Adresse in die ProxyAddresses addiert. On-Premises haben Sie aber keinen HostingProvider.

Kontrollieren Sie also insbesondere die Objekte die schon in Skype for Business Online sind. Das geht recht einfach mir folgendem Befehl:

Get-CsOnlineUser `
   -Filter {Hostingprovider -eq "sipfed.online.lync.com"} `
| ft sipaddress,TeamsUpgradeEffectiveMode,TeamsUpgradePolicy,TeamsUpgradeOverridePolicy

SipAddress                      TeamsUpgradeEffectiveMode     TeamsUpgradePolicy            TeamsUpgradeOverridePolicy
----------                      -------------------------     ------------------            -------
sip:cloudus1@uclabor.de         Islands
sip:Cloudus2@uclabor.de         SfBWithTeamsCollab            SfBWithTeamsCollab
sip:Cloudde3@uclabor.de         Islands
sip:DisabledUser2@UCLABOR.DE    Islands
sip:EnabledUser@UCLABOR.DE      Islands
sip:DisabledUser@UCLABOR.DE     Islands
sip:fctest2@uclabor.de          SfBOnly                       SfBOnlyWithNotify
sip:fctest1@uclabor.de          Islands                       IslandsWithNotify
sip:fctest3@uclabor.de          SfBWithTeamsCollab            SfBWithTeamsCollabWithNotify
sip:fctest4@uclabor.de          SfBWithTeamsCollabAndMeetings SfBWithTeamsCollabAndMeetings
sip:DirectCallUser1@uclabor.de  TeamsOnly                     UpgradeToTeams
sip:fctest5@UCLABOR.DE          TeamsOnly                     UpgradeToTeams

Wenn Sie sich nur noch die Objekte suchen, die noch nicht "UpgradeToTeams" sind, dann können Sie darauf filtern. Ein Filter auf TeamsUpgradeEffectiveMode gibt es wohl nicht.

Get-CsOnlineUser `
   -Filter {Hostingprovider -eq "sipfed.online.lync.com" -and TeamsUpgradePolicy -ne "UpgradeToTeams"} `
| ft sipaddress,hostingprovider,TeamsUpgradeEffectiveMode,TeamsUpgradePolicy,TeamsUpgradeOverridePolicy

Alle Objekte in Skype for Business Online, die noch nicht auf TeamsOnly sind, sollten Sie umgehend über den anstehenden Wechsel informieren:

Manuell umstellen

Ich würde ich als Firma nicht auf den Automatismus von Microsoft verlassen, sondern die Benutzer vorher geplant auf TeamsOnly umstellen.

  1. SfBOnline-Benutzer informieren
  2. Benutzer auf TeamsOnly umstellen
    Das geht mit "Grant-CsTeamsUpgradePolicy -identity <sip-adresse> policy "UpgradetoTeams" sehr einfach
    Durch die Umstellung pro Benutzer wird auch der Teams Meeting Migration Service (MMS) angestoßen
  3. Anwender bekommt in Skype for Business die Meldung, dass er nun Teams nutzt
    In Outlook neu geplante Meetings werden in Teams erstellt und auch jegliche weitere Kommunikation landet in Teams
  4. Umstellung abgeschlossen

Danach können Sie der Migration durch Microsoft recht gelassen ins Auge sehen, denn ihre Online-Benutzer sind dann alles geplant und geordnet schon im "TeamsOnly"-Mode und ihre im Hybrid-Mode eventuell noch lokalen Benutzer behalten ihre Koexistenz-Einstellungen unverändert bei.

Achtung:
Wenn ihr Tenant schon im "Upgrade-Prozess" ist, was wohl für alle Tenants zutrifft, dann ist diese Umstellung eine Einbahnstraße!" Wenn Sie so einen Benutzer auf "UpgradetoTeams" setzen, dann können Sie diesen Benutzer nicht mehr in einen anderen Mode versetzen.

Wenn Sie einen Überblick über ihren Tenant und SfB/Teams-Benutzer bekommen wollen, dann bringen einige PowerShell-Befehle schnell Klarheit

Solche Analysen könnten Sie natürlich auch regelmäßig in ihr Monitoring einbauen.

Wir brauchen zuerst eine Teams PowerShell:

install-module MicrosoftTeams
import-module MicrosoftTeams
Connect-microsoftteams

Zuerst interessiere ich mich nur für die OnlineUser. Ich hole mir die Liste in eine Variable:

$onlineuser= Get-CsOnlineUser -ResultSize unlimited -Filter {hostingprovider -eq 
"sipfed.online.lync.com"}

Dann schauen wir mal, wer schon "TeamsOnly" als effektiven Mode hat

$onlineuser | group TeamsUpgradeEffectiveMode -noelement
 
Count Name
----- ----
115    Islands
530    TeamsOnly

Interessant, dass es in diesem Tenant so viele Island-User gibt, wo doch laut Kunde alles schon auf TeamsOnly sein sollte. Also schauen wir uns mal den InterpretedUserType  der "Island"-User an.

$onlineuser `
| where {$_. TeamsUpgradeEffectiveMode  -eq “Islands”} `
| group InterpretedUserType -NoElement | ft -AutoSize
 
Count Name
----- ----
    5 AADConnectDisabledOnlineActiveDirectoryDisabledUserPendingDeletionFromAD
  210 AADConnectEnabledOnlineSfBUserWithTeamsLicense
   15 AADConnectEnabledOnlineActiveDirectoryDisabledUser
  286 AADConnectEnabledOnlineUserNotLicensedForService
    2 PureOnlineUserNotLicensedForService
    3 PureOnlineSfBUserWithTeamsLicense
    1 AADConnectEnabledOnlineActiveDirectoryDisabledUserPendingAttributeRemovalFromAD
    1 AADConnectEnabledOnlineActiveDirectoryDisabledUserWithMCOValidationError
    1 AADConnectEnabledOnlineSfBUserWithTeamsLicenseWithMCOValidationError
    3 HybridOnlineApplicationInstance
    1 AADConnectDisabledOnlineSfBUserWithTeamsLicensePendingDeletionFromAD
    1 AADConnectEnabledOnlineUserNotLicensedForServicePendingAttributeRemovalFromAD
    1 PureOnlineTeamsUser
    1 PureOnlineActiveDirectoryDisabledUser

Beim Hybrid-Mode sollten fast alle Objekte mit meinem "AADConnect" anfangen. Die "PureOnline"-Objekte werden nicht durch ADSync abgeglichen und damit weiß der lokale SfB Server davon nichts. Das hat Auswirkungen, da die On-Premises-Benutzer nicht mit dem Online-Benutzern kommunizieren können und Federation eingeschränkt ist.

Neben den "PureOnline"-Konten, gibt es aber auch noch Konten, die durch ADSync repliziert werden aber ebenfalls im lokalen Skype for Business On-Premises nicht konfiguriert sind. Das passiert leicht, wenn Sie beim Provisioning einen Benutzer im AD anlegen und nach der Replikation per AADConnect in die Cloud mit einer Lizenz versehen. Diese Objekt kann man wie folgt einfach ermitteln:

($onlineuser | where {$_. OnPremSIPEnabled -ne "true"}).Count
33

Auch das sollte nicht passieren. Diese Benutzer sind in Skype for Business Online bzw. Teams und im lokalen AD nicht gepflegt. Nur wenn sie KEINEN Hybrid-Mode haben, dann sind diese Objekte erwartet.

Das ist nur ein Anfang und letztlich gehört schon etwas Erfahrung beim SfB Hybrid-Mode dazu, um die Werte zu interpretieren. Wenn Sie aber keinen lokalen SfB Server mehr betreiben aber die Benutzer aus dem AD per AADConnect synchronisieren, dann sollten Alle Benutzer "TeamOnly" und AADConnect* haben.

Schwebezustand

Nach der Umstellen sollte ihr Tenant einige Zeit noch folgende Information anzeigen.

Ich erwarte, dass Microsoft irgendwann wir Microsoft diese Anzeige aber wohl verschwinden lässt.

Ich habe einen Tenant, der zwar per DirSync mit einem lokalen Active Directory verbunden ist aber weder Exchange On-Premises noch Skype for Business On-Premises nutzt. Es gibt daher keinen Hybrid-Mode und das war wohl ein Grund, dass dieser Tenant sehr früh umgestellt wurde

Hinweis
Ich berichte hier über die Standard-Einstellungen in dem Tenant am 22. Sep 2021. Sie sind nicht, was ich erwartet habe!.

 Ich habe mir zuerst die Tenant-Konfiguration per PowerShell angezeigt.

PS C:\> Get-CsTenant | fl domains,teams*


Domains                          : {carius.onmicrosoft.com, carius.mail.onmicrosoft.com, msxfaq.net}
TeamsUpgradeEffectiveMode        : Islands
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       : None
TeamsUpgradePolicyIsReadOnly     : None

Hier hätte ich erwartet, dass die "TeamsUpgradeOverridePolicy" nun auf "TeamsOnly" steht. Sie sehen aber auch, dass der "TeamsUpgradeEffectiveMode" ebenfalls noch auf "Island" steht. Das sehe ich auch im Teams Admin Center unter https://admin.teams.microsoft.com/company-wide-settings/teams-upgrade

Auch der Blick in die Benutzer zeigt überraschende Einstellungen:

Get-CsOnlineUser -Filter {Hostingprovider -eq "sipfed.online.lync.com"} `
   | ft sipaddress,TeamsUpgradeEffectiveMode,TeamsUpgradePolicy,TeamsUpgradeOverridePolicy

SipAddress                       TeamsUpgradeEffectiveMode TeamsUpgradePolicy TeamsUpgradeOverridePolicy
----------                       ------------------------- ------------------ --------------------------
sip:User1@carius.de              TeamsOnly                 UpgradeToTeams
sip:User2@carius.de              Islands
sip:user3@carius.de              SfBOnly                   SfBOnly
sip:User4@carius.onmicrosoft.com Islands

Die Anwender, die keine explizit zugewiesene TeamsUpgradePolicy haben, bekommen den "Tenant Default", der in meinem Fall noch Island ist. Allerdings konnte sich der Anwender nicht mehr in Skype for Business anmelden.

Die lokale Logs (Lync-16.0.14430.20148-SigninTelemetryLog.XML) lieferten ein wenig aussagekräftiges

<Info>
   <![CDATA[GetTokenInternal return hr=0x800434d4 for https://webdir0e.online.lync.com/WebTicket/WebTicketAdvancedService.svc/WsFed_bearer]]>
</Info>
<Info>
   <![CDATA[Received IDCRL password error for userId(8) 0x800434d4,hr will be adjusted to 80f10041]]>
</Info>

Der Client ist schon an den webdir0e.online.lync.com gegangen aber hat kein Ticket bekommen. Im AzureSignIn-Logs war aber auch nichts zu sehen. Sehr suspekt. Aber die Anmeldung in Teams hat mit dem gleichen Kennwort funktioniert.

Der Versuch einen Benutzer in dem Status nun eine andere UpgradePolicy zuzuweisen, wurde aber mit einem Fehler quittiert:

PS C:\> Grant-CsTeamsUpgradePolicy -Identity sip:sip:User2@carius.de -PolicyName sfbwithteamscollab
Invoke-CsCommandInfo : User is scheduled to be upgraded by Microsoft in the near future. Notifications are not enabled
and this user can only be upgraded to TeamsOnly mode or to the same mode with notifications.

Obwohl also mein Tenant schon auf der Portalseite ein "Wir sind fertig" anzeigt, ist im Hintergrund das noch nicht erfolgt. Eventuell ist da der Wunsch der Vater des Gedankens aber das Provisioning im Backend muss erst hinterher laufen.

Auf der einen Seite kann ich mich als "Island"-User nicht mehr mit Skype for Business anmelden und bekomme auch nicht den Hinweise, dass ich doch Teams nutzen wollte. Auf der anderen Seite ist "TeamsOnly" noch gar nicht richtig aktiv. Es kann ein Einzelschicksal sein aber im Business-Umfeld ist das keine Antwort.

Finaler Zustand

Zum Glück habe ich auch am 15. September mit einen neuen Office 365 Developer Tenant (https://aka.ms/m365/devprogram) angelegt. Der war von Anfang an schon auf Teams Only". Auf dem Admin Portal gibt es keinen besonderen Hinweis:

Im Teams AdminCenter kann ich bei der Upgrade-Einstellung auch nichts mehr einstellen:

Beim Benutzer ist damit auch die Option nicht mehr vorhanden und der Koexistenzmode auf "nur Teams" gestellt.

Die Kontrolle über die PowerShell liefert nun auch endlich das erwartet Bild.

PS C:\> Get-CsTenant | fl domains,teams*

Domains                          : {msxfaqdev.onmicrosoft.com}
TeamsUpgradeEffectiveMode        : TeamsOnly
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       : ProvisionedAsTeams
TeamsUpgradePolicyIsReadOnly     : ModeAndNotifications

Ein Tenant, der vorher aber schon Skype for Business genutzt hat. sieht etwas anders aus

PS C:\> Get-CsTenant | fl domains,teams*

Domains                          : {msxfaqorg.onmicrosoft.com}
TeamsUpgradeEffectiveMode        : TeamsOnly
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       : UpgradeToTeams
TeamsUpgradePolicyIsReadOnly     : ModeAndNotifications

Hier ist die "TeamsUpgradeOverridePolicy" auf "UpgradeToTeams" und nicht auf "ProvisionedAsTeams"

Die Auswertung des Feldes "TeamsUpgradeOverridePolicy" hilft ihnen schon mal zu ermitteln, ob ihr Tenant schon abgeschlossen oder noch in der Übergangsphase befindet

Wenn ich mich dann als Benutzer versuche mit Skype for Business anzumelden, dann gelingt mir noch die Anmeldung aber danach kommt das bekannte Bild:

So sollte es sein und nicht, wie ich im Abschnitt Schwebezustand beschrieben habe.

Get-CSTeamsUpgradeStatus

Aus verschiedener Quellen gibt es ein Commandlet "Get-CSTeamsUpgradeStatus", welches die neue Microsoft-Teams PowerShell auch bereitstellt. Wenn alles gut läuft, dann sieht es z.B. wie folgt aus

Get-CsTeamsUpgradeStatus

TenantId             : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
State                : ScheduledForUpgrade
OptInEligibleDate    : 2021-05-12 18:06:36Z
UpgradeScheduledDate : 2021-07-15 00:00:00Z
UserNotificationDate : 2021-08-05 00:00:00Z
UpgradeDate          : 2021-08-10 00:00:00Z
LastStateChangeDate  : 2021-07-06 22:52:21Z

Allerdings habe ich in keine meiner Tenants bislang eine Antwort gekommen. Der Fehler war immer:

PS C:\> Get-CsTeamsUpgradeStatus
An error occurred while sending the request.
+ CategoryInfo : NotSpecified: (:) [Get-CsTeamsUpgradeStatus], HttpRequestException
+ FullyQualifiedErrorId : System.Net.Http.HttpRequestException,Microsoft.Rtc.Management.Hosted.Tenant.TeamsUpgradeStatusCmdlets+GetCsTeamsUpgradeStatusCmdlet
+ PSComputerName : api.interfaces.records.teams.microsoft.com

Ich vermute, dass dies vielleicht ein temporäres Problem ist.

Sonderfälle

Durch den Wechsel zu "TeamsOnly" für alle "Online"-User fallen viele Koexistenz-Szenarien weg. Aber da wir nun einen Benutzer nicht mehr nach Skype for Business Online in die Betriebsarten (SfBOnly, SfBwithTeamsCollab oder SfBwithTeamsCollabandMeetings) migrieren können, sonder diese direkt in TeamsOnly unterwegs sind, habe ich eine kleine Testserie gemacht.

Homeserver Aktueller TeamsUpgrade Möglicher Zielmodus Status

Online

<default> (TeamsOnly)

Online TeamsOnly

Online

TeamsOnly

Online TeamsOnly

OnPrem

SfbOnly

Benutzer kann kein Teams nutzen

OnPrem

SfbwithTeamsCollab

Benutzer nutzt Teams für Zusammenarbeit, plant seine Meetings aber weiter mit Skype for Business OnPrmises

OnPrem

SfbwithTeamsCollabandMeeting

Benutzer nutzt Teams für Zusammenarbeit und plant auch seine Meetings mit Teams

OnPrem

TeamsOnly

Diese Konfiguration ist nicht möglich.

Der Versuch einen OnlineUser mit einer anderen Richtlinie als der "Default" oder "TeamsOnly" zu versehen, wird während und nach der Migration aber administrativ unterbunden:

Grant-CsTeamsUpgradePolicy `
   -Identity sip:onlinesbfonly@carius.de `
   -PolicyName sfbwithteamscollabandmeetings

Invoke-CsCommandInfo : User is scheduled to be upgraded by Microsoft in the near future. Notifications are not enabled
and this user can only be upgraded to TeamsOnly mode or to the same mode with notifications.

Im Admin-Portal geht es dann natürlich auch nicht. Die Fehlermeldung ist aber weniger aussagekräftig:

Sobald Sie den Benutzer aber von Hand einmal umgestellt haben, geht es auch nicht mehr zurück!

Grant-CsTeamsUpgradePolicy `
   -Identity sip:onlinesbfonly@carius.de `
   -PolicyName UpgradeToTeams


Grant-CsTeamsUpgradePolicy `
   -Identity sip:onlinesbfonly@carius.de `
   -PolicyName $null


Invoke-CsCommandInfo : This user is hosted in the cloud, so you cannot assign an instance of TeamsUpgradePolicy with a
mode other than TeamsOnly.

Das ist also definitiv eine Einbahnstraße.
Sie könnten im Hybrid-Mode nur den Benutzer wieder nach On-Premises schieben und dann den Mode anpassen. Beim Zurückschieben in die Cloud wäre er dann noch in dem Interop-Mode, bis Microsoft das "UpgradetoTeams" verpflichtend gemacht hat.

Genauso wenig können Sie einen "Skype for Business On-Premises Benutzer auf "UpdatetoTeams" setzen. Die PowerShell unterbindet dies aktiv mit folgendem Fehler:

Grant-CsTeamsUpgradePolicy `
   -Identity sip:onpremuser@UCLABOR.DE `
   -PolicyName upgradetoteams

Invoke-CsCommandInfo : User is homed On-Premises in a Skype for Business or Lync deployment. On-Premises users can be
upgraded to Teams using Move-CsUser in the On-Premises tools. For details, see http://aka.ms/UpgradeToTeams

In der GUID ist der Fehler ebenfalls aussagekräftig:

Wie erwartet müssen Skype for Business On-Premises Benutzer erst einmal in die Cloud migriert werden.

Einschätzung

Der Weg von Microsoft ist klar vorgezeichnet, dass alle "Online-Benutzer" in absehbarer Zeit auf "Teams Only" laufen. Allerdings ist die Zwischenphase alles andere als Konsistenz. Das Portal meldet schon Vollzug während im Hintergrund die Benutzer sich noch wie vor der Migration verhalten. Wird aber manuell migriert, dann ist der Weg zurück für diesen Online-Benutzer blockiert.

Mein Empfehlung lautet: Warten Sie nicht auf die Automatismen von Microsoft sondern stellen Sie selbst ihre Benutzer gezielt um. Dann wissen Sie auch, wie sich das System verhält.

Setzen die daher den TeamsUpgradeMode der Online-Benutzer mit "Grant-CsTeamsUpgradePolicy -identity <sip-adresse> policy "UpgradetoTeams". Damit werden die Benutzer korrekt auf "TeamsOnly" konfiguriert und ggfls. der Teams Meeting Migration Service (MMS) angetriggert. Sie können danach die globale Einstellung ihres Tenant auf TeamsOnly setzen, damit danach angelegt Anwender gleich den richtigen Mode haben.

Weitere Links