Konfigurationsdrift in der Teams-Telefonie erkennen: wenn keiner etwas geändert hat

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Dein Tenant hat ein Eigenleben entwickelt? Wir halten mit dir den Soll-Zustand fest und bauen einen Vergleich, der wirklich läuft. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Routing-Objekte lesen, exportieren und Änderungen sauber nachvollziehen wollen. › Schulung Teams-Telefonie

 

Montag, 7:58 Uhr. Das Telefon im Helpdesk klingelt, und zwar über das Handy, weil das Festnetz in Frankfurt gerade keine Lust hat. „Ich komme bei keinem Kunden mehr durch. Das ging am Freitag noch.“ Du fragst im Team-Chat, wer am Wochenende etwas geändert hat. Die Antworten kommen schnell und sind einstimmig: niemand. Das ist die schönste Eigenschaft von Telefonie-Konfigurationen. Sie ändern sich, obwohl keiner sie anfasst.

Was du gerade erlebst, heißt Konfigurationsdrift. Der Tenant entfernt sich Stück für Stück von dem Zustand, den ihr einmal abgenommen habt. Mal ist es eine Route, deren Priorität jemand „nur zum Testen“ getauscht hat. Mal eine PSTN Usage, die in der Voice Routing Policy plötzlich an anderer Stelle steht. Mal eine Policy-Zuweisung, die bei einer Benutzermigration verloren gegangen ist. Jede einzelne Änderung war vermutlich gut gemeint. In Summe ist sie ein Ausfall mit sechs Tagen Zündschnur.

Dieser Artikel ist für dich, wenn du mit einem dieser Sätze hier gelandet bist: „Gestern ging es noch“, „Wer hat an der Route rumgespielt?“ oder „Wie sah das vorher aus?“. Du erfährst, warum Teams dir keine bequeme Änderungshistorie für Telefonie-Einstellungen anbietet, was das Audit-Log leistet und wo es aufhört, und wie du mit einem dokumentierten Soll-Zustand und einem regelmäßigen Vergleich Drift findest, bevor der Vertrieb sie findet. Grundlagen zu Routing und Wählplänen erklärt die Übersichtsseite zur Teams-Telefonie; hier geht es um den Fehler und seine Spur.

FAKTEN · Das Wichtigste in 30 Sekunden Das Teams Admin Center zeigt den aktuellen Zustand von Wählplänen, Voice Routing Policies, Usages, Voice Routes und SBCs. Eine Versionshistorie, in der du den Stand von letzter Woche aufrufst, gibt es dort nicht. Das Audit-Log in Microsoft Purview protokolliert Änderungen durch Teams-Admins als Vorgang „Teams Admin Action“ (TeamsAdminAction), egal ob über Admin Center, PowerShell oder API. In Audit (Standard) bleiben Einträge 180 Tage abrufbar. Das Audit-Log sagt dir, wer wann etwas getan hat. Ob der Zustand danach richtig ist, sagt es dir nicht. Dafür brauchst du einen dokumentierten Soll-Zustand und einen regelmäßigen Vergleich. Ein Export aller Telefonie-Objekte per PowerShell dauert Minuten und ist dein wichtigstes Werkzeug für Diagnose und Rollback.

 

Das Symptom: „Gestern ging es noch“

Drift hat kein eigenes Fehlerbild. Sie verkleidet sich als jedes andere Problem der Teams-Telefonie. Das macht sie so zäh: Du suchst nach einem SBC-Fehler, einem Regex-Problem oder einer Lizenzlücke und findest am Ende eine Änderung, die jemand vor Tagen gemacht hat. Typisch ist nicht das Symptom selbst, sondern seine Begleitumstände.

Wie es im Helpdesk ankommt

„Seit Montag komme ich nicht mehr nach draußen.“ Betroffen ist ein Standort oder eine Gruppe, nicht alle. Andere Standorte telefonieren munter weiter.

„Handynummern gehen, Festnetz nicht.“ Ein Teil der Rufnummernbereiche fällt aus. Klassischer Hinweis auf ein geändertes Muster in einer Voice Route oder eine fehlende Usage.

„Bei mir zeigt der Angerufene plötzlich die Zentrale an.“ Eine Caller-ID-Richtlinie oder eine Zuweisung hat sich geändert.

„Die Neuen können nicht telefonieren, die Alten schon.“ Die Vorlage oder das Skript für neue Benutzer weist eine andere Policy zu als früher, oder gar keine.

„Ausland geht wieder, seit gestern.“ Jemand hat eine Berechtigung erweitert, die bewusst eingeschränkt war. Auch das ist Drift, nur eine, die keiner meldet.

Wie es der Admin erlebt

Auf Admin-Seite hat Drift drei Kennzeichen. Erstens: Die Konfiguration sieht auf den ersten Blick plausibel aus. Es gibt keine roten Warnungen, der SBC ist aktiv, die Policy ist zugewiesen. Zweitens: Niemand erinnert sich an eine Änderung, oder alle erinnern sich an eine andere. Drittens: Die Dokumentation stimmt nicht mehr mit dem Tenant überein, aber keiner weiß, ob die Dokumentation oder der Tenant falsch ist.

AUS DER PRAXIS · Ein Maschinenbauer mit zwölf Standorten Ein Maschinenbauer mit zwölf Standorten hatte nach der Einführung eine saubere Routing-Struktur: je Standort eine Voice Routing Policy, je Policy drei Usages, Notruf zuerst. Achtzehn Monate, zwei Dienstleisterwechsel und eine Werksübernahme später gab es 31 Voice Routing Policies, von denen elf niemandem mehr zugewiesen waren, vier mit dem Namenszusatz „-neu“ und eine mit „-neu-final“. Ausfälle gab es keine großen, nur viele kleine. Das Audit-Log reichte ein halbes Jahr zurück. Die eigentliche Ursache lag länger zurück.

 

Wie Drift technisch entsteht und warum Teams sie nicht meldet

Ein ausgehender Anruf über Direct Routing läuft durch eine Kette von Objekten: Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC. Jedes Glied ist ein eigenes Konfigurationsobjekt mit eigenem Cmdlet und eigener Seite im Teams Admin Center. Keines dieser Objekte weiß, wer auf es verweist. Wenn du eine Usage aus einer Policy nimmst, prüft Teams nicht, ob danach noch eine Route für deutsche Festnetznummern erreichbar ist. Die Änderung ist syntaktisch korrekt, also wird sie angenommen. Wie die Kette im Detail funktioniert, beschreibt Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen.

Die üblichen Verdächtigen

Die folgende Tabelle zeigt, welche Änderungen in der Praxis am häufigsten unbemerkt bleiben und woran du sie erkennst.

Objekt	Typische Drift	Folge	Erkennbar an
Voice Routing Policy	Usage-Reihenfolge geändert, Usage entfernt oder eingeschoben	Anrufe gehen über den falschen SBC oder finden keine Route	Feld OnlinePstnUsages
PSTN Usage	Neue Usage in der globalen Liste, alte umbenannt	Routen hängen an einer Usage, die keine Policy mehr nutzt	Get-CsOnlinePstnUsages
Voice Route	Muster verengt, Priorität getauscht, Gateway ersetzt	Nummernbereiche fallen aus oder laufen über einen anderen SBC	NumberPattern, Priority, OnlinePstnGatewayList
Wählplan	Regel ergänzt, Reihenfolge geändert	Gewählte Nummern werden anders normalisiert	NormalizationRules
SBC	Deaktiviert, Ports oder Parameter geändert	Routen zeigen auf ein Gateway, das keine Anrufe annimmt	Enabled, SipSignalingPort
Benutzer	Policy-Zuweisung entfernt oder durch Gruppenzuweisung überschrieben	Benutzer landet auf der globalen Richtlinie	OnlineVoiceRoutingPolicy, TenantDialPlan

 

Besonders tückisch ist die letzte Zeile. Eine fehlende direkte Zuweisung fällt im Admin Center nicht auf, weil dort einfach „Global (Standard für die Organisation)“ steht. Wie du das sicher erkennst, steht in Teams-Benutzer fällt auf die globale Richtlinie zurück.

Warum es keine bequeme Änderungshistorie gibt

Das Teams Admin Center ist ein Verwaltungswerkzeug, kein Versionsarchiv. Es zeigt dir für jedes Telefonie-Objekt den aktuellen Zustand. Einen Knopf „Stand vom 3. März anzeigen“ oder einen Vorher-nachher-Vergleich einer Voice Route findest du dort nicht. Auch die PowerShell-Cmdlets des MicrosoftTeams-Moduls liefern ausschließlich den Ist-Zustand. Get-CsOnlineVoiceRoute kennt keinen Parameter für einen Zeitpunkt in der Vergangenheit.

Das ist kein Versehen, sondern ein Rollenverständnis: Die Historie gehört ins Audit-Log, die fachliche Bewertung in deine Dokumentation. Wer beides nicht hat, hat eben nur den Ist-Zustand und eine Teamrunde voller Menschen, die nichts geändert haben.

Was das Audit-Log leistet und was nicht

Microsoft Purview protokolliert Änderungen von Teams-Admins im einheitlichen Audit-Log. Laut Microsoft-Dokumentation wird der Vorgang „Teams Admin Action“ (Operation TeamsAdminAction) erfasst, wenn ein Teams-Admin Einstellungen oder Konfigurationen hinzufügt, ändert oder löscht, und zwar über Admin Center, PowerShell oder API. Damit hast du grundsätzlich eine Spur, wer wann an der Telefonie gearbeitet hat. Wie lange sie zurückreicht, hängt von der Lizenz ab: In Audit (Standard) bewahrt Microsoft die Einträge 180 Tage auf, mit Audit (Premium) und Aufbewahrungsrichtlinien länger. Details beschreibt Microsoft unter Überwachungslösungen in Microsoft Purview.

Frage	Audit-Log	Soll-Ist-Vergleich
Wer hat geändert?	Ja, ausführendes Konto	Nein
Wann wurde geändert?	Ja, Zeitstempel des Vorgangs	Nur eingegrenzt auf das Intervall zwischen zwei Exporten
Was genau steht jetzt anders da?	Teilweise, je nach Detailtiefe des Eintrags	Ja, Feld für Feld
Ist der neue Zustand fachlich richtig?	Nein	Ja, wenn das Soll gepflegt ist
Änderung älter als die Aufbewahrungsfrist?	Nein	Ja, solange der Soll-Export existiert
Wohin genau zurückdrehen?	Nur mit Mühe	Ja, der Soll-Export ist die Vorlage

 

WARNUNG · Verlass dich nicht auf Details im Audit-Eintrag Wie viel Vorher- und Nachher-Information ein Audit-Eintrag für ein Telefonie-Objekt enthält, ist in der Microsoft-Dokumentation nicht für jedes Objekt beschrieben. Prüf das in deinem Tenant mit einer harmlosen Teständerung, bevor du im Ernstfall darauf baust. Und denk daran: Ein Eintrag, der nach 180 Tagen weg ist, war im Zweifel genau der, den du gebraucht hättest.

 

Wie aus einer kleinen Änderung ein großer Ausfall wird

Drift ist selten ein einzelner Fehler. Meist ist es eine Änderung, die zum Zeitpunkt der Änderung funktioniert hat, und ein späteres Ereignis, das die Wirkung auslöst. Der Test-SBC läuft ja noch, also klappen die Anrufe. Bis jemand ihn am Freitagabend abschaltet, weil das Testprojekt vorbei ist.

Der Kern dieses Ablaufs: Zwischen Ursache und Wirkung liegen Tage. Wer am Montag im Audit-Log nach Änderungen vom Wochenende sucht, findet nur das Abschalten des Testsystems, und das war außerhalb von Teams. Die eigentliche Änderung vom Dienstag sieht unverdächtig aus, solange niemand weiß, dass „DE-National“ an dieser Stelle stehen müsste.

Diagnose: Drift Schritt für Schritt finden

Alle folgenden Befehle lesen nur. Sie ändern nichts im Tenant und sind deshalb auch mitten im Ausfall unbedenklich. Du brauchst das MicrosoftTeams-Modul und ein Konto mit Leserechten, für das Audit-Log zusätzlich Exchange Online PowerShell und die passende Purview-Rolle.

Schritt 1: Den betroffenen Rufweg eingrenzen

Bevor du nach Drift suchst, klär, welcher Benutzer welche Nummer nicht erreicht. Dann prüfst du die Kette für genau diesen Fall. Für Benutzer und Wählplan:

Connect-MicrosoftTeams   # Zuweisungen des betroffenen Benutzers (leer bedeutet: globale Richtlinie) Get-CsOnlineUser -Identity anna.berg@contoso.com | Select-Object DisplayName, LineUri, EnterpriseVoiceEnabled, OnlineVoiceRoutingPolicy, TenantDialPlan   # Wie wird die gewählte Nummer für diesen Benutzer normalisiert? Get-CsEffectiveTenantDialPlan -Identity anna.berg@contoso.com | Test-CsEffectiveTenantDialPlan -DialedNumber "00695550100" | Select-Object TranslatedNumber, MatchingRule

 

TIPP · Gewählte Nummer realistisch eingeben Teste genau das, was die Kollegin wählt. Bei Amtsholung 0 wählt sie für die Frankfurter Nummer +49 69 555 0100 die Ziffernfolge 00695550100; das Ergebnis der Normalisierung sollte +49695550100 lauten. Leerzeichen gehören nicht in den Test. Mehr zu typischen Regelfehlern steht in Normalisierungsregeln in Teams: typische Fehler und wie du sie findest.

 

Schritt 2: Policy, Usages und Routen im Ist-Zustand lesen

# Usages der Policy in ihrer tatsächlichen Reihenfolge (Get-CsOnlineVoiceRoutingPolicy -Identity "VRP-Frankfurt").OnlinePstnUsages   # Alle Routen mit Muster, Priorität, Usage und Gateway Get-CsOnlineVoiceRoute | Select-Object Identity, Priority, NumberPattern, @{n='Usages';e={$_.OnlinePstnUsages -join ';'}}, @{n='Gateways';e={$_.OnlinePstnGatewayList -join ';'}} | Sort-Object Usages, Priority | Format-Table -AutoSize   # Zustand der SBCs Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, SipSignalingPort

 

Damit siehst du den Ist-Zustand. Im Beispiel aus der Zeitlinie liefert die erste Zeile „DE-Notruf, Test-SBC2, DE-International“. Für deutsche Nummern wie +49695550100 greift damit die Route VR-Test mit dem Muster ^\+49\d+$, und die zeigt auf sbc-test.contoso.com, das seit Freitag abgeschaltet ist. Der Notruf geht weiter, weil die Usage DE-Notruf mit dem Muster ^(110|112)$ an erster Stelle steht und über sbc1.contoso.com läuft. Aber woher weißt du, dass an Position 2 eigentlich DE-National stehen müsste? Genau dafür brauchst du das Soll.

Im Teams Admin Center findest du dieselben Informationen unter Sprache › Direct Routing (Reiter SBCs und Sprachrouten) und unter Sprache › Sprachroutingrichtlinien. Dort siehst du allerdings nur den aktuellen Stand, keinen Vergleich. Den gesamten Rufweg prüfst du Glied für Glied wie in Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen beschrieben.

Schritt 3: Mit dem Soll vergleichen

Liegt ein früherer Export vor, ist der Vergleich eine Sache von Sekunden. Das folgende Beispiel geht davon aus, dass du Voice Routes und Policies als CSV exportiert hast, wie im Abschnitt zur Vorbeugung beschrieben.

$soll = Import-Csv "D:\TeamsSoll\soll\voicerouting-policies.csv" $ist = Import-Csv "D:\TeamsSoll\2026-11-11_0800\voicerouting-policies.csv"   Compare-Object $soll $ist -Property Identity, Usages | Sort-Object Identity | Format-Table -AutoSize   # Ausgabe (Beispiel): # Identity Usages SideIndicator # Tag:VRP-Frankfurt DE-Notruf;DE-National;DE-International <= # Tag:VRP-Frankfurt DE-Notruf;Test-SBC2;DE-International =>

 

„<=“ steht für den Soll-Stand, „=>“ für den Ist-Stand. Eine Zeile Unterschied, und du weißt, wo du suchen musst. Weil die Usages mit Semikolon in ihrer Reihenfolge zusammengefasst sind, fällt auch eine bloße Umsortierung auf. Das ist wichtig: Teams wertet die Usages einer Policy in der angegebenen Reihenfolge aus, eine vertauschte Reihenfolge ist also eine echte Änderung.

Schritt 4: Im Audit-Log den Zeitpunkt und das Konto finden

Jetzt, da du weißt, was sich geändert hat, suchst du im Audit-Log nach dem Wer und Wann. Das geht im Microsoft Purview-Portal unter Audit oder per PowerShell:

Connect-ExchangeOnline   Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-14) -EndDate (Get-Date) ` -Operations TeamsAdminAction -ResultSize 5000 | Select-Object CreationDate, UserIds, Operations, AuditData | Sort-Object CreationDate

 

Die Spalte AuditData enthält die Details als JSON. Filtere nach dem Namen des betroffenen Objekts, etwa mit Where-Object { $_.AuditData -like "*VRP-Frankfurt*" }. Findest du den Eintrag, hast du Zeitpunkt und Konto. Findest du ihn nicht, ist die Änderung entweder älter als die Aufbewahrung, oder sie lief über ein Konto, an das du nicht gedacht hast, zum Beispiel eine App-Registrierung eines Dienstleisters.

WICHTIG · Audit-Suche ohne Schuldzuweisung Das Ziel ist die Ursache, nicht der Schuldige. Wer im Teams-Chat mit dem Audit-Eintrag winkt, bekommt beim nächsten Mal keine ehrliche Antwort mehr auf die Frage, wer etwas geändert hat. Und genau diese Antwort ist schneller als jede Audit-Suche.

 

So findet es der Teams-Telefonie Diagnostiker

WERKZEUG · Drift-Erkennung im Teams-Telefonie Diagnostiker Der Teams-Telefonie Diagnostiker speichert jeden Diagnoselauf. Die Drift-Erkennung vergleicht zwei Läufe miteinander und listet neue, entfernte und geänderte Objekte auf, jeweils mit Bereich, Objekt sowie altem und neuem Wert. Das umfasst Wählpläne, PSTN Usages, Voice Routes, Voice Routing Policies, Gateways und die Zuweisungen der Benutzer. Zusätzlich zeigt der Vergleich, welche Befunde neu hinzugekommen und welche behoben sind. Den aktuellen Lauf gegen einen abgenommenen Stand zu vergleichen, ersetzt damit den selbst gebauten CSV-Vergleich. Das Audit-Log für das Wer und Wann brauchst du weiterhin. Mehr zum Werkzeug: Teams-Telefonie Diagnostiker. 15 Tage kostenlos testen.

 

Behebung: zurückdrehen, ohne neuen Schaden anzurichten

Wenn du die Abweichung gefunden hast, ist die Versuchung groß, sie sofort zurückzudrehen. Mach das mit Plan, denn auch ein Rollback ist eine Änderung, und zwar eine unter Zeitdruck.

Ist-Zustand sichern. Exportiere den aktuellen Stand, bevor du irgendetwas anfasst. Das ist dein Rollback für den Rollback.

Klären, ob die Änderung gewollt war. Ein kurzer Anruf beim Konto aus dem Audit-Log spart dir das Zurückdrehen einer Änderung, die ein anderes Projekt gerade braucht.

Genau eine Sache ändern. Im Beispiel: in VRP-Frankfurt die Usage Test-SBC2 wieder durch DE-National ersetzen. Nicht gleichzeitig die Route VR-Test löschen und den SBC aufräumen.

Testen. Testanruf aus dem betroffenen Standort, plus Notruf-Routing per Abfrage prüfen, nicht per echtem Notruf.

Soll bestätigen oder fortschreiben. Danach ist der Ist-Zustand wieder das Soll. Neuer Export, Ablage als neuer Referenzstand.

Aufräumen in einem zweiten Schritt. Verwaiste Routen, Usages und Test-SBCs entfernst du später, geplant und mit eigenem Export davor.

Für den konkreten Fall sieht die Korrektur so aus. Set-CsOnlineVoiceRoutingPolicy ersetzt die gesamte Usage-Liste, deshalb gibst du sie vollständig und in der richtigen Reihenfolge an:

# Vorher sichern Get-CsOnlineVoiceRoutingPolicy -Identity "VRP-Frankfurt" | Export-Clixml "D:\TeamsSoll\rollback\VRP-Frankfurt_2026-11-11_0930.xml"   # Usage-Liste vollständig neu setzen Set-CsOnlineVoiceRoutingPolicy -Identity "VRP-Frankfurt" ` -OnlinePstnUsages @{Replace="DE-Notruf","DE-National","DE-International"}

 

WARNUNG · Rollback-Hinweis Läuft die Korrektur schief, setzt du die gesicherte Liste mit derselben Syntax wieder ein: Import-Clixml lesen, OnlinePstnUsages auslesen, per Replace zurückschreiben. Lösche keine Routen, Usages oder Gateways, solange du nicht sicher weißt, dass keine andere Policy sie nutzt. Eine Usage, die in einer Policy steht, aber keine Route mehr hat, verhält sich wie ein Loch in der Kette.

 

Änderungen an Routing-Objekten wirken in der Regel nach kurzer Zeit. Bei geänderten Benutzerzuweisungen kann es laut Microsoft länger dauern, bis sie überall angekommen sind. Plane den Test deshalb nicht im Sekundentakt und notiere die Uhrzeit jeder Änderung.

FAKTEN · Uli erzählt: Drift im eigenen Haus Auch bei mir im Labor läuft ein anynode-SBC für Teams. Nach einem Update habe ich dort Testregeln eingerichtet und im Tenant eine zusätzliche Route mit höherer Priorität für meine Testnummern angelegt. Der Test war erfolgreich, die Route blieb. Wochen später wunderte ich mich, warum ein Teil meiner Anrufe einen anderen Weg nahm als erwartet. Gefunden habe ich es nicht im Audit-Log, sondern im Vergleich mit meinem eigenen Export vom Tag der Inbetriebnahme. Seitdem gilt im Labor dieselbe Regel wie bei Kunden: kein Test ohne Rückbautermin.

 

Vorbeugung: Soll-Zustand dokumentieren und regelmäßig vergleichen

Drift lässt sich nicht verhindern. Teams-Tenants leben, Standorte kommen dazu, Provider wechseln. Du kannst aber dafür sorgen, dass jede Abweichung auffällt, bevor ein Anwender sie meldet. Das Prinzip ist einfach: ein gepflegter Soll-Zustand, ein regelmäßiger Ist-Export, ein Vergleich, eine Entscheidung.

Was in den Soll-Zustand gehört

Bereich	Cmdlet zum Export	Mindestens festhalten
Wählpläne	Get-CsTenantDialPlan	Identity, NormalizationRules in Reihenfolge
Voice Routing Policies	Get-CsOnlineVoiceRoutingPolicy	Identity, OnlinePstnUsages in Reihenfolge
PSTN Usages	Get-CsOnlinePstnUsages	Usage-Liste
Voice Routes	Get-CsOnlineVoiceRoute	Identity, Priority, NumberPattern, Usages, Gateways
SBCs	Get-CsOnlinePSTNGateway	Identity, Enabled, SipSignalingPort, MediaBypass
Benutzer	Get-CsOnlineUser	UserPrincipalName, LineUri, OnlineVoiceRoutingPolicy, TenantDialPlan
Notruf	Get-CsTeamsEmergencyCallRoutingPolicy	Identity, EmergencyNumbers
Rufnummernanzeige	Get-CsCallingLineIdentity	Identity, CallingIDSubstitute, ServiceNumber

 

Ein einfaches Export-Skript

Das folgende Skript liest nur aus dem Tenant und schreibt CSV-Dateien in einen Ordner mit Zeitstempel. Mehrwertige Felder fasst es mit Semikolon zusammen, damit die Reihenfolge erhalten bleibt und der Vergleich mit Compare-Object funktioniert.

Connect-MicrosoftTeams $ziel = "D:\TeamsSoll\" + (Get-Date -Format "yyyy-MM-dd_HHmm") New-Item -ItemType Directory -Path $ziel -Force | Out-Null   Get-CsOnlineVoiceRoutingPolicy | Select-Object Identity, @{n='Usages';e={$_.OnlinePstnUsages -join ';'}} | Sort-Object Identity | Export-Csv "$ziel\voicerouting-policies.csv" -NoTypeInformation -Encoding UTF8   Get-CsOnlineVoiceRoute | Select-Object Identity, Priority, NumberPattern, @{n='Usages';e={$_.OnlinePstnUsages -join ';'}}, @{n='Gateways';e={$_.OnlinePstnGatewayList -join ';'}} | Sort-Object Identity | Export-Csv "$ziel\voiceroutes.csv" -NoTypeInformation -Encoding UTF8   Get-CsTenantDialPlan | ForEach-Object { $dp = $_.Identity $_.NormalizationRules | Select-Object @{n='DialPlan';e={$dp}}, Name, Pattern, Translation } | Export-Csv "$ziel\dialplans.csv" -NoTypeInformation -Encoding UTF8   Get-CsOnlineUser -Filter {EnterpriseVoiceEnabled -eq $true} | Select-Object UserPrincipalName, LineUri, @{n='VRP';e={"$($_.OnlineVoiceRoutingPolicy)"}}, @{n='DialPlan';e={"$($_.TenantDialPlan)"}} | Sort-Object UserPrincipalName | Export-Csv "$ziel\users.csv" -NoTypeInformation -Encoding UTF8

 

Bei den Wählplänen bleibt die Reihenfolge der Regeln durch die Zeilenreihenfolge erhalten. Willst du auch eine Umsortierung erkennen, ergänze eine laufende Nummer je Regel. Beim Vergleich der Benutzer gilt: Eine leere Spalte VRP bedeutet, dass der Benutzer die globale Richtlinie nutzt. Taucht ein Benutzer, der im Soll eine Policy hatte, plötzlich mit leerer Spalte auf, hast du die häufigste Form von Drift gefunden.

TIPP · Notrufmuster im Soll ausdrücklich prüfen Nimm die Route für 110 und 112 als eigene Zeile in deine Prüfliste auf. Ein Muster wie ^(110|112)$ trifft genau diese beiden Nummern und nichts anderes. Ändert sich hier etwas, ist das kein Schönheitsfehler, sondern ein Thema für sofort.

 

Rhythmus und Zuständigkeit

Anlass	Was du tust	Wer entscheidet
Nach jeder Abnahme	Export als neues Soll ablegen, mit Datum und Ticketnummer	Telefonie-Verantwortung
Wöchentlich	Ist-Export und Vergleich gegen Soll, Abweichungen prüfen	Betrieb
Vor jeder geplanten Änderung	Ist-Export als Rollback-Basis	Wer die Änderung umsetzt
Nach Dienstleister- oder Personalwechsel	Vollständiger Vergleich, Konten im Audit-Log prüfen	Telefonie-Verantwortung
Bei jeder Störung	Erst vergleichen, dann suchen	Helpdesk mit Betrieb

 

Der wichtigste Satz dieses Abschnitts: Jede gewollte Änderung schreibt das Soll fort. Wer das vergisst, hat nach drei Monaten ein Soll, das niemand mehr ernst nimmt, und einen Vergleich, der jede Woche dieselben zwanzig „Abweichungen“ meldet. Wie du Zuständigkeiten, Freigaben und Namenskonventionen für die Telefonie festlegst, steht in Microsoft Teams Telefonie-Governance.

WICHTIG · Testobjekte mit Ablaufdatum Gib Testobjekten einen eindeutigen Präfix wie „Test-“ und ein Ablaufdatum in der Beschreibung oder im Ticket. Dein wöchentlicher Vergleich listet dann alle Objekte mit diesem Präfix gesondert auf. Kein Test ohne Rückbautermin, und kein Rückbautermin ohne Erinnerung.

 

Wenn dein Tenant schon so weit gedriftet ist, dass keiner mehr weiß, welcher Stand der richtige ist, hilft kein Vergleich. Dann musst du das Soll erst neu festlegen. Wie man das strukturiert angeht, beschreibt Teams-Telefonie nach der Einführung retten: ein Plan in fünf Schritten; einen kompakten Einstieg bietet das Festpreispaket Grobkonzept Teams-Telefonie. Und wenn du dein Team darin fit machen willst, Routing-Objekte selbst zu lesen und zu exportieren, ist die Schulung Teams-Telefonie der passende Rahmen.

FAQ: Konfigurationsdrift in der Teams-Telefonie

Gibt es im Teams Admin Center eine Änderungshistorie für Voice Routes?

Nein. Das Teams Admin Center zeigt den aktuellen Zustand der Telefonie-Objekte. Einen früheren Stand kannst du dort nicht aufrufen. Für das Wer und Wann nutzt du das Audit-Log in Microsoft Purview, für den früheren Inhalt deine eigenen Exporte.

Werden Änderungen per PowerShell im Audit-Log protokolliert?

Laut Microsoft-Dokumentation erfasst der Vorgang „Teams Admin Action“ Änderungen durch Teams-Admins über Admin Center, PowerShell und API. Wie detailliert ein Eintrag für ein bestimmtes Telefonie-Objekt ist, solltest du in deinem Tenant mit einer Teständerung prüfen.

Wie lange reicht das Audit-Log zurück?

In Audit (Standard) bewahrt Microsoft die Einträge 180 Tage auf. Mit Audit (Premium) lassen sich über Aufbewahrungsrichtlinien längere Zeiträume festlegen. Ältere Änderungen findest du nur über eigene Exporte.

Wie oft sollte ich den Ist-Zustand exportieren?

Wöchentlich ist für die meisten Umgebungen ein guter Rhythmus, zusätzlich vor jeder geplanten Änderung und nach jeder Abnahme. In Umgebungen mit vielen Admins oder Dienstleistern lohnt ein täglicher Export, weil er das Zeitfenster für die Audit-Suche verkleinert.

Reicht es, nur Voice Routes zu exportieren?

Nein. Viele Drift-Fälle stecken in der Reihenfolge der Usages in einer Policy oder in Benutzerzuweisungen. Exportiere mindestens Wählpläne, Voice Routing Policies, Usages, Voice Routes, SBCs und die Telefonie-Benutzer.

Warum fällt eine geänderte Usage-Reihenfolge so selten auf?

Weil die Policy danach syntaktisch korrekt ist und viele Anrufe weiter funktionieren. Erst wenn eine bestimmte Nummer über eine andere Route läuft oder ein SBC ausfällt, zeigt sich die Wirkung. Die Reihenfolge erklärt Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen.

Wie unterscheide ich gewollte von ungewollter Drift?

Gar nicht im Tenant, sondern im Prozess. Eine gewollte Änderung hat ein Ticket und schreibt das Soll fort. Alles, was im Vergleich auftaucht und kein Ticket hat, ist erst einmal ungewollt, bis jemand das Gegenteil belegt.

Kann ich einen alten Zustand einfach zurückspielen?

Nicht mit einem Knopf. Du nutzt den Export als Vorlage und setzt die betroffenen Objekte mit den Set-Cmdlets gezielt zurück, eines nach dem anderen und mit Test dazwischen. Ein kompletter Rückspielvorgang über alle Objekte ist riskanter als die Drift selbst.

Fazit: Wer das Soll nicht kennt, kann keine Abweichung finden

Konfigurationsdrift ist kein exotischer Fehler, sondern der Normalzustand jedes Tenants, der länger als ein paar Monate lebt. Teams hilft dir dabei nur halb: Das Audit-Log liefert Wer und Wann, aber keinen bequemen Vorher-nachher-Vergleich und nichts über die Zeit vor der Aufbewahrungsfrist. Das Admin Center zeigt nur das Jetzt.

Die Lösung ist unspektakulär und wirksam: ein abgenommener Soll-Zustand als Export, ein regelmäßiger Ist-Export mit demselben Skript, ein Vergleich und eine Entscheidung für jede Abweichung. Dann ist der nächste Montagmorgen in Frankfurt eine Sache von fünf Minuten und einer Zeile Unterschied. Und die Teamrunde, in der niemand etwas geändert hat, darf ausnahmsweise recht haben. Wenn du dabei Unterstützung willst, findest du sie in der Beratung zur Teams-Telefonie.

WEITERLESEN · Weiterlesen › Microsoft Teams Telefonie-Governance › Voice Routing Policy, PSTN Usage und Voice Route: Reihenfolge verstehen › Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen › Teams-Benutzer fällt auf die globale Richtlinie zurück › Teams-Telefonie Probleme: die zehn häufigsten Ursachen