Notrufadresse fehlt in Teams: was bei 112 wirklich passiert

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Du willst wissen, ob deine Notrufkonfiguration zu Standorten, Rufnummern und Vertrag passt? Wir prüfen das mit dir. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Notrufstandorte, LIS und Notruf-Routing selbst sicher pflegen und prüfen wollen. › Schulung Teams-Telefonie

 

Eine fehlende Notrufadresse ist der höflichste Fehler in der ganzen Teams-Telefonie. Er meldet sich nicht. Kein Ticket, keine Beschwerde, kein rotes Symbol im Client. Telefonieren geht, Meetings gehen, die Warteschlange tut, was sie soll. Der Fehler wartet geduldig auf genau den einen Anruf, bei dem es auf jede Minute ankommt. Und dann stellt er sich vor.

In diesem Beitrag geht es um genau diesen Fall: Teams Notrufadresse fehlt, ist dem falschen Benutzer zugewiesen oder wurde nie validiert. Du erfährst, was beim Wählen von 112 technisch passiert, was die Leitstelle in diesem Moment tatsächlich sieht, wie du die Lücken mit dem Teams Admin Center und lesenden PowerShell-Befehlen findest und wie du sie schließt, ohne dir Neues einzubauen. Die Grundlagen der Konfiguration stehen in Notruf in Microsoft Teams konfigurieren; hier geht es um die Fehlersuche. Der Beitrag gehört zur Serie rund um die Teams-Telefonie.

FAKTEN · Kurz gesagt Teams kennt drei Stellen, an denen eine Notrufadresse hängen kann: an der Rufnummer des Benutzers (registrierte Adresse), an Netzwerkkennungen wie Subnetzen, WLAN-Zugangspunkten und Switches im Location Information Service (dynamischer Standort) und, nur bei Direct Routing, im Notruf-Routing über eine Emergency Call Routing Policy. Fehlt sie an allen Stellen, wählt Teams trotzdem 112. Nur weiß dann niemand verlässlich, wo du bist. Für Calling Plans in Deutschland dokumentiert Microsoft: Die zur Rufnummer registrierte Adresse liegt in einer nationalen Notrufdatenbank, die Leitstelle schlägt sie anhand der übermittelten Rufnummer nach. Bei Direct Routing entscheidet in Deutschland dein Netzbetreiber, was die Leitstelle zu sehen bekommt.

 

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com) mit Zentrale in Frankfurt und Standorten in Köln, Berlin, Hamburg und München. Direct Routing über sbc1.contoso.com und sbc2.contoso.com, Rufnummern im Muster +49 69 555 0100. Hamburg ist vor einem Jahr dazugekommen, und genau dort fehlt die Notrufadresse.

 

Das Symptom: Es gibt keins, bis jemand 112 wählt

So erleben es Anwender

Anwender bemerken eine fehlende Notrufadresse im Alltag praktisch nie. Wenn überhaupt, fällt sie in Situationen auf, die niemand gern im Ticketsystem nachliest:

„Der Sicherheitsdienst hat eine Benachrichtigung bekommen, aber da stand kein Standort drin.“

„Die Leitstelle hat dreimal gefragt, ob wir wirklich in Hamburg sind. Auf ihrem Schirm stand Frankfurt.“

„Bei der Brandschutzübung hat jemand gefragt, welche Adresse Teams eigentlich durchgibt. Keiner wusste es.“

„Im Homeoffice hat Teams mich gefragt, ob ich meinen Standort freigeben will. Ich habe auf Nein geklickt.“

So erleben es Admins

Admins stoßen meist bei einer Prüfung, einem Audit oder einer Migration auf das Thema. Typische Sätze in der Teambesprechung:

„Hamburg haben wir als Netzwerkstandort angelegt, das reicht doch?“ (Nein, das ist ein anderes Ding.)

„Die Adresse ist da, ich kann sie aber im Admin Center keinem Benutzer zuweisen.“ (Nicht validiert.)

„Die Adresse stimmt nicht mehr, ich ändere schnell die Hausnummer.“ (Geht bei validierten Adressen nicht.)

„Bei Direct Routing braucht man keine Notrufadresse, das macht der Carrier.“ (Halb richtig, also gefährlich.)

WARNUNG · Kein Fehler, den du durch Probieren findest Wähle zum Testen nie einfach 112. Ein Notruf ohne Notfall bindet die Leitstelle, und je nach Konfiguration alarmiert er auch deinen Sicherheitsdienst. Wie du Notrufe kontrolliert prüfst, steht in Notruf in Teams testen, ohne die Leitstelle zu verärgern. Für die Diagnose in diesem Beitrag brauchst du keinen einzigen Testanruf.

 

Damit klar ist, worüber wir reden: Es gibt drei Varianten von „Notrufadresse fehlt“, die sich in Ursache und Prüfweg unterscheiden.

Variante	Was fehlt	Wo du es siehst	Typische Ursache
Standort ohne Adresse	Netzwerkkennung im LIS (Subnetz, WAP, Switch, Port) mit Notrufstandort	Admin Center: Standorte › Netzwerke und Standorte; Get-CsOnlineLisSubnet	Neuer Standort nur als Netzwerkstandort angelegt, LIS vergessen
Benutzer ohne Adresse	Notrufstandort an der Rufnummer	Admin Center: Benutzer bzw. Telefonnummern; Get-CsPhoneNumberAssignment	Direct-Routing-Nummer per Skript vergeben, Standort optional und deshalb weggelassen
Adresse nicht validiert	Gültige, geocodierte Adresse	Admin Center: Standorte › Notfalladressen; Get-CsOnlineLisLocation -ValidationStatus	Adresse von Hand oder per Skript ohne Kartenabgleich angelegt

 

Wie der Fehler technisch zustande kommt

Drei Orte für eine Adresse

Microsoft trennt sauber zwischen Begriffen, die im Alltag gern durcheinandergehen. Die Notrufadresse (emergency address) ist die Postanschrift eines Gebäudes. Ein Ort (place) verfeinert sie, etwa um Etage oder Gebäudeteil. Aus Adresse und optionalem Ort entsteht ein Notrufstandort mit eigener LocationId. Diese LocationId hängst du an eine Rufnummer, dann ist sie die registrierte Adresse des Benutzers. Oder du hängst sie an eine Netzwerkkennung im Location Information Service (LIS), dann bekommt der Client sie dynamisch, sobald er sich in diesem Netz meldet.

Beim dynamischen Abgleich prüft der Client in einer festen Reihenfolge und nimmt den ersten Treffer: WLAN-Zugangspunkt, Switch mit Port, Switch, Subnetz. Findet er nichts, gibt es keinen dynamischen Standort. Wichtig: Ein Netzwerkstandort für Routing, Media Bypass oder Richtlinien ist nicht dasselbe wie ein Subnetz im LIS. Microsoft schreibt ausdrücklich, dass du Subnetze aus Netzwerkstandorten im LIS noch einmal definieren musst, damit sie einen Notrufstandort liefern. Wie du Netzwerkstandorte sauber pflegst, steht in Netzwerkstandorte und Subnetze in Teams richtig pflegen.

Die Kette beim Wählen von 112

Bei Calling Plans und Operator Connect ist die Kette kurz: Benutzer › Rufnummer › hinterlegte Adresse › Netz › Leitstelle. Bei Direct Routing ist sie länger, weil du selbst routest: Benutzer › Emergency Call Routing Policy (vom Netzwerkstandort oder vom Benutzer) › Notrufnummer › PSTN Usage › Voice Route › SBC › Netzbetreiber › Leitstelle. Die Notrufadresse aus Teams läuft dabei nur bis zum SBC mit, und auch das nur, wenn das Gateway für PIDF-LO freigeschaltet ist. Dann steckt der Standort als zusätzlicher Teil im SIP-INVITE.

FAKTEN · Was Microsoft zu Deutschland dokumentiert Calling Plans: Für Deutschland beschreibt Microsoft, dass Notrufe von der Adresse des Anrufers abhängen. Die zur Rufnummer registrierte Adresse liegt in einer nationalen Notrufdatenbank, die Leitstelle schlägt sie anhand der Rufnummer nach und zeigt sie an. Außerhalb von USA und Kanada wird ein Notrufstandort fällig, wenn du die Nummer von Microsoft beziehst oder portierst. Zur Aktivierung einer Nummer in Deutschland muss die Adresse zur Ortsvorwahl der Nummer passen. Direct Routing: Dynamisches Notruf-Routing anhand des Client-Standorts unterstützt Microsoft nur in den USA (und mit Einschränkungen in Kanada). In Deutschland bleibt das Routing zur Leitstelle Sache deines Netzbetreibers. Ohne Emergency Call Routing Policy ist ein Direct-Routing-Benutzer laut Microsoft gar nicht für Notrufe aktiviert.

 

Die Details zu den Verbindungsarten findest du bei Microsoft unter Überlegungen zu Anrufplänen und Überlegungen zu Direct Routing.

Wer welche Adresse wofür nutzt

Anbindung	Registrierte Adresse an der Rufnummer	Dynamischer Standort (LIS)	Was die Leitstelle in Deutschland sieht
Calling Plan	Pflicht; ohne passende Adresse keine Aktivierung	Für Sicherheitsdienst-Benachrichtigung; Routing in DE nicht dynamisch	Adresse aus der Notrufdatenbank zur übermittelten Rufnummer
Operator Connect	Abhängig vom Operator und den Fähigkeiten der Nummer	Wie Calling Plan; Weitergabe regelt der Operator	Was der Operator zur Rufnummer hinterlegt hat
Direct Routing	Optional, wird aber für Benachrichtigung und Anzeige genutzt	Geht per PIDF-LO an den SBC, wenn freigeschaltet	Was dein Netzbetreiber zur Rufnummer bzw. zum Anschluss kennt

 

WICHTIG · „Optional“ heißt nicht „egal“ Dass Microsoft den Notrufstandort bei Direct Routing als optional bezeichnet, bedeutet nur, dass die Nummernzuweisung ohne ihn technisch klappt. Ohne Standort fehlt der Benachrichtigung an den Sicherheitsdienst die Ortsangabe, der SBC bekommt kein PIDF-LO, und du hast nichts, womit du die Daten beim Netzbetreiber abgleichen kannst.

 

Was die Leitstelle dann wirklich sieht

Jetzt der Teil, um den es im Titel geht. Die Leitstelle sieht keine Teams-Oberfläche, keinen Benutzer-Steckbrief und keine LocationId. Sie sieht, was über das öffentliche Netz bei ihr ankommt: die Rufnummer und die Daten, die der Netzbetreiber dieser Rufnummer oder diesem Anschluss zuordnet. Daraus ergeben sich drei typische Bilder.

Situation	Was ankommt	Was die Leitstelle daraus macht
Calling Plan, Adresse korrekt	Rufnummer, Adresse aus der Notrufdatenbank	Richtiger Ort auf dem Schirm, Rückfrage zur Bestätigung
Calling Plan, Benutzer umgezogen, Adresse alt	Rufnummer, alte Adresse	Fährt im Zweifel zur alten Adresse, wenn der Anrufer nicht widerspricht
Direct Routing, Hamburger Benutzer sendet Frankfurter Zentrale	+49 69 555 0100, Anschluss Frankfurt	Leitstelle in Frankfurt nimmt an, sieht Frankfurt, muss den echten Ort erfragen
Direct Routing, Homeoffice in Köln, Firmennummer Frankfurt	Firmennummer, Firmenanschluss	Sieht die Firma, nicht die Wohnung; der Ort hängt am Gespräch
Direct Routing, keine Notrufroute	Nichts	Gar nichts. Der Anruf scheitert, bevor er das Netz erreicht

 

Die vierte Zeile ist der Klassiker der letzten Jahre. Wer im Homeoffice mit Teams 112 wählt, telefoniert über einen Anschluss, der in der Firma steht. Ohne dynamischen Standort, den der Netzbetreiber auswertet, landet der Notruf im Zweifel bei der Leitstelle, die für den Firmensitz zuständig ist. Das ist kein Teams-Fehler, das ist Physik mit Rufnummern. Aber es ist dein Job, es zu wissen und die Belegschaft darauf hinzuweisen. Die Rufnummer, die nach außen geht, bestimmen deine Caller-ID-Richtlinie und der SBC; mehr dazu in Rufnummernanzeige in Teams falsch: CLIP, Caller ID Policy und SBC.

AUS DER PRAXIS · Ein Maschinenbauer mit zwölf Standorten Alle Standorte telefonierten über zwei zentrale SBCs, nach außen ging aus Gründen der Einheitlichkeit überall die Zentralnummer. Notrufadressen gab es in Teams für zwei Werke, die anderen zehn hatten Netzwerkstandorte, aber kein LIS. Bei einer Brandschutzbegehung fragte der Sicherheitsbeauftragte, welche Leitstelle eigentlich abnimmt, wenn jemand im Werk 9 die 112 wählt. Antwort nach zwei Tagen Recherche beim Netzbetreiber: die am Firmensitz, 140 Kilometer entfernt. Gelöst wurde es nicht in Teams allein, sondern mit Standortrufnummern je Werk für Notrufe und einer Abstimmung mit dem Netzbetreiber, welche Anschlussadresse zu welcher Rufnummer gehört.

 

Verantwortung des Betreibers, sachlich betrachtet

Wer eine Telefonanlage betreibt, und Teams mit Direct Routing ist genau das, trägt Verantwortung dafür, dass Notrufe funktionieren und möglichst gut zugeordnet werden können. Microsoft regelt in den eigenen Bedingungen für Notrufe, was Microsoft leistet und was nicht; beim Direct Routing liegt ein großer Teil der Kette ohnehin bei dir und deinem Netzbetreiber. Welche Pflichten im Einzelnen gelten, hängt von Anbindung, Vertrag und Rechtslage ab und gehört in die Hände deiner Rechtsabteilung oder des Datenschutz- und Arbeitsschutzverantwortlichen. Dieser Beitrag ist keine Rechtsberatung.

Technisch lässt sich die Verantwortung aber gut in Fragen fassen, die du beantworten können solltest:

Erreichbarkeit: Kommt ein Notruf von jedem Standort und jedem Client überhaupt raus?

Zuordnung: Welche Adresse sieht die Leitstelle für die Rufnummer, die bei einem Notruf gesendet wird?

Aktualität: Wer pflegt Adressen nach, wenn ein Standort umzieht, ein Stockwerk dazukommt oder ein Werk schließt?

Information: Weiß die Belegschaft, dass im Homeoffice oder über VPN der Standort nicht automatisch stimmt, und dass sie ihn am Telefon nennen muss?

Nachweis: Kannst du zeigen, wann du das zuletzt geprüft hast?

Diagnose Schritt für Schritt

Alle Befehle in diesem Abschnitt lesen nur. Du brauchst das MicrosoftTeams-Modul in einer aktuellen Version und eine Rolle, die Sprachkonfiguration lesen darf, etwa Teams-Kommunikationsadministrator. Im Teams Admin Center findest du die Notrufthemen unter Standorte (Locations).

Schritt 1: Adressen vorhanden und validiert?

Im Teams Admin Center öffnest du Standorte › Notfalladressen (Locations › Emergency addresses). Dort siehst du jede Adresse mit Beschreibung und Status. Eine Adresse, die du über die Kartensuche angelegt hast, ist automatisch validiert und hat einen Geocode. Eine Adresse ohne Geocode kannst du keiner Netzwerkkennung zuweisen, eine nicht validierte gar nichts.

Connect-MicrosoftTeams   # Alle Notrufadressen mit Prüfstatus und Geocode Get-CsOnlineLisCivicAddress | Select-Object Description, CompanyName, StreetName, HouseNumber, PostalCode, City, CountryOrRegion, ValidationStatus, Latitude, Longitude, CivicAddressId | Sort-Object City | Format-Table -AutoSize   # Nur Adressen, die nicht validiert sind Get-CsOnlineLisCivicAddress | Where-Object ValidationStatus -ne 'Validated'

 

Bei Contoso fällt auf: Hamburg fehlt in der Liste komplett, und die Kölner Adresse steht auf NotValidated, Breiten- und Längengrad sind leer. Jemand hat sie vor Jahren per Skript angelegt.

Schritt 2: Standorte und ihre Nutzung mit Get-CsOnlineLisLocation

Get-CsOnlineLisLocation liefert die eigentlichen Notrufstandorte, also Adresse plus optionalen Ort, jeweils mit LocationId. Mit -ValidationStatus filterst du auf Validated, Invalid oder NotValidated. Die Schalter -PopulateNumberOfVoiceUsers und -PopulateNumberOfTelephoneNumbers zählen, wie viele Benutzer und Rufnummern an einem Standort hängen. Das ist die schnellste Antwort auf die Frage, ob ein Standort zwar existiert, aber niemand ihn nutzt.

# Standorte mit Zählung von Benutzern und Rufnummern Get-CsOnlineLisLocation -PopulateNumberOfVoiceUsers -PopulateNumberOfTelephoneNumbers | Select-Object LocationId, Description, Location, City, ValidationStatus, NumberOfVoiceUsers, NumberOfTelephoneNumbers | Format-Table -AutoSize   # Nicht validierte Standorte Get-CsOnlineLisLocation -ValidationStatus NotValidated   # Seit Modulversion 8.0.0 auch mit Filter, etwa alle deutschen Standorte Get-CsOnlineLisLocation -Filter "CountryOrRegion -eq 'DE'"

 

TIPP · Standorte mit null Benutzern sind verdächtig Ein Standort mit gültiger Adresse und NumberOfVoiceUsers 0 ist selten gewollt. Meist hat jemand die Adresse angelegt und die Zuweisung vergessen, oder die Benutzer hängen an einem Doppelgänger mit leicht anderer Schreibweise. Vergleiche Beschreibungen und Postleitzahlen, bevor du etwas löschst.

 

Schritt 3: Rufnummern ohne Notrufstandort finden

Im Admin Center siehst du den Notrufstandort je Benutzer unter Benutzer › Benutzer verwalten im Konto des Benutzers bzw. bei Calling-Plan- und Operator-Connect-Nummern unter Sprache › Telefonnummern. Für einen Überblick über alle Nummern ist PowerShell bequemer. Get-CsPhoneNumberAssignment zeigt zu jeder Nummer die LocationId; bei Direct-Routing-Nummern ohne Standort steht dort eine Null-GUID.

$leer = '00000000-0000-0000-0000-000000000000'   # Zugewiesene Nummern ohne Notrufstandort (Seitenweise, max. 1000 je Abruf) $skip = 0; $alle = @() do { $seite = Get-CsPhoneNumberAssignment -PstnAssignmentStatus UserAssigned -Skip $skip -Top 1000 $alle += $seite; $skip += 1000 } while ($seite.Count -eq 1000)   $alle | Where-Object { -not $_.LocationId -or $_.LocationId -eq $leer } | Select-Object TelephoneNumber, NumberType, AssignedPstnTargetId | Export-Csv .\nummern-ohne-notrufstandort.csv -NoTypeInformation -Encoding UTF8   # Gegenprobe: Nummern, deren Standort zu einer Stadt gehört Get-CsPhoneNumberAssignment -LocationId <LocationId-Frankfurt> | Select-Object TelephoneNumber

 

Bei Contoso liefert die Liste 35 Hamburger Nummern ohne Standort und, überraschender, zwölf Kölner Nummern, die auf den Frankfurter Standort zeigen. Das waren Benutzer, die nach Köln gewechselt sind und ihre Rufnummer mitgenommen haben, aber nicht ihren Notrufstandort angepasst bekamen.

Schritt 4: Netzwerkkennungen im LIS prüfen

Für den dynamischen Standort zählt, was im LIS steht, nicht was in den Netzwerkeinstellungen steht. Im Admin Center findest du beides unter Standorte › Netzwerke und Standorte (Networks & locations), das LIS in den Reitern Subnetze, WLAN-Zugangspunkte, Switches und Ports. Vergleiche die Subnetze der Netzwerkstandorte mit den Subnetzen im LIS.

# Subnetze im LIS mit zugeordnetem Standort $lis = Get-CsOnlineLisSubnet | Select-Object Subnet, LocationId, Description   # Subnetze der Netzwerkstandorte $net = Get-CsTenantNetworkSubnet | Select-Object SubnetID, MaskBits, NetworkSiteID   # Subnetze, die nur als Netzwerkstandort existieren, nicht im LIS $net | Where-Object { $_.SubnetID -notin $lis.Subnet } | Format-Table   # LIS-Einträge, deren LocationId auf keinen existierenden Standort zeigt $ids = (Get-CsOnlineLisLocation).LocationId $lis | Where-Object { $_.LocationId -notin $ids }   # Weitere Kennungen Get-CsOnlineLisWirelessAccessPoint; Get-CsOnlineLisSwitch; Get-CsOnlineLisPort

 

WARNUNG · Subnetz-ID ist die Netzadresse, nicht irgendeine Adresse Der LIS berechnet die Netzwerk-ID aus der IP-Adresse des Clients und der gemeldeten Präfixlänge. Ein Client mit 10.50.12.34/16 ergibt 10.50.0.0, und genau das muss als Subnetz im LIS stehen. Bei IPv6 mit DHCPv6 meldet Windows unter Umständen /128, dann passt kein /64-Eintrag. Microsoft empfiehlt dafür das IPv4-Subnetz oder Switch- und WLAN-Kennungen statt Einträgen je Gerät. Den dynamischen Fall behandelt Dynamischer Notruf in Teams funktioniert nicht ausführlich.

 

Schritt 5: Notruf-Routing bei Direct Routing

Bei Direct Routing kann der Notruf an einer ganz anderen Stelle scheitern als an der Adresse. Prüfe die Kette Emergency Call Routing Policy › PSTN Usage › Voice Route › SBC. Teams stellt Notrufnummern kein Pluszeichen mehr voran, die Route muss also auf 112 und 110 ohne + passen.

# Notrufnummern und Usages je Policy Get-CsTeamsEmergencyCallRoutingPolicy | ForEach-Object { $p = $_.Identity $_.EmergencyNumbers | Select-Object @{n='Policy';e={$p}}, EmergencyDialString, EmergencyDialMask, OnlinePSTNUsage } | Format-Table -AutoSize   # Welche Policy hat ein Benutzer, welche ein Netzwerkstandort? Get-CsUserPolicyAssignment -Identity anna.schmidt@contoso.com -PolicyType TeamsEmergencyCallRoutingPolicy Get-CsTenantNetworkSite | Select-Object Identity, EmergencyCallRoutingPolicy, EmergencyCallingPolicy   # Voice Routes für Notrufnummern Get-CsOnlineVoiceRoute | Where-Object NumberPattern -match '11[02]' | Select-Object Identity, NumberPattern, OnlinePstnUsages, OnlinePstnGatewayList, Priority   # Geht der Standort per PIDF-LO an den SBC? Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, PidfloSupported

 

Eine passende Route sieht bei Contoso so aus: Muster ^(110|112)$, Usage DE-Notruf, Gateways sbc1.contoso.com und sbc2.contoso.com. Das Muster ist absichtlich eng. Ein lockeres ^11 würde auch die 116 117 und alle anderen 11er-Nummern einsammeln. Warum eine Route trotz richtigem Muster nicht greift, steht in Teams Voice Route greift nicht: Regex, Priorität und überdeckte Routen.

FAKTEN · Policy am Standort schlägt Policy am Benutzer Meldet sich ein Client an einem Netzwerkstandort mit eigener Emergency Call Routing Policy, gilt diese. Hat der Standort keine, ist der Client in einem unbekannten Netz oder passt die gewählte Nummer auf keine Notrufnummer der Standort-Policy, gilt die Policy des Benutzers. Bekommt der Client gar keine, ist der Benutzer laut Microsoft nicht für Notrufe aktiviert.

 

Schritt 6: Was weiß der Netzbetreiber?

Der letzte Schritt hat kein Cmdlet. Bei Direct Routing musst du wissen, welche Adresse dein Netzbetreiber zu welchem Rufnummernblock und Anschluss hinterlegt hat, wie er Notrufe zuordnet und ob er einen Standort aus dem SIP-INVITE überhaupt auswertet. Die Antwort steht in der Leistungsbeschreibung oder kommt vom Support, nicht aus deinem Tenant.

AUS DER PRAXIS · Uli und sein eigener anynode-SBC Als ich am eigenen anynode-SBC die PIDF-LO-Unterstützung für das Gateway eingeschaltet habe, war der Unterschied im SIP-Trace sofort zu sehen: Der INVITE für einen Notruf kam als mehrteilige Nachricht an, mit SDP und einem zweiten Teil, der den Standort aus dem LIS enthält. Spannend war die nächste Frage: Was macht der SIP-Trunk-Anbieter dahinter damit? Die ehrliche Antwort stand in seiner Leistungsbeschreibung, und die sprach von Rufnummer und Anschlussadresse. Seitdem prüfe ich beides: dass Teams den Standort mitschickt, und dass beim Anbieter die richtige Adresse zur Nummer steht.

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Der Teams-Telefonie Diagnostiker liest die Notrufkonfiguration im Nur-Lese-Modus aus und legt Befunde mit Prüffall an, etwa für einen Netzwerkstandort ohne Notrufadresse, für Benutzer ohne ermittelbaren Notrufstandort oder für nicht validierte Adressen. Die Ampel zeigt, in welchem Bereich die Befunde liegen. Im Benutzer-Steckbrief siehst du für einen einzelnen Benutzer den Notrufstandort neben Rufnummer, Lizenzen und effektiven Richtlinien. Im Bericht werden Notruf-Befunde eigens hervorgehoben, damit sie zwischen Wählplan- und Routing-Themen nicht untergehen. Das hilft, wenn du das Ergebnis an Sicherheitsbeauftragte oder die Geschäftsführung weitergeben musst. Mehr dazu auf der Produktseite Teams-Telefonie Diagnostiker. 15 Tage kostenlos testen.

 

Behebung: Adressen anlegen, zuweisen, Netze nachtragen

Die Reihenfolge ist wichtig, weil Teams manche Fehler nicht mehr verzeiht, sobald sie validiert sind. Erst Adresse, dann Orte, dann Zuweisung an Nummern, dann Netzwerkkennungen, dann Routing.

Variante 1: Adresse fehlt oder ist nicht validiert

Adresse über die Kartensuche anlegen: Admin Center › Standorte › Notfalladressen › Hinzufügen. Name und Beschreibung, Land Deutschland, Adresse eintippen und aus der Kartensuche übernehmen. So ist sie validiert und hat einen Geocode. Manuelles Bearbeiten nur, wenn die Karte die Adresse wirklich nicht kennt, dann mit Stecknadel.

Firmenname prüfen: Für Calling Plans verlangt Microsoft unter anderem Hausnummer, Straße, Ort, Postleitzahl, Breiten- und Längengrad und den Firmennamen.

Orte ergänzen: Etage oder Gebäudeteil als Ort anlegen, wenn das Gebäude groß ist. Jeder Ort bekommt eine eigene LocationId.

Alte Adresse ersetzen: Eine validierte Adresse kannst du nicht einfach umschreiben. Neue Adresse anlegen, Nummern und Netzwerkkennungen umhängen, alte Adresse erst danach löschen.

WARNUNG · Rollback bei Adressen Löschen geht nur, wenn kein Benutzer und keine Rufnummer mehr an der Adresse hängt. Das ist eine gute Bremse. Exportiere vor jeder Änderung den Ist-Zustand mit Get-CsOnlineLisCivicAddress, Get-CsOnlineLisLocation, Get-CsOnlineLisSubnet und Get-CsPhoneNumberAssignment in CSV-Dateien. Dann weißt du hinterher, welche Nummer vorher an welcher LocationId hing, und kannst sie zurückhängen.

 

Variante 2: Benutzer ohne Adresse

Im Admin Center weist du den Standort bei Direct Routing unter Benutzer › Benutzer verwalten › Konto › Allgemeine Informationen › Bearbeiten im Feld Notfallstandort zu, bei Calling Plan und Operator Connect unter Sprache › Telefonnummern. Standort, Benutzer und Rufnummer müssen im selben Land liegen. Für viele Nummern nimmst du Set-CsPhoneNumberAssignment mit -LocationId; teste das vorher an einer Nummer und prüfe das Ergebnis mit Get-CsPhoneNumberAssignment.

# Schreibend, erst nach Export und Test an einer Nummer: Set-CsPhoneNumberAssignment -Identity jan.krause@contoso.com ` -PhoneNumber '+49405550123' -PhoneNumberType DirectRouting -LocationId <LocationId-Hamburg>   # Kontrolle Get-CsPhoneNumberAssignment -TelephoneNumber '+49405550123' | Select-Object TelephoneNumber, LocationId

 

Rollback: dieselbe Zuweisung mit der vorherigen LocationId aus deinem Export. Bei Calling-Plan-Nummern in Deutschland gilt zusätzlich: Die Adresse muss zur Ortsvorwahl der Nummer passen. Eine Frankfurter Nummer bekommt also keine Hamburger Adresse, wer dauerhaft umzieht, braucht in der Regel eine Nummer aus dem neuen Ortsnetz.

Variante 3: Standort ohne Adresse im LIS

Trage die Subnetze, WLAN-Zugangspunkte oder Switches des Standorts im Admin Center unter Standorte › Netzwerke und Standorte ein, einzeln oder per CSV-Vorlage, jeweils mit dem passenden Notrufstandort. Per PowerShell geht das mit Set-CsOnlineLisSubnet. Microsoft nennt bis zu vier Stunden, bis neue Netzwerkkennungen bei den Clients ankommen; erwarte also keinen sofortigen Effekt.

Rollback für LIS-Einträge: Remove-CsOnlineLisSubnet für neu angelegte Subnetze bzw. erneutes Set-CsOnlineLisSubnet mit der alten LocationId aus deinem Export. Danach gilt wieder: bis zu vier Stunden Geduld.

Und bei Direct Routing: Notrufroute und Netzbetreiber

Policy zuweisen: Jeder Direct-Routing-Benutzer braucht eine Emergency Call Routing Policy, per Benutzer oder per Netzwerkstandort. Notrufnummern 112 und 110 eintragen, jeweils mit PSTN Usage.

Route prüfen: Voice Route mit ^(110|112)$ auf die Notruf-Usage, mindestens zwei SBCs.

PIDF-LO einschalten, wenn der SBC es kann: Admin Center › Sprache › Direct Routing › SBC › Bearbeiten, Option für PIDF/LO bei Notrufen. Vorher klären, ob der SBC damit umgehen kann.

Rufnummer für Notrufe festlegen: Bei zentralen Anschlüssen mit dem Netzbetreiber klären, welche Rufnummer und Adresse bei Notrufen aus welchem Standort ankommen sollen. Das ist Konzeptarbeit, kein Schalter. Der Aufbau des SBC selbst steht in

TIPP · Erst messen, dann glauben Nach der Behebung prüfst du nicht mit 112, sondern mit den Befehlen aus der Diagnose und, wo der Netzbetreiber es anbietet, mit einem abgestimmten Testverfahren. Wie das ohne Ärger geht, beschreibt Notruf in Teams testen, ohne die Leitstelle zu verärgern.

 

Vorbeugung: Notrufadressen gehören in jeden Prozess, der Menschen oder Netze bewegt

Notrufadressen verfallen nicht, aber sie veralten. Jeder Umzug, jede Etage, jedes neue Subnetz und jeder Wechsel eines Mitarbeiters an einen anderen Standort ist eine Gelegenheit, dass Teams und Wirklichkeit auseinanderlaufen.

Anlass	Was du prüfst	Wer zuständig ist
Neuer Standort	Adresse validiert, Orte, LIS-Subnetze, Policy am Netzwerkstandort	Telefonie-Team mit Netzwerk-Team
Neue Rufnummer	LocationId gesetzt, passt zur Ortsvorwahl (Calling Plan)	Telefonie-Team
Umzug eines Benutzers	Notrufstandort an der Nummer, bei Calling Plan ggf. neue Nummer	Personalprozess löst Ticket aus
Neues Subnetz, neues WLAN	Eintrag im LIS mit Standort	Netzwerk-Team
Vertragswechsel beim Netzbetreiber	Anschlussadressen je Rufnummernblock	Einkauf mit Telefonie-Team
Quartalsweise	Diagnose-Befehle aus Schritt 1 bis 5, Ergebnis ablegen	Telefonie-Team

 

Damit der Quartalscheck nicht einschläft, hilft ein Vergleich mit dem letzten Stand: Was ist dazugekommen, was verschwunden, was hat jemand nebenbei geändert? Genau das beschreibt Konfigurationsdrift in der Teams-Telefonie erkennen. Und wer Notruf als festen Teil von Rollen, Freigaben und Dokumentation verankern will, findet den Rahmen in Microsoft Teams Telefonie-Governance.

WICHTIG · Die Belegschaft informieren Technik allein reicht nicht. Sag den Kolleginnen und Kollegen, dass Teams im Homeoffice oder über VPN den Standort nicht immer kennt und dass sie bei einem Notruf immer selbst sagen sollen, wo sie sind. Bei VPN ohne Split Tunneling sieht Teams oft nur die Firmen-IP, mehr dazu in Teams-Telefonie über VPN: Split Tunneling richtig einrichten.

 

WEITERLESEN · Passend dazu › Notruf in Microsoft Teams konfigurieren › Dynamischer Notruf in Teams funktioniert nicht › Notruf in Teams testen, ohne die Leitstelle zu verärgern › Netzwerkstandorte und Subnetze in Teams richtig pflegen › Rufnummernanzeige in Teams falsch: CLIP, Caller ID Policy und SBC

 

FAQ: Teams Notrufadresse fehlt

Kann ein Teams-Benutzer ohne Notrufadresse 112 wählen?

Bei Calling Plan und Operator Connect ja, die Benutzer sind automatisch für Notrufe aktiviert. Bei Direct Routing hängt es nicht an der Adresse, sondern an der Emergency Call Routing Policy und einer passenden Voice Route. Ohne Policy ist der Benutzer laut Microsoft nicht für Notrufe aktiviert.

Sieht die Leitstelle die Adresse aus dem Teams Admin Center?

Nicht direkt. Bei Calling Plans in Deutschland sieht sie die Adresse, die zur Rufnummer in der nationalen Notrufdatenbank steht, und die stammt aus deiner Zuweisung. Bei Direct Routing sieht sie, was dein Netzbetreiber zur Rufnummer oder zum Anschluss hinterlegt hat.

Warum kann ich eine Adresse keinem Subnetz zuweisen?

Meist fehlt der Geocode oder die Adresse ist nicht validiert. Microsoft erlaubt für Netzwerkkennungen nur Adressen mit Geocode, und sehr alte Adressen musst du laut Microsoft neu anlegen. Lege die Adresse über die Kartensuche im Admin Center an.

Wie ändere ich eine validierte Adresse?

In der Regel gar nicht. Microsoft erlaubt Änderungen an der Anschrift nur, solange sie nicht validiert ist. Lege eine neue Adresse an, hänge Nummern und Netzwerkkennungen um und lösche die alte erst danach. Den Geocode kannst du mit Set-CsOnlineLisCivicAddress nachtragen.

Reicht ein Netzwerkstandort für den dynamischen Notruf?

Nein. Netzwerkstandorte liefern Richtlinien, etwa die Emergency Call Routing Policy. Den Standort liefert der LIS. Subnetze aus Netzwerkstandorten musst du im LIS noch einmal mit Notrufstandort anlegen.

Wie lange dauert es, bis eine Änderung im LIS wirkt?

Microsoft nennt bis zu vier Stunden, bis neue Netzwerkkennungen oder Adressen bei den Clients ankommen. Der Client fragt beim Start, regelmäßig und beim Netzwechsel nach.

Kann ich mit 933 testen wie in den USA?

Nein. Die Testnummer 933 ist für Calling Plan, Operator Connect und Teams Phone Mobile in den USA und Kanada dokumentiert. In Deutschland stimmst du Tests mit deinem Netzbetreiber ab und wählst nicht einfach 112.

Fazit: Der Fehler, der nie ein Ticket schreibt

Eine fehlende Notrufadresse kostet dich im Alltag nichts und im Ernstfall Zeit, die niemand hat. Die Prüfung dagegen kostet eine Stunde: Adressen und Validierung mit Get-CsOnlineLisCivicAddress und Get-CsOnlineLisLocation, Rufnummern ohne LocationId mit Get-CsPhoneNumberAssignment, LIS-Subnetze gegen Netzwerkstandorte, bei Direct Routing die Notrufroute und am Ende die eine Frage an den Netzbetreiber, welche Adresse er zu deiner Nummer kennt. Danach weißt du, was die Leitstelle sieht, statt es zu hoffen.

Wenn du die Notrufkonfiguration mit einem zweiten Blick absichern oder ein Konzept für Standorte, Rufnummern und Netzbetreiber aufsetzen willst, hilft dir die Beratung zur Teams-Telefonie. Und wer Notruf, LIS und Routing im Team selbst sicher beherrschen will, findet den Einstieg in der Schulung Teams-Telefonie.