W I S S E N · S K Y P E F O R B U S I N E S S S E R V E R S E

Skype for Business Server SE und Microsoft Teams: Coexistence-Modi richtig steuern

Welcher Modus schickt Chat, Anruf und Meeting in welchen Client – und wie du verlorene Anrufe und genervte User vermeidest. Mit PowerShell und DACH-Hybrid-Gotchas.

 

Boddenberg – IT-Beratung & Engineering · boddenberg.de · Stand: Juni 2026

TL;DR Die Kurzfassung für Eilige Die Coexistence-Modi (TeamsUpgradePolicy) entscheiden, in welchem Client Chat, Anruf und Meeting eines Users landen – nicht, ob er beide Apps installiert hat. Es gibt fünf Modi: SfBOnly, SfBWithTeamsCollab, SfBWithTeamsCollabAndMeetings, Islands und TeamsOnly. Zwei harte Regeln: Cloud-gehostete User sind zwingend TeamsOnly, on-prem-gehostete können jeden Modus außer TeamsOnly bekommen. Islands ist der Default in Hybrid – und genau der, der am meisten verwirrt, weil Nachrichten und Anrufe in beiden Clients ankommen. Gesteuert wird per Grant-CsTeamsUpgradePolicy, am besten wellenweise statt tenant-weit auf einen Schlag.

 

Worum es hier geht

In fast jeder realen Umgebung ist Skype for Business Server SE nicht das Endziel, sondern eine Brücke: Du hast On-Prem-User, du hast Teams-User, und beide sollen miteinander reden können. Die Coexistence-Modi sind das Werkzeug, das dieses Nebeneinander steuert. Wer sie nicht aktiv in die Hand nimmt, produziert verlorene Anrufe, doppelte Meetings und vor allem genervte Anwender. Das große Bild zu Hybrid liefert der Pillar „Skype for Business Server SE im Überblick“; dieser Artikel ist die Steuerungs-Logik im Detail.

Der häufigste Irrtum vorweg: Der Modus ist keine technische Spielerei und auch keine Frage, welche App jemand installiert hat. Er ist ein knallhartes Routing-Werkzeug. Er entscheidet, in welchem Client ein eingehender Anruf klingelt, wo ein Chat ankommt und wo ein neues Meeting angelegt wird. Genau deshalb ist er das wichtigste Steuerungsinstrument jeder Hybrid-Migration.

Die fünf Modi im Überblick

Die fünf Modi bilden ein Spektrum von „ganz SfB“ bis „ganz Teams“. Dazwischen liegen Mischzustände, die einzelne Workloads (Chat, Anruf, Meeting) schrittweise nach Teams verschieben.

Skizze 1: Die fünf Coexistence-Modi und wohin Chat, Anruf und Meeting jeweils laufen. Islands (rot) ist der Default und der größte Verwirrungsstifter; TeamsOnly (grün) ist der Zielzustand.

Die Modi-Matrix: Chat, Call, Meeting-Routing

Diese Tabelle ist das Herzstück. Sie sagt dir für jeden Modus, wo welcher Workload landet – und genau das musst du dem Anwender vorher erklären, sonst sucht er seine Anrufe im falschen Client.

Modus	Chat	Anruf	Meeting	Teams-Collab
SfBOnly	SfB	SfB	SfB	nein
SfBWithTeamsCollab	SfB	SfB	SfB	ja
SfBWithTeamsCollab- AndMeetings	SfB	SfB	Teams	ja
Islands	beide	beide	beide	ja
TeamsOnly	Teams	Teams	Teams	ja

 

ACHTUNG Islands klingt bequem und ist die größte Falle Im Islands-Modus laufen SfB und Teams völlig parallel – Chat, Anruf und Meeting kommen in beiden Clients an. Das fühlt sich am Anfang flexibel an und ist genau deshalb der Default. In der Praxis heißt es: Ein Anruf klingelt im einen Client, der User hat aber den anderen offen – verpasster Anruf. Zwei Chat-Verläufe zum selben Thema in zwei Apps. Islands ist als kurze Übergangsphase okay, als Dauerzustand ein Anwender-Albtraum.

Steuerung per PowerShell

Der Modus wird über die TeamsUpgradePolicy gesteuert – pro User oder tenant-weit. In einer Migration arbeitest du fast immer pro User bzw. pro Gruppe (Welle), nie tenant-weit auf einen Schlag.

# Modus eines einzelnen Users setzen

Grant-CsTeamsUpgradePolicy -Identity max.muster@contoso.de `

    -PolicyName SfBWithTeamsCollabAndMeetings

# Eine ganze Welle (z. B. per Liste) auf TeamsOnly heben

Get-Content .\welle3.txt | ForEach-Object {

    Grant-CsTeamsUpgradePolicy -Identity $_ -PolicyName UpgradeToTeams }

# Aktuellen Modus prüfen

Get-CsOnlineUser max.muster@contoso.de | Select TeamsUpgradePolicy

Der Policy-Name für TeamsOnly heißt in der Praxis UpgradeToTeams (der „Modus“ TeamsOnly ist das Ergebnis). Die Übersetzung zwischen Policy-Namen und sichtbarem Modus ist eine der Stellen, an denen man sich gern vertut – immer mit Get-CsOnlineUser gegenprüfen, was wirklich aktiv ist.

Shared SIP Address Space

Damit Hybrid überhaupt funktioniert, müssen On-Prem und Cloud dieselbe SIP-Domäne teilen – das ist der Shared SIP Address Space. Er sorgt dafür, dass max.muster@contoso.de on-prem und in der Cloud dieselbe Adresse ist und Anrufe korrekt geroutet werden, egal wo der User gerade gehostet ist.

Aktivierung: Über Set-CsTenantFederationConfiguration bzw. die Hybrid-Konfiguration; technisch das Fundament, auf dem die Modi überhaupt erst greifen.

Beim Disable-Hybrid: Der Shared SIP Address Space wird am Ende einer vollständigen Migration wieder deaktiviert – aber erst, wenn wirklich kein User mehr on-prem gehostet ist. Vorzeitig deaktiviert, brechen die noch verbliebenen On-Prem-User weg.

DNS-Implikationen

Die Coexistence-Modi und DNS hängen enger zusammen, als es aussieht. DNS entscheidet, wohin ein Client sich überhaupt erst verbindet – der Modus entscheidet dann, was dort passiert.

Autodiscovery: Solange On-Prem-User existieren, muss lyncdiscover.contoso.de auf den On-Prem-Edge zeigen. Wer das vorzeitig Richtung Microsoft 365 umbiegt (Premature DNS-Switch), schießt die On-Prem-User ab.

Reihenfolge: Erst alle relevanten User nach TeamsOnly, dann DNS umstellen – nie umgekehrt. Details zu den Records im Edge-/DNS-Spoke.

FALLE Premature DNS-Switch trifft Hybrid besonders hart In Hybrid ist der vorzeitige DNS-Umzug der Klassiker schlechthin. Solange auch nur ein User on-prem gehostet ist, muss Autodiscovery zum On-Prem-Edge zeigen. Wird DNS zu früh auf Microsoft 365 gebogen, finden genau diese User ihren Server nicht mehr – obwohl an den Modi alles richtig eingestellt ist. Ändere DNS immer als letzten Schritt, nicht als ersten.

DACH-typische Hybrid-Gotchas

Aus echten Projekten in der DACH-Region kommen immer wieder dieselben Stolpersteine. Wer sie kennt, spart sich tagelange Fehlersuche.

msRTCSIP-Attribute: Die msRTCSIP-*-Attribute im lokalen Active Directory bleiben auch nach der Cloud-Migration synchronisiert. Wer sie blind löscht, kann TeamsOnly-User offline schießen. Anfassen nur mit Plan.

Cloud Connector Edition ist tot: CCE wird nicht mehr unterstützt. Wer noch CCE betreibt, muss auf Direct Routing oder Operator Connect umsteigen – das ist oft ein eigenes Teilprojekt.

Kein SfB Online mehr: Skype for Business Online ist seit Juli 2021 abgeschaltet. Hybrid funktioniert nur noch von On-Prem (SfB 2015/2019/SE) gegen Teams – nicht gegen das ehemalige SfB Online.

Islands als Default vergessen: Neu hinzugefügte User landen ohne explizite Policy im Default-Modus. Wer das nicht steuert, hat plötzlich Islands-User, die er nie bewusst angelegt hat.

Modus pro Welle – die Empfehlung

Statt tenant-weit umzuschalten, fährst du die Migration in Wellen. Pro Welle ein definierter Modus, klar kommuniziert. Ein bewährtes Muster:

Phase	Modus	Ziel der Phase
Start	SfBWithTeamsCollab	Teams für Zusammenarbeit, Telefonie bleibt SfB
Meetings zuerst	SfBWithTeamsCollabAndMeetings	Neue Meetings in Teams, Rest bleibt SfB
Umzug	TeamsOnly (wellenweise)	Gruppe für Gruppe vollständig nach Teams
Vermeiden	Islands als Dauerzustand	verwirrt User, verpasste Anrufe

 

TIPP Kommunikation ist die halbe Migration Der technische Modus-Wechsel dauert Sekunden – die Anwender darauf vorzubereiten ist die eigentliche Arbeit. Jede Welle braucht eine klare Ansage: „Ab Montag klingeln deine Anrufe in Teams, nicht mehr in Skype for Business.“ Wer das auslässt, produziert genau die verpassten Anrufe und Support-Tickets, die den ganzen Migrationsruf ruinieren.

Praxis: die Wellen-Migration der Trendforge Digital GmbH

Die Trendforge Digital GmbH startete im Default-Islands-Modus – unfreiwillig, weil niemand die Policy gesetzt hatte. Folge: Die Vertriebsabteilung verpasste Kundenanrufe, weil die im SfB-Client klingelten, während alle längst in Teams arbeiteten. Erste Maßnahme: bewusst auf SfBWithTeamsCollabAndMeetings stellen, damit wenigstens Meetings sauber in Teams liefen und das Anruf-Routing eindeutig bei SfB blieb.

Danach wellenweise auf TeamsOnly: erst die IT als Pilot, dann Abteilung für Abteilung, jeweils mit einer klaren Mail („ab Donnerstag klingeln deine Anrufe in Teams“) und einem Tag erhöhter Support-Bereitschaft. Der einzige echte Zwischenfall war ein Admin, der msRTCSIP-Attribute aufräumen wollte und damit beinahe eine bereits migrierte Gruppe offline geschossen hätte – rechtzeitig gestoppt. Ergebnis: saubere Migration ohne den „wo ist mein Anruf?“-Dauerfrust, der Islands sonst mit sich bringt.

HINWEIS Der Consulting-Hebel Die Coexistence-Modi sind technisch in Minuten gesetzt – der Wert liegt in der Wellen- und Kommunikationsplanung und im Wissen um die DACH-Gotchas (msRTCSIP, CCE, Premature DNS-Switch). Genau das unterscheidet eine geordnete Migration von einem Support-Ticket-Gewitter. Wer den Islands-Default kennt und aktiv steuert, hat den größten Frustfaktor schon entschärft, bevor er entsteht.

Häufige Fragen

Was steuern die Coexistence-Modi eigentlich?

Sie entscheiden, in welchem Client (SfB oder Teams) Chat, Anruf und Meeting eines Users landen – nicht, welche App installiert ist. Es sind Routing-Regeln, gesteuert über die TeamsUpgradePolicy.

Welche fünf Modi gibt es?

SfBOnly, SfBWithTeamsCollab, SfBWithTeamsCollabAndMeetings, Islands und TeamsOnly. Sie bilden ein Spektrum von reiner SfB-Nutzung bis zur vollständigen Teams-Welt.

Warum ist Islands so problematisch?

Weil Chat, Anruf und Meeting parallel in beiden Clients ankommen. Ein Anruf klingelt im einen Client, der User hat aber den anderen offen – verpasste Anrufe und doppelte Chat-Verläufe. Als kurze Übergangsphase okay, als Dauerzustand ein Anwender-Albtraum. Und es ist der Default.

Wie setze ich den Modus per PowerShell?

Mit Grant-CsTeamsUpgradePolicy -Identity <user> -PolicyName <policy>. Für TeamsOnly heißt der Policy-Name UpgradeToTeams. Den aktiven Modus prüfst du mit Get-CsOnlineUser.

Was ist der Shared SIP Address Space?

Die geteilte SIP-Domäne zwischen On-Prem und Cloud, damit ein User unter derselben Adresse erreichbar ist, egal wo er gehostet wird. Er ist das Fundament, auf dem die Modi überhaupt greifen – und wird erst beim vollständigen Disable-Hybrid wieder deaktiviert.

Darf ich die msRTCSIP-Attribute im AD aufräumen?

Nur mit Plan. Sie bleiben auch nach der Cloud-Migration synchronisiert, und blindes Löschen kann TeamsOnly-User offline schießen. Im Zweifel stehen lassen und nur im Rahmen eines bewussten Disable-Hybrid-Schritts anfassen.

Kann ich tenant-weit auf TeamsOnly umstellen?

Technisch ja, praktisch fast nie sinnvoll. Eine wellenweise Migration (Gruppe für Gruppe, mit Kommunikation) vermeidet das Support-Ticket-Gewitter, das ein Big-Bang-Umzug auslöst. Tenant-weit nur, wenn die Umgebung wirklich klein und homogen ist.

Weiterführende Themen

Coexistence greift in mehrere Nachbarthemen. Weiter geht es hier:

→ Pillar: Skype for Business Server SE im Überblick

→ Dedicated Hybrid Application: Pflicht-Konfiguration für Skype for Business Hybrid mit Exchange Online

→ Von Skype for Business Server SE zu TeamsOnly: Wave-Planung, User-Move und Decommissioning

→ Edge Server, Reverse Proxy und DNS für Skype for Business Server SE

Fazit

Die Coexistence-Modi sind das mächtigste – und am meisten unterschätzte – Steuerungswerkzeug jeder Hybrid-Migration. Wer den Islands-Default kennt, bewusst pro Welle einen Modus setzt und die DACH-Gotchas (msRTCSIP, CCE, Premature DNS-Switch) im Blick hat, migriert geordnet statt chaotisch.

Die wichtigste Botschaft in einem Satz: Steuere die Modi aktiv, bleib nicht im Default-Islands hängen – und sag den Usern vorher, wo ihr Anruf künftig klingelt.

 

Über den Autor

Ulrich B. Boddenberg ist unabhängiger IT-Berater, Software-Engineer und Fachbuchautor mit rund 30 Jahren Erfahrung in Microsoft-Enterprise-Infrastrukturen (Active Directory, ADFS, Entra ID, Exchange, SharePoint, PKI, Teams-Telefonie). Webseite: boddenberg.de.