Teams-Telefonie nach der Einführung retten: ein Plan in fünf Schritten

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Eure Einführung ist live, aber niemand mag sie? Wir machen mit dir die Bestandsaufnahme und bauen den Plan, der wirklich trägt. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Rufwege lesen und Fehler finden wollen, und für Anwender, die Teams endlich als Telefon begreifen sollen. › Schulung Teams-Telefonie

 

Das Projekt ist abgeschlossen. Die alte Anlage ist verschrottet, die Abnahme unterschrieben, der Dienstleister hat sich mit einer freundlichen Mail verabschiedet. Und seit drei Monaten hörst du im Flur Sätze, die man sonst nur über Druckertreiber sagt: „Mit dem alten Telefon war alles besser.“ „Ich nehme fürs Kundengespräch lieber mein Handy.“ „Die Hotline legt einfach auf.“ Herzlichen Glückwunsch: Du hast eine Teams-Telefonie, die technisch läuft und von der Belegschaft gehasst wird.

Die gute Nachricht: Das ist fast nie ein Fall für „alles neu“. In den allermeisten Umgebungen, die ich nach einer holprigen Einführung übernehme, stecken hinter dem Frust eine Handvoll konkreter Konfigurationsfehler, zwei, drei Netzbaustellen und eine Kommunikation, die nach dem Go-live einfach aufgehört hat. Die schlechte Nachricht: Wer jetzt hektisch an Einzelfällen herumschraubt, macht es schlimmer. Was hilft, ist ein Plan.

Dieser Artikel liefert ihn in fünf Schritten: Bestandsaufnahme mit Messdaten statt Meinungen, Sofortmaßnahmen für Notruf, Totalausfälle und Warteschlangen, ein aufgeräumtes Routing, ein Netz, das Sprache aushält, und am Ende die Anwender, die du zurückgewinnen musst. Grundlagen zu Direct Routing, Wählplänen und SBC wiederhole ich hier nicht; die stehen gesammelt auf der Übersichtsseite zur Teams-Telefonie. Hier geht es um die Lage danach.

FAKTEN · Das Wichtigste in 30 Sekunden Frust nach der Einführung hat meist mehrere Ursachen gleichzeitig: Konfiguration (Wählplan, Voice Routing, Zuweisungen), Netz (WLAN, VPN, fehlende QoS) und Organisation (Warteschlangen, Erreichbarkeit, Kommunikation). Erst messen, dann reparieren: Das Anrufqualitätsdashboard (CQD), die Anrufanalyse im Teams Admin Center, das Direct-Routing-Dashboard und die Call Records über Microsoft Graph liefern dir Fakten. Call Records werden laut Microsoft 30 Tage aufbewahrt. Notruf, komplette Ausfälle und auflegende Warteschlangen gehen vor. Alles andere darf eine Woche warten. Routing räumst du nicht im laufenden Betrieb um, sondern mit Export, Soll-Modell, Testfällen und Rollback-Plan. Die Technik ist nach Wochen repariert, das Vertrauen der Anwender erst nach Monaten. Plane die Kommunikation deshalb als eigenen Arbeitsstrang.

 

Das Symptom: eingeführt, abgenommen und trotzdem gehasst

Eine verkorkste Einführung erkennst du nicht an einem Fehler, sondern an einem Muster. Die Ticketqueue ist voll mit Einzelmeldungen, die jede für sich harmlos klingen. Zusammen ergeben sie das Bild einer Telefonie, der niemand mehr traut. Und Misstrauen ist ansteckend: Wer einmal einen wichtigen Kunden verloren hat, weil der Anruf ins Leere ging, erzählt es in der Kantine weiter.

Wie es im Helpdesk ankommt

„Ich komme nicht nach draußen.“ Ein Standort oder eine Gruppe telefoniert nicht ins Amt, andere schon. Klassischer Rufweg-Fehler.

„Die Hotline legt einfach auf.“ Anrufer landen in einer Warteschlange und fliegen nach Überlauf oder Timeout raus, weil als Aktion „Trennen“ eingestellt ist oder keine Agenten angemeldet sind.

„Man versteht mich wie unter Wasser.“ Sprachqualität. Fast immer Netz, Endgerät oder Medienweg, selten Konfiguration.

„Beim Kunden steht die Zentrale statt meiner Durchwahl.“ Rufnummernanzeige, also Caller-ID-Richtlinie, Zuweisung oder SBC.

„Seit der Umstellung hat mein Telefon nie wieder geklingelt.“ Eingehende Anrufe, oft eine Umleitung, die der Benutzer selbst gesetzt und vergessen hat.

„Ich telefoniere lieber übers Handy.“ Kein technisches Symptom, sondern das gefährlichste: Die Leute haben aufgegeben.

Wie es der Admin erlebt

Auf der anderen Seite sitzt ein Team, das zwischen Tagesgeschäft und Dauerfeuer zerrieben wird. Jede Meldung wird einzeln bearbeitet, jeder Fix ist ein Eingriff am offenen Herzen, und jede Änderung erzeugt zwei neue Tickets. Typische Sätze aus dem Admin-Team: „Bei mir geht es.“ „Das ist das WLAN.“ „Das hat der Dienstleister so gebaut.“ Alle drei sind manchmal richtig. Keiner davon hilft, solange niemand weiß, wie oft welches Problem wirklich auftritt.

Die Skizze zeigt, warum das so zäh ist. Ein abgehender Anruf läuft durch die Kette Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC, und bei jeder Station kann eine schnell gebaute Einführung eine Altlast hinterlassen haben. Daneben läuft der Medienweg durch dein Netz, mit ganz eigenen Bremsen. Eine ausführliche Liste der häufigsten Ursachen findest du in Teams-Telefonie Probleme: die zehn häufigsten Ursachen. Hier geht es darum, sie in der richtigen Reihenfolge abzuarbeiten.

Symptom	Wahrscheinliche Ebene	Erster Blick
Anruf geht nicht raus	Wählplan, Voice Routing, SBC	Test-CsEffectiveTenantDialPlan, Routen, SBC-Status im Direct-Routing-Dashboard
Nur ein Standort betroffen	Policy oder Wählplan des Standorts	Zuweisungen der Benutzer, Wählplan-Kopie mit falscher Ortsvorwahl
Neue Benutzer betroffen, alte nicht	Zuweisung fehlt	Leere Policy-Felder bei Get-CsOnlineUser
Warteschlange legt auf	Call Queue, Agenten	Überlauf, Timeout, Agenten-Opt-in
Unter-Wasser-Stimme, Abbrüche	Netz, Endgerät, Medienweg	CQD nach Standort, WLAN, VPN, TCP-Anteil
Falsche Nummer beim Angerufenen	Caller ID, SBC	Caller-ID-Richtlinie, LineUri, SBC-Manipulation
Notruf ohne oder mit falscher Adresse	Notrufkonfiguration, Subnetze	Emergency-Richtlinien, LIS-Subnetze, Netzwerkstandorte

 

Schritt 1: Bestandsaufnahme mit Messdaten statt Meinungen

Der erste Reflex nach einer verkorksten Einführung ist ein Workshop, in dem jeder erzählt, was ihn am meisten nervt. Das ist gut für die Psychohygiene und schlecht für die Priorisierung. Die lauteste Abteilung ist selten die am stärksten betroffene. Und der Geschäftsführer, dessen Anruf letzte Woche abgebrochen ist, hat eine Stichprobe von genau eins. Deshalb beginnst du mit Daten.

Woher die Zahlen kommen

Datenbasis	Was sie dir sagt	Wo du sie findest
Anrufqualitätsdashboard (CQD)	Anteil schlechter Audiostreams nach Standort, Subnetz, WLAN oder LAN, VPN, TCP oder UDP	Eigenes Portal, Standort-Zuordnung über hochgeladene Gebäudedaten
Anrufanalyse im Teams Admin Center	Einzelanruf eines Benutzers mit Geräten, Netz und Medienweg	Benutzer › Benutzer verwalten › Benutzer › Verlauf von Anrufen und Besprechungen
Direct-Routing-Dashboard	SBC-Status, Erfolgsquote der Anrufe, Netzwerkeffektivität	Sprache › Direct Routing › Integritätsdashboard
Berichte zur PSTN-Nutzung	Abgehende und eingehende Anrufe mit Ergebnis, SIP-Code und SBC	Analysen und Berichte › Nutzungsberichte
Call Records (Microsoft Graph)	Rohdaten zu jedem Anruf, auch für eigene Auswertungen	Graph-API, Aufbewahrung laut Microsoft 30 Tage
Konfigurationsexport (PowerShell)	Ist-Zustand aller Telefonie-Objekte	MicrosoftTeams-Modul
Ticketsystem	Was die Leute ärgert, nach Standort und Symptom	Euer Helpdesk

 

Wie du aus den Call Records eine belastbare Statistik baust, statt dich auf Bauchgefühl zu verlassen, zeigt Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl. Für diesen Plan reicht zunächst eine einfache Frage je Quelle: Wo, wie oft, wie viele Betroffene?

Den Ist-Zustand einfrieren

Bevor du irgendetwas änderst, exportierst du die gesamte Telefonie-Konfiguration. Das ist deine Ausgangsbasis für die Analyse und gleichzeitig dein Rollback. Alle Befehle hier sind lesend; sie ändern nichts im Tenant.

Connect-MicrosoftTeams $ziel = "C:\Telefonie\Ist-$(Get-Date -Format yyyyMMdd)" New-Item -ItemType Directory -Path $ziel -Force | Out-Null Get-CsTenantDialPlan | Export-Clixml "$ziel\Wählpläne.xml" Get-CsOnlineVoiceRoutingPolicy | Export-Clixml "$ziel\VoiceRoutingPolicies.xml" Get-CsOnlinePstnUsages | Export-Clixml "$ziel\PstnUsages.xml" Get-CsOnlineVoiceRoute | Export-Clixml "$ziel\VoiceRoutes.xml" Get-CsOnlinePSTNGateway | Export-Clixml "$ziel\Gateways.xml" Get-CsTeamsEmergencyCallRoutingPolicy | Export-Clixml "$ziel\NotrufRouting.xml" Get-CsCallQueue -First 100 | Export-Clixml "$ziel\Warteschlangen.xml"

 

Danach die Benutzerseite. Die wichtigste Frage lautet: Wer hat überhaupt welche Richtlinie? Ein leeres Feld bei OnlineVoiceRoutingPolicy oder TenantDialPlan bedeutet, dass die globale Richtlinie greift. Das ist nach einer schnellen Einführung erschreckend oft der Fall, und warum das gefährlich ist, beschreibt Teams-Benutzer fällt auf die globale Richtlinie zurück.

Get-CsOnlineUser -Filter {EnterpriseVoiceEnabled -eq $true} | Select-Object UserPrincipalName, LineUri, UsageLocation, OnlineVoiceRoutingPolicy, TenantDialPlan, CallingLineIdentity | Export-Csv "$ziel\Benutzer.csv" -NoTypeInformation -Encoding UTF8

 

Aus Tickets ein Bild machen

Die Tickets der letzten Wochen sortierst du in drei Körbe: Rufweg (geht nicht, falsche Nummer, landet falsch), Qualität (klingt schlecht, bricht ab) und Organisation (niemand geht ran, Warteschlange, Umleitung). Dazu der Standort. Schon nach einer Stunde Fleißarbeit siehst du Muster: Köln hat fast nur Rufweg-Tickets, Berlin fast nur Qualität, die Zentrale in Frankfurt vor allem Warteschlangen. Das sind drei verschiedene Baustellen mit drei verschiedenen Werkzeugen.

TIPP · Messen schlägt Mehrheitsmeinung Lege zu jedem Ticketkorb eine Kennzahl fest, die du ohne Umfrage messen kannst: Anteil schlechter Audiostreams je Standort aus dem CQD, Anteil fehlgeschlagener PSTN-Anrufe je SBC aus dem Direct-Routing-Dashboard, abgebrochene Anrufe je Warteschlange aus den Warteschlangenberichten. Diese drei Zahlen sind später auch dein Beweis, dass der Plan wirkt.

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Für die Bestandsaufnahme fasst der Teams-Telefonie Diagnostiker die Lage in einer Ampel für die Bereiche Netz, SBC/Routing, Konfiguration und Organisation zusammen. Jeder Befund kommt mit einem Prüffall, sodass du nachvollziehen kannst, warum er gemeldet wird. Die Anrufqualität zeigt schlechte Audiostreams und TCP-Anteile je Standort. Der Bericht fasst den Stand als Word-Datei und als Ein-Seiten-Bericht für die Geschäftsführung zusammen. Nach der Sanierung vergleicht die Drift-Erkennung zwei Läufe miteinander und zeigt, welche Objekte sich geändert haben und welche Befunde behoben sind. Mehr zum Werkzeug: Teams-Telefonie Diagnostiker. 15 Tage kostenlos testen.

 

Schritt 2: Sofortmaßnahmen für Notruf, Totalausfälle und Warteschlangen

Manche Dinge warten nicht auf die fertige Analyse. Ein Notruf, der nicht funktioniert, ist kein Ticket mit mittlerer Priorität, sondern ein Haftungsthema mit Menschenleben dran. Ein Standort ohne Amtsleitung ist ein Geschäftsausfall. Und eine Hotline, die Kunden nach zwei Minuten wortlos rauswirft, kostet täglich Umsatz. Diese drei Themen ziehst du vor, auch wenn Schritt 1 noch läuft.

Notruf: 110 und 112 müssen immer gehen

Prüfe zuerst, ob Notrufe überhaupt einen Weg haben. Bei Direct Routing heißt das: Die gewählte 110 oder 112 muss nach der Normalisierung als 110 oder 112 übrig bleiben, und eine Voice Route mit passendem Muster muss in einer Usage stehen, die der Voice Routing Policy jedes Benutzers zugeordnet ist. Ein Wählplan, der aus der 112 eine +49…112 macht, oder eine Amtsholungsregel, die die Notrufnummer verschluckt, sind die Klassiker.

# Was passiert, wenn ein Kölner Benutzer 112 wählt? Get-CsEffectiveTenantDialPlan -Identity anna.berg@contoso.com | Test-CsEffectiveTenantDialPlan -DialedNumber 112   # Welche Routen fangen 110 und 112? Get-CsOnlineVoiceRoute | Where-Object { '112' -match $_.NumberPattern } | Format-Table Identity, NumberPattern, Priority, OnlinePstnUsages, OnlinePstnGatewayList   # Notrufrichtlinien und hinterlegte Notrufadressen Get-CsTeamsEmergencyCallRoutingPolicy | Format-List Identity, EmergencyNumbers Get-CsOnlineLisLocation | Format-Table CompanyName, City, StreetName, HouseNumber Get-CsOnlineLisSubnet | Format-Table Subnet, LocationId

 

Eine saubere Notrufroute sieht in der Regel so aus: eine eigene PSTN Usage, etwa DE-Notruf, als erste Usage in jeder Voice Routing Policy, darin eine Voice Route mit dem Muster ^(110|112)$ und den SBCs des Standorts. Der Wählplan enthält eine Regel, die 110 und 112 unverändert durchreicht, also Muster ^(110|112)$ und Übersetzung $1, ganz oben in der Liste. Ob eure Umgebung zusätzlich eine Notrufadresse über das Location Information Service (LIS) oder dynamischen Notruf braucht, hängt vom Aufbau ab; das Gesamtbild erklärt Notruf in Microsoft Teams konfigurieren, die Folgen einer fehlenden Adresse beschreibt Notrufadresse fehlt in Teams: was bei 112 wirklich passiert.

WARNUNG · Nicht einfach 112 wählen, um es auszuprobieren Ein echter Testanruf landet bei der Leitstelle, und die hat Besseres zu tun. Stimme Tests mit dem Carrier und, wo vorgesehen, mit der Leitstelle ab, und nutze vorher die lesenden Prüfungen oben. Wie das geordnet geht, steht in Notruf in Teams testen, ohne die Leitstelle zu verärgern.

 

Totalausfälle: ein Standort ohne Amt

Fällt ein ganzer Standort aus, ist die Ursache fast immer in einem von drei Objekten zu finden: die Voice Routing Policy der Benutzer, die Voice Route oder der SBC. Prüfe zuerst den SBC: Im Direct-Routing-Integritätsdashboard siehst du, ob Teams ihn als aktiv betrachtet. Danach prüfst du mit Test-CsEffectiveTenantDialPlan und der Routenliste, ob die normalisierte Nummer überhaupt eine Route findet. Den vollständigen Rufweg Schritt für Schritt beschreibt Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen.

Get-CsOnlinePSTNGateway | Format-Table Identity, Enabled, SipSignalingPort, MediaBypass, FailoverTimeSeconds   Get-CsEffectiveTenantDialPlan -Identity jan.vogt@contoso.com | Test-CsEffectiveTenantDialPlan -DialedNumber 0695550199

 

Steht nur ein SBC in der Route und ist kein zweiter Weg vorgesehen, hast du gerade gelernt, warum Redundanz kein Luxus ist. Wie Failover in Teams wirklich funktioniert und warum er so oft nicht greift, steht in SBC-Failover in Teams funktioniert nicht.

AUS DER PRAXIS · Ein eigener Fall: der SBC im Labor Ich betreibe für meine eigene Umgebung einen anynode-SBC. Eines Morgens ging dort kein Anruf mehr raus, und ich habe zuerst Wählplan und Routen zerlegt, wie es sich für einen Berater gehört. Ursache war das TLS-Zertifikat des SBC, dessen Erneuerung zwar geklappt hatte, aber nicht aktiv geschaltet war. Seitdem schaue ich bei „plötzlich geht gar nichts“ zuerst auf den SBC-Status und das Zertifikat und erst danach auf das Routing. Der Blick kostet eine Minute und erspart eine Stunde Regex-Meditation.

 

Warteschlangen, die auflegen

Die Hotline, die Kunden rauswirft, ist das sichtbarste Symptom einer verkorksten Einführung, weil es außerhalb des Unternehmens passiert. Laut Microsoft-Dokumentation erlaubt eine Anrufwarteschlange zwischen 0 und 200 wartende Anrufe (Standard 50) und eine maximale Wartezeit zwischen 0 Sekunden und 45 Minuten. Für Überlauf, Timeout und „keine Agenten“ legst du jeweils fest, ob der Anruf getrennt oder weitergeleitet wird. Steht dort „Trennen“, legt die Warteschlange auf, und zwar genau so, wie sie konfiguriert wurde.

Get-CsCallQueue -First 100 | Select-Object Name, OverflowThreshold, OverflowAction, TimeoutThreshold, TimeoutAction, @{n='Agenten';e={$_.Agents.Count}} | Format-Table -AutoSize

 

Befund	Sofortmaßnahme	Rollback
Überlauf oder Timeout mit Aktion „Trennen“	Weiterleitung auf Sammel-Voicemail oder zweite Warteschlange	Alte Werte aus dem Export zurücksetzen
Timeout sehr kurz, etwa unter einer Minute	Wartezeit erhöhen, Ansage mit Rückrufangebot prüfen	Wert aus dem Export
Keine Agenten angemeldet (Opt-in)	Agenten-Opt-in prüfen, Regel für „keine Agenten“ setzen	Regel wieder entfernen
Warteschlange ohne Ressourcenkonto mit Nummer	Ressourcenkonto und Nummer zuweisen	Zuweisung entfernen

 

Details zu Überlauf, Timeout und den Fallstricken bei Rückrufen findest du in Teams-Warteschlange legt auf: Überlauf und Timeout richtig einstellen; die offiziellen Grenzwerte stehen in Microsofts Anleitung Einrichten einer Anrufwarteschlange.

WICHTIG · Jede Sofortmaßnahme braucht einen Rückweg Auch unter Druck gilt: Vorher den Ist-Wert sichern, die Änderung im Ticket dokumentieren und genau einen Parameter pro Schritt ändern. Wer im Notfall fünf Dinge gleichzeitig dreht, weiß hinterher nicht, welches geholfen hat, und kann das schädliche nicht gezielt zurücknehmen.

 

Schritt 3: Routing aufräumen

Nach den Sofortmaßnahmen läuft das Nötigste. Jetzt kommt die eigentliche Sanierung. Schnelle Einführungen hinterlassen fast immer dasselbe Erbe: pro Standort eine Voice Routing Policy, jede leicht anders, Usages mit Namen wie „Test2“ oder „Neu-Final“, eine Catch-all-Route, die irgendwann jemand „zur Sicherheit“ mit Priorität 1 angelegt hat, und Wählpläne, die von Frankfurt nach Köln kopiert wurden, inklusive Frankfurter Ortsvorwahl.

Erst das Soll-Modell, dann die Befehle

Bevor du ein einziges Objekt anfasst, schreibst du auf, wie es aussehen soll. Ein bewährtes Muster für mehrere Standorte in Deutschland: ein Wählplan je Ortsnetz, eine kleine Zahl von Voice Routing Policies je Berechtigungsstufe und Standort, Usages nach Zweck und Standort benannt, Routen mit eindeutigen Mustern ohne Überschneidung. Wie die Reihenfolge zwischen Policy, Usage und Route zusammenspielt, erklärt Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen.

Objekt	Namensmuster	Beispiel Contoso
Wählplan	DP-<Standort>	DP-Frankfurt, DP-Köln, DP-Berlin
Voice Routing Policy	VRP-<Standort>-<Berechtigung>	VRP-Hamburg-National, VRP-München-International
PSTN Usage	DE-<Standort>-<Zweck>	DE-Hamburg-Notruf, DE-Hamburg-National
Voice Route	VR-<Standort>-<Zweck>	VR-Hamburg-Notruf, VR-Hamburg-National
SBC	sbc<n>.contoso.com	sbc1.contoso.com, sbc2.contoso.com

 

Die Catch-all-Route und andere Überdeckungen

Eine Route mit dem Muster ^.*$ oder .* fängt jede Nummer, auch die, für die eigentlich eine andere Route gedacht war. Steht sie in einer Usage, die in der Policy weiter oben steht, oder hat sie innerhalb derselben Usage die bessere Priorität, gewinnt sie. Die Folge sind Anrufe über den falschen SBC, fehlende Berechtigungsgrenzen oder Hairpinning über einen anderen Standort.

Zweck	Muster (.NET-Regex)	Bemerkung
Notruf	^(110|112)$	Eigene Usage, in jeder Policy ganz oben
Deutschland	^\+49\d+$	Alles mit +49, nach der Normalisierung
International	^\+\d+$	Nur in Policies mit Auslandsberechtigung, Usage nach der Deutschland-Usage
Zu vermeiden	^.*$	Fängt alles, auch Notruf und interne Nummern

 

Die Kombination aus Deutschland- und Auslandsroute funktioniert, weil Teams die Usages einer Policy in ihrer Reihenfolge prüft: Eine +49-Nummer trifft schon in der Deutschland-Usage, nur alles andere fällt durch in die Auslands-Usage. Wie du überdeckte Routen findest, beschreibt Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen; welche Normalisierungsfehler typischerweise davorliegen, steht in Normalisierungsregeln in Teams: typische Fehler und wie du sie findest. Wer mit Amtsholung 0 arbeitet, findet die passenden Regeln in Wählplan mit Amtsholung 0 in Teams richtig bauen.

# Routen nach Priorität, um Überdeckungen zu sehen Get-CsOnlineVoiceRoute | Sort-Object Priority | Format-Table Identity, NumberPattern, Priority, OnlinePstnUsages, OnlinePstnGatewayList   # Reihenfolge der Usages je Policy Get-CsOnlineVoiceRoutingPolicy | Format-List Identity, OnlinePstnUsages

 

Umbauen mit Testfällen und Rollback

Testfälle schreiben. Je Standort eine Liste typischer Wählvarianten: intern, Ortsnetz, national, Mobilfunk, Ausland, 110, 112, Servicenummern. Dazu das erwartete E.164-Ergebnis und der erwartete SBC.

Neue Objekte parallel anlegen. Neue Policies und Usages entstehen neben den alten, ohne Benutzer.

Pilotgruppe umstellen. Fünf bis zehn Benutzer je Standort bekommen die neue Policy und den neuen Wählplan. Testfälle durchspielen, CQD und Dashboard beobachten.

Standortweise ausrollen. Mit Grant-CsOnlineVoiceRoutingPolicy und Grant-CsTenantDialPlan, standortweise, mit Tagesabstand.

Altlasten entfernen. Erst wenn keine Zuweisung mehr auf ein altes Objekt zeigt, wird es gelöscht.

TIPP · Rollback heißt zurückweisen, nicht zurückbauen Solange die alten Policies und Wählpläne noch existieren, ist der Rollback eine einzige Zuweisung pro Benutzer zurück auf das alte Objekt. Deshalb löschst du Altlasten erst ganz am Ende. Wer früh aufräumt, hat im Fehlerfall nur noch den Export, und der ist eine Vorlage, kein Knopf.

 

AUS DER PRAXIS · Ein Großhändler mit siebzehn Standorten Ein Großhändler mit siebzehn Standorten hatte seine Teams-Telefonie in sechs Wochen eingeführt, weil der Wartungsvertrag der alten Anlage auslief. Drei Monate später war die Stimmung im Keller. Die Bestandsaufnahme ergab: gut ein Zehntel der Benutzer ohne eigene Voice Routing Policy, sodass die globale griff; zwei Standorte mit kopiertem Frankfurter Wählplan; eine Catch-all-Route mit Priorität 1, die sämtliche Anrufe über die Zentrale schickte; eine Hotline-Warteschlange, die bei Timeout trennte. Dazu kamen ein Lager mit 2,4-GHz-WLAN und ein VPN ohne Split Tunneling für die Außendienstler. Keiner dieser Fehler war für sich dramatisch. Zusammen sorgten sie dafür, dass die Belegschaft lieber zum Handy griff. Nach zehn Wochen mit genau diesem Plan waren die Tickets auf einen Bruchteil zurückgegangen. Die letzte Rückmeldung aus dem Lager lautete sinngemäß: „Es ist halt ein Telefon.“ Mehr Lob gibt es in der Telefonie nicht.

 

Schritt 4: Netz nachziehen

Wenn die Anrufe ankommen, aber klingen wie aus einem U-Boot, ist das Routing unschuldig. Dann redest du über das Netz. Das ist unangenehm, weil es oft ein anderes Team betrifft, ein anderes Budget und eine andere Verantwortung. Es lässt sich aber nicht wegkonfigurieren.

Woran du schlechte Qualität messbar festmachst

Das Anrufqualitätsdashboard klassifiziert einen Audiostream laut Microsoft als schlecht, wenn er mehr als 500 Pakete umfasst und mindestens eine dieser Bedingungen erfüllt: Roundtrip über 500 Millisekunden, Paketverlustrate über 0,1, also zehn Prozent, oder Jitter über 30 Millisekunden. Microsoft betont selbst, dass ein so klassifizierter Stream nicht zwingend schlecht geklungen hat; der Medienstack gleicht viel aus. Als Vergleichsgröße zwischen Standorten taugt die Zahl trotzdem. Die Definition steht in Datenstromklassifizierung im Anrufqualitätsdashboard.

Damit das CQD dir Standorte statt nackter IP-Adressen zeigt, braucht es die Zuordnung der Subnetze zu Gebäuden. Ohne diese Daten bleibt der Bericht eine Liste von Netzen, mit denen niemand etwas anfangen kann. Werkzeuge und Vorgehen beschreibt Sprachqualität in Teams (QoS, CQD, Troubleshooting).

Die üblichen Verdächtigen

Baustelle	Typisches Zeichen	Maßnahme
VPN ohne Split Tunneling	Schlechte Werte vor allem im Homeoffice	Teams-Medienverkehr am VPN vorbeiführen, siehe Split-Tunnel-Artikel
TCP statt UDP	Hoher TCP-Anteil im CQD, Verzögerungen	UDP 3478 bis 3481 zu Microsoft freigeben, Proxy für Medien umgehen
WLAN	Schlechte Werte nur bei WLAN-Streams	5 GHz, Kanalplanung, WMM bzw. QoS im WLAN
Fehlende QoS im LAN und WAN	Probleme zu Lastzeiten	DSCP-Markierung für Audio, Video, Bildschirmfreigabe durchgängig umsetzen
Zentraler Internet-Breakout	Ein Standort weit vom nächsten Microsoft-Zugang	Lokaler Breakout für Microsoft-365-Verkehr
Media Bypass ohne Netzplanung	Einseitiges Audio, Abbrüche bei Direct Routing	Erreichbarkeit Client zu SBC prüfen, ggf. Local Media Optimization

 

Zu jeder dieser Baustellen gibt es einen eigenen Artikel: Teams-Telefonie über VPN: Split Tunneling richtig einrichten, Teams-Telefonie über TCP statt UDP: warum das schlecht klingt, Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip sowie Teams Media Bypass und Local Media Optimization. Für die Standortzuordnung von Netzen und Subnetzen, die auch für den dynamischen Notruf zählt, lies Netzwerkstandorte und Subnetze in Teams richtig pflegen.

# Netzwerkstandorte, Subnetze und vertrauenswürdige IP-Adressen in Teams Get-CsTenantNetworkSite | Format-Table Identity, NetworkRegionID, Description Get-CsTenantNetworkSubnet | Format-Table SubnetID, MaskBits, NetworkSiteID Get-CsTenantTrustedIPAddress | Format-Table IPAddress, MaskBits

 

FAKTEN · QoS für den Teams-Client in Zahlen Microsoft empfiehlt für den Teams-Client getrennte Quellportbereiche je Medienart, standardmäßig 50000 bis 50019 für Audio, 50020 bis 50039 für Video und 50040 bis 50059 für Bildschirmfreigabe. Die empfohlenen DSCP-Werte sind 46 (EF) für Audio, 34 (AF41) für Video und 18 (AF21) für Bildschirmfreigabe. QoS wirkt nur, wenn alle Netzgeräte auf dem Weg die Markierung respektieren.

 

WARNUNG · Nicht alles auf einmal Netzmaßnahmen änderst du standortweise und misst danach eine Woche im CQD. Wer an einem Tag Firewall, WLAN und QoS anfasst, bekommt entweder ein Wunder oder ein Rätsel, und meistens ist es ein Rätsel.

 

Schritt 5: Anwender zurückgewinnen

Jetzt kommt der Teil, den Technikteams gern überspringen. Die Messwerte sind grün, die Tickets gehen zurück, und trotzdem greift der Vertrieb weiter zum Handy. Der Grund ist einfach: Die Leute haben gelernt, dass Teams-Telefonie unzuverlässig ist, und dieses Wissen verschwindet nicht durch eine bereinigte Voice Route. Es verschwindet durch Erfahrung, und die musst du aktiv organisieren.

Ehrlich kommunizieren

Der wirksamste Satz in dieser Phase lautet: „Ihr hattet recht.“ Eine kurze, ehrliche Mitteilung der IT oder der Geschäftsführung, dass die Einführung Schwächen hatte, was jetzt konkret behoben wird und woran man es merkt, entschärft mehr als jede Hochglanz-Schulung. Danach informierst du regelmäßig, kurz und mit Zahlen: „Der Standort Berlin hat seit Montag ein neues WLAN, der Anteil schlechter Gespräche ist dort von zweistellig auf einstellig gefallen.“

Zielgruppe	Was sie hören will	Kanal
Geschäftsführung	Risiko, Kosten, Termin, Fortschritt in einer Zahl	Ein-Seiten-Bericht, monatlich
Führungskräfte	Was ändert sich für mein Team, wann, wen frage ich	Kurzes Briefing, Teams-Kanal
Anwender	Was ist behoben, was muss ich tun, wo melde ich Probleme	Kurze Mitteilungen, Sprechstunde
Hotline-Agenten	Wie funktioniert die Warteschlange jetzt, was passiert bei Überlauf	Schulung direkt am Arbeitsplatz
Helpdesk	Wie erkenne ich Rufweg, Qualität und Organisation, was prüfe ich zuerst	Checkliste, Admin-Schulung

 

Schulen, wo es weh tut

Viele Einführungen hatten eine Schulung, die aus einem Video und einem PDF bestand. Die eigentlichen Fragen kamen danach: Wie übergebe ich ein Gespräch, wie richte ich eine Stellvertretung ein, warum klingelt mein Handy nicht mit, wie melde ich mich in der Warteschlange an? Kurze, praxisnahe Termine mit echten Arbeitsabläufen helfen mehr als ein Rundumschlag. Für Admins und Helpdesk lohnt sich eine eigene Schulung zu Rufweg und Diagnose, damit das nächste Problem nicht wieder eine Woche im Kreis läuft. Passende Formate findest du bei der Schulung Teams-Telefonie.

Champions je Standort: Eine Person pro Standort, die Fragen sammelt und direkten Draht zur IT hat.

Endgeräte ernst nehmen: Ein zertifiziertes Headset oder Tischtelefon für Vieltelefonierer ist billiger als der Ärger über das Laptopmikrofon.

Feedback messbar machen: Die Bewertung nach dem Anruf und die Tickets je Standort zeigen dir, ob die Stimmung kippt.

Erfolge sichtbar machen: Wenn ein Standort grün ist, sag es. Gute Nachrichten verbreiten sich langsamer als schlechte, also hilf nach.

Vorbeugung: damit du diesen Artikel nicht noch einmal brauchst

Eine gerettete Telefonie verfällt erstaunlich schnell wieder, wenn niemand aufpasst. Neue Standorte werden per Kopie angelegt, neue Benutzer ohne Zuweisung eingerichtet, und irgendwer testet „nur kurz“ eine Route mit Priorität 1. Drei Dinge halten den Zustand stabil:

Ein dokumentiertes Soll: Export nach der Sanierung, abgelegt und freigegeben. Jede gewollte Änderung schreibt das Soll fort, alles andere ist Drift.

Klare Zuständigkeiten: Wer darf Routing ändern, wer prüft, wer gibt frei. Das Rahmenwerk legt fest, wer was wann darf.

Ein fester Prüfrhythmus: Monatlich CQD nach Standort, Dashboard nach SBC, Zuweisungen nach leeren Feldern, Warteschlangen nach Trennen-Aktionen.

Vertiefung zu diesen Punkten: Konfigurationsdrift in der Teams-Telefonie erkennen und Microsoft Teams Telefonie-Governance. Wer neue Standorte oder eine zweite Welle plant, sollte diesmal mit einem Konzept starten, etwa dem Festpreispaket Grobkonzept Teams-Telefonie.

FAQ zur Rettung einer Teams-Telefonie

Müssen wir die Teams-Telefonie komplett neu aufsetzen?

Fast nie. Die typischen Fehler sitzen in wenigen Objekten: Zuweisungen, Wählplänen, Usages, Routen, Warteschlangen und im Netz. Ein Neuaufbau verschiebt das Problem nur, wenn die Ursachen nicht verstanden sind. Ein geordneter Umbau mit Pilotgruppe ist schneller und risikoärmer.

Womit fange ich an, wenn alles gleichzeitig brennt?

Mit Notruf, Standorten ohne Amt und auflegenden Warteschlangen. Parallel exportierst du die Konfiguration, damit jede Sofortmaßnahme einen Rückweg hat. Erst danach beginnt die eigentliche Bestandsaufnahme.

Woran erkenne ich, ob ein Problem im Routing oder im Netz liegt?

Kommt der Anruf gar nicht zustande, landet falsch oder zeigt die falsche Nummer, ist es meist der Rufweg. Kommt er zustande und klingt schlecht oder bricht ab, ist es meist Netz, Endgerät oder Medienweg. Das CQD trennt das sauber, wenn du nach Standort, WLAN und TCP-Anteil filterst.

Wie lange dauert so eine Rettung?

Die Technik ist in einer mittelgroßen Umgebung oft in wenigen Wochen saniert, das Netz je nach Standortzahl länger. Die Akzeptanz braucht erfahrungsgemäß Monate. Plane deshalb Kommunikation und Schulung von Anfang an mit ein.

Wie lange reichen die Daten aus Teams zurück?

Call Records über Microsoft Graph werden laut Microsoft 30 Tage aufbewahrt. Wenn du Trends über Monate brauchst, exportiere die Daten regelmäßig. Für den Vorher-nachher-Vergleich lohnt es sich, die Kennzahlen gleich zu Beginn festzuhalten.

Brauchen wir externe Hilfe?

Nicht zwingend. Der Plan funktioniert auch mit eigenem Team, wenn dafür Zeit eingeplant ist und nicht nebenher Tickets abgearbeitet werden. Hilfreich ist ein frischer Blick vor allem bei der Bestandsaufnahme und beim Soll-Modell. Unterstützung findest du bei der Beratung zur Teams-Telefonie.

Fazit: Erst Fakten, dann Fixes, dann Vertrauen

Eine Teams-Telefonie, die nach der Einführung gehasst wird, ist selten kaputt. Sie ist meist unfertig: ein paar Objekte zu schnell gebaut, ein Netz, das für Sprache nie geplant war, und eine Belegschaft, die nach dem Go-live allein gelassen wurde. Das lässt sich reparieren, aber nur in der richtigen Reihenfolge.

Messen statt meinen, Notruf und Totalausfälle zuerst, Routing mit Soll-Modell und Pilotgruppe umbauen, das Netz Standort für Standort nachziehen und dann ehrlich mit den Leuten reden. Wer das durchhält, hört nach ein paar Monaten den schönsten Satz, den eine Telefonie bekommen kann: gar keinen. Denn über ein Telefon, das einfach funktioniert, redet niemand mehr.

WEITERLESEN · Weiterlesen › Teams-Telefonie Probleme: die zehn häufigsten Ursachen › Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen › Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen › Teams-Warteschlange legt auf: Überlauf und Timeout richtig einstellen › Sprachqualität in Teams (QoS, CQD, Troubleshooting) › Microsoft Teams Telefonie-Governance