Normalisierungsregeln in Teams: typische Fehler und wie du sie findest

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Notruf, Sprachqualität und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Deine Wählpläne sind über Jahre gewachsen und keiner traut sich mehr ran? Wir räumen sie gemeinsam mit dir auf. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Wählpläne, Normalisierungsregeln und Voice Routing selbst sicher bauen und prüfen wollen. › Schulung Teams-Telefonie

 

Normalisierungsregeln sind die stillen Übersetzer der Teams-Telefonie. Solange sie funktionieren, merkt niemand, dass es sie gibt. Wenn nicht, klingelt beim Notruf die Kantine, Köln landet in Frankfurt, und die Hälfte der Kollegen erreicht ihre Kunden nur noch, wenn sie die Nummer mit +49 eintippen. Was die meisten natürlich nicht tun, denn so hat man ja auch noch nie telefoniert.

Das Tückische: Ein Fehler in einer Normalisierungsregel sieht fast nie wie ein Fehler in einer Normalisierungsregel aus. Er sieht aus wie eine kaputte Voice Route, ein zickiger SBC oder ein Provider mit schlechter Laune. Gesucht wird dann überall, nur nicht da, wo es hakt. Dieser Beitrag zeigt dir die typischen Fehler beim Thema teams normalisierungsregeln, wie sie technisch entstehen, wie du sie mit lesenden PowerShell-Befehlen in Minuten findest und wie du sie reparierst, ohne neue einzubauen.

Grundlagen zu Wählplänen und Direct Routing wiederholen wir hier nur so weit, wie sie für die Fehlersuche nötig sind. Den Gesamtüberblick findest du auf der Seite Teams-Telefonie, den Aufbau des Rufwegs in Teams Direct Routing einrichten.

FAKTEN · Worum es hier geht Betrachtet werden Teams-Wählpläne (Tenant Dial Plans) mit ihren Normalisierungsregeln, typischerweise in einer Umgebung mit Direct Routing. Alle Beispiele nutzen den erfundenen Tenant Contoso (contoso.com) mit Standorten in Frankfurt, Köln, Berlin, Hamburg und München, Rufnummern im Muster +49 69 555 0100 und SBCs wie sbc1.contoso.com. Das Beispiel-Setup in diesem Beitrag kommt ohne Amtsholung aus: Wer national wählt, tippt 0 plus Vorwahl, international 00 plus Landeskennzahl, intern dreistellige Durchwahlen. Wenn bei dir eine 0 vor jedem externen Gespräch steht, gelten dieselben Fehlerbilder, nur die Muster sehen anders aus. Dafür gibt es einen eigenen Beitrag. Alle Diagnosebefehle sind lesend (Get- und Test-Cmdlets aus dem Modul MicrosoftTeams). Geschrieben wird erst im Abschnitt zur Behebung, und dort mit Sicherung und Rückweg.

 

Das Symptom: wie kaputte Normalisierung im Helpdesk klingt

Niemand ruft beim Helpdesk an und sagt: „Ich glaube, Regel vier in DP-Frankfurt ist zu gierig.“ Die Meldungen sind unscharf, aber sie haben ein Muster. Wenn ein Fehler nur bei bestimmten Schreibweisen auftritt, bei manchen Standorten oder bei auffällig kurzen Nummern, ist die Normalisierung der Hauptverdächtige.

Was der Helpdesk hört	Was dahinterstecken kann	Typischer Fehler
„Mit +49 geht es, mit 0 vorne nicht.“	Für die nationale Schreibweise greift keine oder die falsche Regel	Regel fehlt, Reihenfolge falsch, Muster zu eng
„Ins Ausland komme ich nicht, Inland geht.“	Eine nationale Regel mit 0 frisst auch die 00	Zu gieriges Muster, falsche Reihenfolge
„Ich wähle eine Kölner Nummer und lande bei einem Frankfurter Anschluss.“	Eine Ortsnetzregel ergänzt die falsche Vorwahl oder greift ohne Grund	Ortsnetz ohne Vorwahl, Benutzer im falschen Wählplan
„Die Durchwahl 112 von Kollege Meier ist komisch belegt.“	Die Durchwahlregel macht aus 112 eine interne Rufnummer	Durchwahlen kollidieren mit Notrufnummern
„Nummern aus der Anrufliste kann ich nicht zurückrufen.“	Die gespeicherte Schreibweise passt auf eine unerwartete Regel	Fehlende Anker ^ und $
„Seit gestern geht es in Hamburg nicht mehr, sonst überall.“	Jemand hat den Wählplan eines Standorts geändert	Unkontrollierte Änderung, Drift
„Am SBC kommt die Nummer ohne Plus an.“	Eine Regel liefert ein Ergebnis ohne +	Doppelte Normalisierung, Ergebnis nicht E.164

 

WARNUNG · Ein Symptom, das niemand meldet Der gefährlichste Normalisierungsfehler erzeugt keine Tickets: Wenn eine Durchwahlregel 110 oder 112 übersetzt, merkt das niemand, bis jemand im Ernstfall die Leitstelle braucht und stattdessen einen Kollegen in der Buchhaltung erreicht. Oder niemanden. Prüfe Notrufnummern deshalb nach jeder Änderung am Wählplan aktiv, nicht erst, wenn sich jemand beschwert. Wie das gefahrlos geht, steht weiter unten.

 

Wie der Fehler technisch zustande kommt

Ein abgehender Anruf läuft in Teams durch eine feste Kette: Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC. Die Normalisierung ist Station drei, und alles danach sieht nur noch ihr Ergebnis. Liefert sie eine falsche Nummer, sucht die Voice Route brav nach einem Muster für diese falsche Nummer, und der SBC bekommt genau das, was man ihm gibt.

Der effektive Wählplan: was wirklich gilt

Jeder Benutzer hat laut Microsoft einen effektiven Wählplan. Der setzt sich zusammen aus dem Service-Wählplan des Landes, das sich aus der Usage Location ergibt, und entweder einem dem Benutzer zugewiesenen Wählplan oder, wenn keiner zugewiesen ist, dem Global-Wählplan des Tenants. Die Regeln aus deinem Wählplan haben dabei Vorrang vor denen des Service-Wählplans. Den Service-Wählplan selbst kannst du nicht ändern.

Daraus folgt der erste Klassiker: Ein Benutzer, dem kein Standort-Wählplan zugewiesen wurde, bekommt die Regeln des Global-Wählplans. Steht dort die Frankfurter Durchwahlregel, wählt der Kollege in München mit seiner dreistelligen Durchwahl fröhlich in Frankfurt an. Das ist dasselbe Muster wie bei den Voice Routing Policies, beschrieben in Teams-Benutzer fällt auf die globale Richtlinie zurück.

FAKTEN · Was Microsoft zu Wählplänen festlegt Normalisierungsregeln werden von oben nach unten geprüft. Die erste passende Regel wird angewendet, weitere Regeln werden nicht mehr betrachtet. Ein Wählplan darf höchstens 50 Normalisierungsregeln enthalten, ein Tenant höchstens 1.000 Tenant-Wählpläne. Muster und Übersetzungen sind reguläre Ausdrücke im .NET-Format. Liefert eine Regel ein Ergebnis ohne führendes +, versucht der Dienst die Nummer erneut mit den Regeln aus Tenant- und Landeswählplan zu normalisieren. Microsoft empfiehlt deshalb, dass alle Regeln ein Ergebnis mit + erzeugen. Der Teams-Client normalisiert alle abgehenden Anrufe nach dem effektiven Wählplan, auch Anrufe aus dem Verlauf und über Rufnummern-Links. Den Wählplan erhält der Client über die Bereitstellung bei der Anmeldung.

 

Fehler 1: Die Reihenfolge der Regeln

„Erste passende Regel gewinnt“ klingt harmlos und ist die Ursache für vermutlich die Hälfte aller Normalisierungsprobleme. Teams prüft die Regeln nicht nach Logik oder Spezifität, sondern stur nach Position. Eine breite Regel weiter oben überdeckt jede speziellere darunter, egal wie liebevoll die formuliert ist. Microsoft selbst schreibt dazu sinngemäß: Wenn eine Nummer auf mehrere Regeln passen kann, gehören die restriktiveren nach oben.

Das Lehrbuchbeispiel ist die Kombination aus nationaler und internationaler Wahl. Steht die Regel für nationale Nummern (beginnt mit 0) über der Regel für internationale Nummern (beginnt mit 00) und schließt die zweite 0 nicht aus, landet jede Auslandsnummer in der nationalen Regel. Aus 0033 … wird dann +49033 … und der Anruf geht, wenn überhaupt, irgendwohin in Deutschland.

Fehler 2: Zu gierige Muster

Gierig ist ein Muster, das mehr Nummern trifft, als es soll. Die üblichen Verdächtigen sind \d+ ohne Längenbegrenzung, .* oder .+ als Allesfresser und Zeichenklassen ohne Ausschluss. ^0(\d+)$ zum Beispiel trifft nationale Nummern, aber auch jede 00-Auslandsnummer und jede Eingabe, die mit 0 beginnt und sich verlaufen hat.

Die Lösung ist immer dieselbe: Beschreib die Nummer, die du erwartest, so genau wie nötig. Für nationale Nummern heißt das zum Beispiel ^0([1-9]\d{3,12})$: eine 0, danach eine Ziffer von 1 bis 9 (also keine zweite 0), dann eine begrenzte Anzahl weiterer Ziffern. Die genaue Untergrenze ist Geschmackssache; wichtig ist, dass die Regel keine Nummern erfasst, die einer anderen gehören.

Fehler 3: Fehlende Anker ^ und $

Ein regulärer Ausdruck ohne ^ am Anfang und $ am Ende sucht nicht die ganze Nummer, sondern irgendein passendes Teilstück. Das Muster (\d{3}) für dreistellige Durchwahlen passt dann nicht nur auf 104, sondern auch auf die ersten drei Ziffern jeder beliebigen längeren Nummer. Die Regel greift bei Nummern, für die sie nie gedacht war, und weil sie vermutlich weit oben steht, kommt danach auch keine andere mehr zum Zug.

TIPP · Regex lokal prüfen, bevor du sie einträgst PowerShell nutzt dieselbe .NET-Regex-Engine. Ob ein Muster passt und was die Übersetzung daraus macht, siehst du in Sekunden: '02215550100' -match '^(10\d|1[2-9]\d)$' liefert False, '104' -replace '^(10\d|1[2-9]\d)$', '+49695550$1' liefert +49695550104. Achte auf einfache Anführungszeichen, sonst interpretiert PowerShell das $1 als Variable.

 

Fehler 4: Ortsnetz ohne Vorwahl

Viele Anwender wählen Nummern im eigenen Ortsnetz ohne Vorwahl, weil sie das seit dreißig Jahren so machen. Eine Regel, die dafür die Vorwahl ergänzt, ist legitim, aber sie ist die gefährlichste im ganzen Wählplan. Die naive Variante ^(\d{5,8})$ mit Übersetzung +4969$1 trifft nämlich alles, was fünf bis acht Ziffern hat: Sonderrufnummern der 116er- und 118er-Gasse, verkürzt eingetippte Nummern, falsch kopierte Durchwahlen. Und sie gilt für jeden, der diesen Wählplan hat, auch für den Kollegen aus Köln, der versehentlich im Frankfurter Wählplan gelandet ist.

Besser ist ^([2-9]\d{4,7})$ mit +4969$1. Teilnehmernummern im deutschen Festnetz beginnen in aller Regel nicht mit 0 oder 1, die Einschränkung auf 2 bis 9 hält also Notruf, Sonderrufnummern und nationale Wahl draußen. Achte außerdem darauf, dass nach +49 die Ortsvorwahl ohne führende 0 steht: +4969, nicht +49069. Dieser Fehler fällt im Wählplan kaum auf, aber garantiert beim ersten Anruf.

WICHTIG · Ortsnetzregeln gehören in Standort-Wählpläne Eine Regel, die eine Ortsvorwahl ergänzt, hat im Global-Wählplan nichts verloren. Sie gehört in den Wählplan genau des Standorts, für den sie gilt, und dieser Wählplan gehört nur Benutzern dieses Standorts zugewiesen. Sonst wählt Hamburg mit Frankfurter Vorwahl. Überlege auch, ob du die Kurzwahl im Ortsnetz überhaupt brauchst: Jede Regel, die du nicht anlegst, kann auch nicht falsch sein.

 

Fehler 5: Durchwahlen kollidieren mit Notrufnummern

Das ist der Fehler aus dem Beitragsbild, und er ist häufiger, als einem lieb ist. Contoso Frankfurt hat den Rufnummernblock +49 69 5550 mit dreistelligen Durchwahlen ab 100. Die erste Idee für die Durchwahlregel lautet ^(1\d{2})$ mit Übersetzung +49695550$1. Funktioniert prima für 104 und 157. Und für 110 und 112, die dann zu +49695550110 und +49695550112 werden. Ist die Nummer vergeben, klingelt dort ein Telefon. Ist sie nicht vergeben, landet der Anruf im Nirwana. In beiden Fällen ist die Leitstelle nicht dabei.

Die Abhilfe hat zwei Teile. Erstens steht eine Notrufregel ganz oben im Wählplan, die 110 und 112 unverändert durchreicht, zum Beispiel ^(110|112)$ mit Übersetzung $1. Zweitens schließt das Durchwahlmuster die Notrufnummern selbst aus, etwa ^(10\d|1[2-9]\d)$. Damit sind 110 bis 119 als Durchwahl verbrannt, was ein geringer Preis ist. Am saubersten ist es, solche Bereiche schon bei der Rufnummernplanung gar nicht erst als Durchwahl zu vergeben.

Wichtig: Wie 110 und 112 nach der Normalisierung aussehen müssen, hängt von deiner Notrufkonfiguration ab, also von Emergency Call Routing Policy und den Voice Routes, über die der Notruf zum SBC geht. Üblich ist, die Nummer unverändert zu lassen. Die Einzelheiten stehen in Notruf in Microsoft Teams konfigurieren.

AUS DER PRAXIS · Ein Logistiker mit sechs Standorten Ein Logistikunternehmen hatte seine Wählpläne aus der alten Telefonanlage übernommen, inklusive einer Durchwahlregel ^(1\d{2})$ an Position eins. Aufgefallen ist es bei einem Audit, nicht bei einem Notfall, und das war pures Glück. Test-CsEffectiveTenantDialPlan mit der Nummer 112 zeigte als Ergebnis eine interne Rufnummer, die zufällig dem Empfang gehörte. Der Empfang hätte im Ernstfall immerhin gewusst, wo der Verbandskasten steht.

 

Fehler 6: Ergebnis ohne + und falsch referenzierte Gruppen

Eine Regel mit Übersetzung 49$1 statt +49$1 sieht im Wählplan fast richtig aus. Laut Microsoft versucht der Dienst aber, ein Ergebnis ohne + erneut mit Tenant- und Landesregeln zu normalisieren. Was dabei herauskommt, hängt von allen anderen Regeln ab und ist genau die Art von Überraschung, die du nicht willst. Die Ausnahme sind bewusst unveränderte Nummern wie 110 und 112, die durch die Notrufregel oben im Wählplan immer wieder auf sich selbst abgebildet werden.

Verwandt damit sind Gruppenfehler: Das Muster ^(0)(\d+)$ hat zwei Gruppen. Wer in der Übersetzung +49$1 schreibt, bekommt +490 statt der Nummer. $1 ist immer die erste Klammer, nicht die interessanteste.

AUS DER PRAXIS · Uli und der eigene anynode-SBC Ich betreibe für Tests einen eigenen anynode-SBC an einem Labor-Tenant. Nach einer Umstellung kamen am SBC plötzlich Rufnummern ohne + an, und ich habe zuerst, wie alle, am SBC gesucht: Rufnummernmanipulation, Trunk-Einstellungen, alles sauber. Die Ursache war eine Regel, in der ich das + in der Übersetzung vergessen hatte. Seitdem ist mein erster Blick bei komischen Nummern am SBC nicht das SBC-Protokoll, sondern Test-CsEffectiveTenantDialPlan.

 

Fehler 7: Missverständnisse um IsInternalExtension

Jede Normalisierungsregel hat die Eigenschaft IsInternalExtension. Viele Admins setzen sie auf True, weil sie annehmen, Teams würde die Nummer dann intern behandeln und nicht über den SBC schicken. Das ist ein Erbe aus Lync und Skype for Business. In der Teams-Dokumentation steht zu dem Parameter: Er soll kennzeichnen, ob das Ergebnis eine interne oder externe Nummer ist, wird aber ignoriert, wenn OptimizeDeviceDialing im Wählplan auf False steht. OptimizeDeviceDialing und ExternalAccessPrefix sind laut Microsoft aus New-CsTenantDialPlan und Set-CsTenantDialPlan entfernt, weil sie nicht mehr verwendet werden.

Für die Praxis heißt das: Ob ein Anruf intern bei einem Kollegen landet, entscheidet nicht dieses Flag, sondern ob die normalisierte Nummer einem Benutzer oder Ressourcenkonto im Tenant zugewiesen ist (Reverse Number Lookup). Verlass dich bei der Fehlersuche nicht auf IsInternalExtension. Steht es bei migrierten Regeln auf True, ist es meist ein Überbleibsel. Für neue Regeln, die E.164 liefern, setzt du es auf False, so wie es auch in den Microsoft-Beispielen steht.

Fehler	Fehlerhafte Regel	Was passiert	Korrigierte Regel
Reihenfolge	1: ^0(\d+)$ › +49$1 2: ^00(\d+)$ › +$1	0033 … wird zu +49033 …, Regel 2 wird nie erreicht	1: ^00([1-9]\d{6,14})$ › +$1 2: ^0([1-9]\d{3,12})$ › +49$1
Zu gierig	^0(.*)$ › +49$1	Trifft jede Eingabe mit 0, auch 0 allein und 00	^0([1-9]\d{3,12})$ › +49$1
Fehlende Anker	(\d{3}) › +49695550$1	Greift bei jeder Nummer, die drei Ziffern enthält	^(10\d|1[2-9]\d)$ › +49695550$1
Ortsnetz ohne Vorwahl	^(\d{5,8})$ › +49069$1	Frisst Sonderrufnummern, und die 0 der Vorwahl steht falsch hinter +49	^([2-9]\d{4,7})$ › +4969$1 nur im Standort-Wählplan Frankfurt
Kollision mit Notruf	^(1\d{2})$ › +49695550$1 (ohne Notrufregel davor)	110 und 112 werden zu internen Rufnummern	1: ^(110|112)$ › $1 2: ^(10\d|1[2-9]\d)$ › +49695550$1
Ergebnis ohne +	^0([1-9]\d{3,12})$ › 49$1	Zweite Normalisierung mit ungewissem Ergebnis	^0([1-9]\d{3,12})$ › +49$1
Falsche Gruppe	^(0)(\d+)$ › +49$1	Ergebnis ist +490	^0([1-9]\d{3,12})$ › +49$1
IsInternalExtension	Durchwahlregel mit IsInternalExtension True	Admin erwartet internes Routing, das Flag steuert es nicht	IsInternalExtension False; intern entscheidet die zugewiesene Rufnummer

 

Zur Lesart: Das Zeichen › trennt Muster und Übersetzung. Die Regeln beziehen sich auf das Beispiel-Setup ohne Amtsholung mit dreistelligen Durchwahlen im Block +49 69 5550. Die Auslandsregel lässt nach 00 eine Landeskennzahl ab 1 zu und begrenzt die Länge so, dass das Ergebnis höchstens 15 Ziffern hat, wie E.164 es vorgibt.

WEITERLESEN · Wenn die Normalisierung stimmt, aber trotzdem nichts geht › Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen › Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen › Wählplan mit Amtsholung 0 in Teams richtig bauen

 

Diagnose Schritt für Schritt

Die gute Nachricht: Kein Teil der Rufkette lässt sich so bequem prüfen wie die Normalisierung. Du brauchst einen konkreten Benutzer, eine konkrete gewählte Nummer genau so, wie der Anwender sie eintippt, und fünf Minuten. Alle Befehle in diesem Abschnitt sind lesend.

Schritt 1: Welcher Wählplan gilt für den Benutzer?

Connect-MicrosoftTeams Get-CsOnlineUser -Identity anna.berg@contoso.com | Select-Object DisplayName, UsageLocation, TenantDialPlan, LineUri

 

Ist TenantDialPlan leer, gilt der Global-Wählplan des Tenants. Steht dort ein Wählplan, prüfe, ob er zum Standort des Benutzers passt. Die Usage Location bestimmt den Service-Wählplan, also das Land. Eine Kollegin in Köln mit Usage Location US bekommt die US-Regeln dazu. Im Teams Admin Center findest du die Zuweisung beim Benutzer unter Richtlinien.

Schritt 2: Welche Regeln sind effektiv?

Get-CsEffectiveTenantDialPlan -Identity anna.berg@contoso.com | Select-Object -ExpandProperty NormalizationRules | Format-Table Name, Pattern, Translation, IsInternalExtension -AutoSize

 

Das ist die Liste, die der Client tatsächlich verwendet, in der Reihenfolge, in der sie geprüft wird, inklusive der Regeln aus dem Service-Wählplan. Lies sie von oben nach unten und frag dich bei jeder Regel: Welche Nummern fängt die ab, bevor sie weiter unten ankommen? Die Wählpläne selbst siehst du mit Get-CsTenantDialPlan, im Teams Admin Center unter Sprache › Wählpläne.

Schritt 3: Welche Regel greift wirklich?

Das wichtigste Werkzeug dieses Beitrags ist Test-CsEffectiveTenantDialPlan. Es wendet die Regeln des effektiven Wählplans auf eine Nummer an und zeigt dir das Ergebnis und die Regel, die gegriffen hat. Es baut dabei keinen Anruf auf. Du kannst also auch 110 und 112 testen, ohne dass irgendwo ein Telefon klingelt.

Test-CsEffectiveTenantDialPlan -Identity anna.berg@contoso.com -DialedNumber 112   # Mehrere Nummern auf einmal, so wie Anwender sie tippen # (ergänze eine Auslandsnummer, die du kennst, mit 00 davor) $nummern = '110', '112', '104', '02215550100', '5550100' $nummern | ForEach-Object { $r = Test-CsEffectiveTenantDialPlan -Identity anna.berg@contoso.com -DialedNumber $_ [pscustomobject]@{ Eingabe = $_; Ergebnis = $r.TranslatedNumber; Regel = $r.MatchingRule } } | Format-Table -Wrap

 

Mit dem Schalter -TenantScopeOnly prüfst du nur gegen die Tenant-Wählpläne, ohne die Regeln des Service-Wählplans. Unterscheiden sich die Ergebnisse mit und ohne den Schalter, weißt du, dass für diese Nummer eine Landesregel einspringt, weil deine eigenen Regeln nicht greifen. Im Teams Admin Center kannst du beim Bearbeiten eines Wählplans ebenfalls eine Nummer testen; dort prüfst du allerdings den einzelnen Wählplan, nicht den effektiven Wählplan eines Benutzers.

Schritt 4: Stimmt das Ergebnis?

Vergleiche jedes Ergebnis mit dem, was herauskommen soll. Eine kleine Prüftabelle für deinen Standort ist hier Gold wert, und sie ist gleichzeitig die Grundlage für jeden Test nach Änderungen.

Eingabe	Erwartetes Ergebnis	Greifende Regel (Beispiel)	Woran du einen Fehler erkennst
112	112	DE-Notruf	Ergebnis beginnt mit +49 69 oder Regel heißt nach Durchwahl
110	110	DE-Notruf	wie bei 112
104	+49695550104	FFM-Durchwahl	Ergebnis ohne + oder mit falschem Stamm
02215550100	+492215550100	DE-National	+49022… (0 nicht entfernt) oder Ortsnetzregel greift
5550100	+49695550100	FFM-Ortsnetz	Regel greift bei Benutzern außerhalb Frankfurts
00 + Landeskennzahl + Nummer	+ Landeskennzahl + Nummer	DE-International	Ergebnis beginnt mit +490 (nationale Regel zuerst)

 

Schritt 5: Passt danach eine Voice Route?

Ist das Ergebnis richtig und der Anruf geht trotzdem nicht raus, liegt der Fehler weiter hinten. Prüfe, welche Voice Routes auf die normalisierte Nummer passen:

$ziel = '+492215550100' Get-CsOnlineVoiceRoute | Where-Object { $ziel -match $_.NumberPattern } | Select-Object Identity, NumberPattern, Priority, OnlinePstnUsages, OnlinePstnGatewayList

 

Kommt hier nichts zurück, passt kein Routenmuster. Ob die passende Route auch in einer PSTN Usage steckt, die die Voice Routing Policy des Benutzers enthält, ist dann Thema von Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen.

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Der Rufweg-Simulator spielt eine gewählte Nummer für einen Benutzer durch und zeigt den effektiven Wählplan, die greifende Normalisierungsregel mit dem Ergebnis und danach Policy, PSTN Usage, Voice Route und Gateway. Der Benutzer-Steckbrief zeigt, welcher Wählplan einem Benutzer zugewiesen ist und ob er auf den Global-Wählplan zurückfällt. Problematische Regeln, etwa eine Durchwahlregel, die 110 oder 112 übersetzt, erscheinen als Befunde mit Prüffall, sodass du nachvollziehen kannst, mit welcher Nummer der Fehler belegt wurde. Der Assistent für Wählpläne zeigt Änderungen vor dem Anwenden, sichert vorher einen Snapshot und protokolliert den Lauf mit der Möglichkeit, ihn zurückzunehmen. Die Drift-Erkennung meldet, wenn sich ein Wählplan außerhalb des geplanten Wegs geändert hat. Der Teams-Telefonie Diagnostiker lässt sich 15 Tage kostenlos testen. › Teams-Telefonie Diagnostiker

 

Behebung: Regeln reparieren, ohne neue Fehler einzubauen

Wählpläne gehören zu den Einstellungen, bei denen eine gut gemeinte Korrektur am Freitagnachmittag am Montag einen ganzen Standort lahmlegt. Deshalb gilt hier besonders streng: sichern, ändern, mit derselben Prüftabelle testen.

Vorher sichern

Get-CsTenantDialPlan -Identity DP-Frankfurt | Export-Clixml -Path .\DP-Frankfurt-vorher.xml Get-CsTenantDialPlan | Export-Clixml -Path .\DialPlans-alle-vorher.xml

 

Regeln in der richtigen Reihenfolge neu setzen

Im Teams Admin Center öffnest du unter Sprache › Wählpläne den Wählplan, korrigierst die Regel und verschiebst sie mit den Schaltflächen zum Hoch- und Runterschieben an die richtige Position. Für mehrere Regeln ist PowerShell übersichtlicher: Du baust die vollständige Liste in der gewünschten Reihenfolge und übergibst sie komplett an Set-CsTenantDialPlan. Die Reihenfolge der Liste ist die Reihenfolge der Prüfung.

$regeln = @( New-CsVoiceNormalizationRule -Parent Global -Name 'DE-Notruf' -Pattern '^(110|112)$' ` -Translation '$1' -IsInternalExtension $false -InMemory New-CsVoiceNormalizationRule -Parent Global -Name 'FFM-Durchwahl' -Pattern '^(10\d|1[2-9]\d)$' ` -Translation '+49695550$1' -IsInternalExtension $false -InMemory New-CsVoiceNormalizationRule -Parent Global -Name 'DE-International' -Pattern '^00([1-9]\d{6,14})$' ` -Translation '+$1' -IsInternalExtension $false -InMemory New-CsVoiceNormalizationRule -Parent Global -Name 'DE-National' -Pattern '^0([1-9]\d{3,12})$' ` -Translation '+49$1' -IsInternalExtension $false -InMemory New-CsVoiceNormalizationRule -Parent Global -Name 'FFM-Ortsnetz' -Pattern '^([2-9]\d{4,7})$' ` -Translation '+4969$1' -IsInternalExtension $false -InMemory ) Set-CsTenantDialPlan -Identity DP-Frankfurt -NormalizationRules $regeln -WhatIf Set-CsTenantDialPlan -Identity DP-Frankfurt -NormalizationRules $regeln

 

Pattern und Translation stehen in einfachen Anführungszeichen; Microsoft weist ausdrücklich darauf hin, dass doppelte Anführungszeichen hier nicht funktionieren. Die beiden Regeln DE-International und DE-National schließen sich durch das [1-9] nach der ersten 0 gegenseitig aus, ihre Reihenfolge ist deshalb unkritisch. Die Notrufregel steht trotzdem ganz oben, damit keine künftige Regel sich versehentlich davordrängeln kann.

Testen und dem Client Zeit geben

Führe danach die Testschleife aus Schritt 3 erneut aus, mit denselben Nummern, für mindestens einen Benutzer pro betroffenem Standort. Der Teams-Client bekommt den Wählplan über die Bereitstellung bei der Anmeldung. Bis ein Anwender das neue Verhalten sieht, kann es also dauern; eine Ab- und Wiederanmeldung im Client hilft beim Test. Für echte Notruftests gibt es eigene Regeln, beschrieben in Notruf in Teams testen, ohne die Leitstelle zu verärgern.

WARNUNG · Rollback: so kommst du zurück Aus der Sicherung lässt sich der alte Stand wiederherstellen, indem du die Regeln aus der XML-Datei neu als In-Memory-Objekte erzeugst und zurückschreibst: $alt = Import-Clixml -Path .\DP-Frankfurt-vorher.xml $regeln = foreach ($nr in $alt.NormalizationRules) { New-CsVoiceNormalizationRule -Identity ("Global/" + $nr.Name) -Description $nr.Description -Pattern $nr.Pattern -Translation $nr.Translation -IsInternalExtension $nr.IsInternalExtension -InMemory } Set-CsTenantDialPlan -Identity DP-Frankfurt -NormalizationRules $regeln Das ist dasselbe Vorgehen, das Microsoft für die Übernahme von Wählplänen aus Skype for Business beschreibt. Teste nach dem Rollback mit derselben Prüftabelle, und vergiss 110 und 112 nicht.

 

Vorbeugung: damit der nächste Fehler gar nicht erst entsteht

Notrufregel immer oben. Jeder Wählplan beginnt mit der Regel für 110 und 112. Durchwahlbereiche werden so geplant, dass sie nicht mit Notruf- oder Sonderrufnummern kollidieren.

Jedes Muster mit ^ und $. Keine Ausnahme ohne schriftliche Begründung im Beschreibungsfeld der Regel.

Jede Übersetzung mit +. Mit Ausnahme der bewusst unveränderten Notrufnummern liefert jede Regel E.164 mit +49 und Ortsvorwahl ohne führende 0.

Ortsnetzregeln nur im Standort-Wählplan. Der Global-Wählplan enthält nichts, was nur für einen Standort stimmt.

Prüftabelle je Standort. Eine feste Liste von Testnummern, die nach jeder Änderung mit Test-CsEffectiveTenantDialPlan durchläuft, am besten als Skript.

Regeln sprechend benennen und beschreiben. Name und Beschreibung sagen, welche Nummern die Regel erfassen soll. Wer sie in zwei Jahren liest, bist vielleicht du.

Änderungen nachvollziehbar machen. Exportiere die Wählpläne regelmäßig und vergleiche die Stände, damit du siehst, wer wann was geändert hat.

Zum letzten Punkt gibt es zwei Vertiefungen: Konfigurationsdrift in der Teams-Telefonie erkennen zeigt, wie du ungeplante Änderungen erkennst, und Microsoft Teams Telefonie-Governance beschreibt, wer überhaupt an Wählplänen schrauben darf. Wenn du deine Wählpläne einmal grundsätzlich aufräumen willst, unterstützen wir dich gern in einer Beratung zur Teams-Telefonie. Und wer die Regex-Logik lieber einmal gründlich in Ruhe lernen will, statt sie im Störungsfall zu üben, ist in der Schulung Teams-Telefonie richtig.

TIPP · Weniger Regeln sind mehr Der Service-Wählplan für Deutschland bringt bereits eigene Regeln mit. Prüfe mit Get-CsEffectiveTenantDialPlan und Test-CsEffectiveTenantDialPlan ohne -TenantScopeOnly, welche Schreibweisen schon ohne deine Regeln richtig normalisiert werden. Microsoft empfiehlt selbst, nur die Muster zu definieren, die der Landeswählplan nicht abdeckt. Jede Regel, die du nicht brauchst, kann auch keine Nummer verbiegen.

 

WEITERLESEN · Passend dazu › Notruf in Microsoft Teams konfigurieren › Wählplan mit Amtsholung 0 in Teams richtig bauen › Eingehende Anrufe kommen in Teams nicht an

 

FAQ

In welcher Reihenfolge prüft Teams die Normalisierungsregeln?

Von oben nach unten. Die erste Regel, deren Muster passt, wird angewendet, alle weiteren werden ignoriert. Regeln aus dem zugewiesenen Wählplan oder dem Global-Wählplan haben Vorrang vor den Regeln des Service-Wählplans des Landes.

Wie finde ich heraus, welche Normalisierungsregel bei einer Nummer greift?

Mit Test-CsEffectiveTenantDialPlan -Identity <UPN> -DialedNumber <Nummer>. Die Ausgabe zeigt die übersetzte Nummer (TranslatedNumber) und die Regel, die gegriffen hat (MatchingRule). Der Befehl baut keinen Anruf auf.

Darf ich mit Test-CsEffectiveTenantDialPlan auch 110 und 112 prüfen?

Ja. Das Cmdlet wendet nur die Regeln auf die Nummer an, es wird nichts gewählt. Damit ist es der sicherste Weg, nach einer Änderung zu prüfen, dass die Notrufnummern unverändert bleiben.

Wie viele Normalisierungsregeln darf ein Wählplan haben?

Laut Microsoft höchstens 50 pro Wählplan. Wer an diese Grenze stößt, sollte eher die Struktur überdenken als die Regeln zusammenquetschen.

Was bewirkt IsInternalExtension in Teams?

Laut Dokumentation kennzeichnet das Flag ein Ergebnis als interne Nummer, wird aber ignoriert, wenn OptimizeDeviceDialing auf False steht. Diesen Parameter gibt es in den aktuellen Teams-Cmdlets nicht mehr. Ob ein Anruf intern ankommt, hängt davon ab, ob die normalisierte Nummer im Tenant vergeben ist.

Warum soll jede Regel ein Ergebnis mit + liefern?

Weil der Dienst Nummern ohne + erneut mit Tenant- und Landesregeln normalisiert. Microsoft empfiehlt, dass alle Regeln ein Ergebnis mit + erzeugen. Braucht dein SBC oder Provider ein anderes Format, gehört die Anpassung in die Übersetzungsregeln am Trunk oder in den SBC, nicht in den Wählplan.

Ich habe den Wählplan korrigiert, aber der Anwender hat noch das alte Verhalten. Warum?

Der Client erhält seinen Wählplan über die Bereitstellung bei der Anmeldung. Prüfe mit Test-CsEffectiveTenantDialPlan, ob die Änderung im Dienst angekommen ist, und lass den Anwender sich im Client ab- und wieder anmelden, bevor du weitersuchst.

Fazit: erst testen, dann suchen

Normalisierungsregeln scheitern selten an Raketenwissenschaft. Sie scheitern an Reihenfolge, Gier, fehlenden Ankern, einem vergessenen Plus und Durchwahlen, die sich mit 110 und 112 in die Quere kommen. Das Gute daran: Jeder dieser Fehler ist mit Test-CsEffectiveTenantDialPlan in Sekunden sichtbar, ohne dass ein einziges Telefon klingelt.

Gewöhn dir an, bei jedem Problem mit abgehenden Anrufen zuerst die Normalisierung zu prüfen, mit dem echten Benutzer und der Nummer so, wie er sie tippt. Halte eine Prüftabelle pro Standort bereit, sichere vor jeder Änderung und teste danach immer auch die Notrufnummern. Dann klingelt beim Notruf wieder die Leitstelle und nicht die Kantine. Die hat ohnehin schon genug zu tun.