TeamsOnly Rollback

Wie so oft lassen sich nicht alle Fehlerfälle in einem Labor vorab durchspielen sondern passieren im echten Leben oder eben beim Kunden. Auf dieser Seite habe ich unsanft die Auswirkungen eines Teams Zwangsmigration erfahren dürften und über den Weg wieder mehr über die Funktionen im Unterbau gelernt. Microsoft hat seit Herbst 2021 die Skype for Business Online-Funktion abgeschaltet hat und damit sind Anwender entweder in der Cloud mit "TeamsOnly" oder auf SfB On-Premises mit einem der anderen Betriebsarten aber eben nicht "TeamsOnly".

Beachten Sie dazu auch die Seiten Teams Modes, Teams Koexistenz-Konfiguration und InterpretedUserType

Fehlerbild: HybridOnPremTeamsOnlyUser

Ausgangspunkt ist eine Firma, bei dem alle Anwender noch "On-Premises" mit Skype for Business arbeiten und dies auch noch einige Zeit lang so bleiben wird. Parallel gibt es natürlich einen Microsoft 365 Tenant mit Exchange Online, Intune und auch schon Teams. Dieses Betrieb ist durchaus möglich, weil die Anwender parallel zu Skype vor Business auch Microsoft Teams nutzen können. Über den per Benutzer oder global konfigurierbar UpdatePolicy kann eine Betriebsart (Siehe Teams Modes) eingestellt werden Viele Firmen haben sich darüber nie Gedanken gemacht und nutzen den Islands-Mode (Siehe auch Teams Island-Mode - nichts wie weg damit?).

In diesem Fall war es aber so, dass die Benutzer in der Cloud schon mit der Betriebsart "TeamsOnly" konfiguriert waren, obwohl sie lokale SfB On-Premises-Benutzer waren. Ein Get-CSOnline-User hat die unglückliche Konfiguration bei einem Benutzer direkt aufgezeigt: (Auszug).

PS C:\> get-csonlineuser user@msxfaq.de

TeamsUpgradeEffectiveMode        : TeamsOnly
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       :
TeamsUpgradePolicy               : Islands
TeamsUpgradePolicyIsReadOnly     : None
OnPremEnterpriseVoiceEnabled     : True
OnPremHostingProvider            : SRV:
OnPremLineUri                    :
OnPremOptionFlags                : 0
OnPremSIPEnabled                 : True
HostingProvider                  : SRV:
InterpretedUserType              : HybridOnPremTeamsOnlyUser

Auch die Anzeige im Admin-Portal zeigt eindeutig, das dieser Benutzer schon "TeamsOnly" ist.

Allerdings ist diese Konfiguration eigentlich gar nicht möglich, denn ein "TeamsOnly"-User muss auch in SfBOnline gehostet sein und darf nicht ein SfBOn-Premises-Konto haben. Aber genau das ist durch ADSync vorgegeben.

Auch der Versuch dem Benutzer eine andere Richtlinie zuzuweisen schlägt fehl:

 Die Meldung sagt dazu:

"TeamsUpgradePolicy cannot be set because Microsoft has already upgraded user or organization to Teams"

Das bringt mir ein anderes Verhalten von Microsoft Teams wieder in Erinnerung, welches in 2021 aktuell war.

Microsoft offers an automated upgrade option for small organizations which might not have dedicated IT resources who are able to perform the upgrade to Teams. Before upgrade, Microsoft will send a notification in Message Center and email to your mailbox to notify that your tenant will be upgraded to Teams. You can choose to accept or postpone it. Once you accept or ignore, Microsoft will automatically upgrade to Teams. In this scenario, you cannot downgrade to Skype for Business by yourself.
Quelle: https://answers.microsoft.com/en-us/msteams/forum/all/the-settings-fro-your-organization-have-been-set/4bf00f04-0e88-4225-b0f6-19e5d18c9838

Teams Zwangsupdate

Auf der Seite Teams Zwangsmigration habe ich beschrieben, dass Microsoft Tenants unter bestimmten Umständen auf "TeamsOnly" hochsetzt. Der Prozess ist mit mehreren Meldungen an die globalen Administratoren verbunden und eine Zeit lang konnte man den Tenant von "TeamsOnly" sogar wieder auf "Island" über ein Support-Ticket zurückstellen lassen. Das ist aber seit August 2021 (?) anscheinend nicht mehr möglich. Eine Kontrolle des Kundentenant mit "Get-CSTenant" ergab dann folgendes Bild.

Auszug von Get-CSTenant

TeamsUpgradeOverridePolicy: UpgradeToTeams

Interessanterweise waren alle meine anderen großen und kleinen Test-Tenant noch nicht mit diesem Flag versehen und sogar der Net at Work-Tenant, der alle Anforderungen erfüllt, ist das Update noch nicht erfolgt.

Hier gibt es also durchaus noch Klärungsbedarf.

Vorgeschichte

Es stellt sich aber die Frage, wie das bei dem Tenant denn soweit kommen konnte und hier gibt es eine interessante Vorgeschichte. Der betroffene Tenant ist nämlich erst später zum produktiven Tenant geworden. Der zeitliche Ablauf stellte sich in etwa so dar

1. Jahr 2020: Der Kunde hat einen Tenant "<kundeteams>.onmicrosoft.com" angelegt
   Der wurde mit Teams zu Corona-Zeiten als Konferenztenant genutzt. Allerdings waren alle Benutzer noch auf Skype for Business On-Premises und damit war die Betriebsart "Island-Mode" und dank der "Lyncdiscover"-Einträge für die Kundendomain hat Microsoft auch nichts umgestellt.
2. Jahreswechsel 2021/2022: Ein neuer Tenant wird geplant
   Wie so oft ist der bisherige Tenant natürlich nicht komplett konfiguriert wurden. Vielleicht passt auch der Namen nicht oder man möchte einfach noch mal "frisch" anfangen. Es wird also eine Tenant zu Tenant -Migration geplant. Im bisherigen Tenant sind ja "nur" ein paar Teams User mit etwas OneDrive und SharePoint Online drin und nicht die komplette Firma etc.
3. Frühjahr 2022: Zweiter Tenant "<kundewelt>.onmicrosoft.com wird angelegt
   In Vorbereitung zur Tenant Migration wird ein zweiter Tenant mit ein paar Usern angelegt. Er bekommt eine Teams Exploratory-License aber noch keine Custom Domain. Das scheint ein Schlüsselelement zu sein, da der Tenant "irgendwann" dann wohl auf "TeamsOnly" umgestellt wird, weil es keinen lyncdiscover-Eintrag gibt. Es gibt auch nur ein paar Benutzer mit einer "onmicrosoft.com-Adresse" in dem Tenant.
4. Frühsommer 2022
   Nun wird ADSync in der Konfiguration installiert, die erst seit Dez 2021 möglich ist (Siehe dazu ADSync T2T-Migration). Damit kommen nun alle Benutzer in den neuen Tenant aber noch ohne die Custom Domain. Sie haben "noch" eine <kundewelt>.onmicrosoft.com-Adresse. Auch werden erste Daten des alten Tenants schon einmal "kopiert" und SharePoint-Bibliotheken angelegt und Berechtigungen vergeben. Eben alles, was z.B. in der Checkliste Tenant Einrichtung so besprochen wird.
5. Sommer 2022
   Am "großen Tag" wird dann die eigentlich Domain im alten Tenant entfernt un im neuen Tenant eingetragen. Klar gibt es einige Stoplersteine aber die meisten Dinge funktionieren wie geplant. Nur eben das Thema Teams Upgrade Mode fällt nun auf.

Eine Bestätigung von Microsoft habe ich bislang nicht bekommen aber ich vermute, dass nach dem Schritt 3 irgendwann Microsoft den Tenant umgestellt hat.

Wenn Sie das sicher verhindern wollen, dann sollten Sie in dem Tenant eine DNS-Domain addieren, in der es einen Lyndiscover-DNS-Eintrag gibt, der nicht auf die Microsoft Cloud verweist. Das sollte dann das Upgrade blockieren.

Die Benutzer haben als InterpretedUserType aber tatsächlich ein "HybridOnPremTeamsOnlyUser", was so eigentlich nicht erlaubt ist.

Auswirkungen

Nun könnte man sagen, dass das doch alles nicht so schlimm ist. Die Anwender können ja dennoch mit Skype for Business On-Premises arbeiten und der Funktionsumfang mit Teams ist bei "TeamsOnly" oder "Island" doch auf den ersten Blick identisch. Für den Anwender und Administrator sind auf den ersten Blick tatsächlich keine Unterschiede zu erkennen aber im Details knirscht es dann doch kräftig. Zwei Probleme konnte ich schon bestätigen:

• Presens/Chat-Federation
  Wenn ich "TeamsOnly" bin, dann sehe ich auch die Chat-Funktion, mit der ich aber nur andere Teams-Benutzer erreichen kann. Soweit ist das auch bei ISLAND so aber ich kann die anderen SfBOnPrem-Benutzer nicht erreichen, da die keinen anderen Interop-Mode (SfbOnly, SfBwithTeamsCollab, SfBwithTeamsCollabandMeeting) haben können. Auch bei der Federation mit anderen Firmen wird Teams nicht mehr die SIP-Federation nutzen, wenn es das Ziel schon als "TeamsOnly"-Benutzer findet.
• Telefon-Applikation
  Wenn der Teams Client erkennt, dass der Mode schon "TeamsOnly" ist, dann scheint er sich auf ihrem Desktop auch als primäre "Telefonie-Applikation" zu registrieren. Ich hätte erwartete, dass Teams dies nur tut, wenn der Benutzer eine PSTN-Lizenz hat. Aber in einem Fall hat Teams die vorhandene Skype for Business On-Premises-Konfiguration bei jedem Start wieder überschrieben.

Das dritte Problem gilt es noch zu verifizieren:

• Migration
  Wenn meine Buddy-Liste und Termine alle in Skype for Business On-Prem liegen und ich dann irgendwann in die Cloud möchte, dann ist der normale Prozess ein "Move-CSUser" in die Cloud. Das Commandlet kopiert dann optional meine Skype Kontakte zu Skype Online und setzt den Status auf TeamsOnly, so dass alles in Teams landet. Ich habe noch nicht getestet, was in dem Fall passiert, dass das Ziel schon "TeamsOnly" ist. Vielleicht kann ich einfach nicht migrieren und muss stattdessen den SfB-Benutzer deaktivieren und als SfB-Online User mit TeamsOnly anlegen? Meine Buddylisten sind weg aber auch meine Kollegen verlieren mich, da ich ja dann ein neuer Benutzer bin.

Und vielleicht gibt es noch weitere Einschränkungen, auf die ich noch gar nicht gestoßen bin.

Tenant Upgrade Default

Ich habe in der Zeit natürlich all meine Tenants durchgeforstet und den aktuellen Status ermittelt. Da gibt es nämlich durchaus inkonsistente Anzeigen. Wenn ich auf auf https://admin.teams.microsoft.com/dashboard gehe, dann zeigt mit das Dashboard ein "Your Teams upgrade is complete" an:

Das erscheint sinnvoll, denn auch Lyncdisover verweist in die Cloud und lokale SfB On-Premises-Server gibt es nicht mehr. Wenn ich aber die "Teams Upgrade Settings" auf https://admin.teams.microsoft.com/company-wide-settings/teams-upgrade anschaue, dann steht da auch immer noch ein "Island".

Auch die Kontrolle per PowerShell liefert ein "Island" und dass keine "TeamsUpgradeOverridePolicy" gesetzt wurde.

PS C:\> Get-CsTenant | fl team*

TeamsUpgradeEffectiveMode        : Islands
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       : None
TeamsUpgradePolicyIsReadOnly     : None

Und das, obwohl alle Domains dieses carius.onmicrosoft.com-Tenant auf Microsoft 365 verweisen und der ADSync auch keine MSRTC*-Felder repliziert und ich gerade mal 5 Office 365 E3-Lizenzen aktiv habe.

So richtig kann ich hier nicht verstehen, warum es meinen Tenant noch nicht "erwischt" hat. ein Blick in das Postfach des Administrators hat auch noch keine "Tenant Upgrade"-Ankündigung geliefert.

Nur zur Sicherheit habe ich noch die globale TeamsUpgradePolicy per PowerShell ermittelt:

PS C:\> Get-CsTeamsUpgradePolicy global

Identity       : Global
Description    : Use either Skype for Business client or Teams client
Mode           : Islands
NotifySfbUsers : False
Action         : None

Wenn ich dem Benutzer keine manuelle Betriebsart zuweise, sollte der Anwender daher auch nach dem Wechsel durch Microsoft in "Island" bleiben. Allerdings passt das bei mir dann wieder nicht, denn mein Benutzer in der "carius.de"-Domain hat dennoch den "Teams Only"-Mode und ich kann es nicht ändern.

Some of these settings for your organization have been set by Microsoft and can't be changed. Learn more (https://docs.microsoft.com/en-US/microsoftteams/upgrade-and-coexistence-of-skypeforbusiness-and-teams )

Hingegen hat ein Benutzer im Net at Work-Tenant diese blaue Warnung nicht, obwohl dieser Tenant nicht im SfB Hybrid Mode ist.

Bei diesen Benutzer kann ich dann auch ein "Edit" machen aber auch das ist nicht immer von Erfolg gekrönt:

Da muss es noch eine weitere Einstellung geben, die nicht so offensichtlich ist. Microsoft schreibt selbst auch

Microsoft offers an automated upgrade option for small organizations which might not have dedicated IT resources who are able to perform the upgrade to Teams. Before upgrade, Microsoft will send a notification in Message Center and email to your mailbox to notify that your tenant will be upgraded to Teams. You can choose to accept or postpone it. Once you accept or ignore, Microsoft will automatically upgrade to Teams. In this scenario, you cannot downgrade to Skype for Business by yourself.
Quelle: https://answers.microsoft.com/en-us/msteams/forum/all/the-settings-fro-your-organization-have-been-set/4bf00f04-0e88-4225-b0f6-19e5d18c9838

Get-CsTeamsUpgradeStatus

Microsoft bietet dazu ein eigenes Commandlet an, um den Upgrade-Status zu prüfen oder auszulesen:

• Get-CsTeamsUpgradeStatus
  https://docs.microsoft.com/en-us/powershell/module/skype/get-csteamsupgradestatus?view=skype-ps
  Returns information related to the Microsoft-driven automated upgrade status from Skype for Business Online to Teams.

Leider konnte ich aber in meinem Tenants damit keine Daten mehr abfragen. Die Fehlermeldungen unterscheiden sich aber:

Aus der Dokumentation von Microsoft zu Get-CsTeamsUpgradeStatus kann man aber noch sehen, wie es mal ausgesehen haben dürfte:

PS C:\> Get-CsTeamsUpgradeStatus

TenantId             : ca573b31-a0db-4185-951e-3af848668397
State                : ScheduledForUpgrade
OptInEligibleDate    : 2018-04-12 18:06:36Z
UpgradeScheduledDate : 2018-06-15 00:00:00Z
UserNotificationDate : 2018-07-05 00:00:00Z
UpgradeDate          : 2018-07-10 00:00:00Z
LastStateChangeDate  : 2018-06-06 22:52:21Z

Das ist alles etwas verwirrend und hier sind noch einige Fragezeichen.

TeamsOnly zu Island mit ADSync TeamsUpgradeOverridePolicy=None

Ich wollte nun erst einmal sehen, wie sich ein noch nicht von Microsoft umgestellter Tenant verhält, in dem aber alle Benutzter schon "TeamsOnly" sind. Wäre das unveränderlich, dann könnten Sie nachträglich keine SfB On-Premises-Installation aufbauen wollen oder diese erst nachträglich mit dem Tenant verbinden. Die folgenden Tests wurden mit einem Tenant mit folgender Konfiguration gemacht:

PS C:\> Get-CSTenant | fl teams*,sipdomain

TeamsUpgradeEffectiveMode        : Islands
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       : None
TeamsUpgradePolicyIsReadOnly     : None
SipDomain                        : {msxfaq.net, msxfaqnet.onmicrosoft.com}

Alle "lyncdiscover"-Einträge verweisen auf die Cloud und ich habe keine Idee, warum dieser Tenant noch ein "TeamsUpgradeOverwritePolicy:None" hat. Aber für meinen ersten Test ist das OK. Solange die Benutzer im lokalen AD keine Skype for Business Properties haben, kann ADSync natürlich nichts replizieren und die Eigenschaften des Benutzers sind überschaubar:

# keine msRTC-Felder im lokalen AD
PS C:\> get-csonlineuser testuser1@msxfaq.net | fl *upgrade*,onprem*,hostingprovider,inter*

TeamsUpgradeEffectiveMode        : TeamsOnly
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       :
TeamsUpgradePolicy               : UpgradeToTeams
TeamsUpgradePolicyIsReadOnly     : None
OnPremEnterpriseVoiceEnabled     : False
OnPremHostingProvider            :
OnPremLineUri                    :
OnPremOptionFlags                : 0
OnPremSIPEnabled                 : False
OnPremSipAddress                 :
HostingProvider                  : sipfed.online.lync.com
InterpretedUserType              : DirSyncEnabledOnlineTeamsOnlyUser

Mit der Konfiguration ist der Benutzer in der Cloud auch mit "TeamsOnly" richtig konfiguriert. Wenn sie in der Cloud aber Island oder einen anderen Mode ungleich "TeamsOnly" setzen wollen, dann muss der Benutzer "SfB On-Premises" sein. Dazu ist es zumindest erforderlich, das in einem lokalen AD auch das SfB Schema vorhanden ist und ADSync die Felder in die Cloud repliziert.

In diesem Labor hatte ich leider keinen lokalen SfB-Server mehr und daher auch keinen Hybrid-Mode eingerichtet.

Ich habe dann nur folgende drei Felder direkt mit ADSIEDIT in meinem Labor gesetzt:

msRTCSIP-PrimaryUserAddress = "sip:user1@msxfaq.de"
msRTCSIP-DeploymentLocator = "SRV:"
msRTCSIP-UserEnabled = "true"

Nachdem ADSync diese Werte in die Cloud repliziert hat, haben sich einige Felder geändert:

# msRTC-Felder im lokalen AD gefüllt
PS C:\> get-csonlineuser testuser1@msxfaq.net | fl *upgrade*,onprem*,hostingprovider,inter*

TeamsUpgradeEffectiveMode        : Islands
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       :
TeamsUpgradePolicy               : Islands
TeamsUpgradePolicyIsReadOnly     : None
OnPremEnterpriseVoiceEnabled     : False
OnPremHostingProvider            : SRV:
OnPremLineUri                    :
OnPremOptionFlags                : 0
OnPremSIPEnabled                 : True
HostingProvider                  : SRV:
InterpretedUserType              : HybridOnPremSfBUserWithTeamsLicense

Sie sehen, dass Microsoft 365 in diesem Tenant den Cloud-Benutzer allein durch das Setzen der lokalen msRTC-Felder komplett zurückdreht und aus dem "TeamsOnly/SfBOnline"-User mit dem Status "DirSyncEnabledOnlineTeamsOnlyUser" wieder einen SfBOnPrem/Island-User macht, dessen InterpretedUserType wieder auf HybridOnPremSfBUserWithTeamsLicense steht.

Sobald ich die msRTC-Felder wieder lösche und ADSync die Änderungen übertragen hat, wird der Benutzer kurze Zeit später wieder zum Teams-Only User.

Hier funktioniert die Transformation wie erwartet.

Tenant mit TeamsUpgradeOverridePolicy=ProvisionedAsTeams

Mein MSXFAQLAB-Tenant wurde sehr spät angelegt und hat daher die "TeamsUpgradeOverridePolicy:ProvisionedAsTeams". Das ist also weder ein "´None" noch ein "UpgradeToTeams".

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

TeamsUpgradeEffectiveMode        : TeamsOnly
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       : ProvisionedAsTeams
TeamsUpgradePolicyIsReadOnly     : ModeAndNotifications

Auch hier habe ich einen Benutzer mit Teams Only als Startpunkt genommen. 

PS C:\> Get-CsOnlineUser fctest1 | fl *upgrade*,onprem*,hostingprovider,inter*

TeamsUpgradeEffectiveMode        : TeamsOnly
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       :
TeamsUpgradePolicy               : UpgradeToTeams
TeamsUpgradePolicyIsReadOnly     : ModeAndNotifications
OnPremEnterpriseVoiceEnabled     : False
OnPremHostingProvider            : sipfed.online.lync.com
OnPremLineUri                    : 
OnPremOptionFlags                : 0
OnPremSIPEnabled                 : false
OnPremSipAddress                 : sip:fctest1@uclabor.de
HostingProvider                  : sipfed.online.lync.com
InterpretedUserType              : HybridOnlineTeamsOnlyUser

Auch hier habe ich dann On-Premises die msRTC-Felder gefüllt und nach einem ADSync-Lauf hat sich der Benutzer etwas verändert:

PS C:\> Get-CsOnlineUser fctest1 | fl *upgrade*,onprem*,hostingprovider,inter*

TeamsUpgradeEffectiveMode        : TeamsOnly
TeamsUpgradeNotificationsEnabled : False
TeamsUpgradeOverridePolicy       :
TeamsUpgradePolicy               :
TeamsUpgradePolicyIsReadOnly     : ModeAndNotifications
OnPremEnterpriseVoiceEnabled     : False
OnPremHostingProvider            : SRV:
OnPremLineUri                    : 
OnPremOptionFlags                : 0
OnPremSIPEnabled                 : True
OnPremSipAddress                 : sip:fctest1@uclabor.de
HostingProvider                  : SRV:
InterpretedUserType              : HybridOnPremTeamsOnlyUser

Die Betriebsart ist zwar weiterhin "TeamsOnly" aber die Felder zur On-Prem sind gefüllt.

Hier noch mal als Gegenüberstellung der Änderungen:

Die Cloud hat erkannt, dass der Benutzer On-Premises ist aber sowohl der TeamsUpgradeEffectiveMode als auch der InterpretedUserType wurden nicht geändert.

Der Mode "HybridOnPremTeamsOnlyUser" dürfte es nie geben.

Achtung: Diese Konfiguration ist natürlich ungültig, denn ein Benutzer mit SFB On-Premises kann nie "TeamsOnly" sein.

Aber mit diesen Vorgaben konnte ich nun den Upgrade-Mode endlich auf einen anderen Mode umstellen:

#Umstellen auf den globalen Default, der bei mir immer noch ISLANDS ist
PS C:\> Get-CSOnlineUser user1@msxfaq.de | Grant-CsTeamsUpgradePolicy -Identity  -PolicyName global
# oder 
PS C:\> Get-CSOnlineUser user1@msxfaq.de | Grant-CsTeamsUpgradePolicy -Identity  -PolicyName $null


# oder Umstellen auf Island
PS C:\> Get-CSOnlineUser user1@msxfaq.de | Grant-CsTeamsUpgradePolicy -Identity 3b57a401-3a03-47a9-93b6-1ac8becf4202 -PolicyName Islands

Die Umstellung auf TeamsOnly" ist nun aber nicht mehr möglich, weil für die Cloud der Benutzer ja "SfB On-Premises" nutzt. Die Fehlermeldung gibt dies auch wieder:

PS C:\> Get-CSOnlineUser user1@msxfaq.de | Grant-CsTeamsUpgradePolicy -PolicyName upgradetoteams
Grant-CsTeamsUpgradePolicy: 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

Ergebnisse

Nach alle den Versionen sollte ich hier noch mal eine Kurzfassung bereitstellen. Habe vier Komponenten, von denen zwei als "Input" dienen:

• Tenant: TeamsUpgradeOverridePolicy
  Den aktuellen Wert ihres Tenants können Sie mit "(Get-CSTenant).TeamsUpgradeOverridePolicy" in Erfahrung bringen und hat einen von drei Werten:
  None = Nichts von Microsoft vorgegeben, d.h ihre eigenen Policies greifen
  UpgradeToTeams = Microsoft stellt alle Personen auf "TeamsOnly" um
  ProvisionedAsTeams = Der Tenant war schon immer Teams.
• Tenant: TeamsUpgradeEffectiveMode   : TeamsOnly oder Island   weis aber nicht, wie der gesetzt wird.
  Mit "(Get-CSTenant).TeamsUpgradeEffectiveMode" können Sie die effektiven Einstellung des aktuellen Modes des Tenants anzeigen.
  
• Global UpgradePolicy
  Jeder Tenant hat sechs "Get-CsTeamsUpgradePolicy"-Einträge und der "Mode"-Wert der "Global" Policy zeigt den Standard an, der für alle Benutzer gilt, wenn Sie keine abweichende individuelle Policy haben oder dieser Mode nicht "TeamsOnly" ist. Sie können den Wert mit "(Get-CsTeamsUpgradePolicy global).mode" auslesen.
• Pro Benutzer: Zuweisung einer Policy
  Wenn ihr globaler Mode noch nicht "TeamsOnly" ist, dann können Sie pro Benutzer individuelle Richtlinien zuweisen.

Entsprechend habe ich mit mehreren Tenants geschaut, welcher "TeamsUpgradeEffectiveMode" bei einem Tenant ankommt, wenn Microsoft die "TeamsUpgradeOverridePolicy" ändert.

Ich wollte meine Tenants nicht mit dem unumkehrbaren Setzen der CsTeamsUpgradePolicy "Global" kaputt machen und liefere die Daten nach, wenn ich entsprechende Tenants gefunden habe. Logisch wäre aber:

UpgradetoTeams

Island

Teamsonly

ProvisionedAsTeams

Island

Teamsonly

None

Island

Pro Benutzer per Policy konfigurierbar

UpgradetoTeams

UpgradeToTeams

TBD: Vermutlich Teamsonly

ProvisionedAsTeams

UpgradeToTeams

TBD: Vermutlich Teamsonly

None

UpgradeToTeams

TBD: Vermutlich Teamsonly

Nur solange ihr Tenant noch eine "TeamsUpgradeOverridePolicy=None" hat und sie selbst ihre globale CsTeamsUpgradePolicy noch nich auf "TeamsOnly" gestellt haben, können Sie Hybrid mit Skype for Business arbeiten oder für die Benutzer andere Betriebsarten als "TeamsOnly" einstellen.

Rollback

Nun habe ich am Anfang ja gesagt, dass ein Kunden-Tenant schon mit einer "TeamsUpgradeOverridePolicy=UpgradeToTeams" versehen war, obwohl das für einen Hybrid-Mode nicht die richtige Betriebsart sein kann. Die Ursache war wohl, dass der Tenant eben einige Zeit noch nicht fertig konfiguriert war und vor allem keine Custom Domain mit den DNS-Einträgen hatte. So konnte Microsoft gar nicht wissen, dass eine Hybrid-Bereitstellung geplant ist. Damit stellt sich natürlich die Frage nach einem "RollBack".

Angeblich sollte ein Tenant automatisch wieder von TeamsOnly auf "Island" umgestellt, werden wenn die DNS-Einträge einer Domain auf einen lokale SfB Installation verweisen. Eine schriftliche Quelle habe ich dazu aber nicht und so wissen wir nicht, ob das nur beim Addieren einer neuen Domain oder eines Users oder zyklisch geprüft wird. Auch ist nicht klar, ob es sich dabei um die "TeamsUpgradeOverridePolicy" oder die Einstellung der globalen TeamsUpgradePolicy oder noch eine bislang nicht bekannte Einstellung handelt.

in meinem Fall hat sich aber einige Tage nichts getan und daher haben wir über ein Microsoft Ticket die Problematik prüfen lassen. Parallel habe ich natürlich über meine MVP-Kontakte mal gefragt, wie das passieren kann und ob es überhaupt einen Rückweg gibt. Microsoft selbst schreibt ja, dass der Weg zu TeamsOnly "unumkehrbar" wäre. Aber aus der Aussage geht nicht genau hervor, ob damit die "TeamsUpgradeOverridePolicy" des Tenants oder der mode der globalen CsTeamsUpgradePolicy gemeint ist. Letztlich bekam ich dann aber eine hoffnungsvolle Antwort, die ich hier verkürzt zitiere:

.... Hybrid tenants should not be set to TeamsOnly mode. Confirm, that hybrid configuration is properly setup (Get-CsTenantFederationConfiguration shared address SIP space should be true) and then ask support engineer to fill an IcM on aka.ms\teamsrollback (internal website). These will be only entertained for hybrid deployments that is a requirement for Teams interop. For pure online tenants rollbacks are no longer an option.

Es gibt also einen Weg, die Umstellung des Tenants durch Microsoft in einigen Fällen wieder rückgängig zu machen. Leider gibt es keine deutlichere Aussage, was ein "pure online tenant" ist. Ich tippe mal auf Tenants, die gleich mit TeamsUpgradeOverridePolicy=ProvisionedAsTeams angelegt wurden oder der Administrator selbst wen Wechsel auf "TeamsOnly" durchgeführt hat.

Auf jeden Fall hat der Supporter den Prozess gestartet und dann muss wohl noch jemand drüber schauen ehe der Tenant dann zurück gestellt wird. Zwischen dem Start und der Rückmeldung sind ca. 1-2 Stunden vergangen, bis der Status im Tenant geändert war:

Allerdings hat des dann noch etwas gedauert, bis dies bei allen Benutzern angekommen ist. Der "TeamsUpgradeEffectiveMode" beim Benutzer war dabei schon recht schnell im Teams Backend angekommen. Aber es dauert natürlich schon noch einige Zeit, bis da auch der Desktop-Client bekommen hat und einige Einstellungen wurden erst nach einem Neustart der Applikationen (Teams, Outlook) aktiv.

Checkliste	Status
Kontrolle Tenant Mode PS C:\> (Get-CSTenant) | select TeamsUpgradeOverridePolicy | fl TeamsUpgradeOverridePolicy : None Das ist die Einstellung, die Microsoft von "UpgradeToTeams" beim Rollback ändern kann.	"None"
Kontrolle Global Upgrade Policy PS C:\> Get-CsTeamsUpgradePolicy global | select mode | fl Mode : Islands Diesen Parameter kann Microsoft angeblich nicht ändern und hoffentlich haben Sie als Admin diesen Wert noch nicht auf "TeamsOnly" geändert.	"Islands"
Kontrolle Benutzereinstellung Abfrage der Benutzer nach ihrem TeamsUpgradeOverridePolicy PS C:\> Get-CsOnlineUser | group TeamsUpgradeOverridePolicy -NoElement Count Name ----- ---- 21325 Durch den Rollback wird nun wieder die UpgradePolicy pro Benutzer und hat damit Auswirkungen auf den TeamsUpgradeEffectiveMode Vorher war der Effective Mode "TeamsOnly" und den Rollback machen Sie ja nur, wenn Sie weder den Tenant noch alle Benutzer per "TeamsUpgradePolicy" auf "UpgradeToTeam" gesetzt haben. Entsprechend sollte dann der "TeamsUpgradeEffectiveMode" bei einigen Benutzern wieder zurückgedreht sein. PS C:\> Get-CsOnlineUser | group TeamsUpgradeEffectiveMode -NoElement Count Name ----- ---- 21025 Islands 2 SfBWithTeamsCollab 2 SfBWithTeamsCollabandmeeting 2 SfBOnly 294 TeamsOnly Interessant ist in dem Zuge auch die auf die Anwender angewendete Policy. Zumindest die Benutzer ohne eine individuelle Richtlinie nutzen dann wieder Islands. PS C:\> Get-CsOnlineUser | group TeamsUpgradePolicy -NoElement Count Name ----- ---- 21021 4 IslandsWithNotify 1 SfBWithTeamsCollabWithNo… 1 SfBWithTeamsCollab 2 SfBWithTeamsCollabandMeeting 294 UpgradeToTeams	"$null"
Outlook Meeting AddOn Mit dem Wechsel des Benutzerstatus von "TeamsOnly" auf "Island" ändert sich auch die Anzeige der AddÓns in Outlook. Im Island-Mode sehe ich wieder sowohl das Skype for Business Addon als auch das Teams addOn
Externe Federation SFB On-Prem mit anderen Tenants Wenn ich einen Benutzer in einem anderen Tenant aus Teams anspreche, dann prüft das Teams Backend erst einmal, ob das Ziel "TeamsOnly" ist. Nur wenn der Mode nicht "TeamsOnly" ist, dann wird Teams die "_sipfederationtls._tcp"-Einträge zur Domain auflösen und die Anfragen zum Edge-Server senden. Auch in der Gegenrichtung muss das funktionieren. Achtung: Wenn Sie eine alten Chat in Teams fortsetzen wollen, bekommen Sie einen Fehler mit dem Hinweis, in SfB fortzusetzen.
Primärer Chat-Client und Call Handler Sobald ihr Benutzer auf "TeamsOnly" steht, wird der Teams Client natürlich auch den Call-Handler umstellen, d.h. ein Klick durch den Anwender auf eine Callto-URL oder Rufnummer oder Anwahl in Outlook startet den Teams Client. Mit dem Wechsel zurück auf Island hat bei mir der Client den Call Handler nicht zurück gedreht. Teams weiß ja auch nicht mehr, ob der vorherige Client nun Skype for Business oder vielleicht Cisco, Avaya o.ä. war. Hier müssen Sie Vorkehrungen treffen, diese Einstellung wieder umzustellen.
Weitere Probleme Liste wird fortgesetzt.

Weitere Links

• Teams Modes
• Teams Island-Mode - nichts wie weg damit?
• Teams Koexistenz-Konfiguration
• InterpretedUserType
• Teams Zwangsmigration
• Teams Koexistenz-Konfiguration
• UC Felder
• AADSync T2T-Migration
• Error when switching a tenant to Teams Only mode
  https://docs.microsoft.com/en-us/microsoftteams/troubleshoot/teams-administration/cannot-switch-to-teams-only-mode
  Hinweis auf "Lyncdiscover" als Schlüssel für die Umstellung
• The settings fro Your Organization have been set by Microsoft and can't be chasnged (Teams Upgrade)
  https://answers.microsoft.com/en-us/msteams/forum/all/the-settings-fro-your-organization-have-been-set/4bf00f04-0e88-4225-b0f6-19e5d18c9838
• Enabling Skype for Business in a new Teams-Only Office 365 Tenant
  https://practical365.com/log/enabling-skype-for-business-in-a-new-teams-only-office-365-tenant/
  Der Blog-Eintrag ist von Dez 2018 und nicht mehr zutreffend
• Self-rollback from Teams Only coexistence Mode to Island Mode
  https://medium.com/@doolatunde/self-rollback-from-teams-only-coexistence-mode-to-island-mode-baabdbc4fc78