Notruf in Teams: Dynamische Notfallanrufe richtig konfigurieren

In jedem Migrationsprojekt gibt es einen Punkt, an dem jemand sagt: „Den Notruf machen wir später.“ Dieser Artikel existiert, damit dieser Satz nie wieder unwidersprochen bleibt — denn der Notruf ist das eine Telefonie-Feature, dessen Versagen nicht mit einem Ticket endet, und die Teams-Welt bringt mit ihrer Ortsunabhängigkeit ein Problem mit, das die alte Anlage nie hatte: Die Rufnummer sagt nichts mehr darüber, wo ein Mensch gerade sitzt. Die Antwort heißt dynamische Notfallanrufe — Standortermittlung über Netzwerkmerkmale, konfiguriert statt gehofft. Hier steht, wie die Mechanik funktioniert, welche fünf Schritte zur Konfiguration gehören und wo die ehrlichen Grenzen im Homeoffice liegen.

Warum der Notruf kein „später“ verträgt

Das Szenario, für das dieses Kapitel geschrieben ist, dauert neunzig Sekunden: Ein Kollege kollabiert im zweiten Obergeschoss von Werk 2, die Kollegin daneben wählt die 112 aus dem Teams-Client — und jetzt entscheidet die Konfiguration, ob die Leitstelle „Musterstraße 12, Werk 2, Gebäude B, 2. OG“ sieht oder die Adresse der Firmenzentrale in einer anderen Stadt, weil dort der SIP-Trunk hängt. Die alte TK-Anlage hatte dieses Problem strukturell nicht: Die Nebenstelle steckte in einer Wand, die Wand stand in einem Gebäude, fertig. Teams-Nutzer stecken in gar nichts — derselbe Account telefoniert morgens am Hauptstandort, mittags im Zweigwerk und abends am Küchentisch, und ohne dynamische Standortermittlung wandert der Notruf-Standort nicht mit. Dazu kommt die Pflichtseite: Das Telekommunikationsrecht verlangt die Übermittlung von Standortdaten beim Notruf, und die betriebliche Fürsorgepflicht verlangt funktionierende Notfallprozesse — ein Konzept, das den Notruf auf „später“ verschiebt, verschiebt Haftungsfragen auf den Ernstfall. Deshalb gehört der Notruf in jedem Migrations-Phasenplan zu den Pilot-Pflichtkriterien: getestet vor dem ersten Rollout, nicht versprochen für danach.

Die Mechanik: Netzwerkmerkmale statt Nummernraterei

Die dynamische Standortermittlung beruht auf einer einfachen Beobachtung: Der Client weiß zwar nicht, wo er ist — aber er weiß, in welchem Netz er steckt, und das Netz steht still. Also pflegt der Administrator eine Standortdatenbank (Location Information Service), die Netzwerkmerkmale auf Notfallstandorte abbildet: Das Subnetz 10.20.3.0/24 ist Werk 2, Halle B, Erdgeschoss; die WLAN-BSSID des Access Points im dritten Stock ist Verwaltung, 3. OG; der Switch mit Port 14 ist der Empfang. Drei Merkmalstypen stehen zur Verfügung — Subnetze als gröbstes und wartungsärmstes Raster, WLAN-BSSIDs für die Funk-Ebene und Switch/Port-Informationen via LLDP für die feinste Auflösung bis zur Dose. Der Client gleicht seine aktuelle Netzsituation bei jeder Anmeldung und jedem Netzwechsel gegen diese Datenbank ab, zeigt den ermittelten Standort sichtbar an und gibt ihn im Notruffall mit auf die Reise. Das Prinzip dahinter verdient den einen Merksatz: Der Standort wandert mit dem Menschen, nicht mit der Nummer — vorausgesetzt, jemand hat der Datenbank beigebracht, welches Netz welches Gebäude ist.

Die Merkmal-Wahl: Subnetz reicht oft, Port kann mehr

Welche Merkmalstypen man pflegt, ist eine Abwägung zwischen Auflösung und Wartbarkeit. Subnetze sind der Sweet Spot für die meisten Häuser: Wo die Netzsegmentierung ohnehin je Gebäude oder Etage geschnitten ist, liefert die Subnetz-Zuordnung brauchbare Granularität bei minimaler Pflege — ein neues Subnetz pro Jahr ist schnell nachgetragen. WLAN-BSSIDs lohnen dort, wo per Funk gearbeitet wird und die Access-Point-Positionen feiner auflösen als die Subnetze — mit dem Pflege-Preis, dass AP-Tausch und -Umzug die Zuordnung berühren. Die Switch/Port-Ebene via LLDP ist die Königsklasse bis zur einzelnen Dose, sinnvoll für große Campusse mit eigenem Sicherheitsdienst — und ein Pflegeversprechen, das man halten können muss. Die Empfehlung für den Start: Subnetze flächendeckend, BSSIDs wo nötig, Ports nur mit gutem Grund — lieber ein gröberes Raster, das stimmt, als ein feines, das veraltet.

Skizze 1: Die Mechanik der dynamischen Standortermittlung — vom Netzwerkmerkmal zur Leitstelle.

Alt-Text-Vorschlag: Ablaufdiagramm der dynamischen Notfallanrufe: Der Client sieht Netzwerkmerkmale wie Subnetz, WLAN-BSSID und Switch mit Port via LLDP und gleicht sie mit der im Teams Admin Center gepflegten Standortdatenbank ab, die Merkmale auf Notfallstandorte abbildet. Der Treffer liefert eine validierte Adresse mit Ortsangaben wie Gebäude, Etage und Raum, die am Client sichtbar ist. Ein Notruf an 110 oder 112 geht mit dem ermittelten Standort zur Notrufleitstelle, damit die Hilfe zur richtigen Tür fährt. Der Client ermittelt den Standort bei jeder Anmeldung und jedem Netzwechsel neu — der Standort wandert mit dem Menschen, nicht mit der Nummer.

Der Konfigurationsüberblick: Fünf Schritte

Die Konfiguration ist kein Hexenwerk, aber sie ist Fleißarbeit mit Verantwortung — und sie folgt einer festen Reihenfolge. Schritt eins: Notfallstandorte anlegen — die validierten Adressen aller Standorte im Teams Admin Center, verfeinert um Ortsangaben (Gebäude, Etage, Flügel), und zwar so granular, wie ein Rettungsdienst es im Ernstfall braucht: „Werk 2“ hilft bei drei Hallen wenig. Schritt zwei ist die eigentliche Arbeit: Netzwerkmerkmale inventarisieren und zuordnen — alle Subnetze, relevanten BSSIDs und gegebenenfalls Switches samt Ports, abgeglichen mit der Realität statt nur mit der Netzwerk-Doku, denn die lügt bekanntlich mit derselben Zuverlässigkeit wie Anlagen-Konfigurationen. Schritt drei sind die Notfallrufrichtlinien: Wer im Haus erfährt, dass gerade ein Notruf abgesetzt wurde? Die Benachrichtigung an Empfang, Sicherheitsdienst oder Ersthelferkreis — als Hinweis oder mit Zuschaltmöglichkeit — sorgt dafür, dass dem Rettungsdienst jemand die Tür öffnet und zum Ort führt. Schritt vier ist die Anbindungsweg-Seite: Bei Direct Routing brauchen 110 und 112 eine eigene Voice Route im Routing-Modell, und der Trunk-Provider muss Notrufe mit dynamisch übermitteltem Standort unterstützen — eines der harten Kriterien aus der SIP-Trunk-Auswahl; bei Operator Connect und Calling Plan liegt die Amtsseite beim Carrier beziehungsweise Microsoft, geprüft gehört sie trotzdem. Und Schritt fünf ist der kontrollierte Test.

Skizze 2: Die fünf Konfigurationsschritte — von den Notfallstandorten bis zum kontrollierten Test.

Alt-Text-Vorschlag: Fünf-Schritte-Übersicht der Notruf-Konfiguration: Erstens Notfallstandorte mit validierten Adressen und Ortsangaben wie Gebäude und Etage im Teams Admin Center anlegen. Zweitens Netzwerkmerkmale wie Subnetze, WLAN-BSSIDs und Switches mit Ports inventarisieren und den Standorten zuordnen. Drittens Notfallrufrichtlinien konfigurieren, die Empfang, Sicherheitsdienst oder Ersthelfer bei einem Notruf benachrichtigen. Viertens den Anbindungsweg notruffähig machen — bei Direct Routing mit einer Voice Route für 110 und 112 und einem Provider, der Notruf mit dynamischem Standort unterstützt. Fünftens kontrolliert testen: Standortanzeige und Benachrichtigungen prüfen, echte Notruftests nur über das abgestimmte Testverfahren des Providers, niemals unangekündigt.

Homeoffice und unterwegs: Die ehrlichen Grenzen der Nomadik

Außerhalb des Firmennetzes wechselt die Mechanik den Modus. Meldet sich der Client in einem unbekannten Netz an — dem heimischen WLAN, dem Hotel, dem Coworking-Space —, fragt er den Nutzer nach der aktuellen Adresse; die wird gespeichert, dem Netz zugeordnet und beim nächsten Mal wiedererkannt, sodass die Abfrage pro Ort nur einmal nervt. Das funktioniert — aber es funktioniert genau so gut wie die Disziplin der Nutzer, die Abfrage ernst zu nehmen statt wegzuklicken, und diese Abhängigkeit gehört offen kommuniziert statt verschwiegen: Die Adresspflege im Homeoffice ist Teil der Nutzer-Einweisung, mit dem einen Satz, der hängen bleibt: „Diese Adresse ist das, was der Rettungsdienst sieht, wenn dir zuhause etwas passiert.“ Auf Smartphones ist die Lage entspannter: Die Teams-App reicht Notrufe an die native Telefonfunktion des Geräts weiter — der Notruf läuft als regulärer Mobilfunk-Notruf mit der Geräte-Ortung des Mobilfunknetzes, dem etabliertesten Notrufweg überhaupt. Für die Konzeption heißt das: Das Firmennetz löst die Standortfrage administrativ, das Homeoffice löst sie mit Nutzer-Mitwirkung, und mobil gewinnt das Mobilfunknetz — drei Modi, die alle drei dokumentiert und geschult gehören.

Ein Stolperdraht verdient im Homeoffice-Kapitel besondere Erwähnung: das VPN. Je nach Konfiguration kann ein Client im Heimnetz durch den Tunnel Merkmale des Firmennetzes sehen — und dann behauptet die Standortermittlung womöglich einen Bürostandort, während der Mensch am Küchentisch sitzt. Ob und wie das greift, hängt an der VPN-Architektur (Full Tunnel, Split Tunnel, virtuelle Adapter); die Konsequenz ist unabhängig davon dieselbe: Die Kombination aus VPN-Konzept und Standorterkennung gehört explizit getestet — ein Testnutzer im Homeoffice mit aktivem VPN, ein Blick auf die Standortanzeige, fertig ist die Gewissheit. Wo die Anzeige lügt, wird die VPN-Konfiguration angepasst oder das betroffene Merkmal aus der Zuordnung genommen — ein falscher automatischer Standort ist gefährlicher als eine ehrliche Adressabfrage.

Skizze 3: Ein Nutzer, drei Orte — wie der Notruf-Standort im Büro, im Homeoffice und unterwegs ermittelt wird.

Alt-Text-Vorschlag: Drei-Spalten-Übersicht der Standortermittlung je Aufenthaltsort: Im Büro und Firmennetz sind die Netzwerkmerkmale bekannt und der Standort kommt vollautomatisch aus der Standortdatenbank, je nach Pflege bis auf Gebäude und Etage genau. Im Homeoffice oder fremden Netz fragt der Client den Nutzer nach der aktuellen Adresse, die gespeichert und wiedererkannt wird — das funktioniert mit Nutzer-Disziplin. Unterwegs reicht die Teams-App den Notruf an die native Telefonfunktion des Smartphones weiter, sodass der Mobilfunk-Notruf mit Geräteortung greift. Die ehrliche Grenze: Im Firmennetz ist der Standort so gut wie die Datenpflege, im Homeoffice so gut wie die Nutzer-Disziplin — beides gehört kommuniziert und geprüft.

Organisation und Betrieb: Der Notruf endet nicht am Router

Die Technik übermittelt den Standort — den Rest erledigen Menschen, und dieser Rest gehört genauso konzipiert. Die interne Benachrichtigung aus der Notfallrufrichtlinie ist nur so gut wie der Prozess dahinter: Wer am Empfang die Meldung „Notruf aus Gebäude B, 2. OG“ sieht, muss wissen, was zu tun ist — Tor öffnen, Rettungsdienst einweisen, Aufzug freischalten, Ersthelfer informieren. Das ist ein Absatz im Notfallplan und eine Viertelstunde in der Empfangs-Einweisung, und es ist der Unterschied zwischen einem Rettungswagen, der vor dem verschlossenen Werkstor steht, und einem, der durchgewunken wird. Im Betrieb hat der Notruf dann einen natürlichen Feind: die Netzwerkänderung. Jedes neue Subnetz, jeder umgezogene Access Point, jeder getauschte Switch kann die Standortzuordnung entwerten — deshalb wird die LIS-Pflege fest an den Netzwerk-Change-Prozess gekoppelt: Kein Netzwerk-Change gilt als abgeschlossen, bevor die Standortdatenbank nachgezogen ist. Dazu kommt der Prüfrhythmus: quartalsweise Stichproben der Standortanzeige an wechselnden Punkten, jährlich der komplette Abgleich — fünfzehn Minuten pro Quartal für das Feature, das im Ernstfall alles entscheidet.

FAQ: Häufige Fragen zum Notruf in Teams

Funktionieren 110 und 112 in Microsoft Teams?

Ja — Teams Phone unterstützt Notrufe an 110 und 112 inklusive dynamischer Standortübermittlung. Voraussetzung ist die Konfiguration: Notfallstandorte, Netzwerkmerkmal-Zuordnung und ein Anbindungsweg, der Notrufe mit Standort transportiert — bei Direct Routing also Voice Route plus notruffähiger Trunk-Provider. Ohne diese Konfiguration klingelt die 112 zwar auch, aber womöglich mit falschem oder fehlendem Standort.

Woher weiß Teams beim Notruf, wo ich bin?

Über Netzwerkmerkmale: Der Client erkennt Subnetz, WLAN-BSSID oder Switch und Port, gleicht sie mit der vom Administrator gepflegten Standortdatenbank ab und ermittelt so den hinterlegten Notfallstandort — bei jeder Anmeldung und jedem Netzwechsel neu. Die Genauigkeit reicht je nach Pflegetiefe bis auf Gebäude, Etage und Bereich.

Was passiert beim Notruf im Homeoffice?

In unbekannten Netzen fragt der Client den Nutzer nach der aktuellen Adresse und merkt sie sich für dieses Netz. Das funktioniert zuverlässig, wenn die Abfrage ernst genommen wird — weshalb die Adresspflege in die Nutzer-Einweisung gehört. Auf dem Smartphone übergibt die Teams-App Notrufe ohnehin an die native Mobilfunk-Telefonie mit deren Ortung.

Ist die Notruf-Konfiguration Pflicht?

Praktisch ja: Das Telekommunikationsrecht verlangt Standortdaten beim Notruf, die betriebliche Fürsorgepflicht funktionierende Notfallprozesse — und ein Telefoniekonzept ohne durchdachten Notruf ist im Ernstfall ein Haftungsthema. Unabhängig von der juristischen Feinlage gilt die Projektregel: Notruf ist Pilot-Pflichtkriterium, kein Nachrüst-Feature.

Wie testet man den Notruf, ohne die Leitstelle zu stören?

Zweistufig: Alles ohne echten Anruf prüfen — Standortanzeige je Netzsegment, Standortwechsel, interne Benachrichtigungen — und für den Ende-zu-Ende-Test das abgestimmte Testverfahren des Providers nutzen beziehungsweise einen echten Testanruf vorher mit der Leitstelle terminieren. Niemals unangekündigt die 112 wählen und auflegen — ein abgebrochener Notruf löst genau die Kette aus, die er soll.

Was ist mit Tischtelefonen und Gemeinschaftsgeräten?

Für sie gilt dieselbe Mechanik: Auch Teams-Telefone ermitteln ihren Standort über die Netzwerkmerkmale ihres Anschlusses — bei fest verkabelten Geräten sogar besonders zuverlässig, weil sich ihr Netz selten ändert. Wichtig sind sie in der Merkmal-Inventur trotzdem: Gerade Flur- und Hallentelefone hängen gern in Subnetzen, an die bei der Zuordnung niemand gedacht hat.

Fazit: Neunzig Sekunden, für die alles bereit sein muss

Der Notruf ist die unspektakulärste Konfiguration der ganzen Teams-Telefonie — ein paar Adressen, eine Zuordnungstabelle, zwei Richtlinien — und zugleich die einzige, deren Qualität sich in Minuten zwischen Anruf und Rettungswagen bemisst. Wer die fünf Schritte vor dem Piloten erledigt, die LIS-Pflege an den Change-Prozess koppelt und einmal im Quartal auf die Standortanzeige schaut, hat das Thema dauerhaft im Griff — und den einen Satz aus dem Projekt verbannt, mit dem alles anfängt. Wenn du deine Notruf-Konfiguration prüfen oder das Konzept für mehrere Standorte aufsetzen willst: Melde dich kurz für eine Standortbestimmung — im doppelten Wortsinn, und in diesem Fall ist sie dringlicher als jede andere.