Notrufe in Microsoft Teams-Telefonie in Deutschland

1. Management Summary

„Geht das überhaupt: Notruf über Microsoft Teams?“ – Diese Frage höre ich als IT-Consultant in Deutschland regelmäßig. Die kurze Antwort lautet: Ja, aber man muss es richtig machen. In diesem praxisnahen Artikel zeige ich, wie Unternehmen die Notruffunktion ihrer Microsoft Teams-Telefonie compliant, zuverlässig und benutzerfreundlich umsetzen können. Denn es reicht nicht aus, einfach nur die 112 durchzulassen – man muss sicherstellen, dass Hilfe auch wirklich dort ankommt, wo der Anrufer sich befindet.

Microsoft Teams hat sich als moderne Telefonie-Lösung etabliert, doch die Mobilität der Nutzer stellt herkömmliche Notruf-Konzepte auf den Kopf. Mitarbeiter können ihre geschäftliche Rufnummer überall nutzen – im Büro, im Home-Office oder unterwegs. Das Problem: Ein Anruf bei 112 wird in der Regel anhand der Telefonnummer zur zuständigen Rettungsleitstelle (PSAP) geroutet. Wenn Herr Müller aus Dortmund mit seiner Dortmunder Büronummer über Teams den Notruf wählt, während er gerade in München im Meeting ist, klingelt es ohne spezielle Maßnahmen bei der Feuerwehr in Dortmund. Schlechte Karten, wenn die Hilfe eigentlich in München gebraucht wird!

In Deutschland sind Unternehmen rechtlich und moralisch verpflichtet, einen schnellen Notruf zu ermöglichen – und zwar ohne komplizierte Umwege. Gleichzeitig erwarten Mitarbeiter intuitiv, dass ein Notruf „einfach funktioniert“. Ein weit verbreiteter Trugschluss in der Praxis ist: „Im Notfall nimmt man halt das Handy.“ Natürlich ist ein Mobiltelefon oft griffbereit und wählt die 112 standortgerecht. Aber was, wenn gerade kein Handy zur Hand ist, der Akku leer oder kein Empfang im Keller? Unsere Verantwortung als IT ist es, vorzusorgen, sodass der Notruf auch über die bereitgestellte Telefonieplattform jederzeit möglich ist.

Dieser Artikel liefert einen Fahrplan von A bis Z: Von den rechtlichen Grundlagen in Deutschland über die technischen Optionen in Teams bis hin zur konkreten Schritt-für-Schritt-Konfiguration und dem Testing. Ich berichte aus der Ich-Perspektive eines erfahrenen Beraters – locker im Ton, aber präzise inhaltlich – und gebe dabei viele praxisnahe Tipps. So erfahren Sie zum Beispiel, wie man Standorte und Netzwerkdaten in Teams hinterlegt, damit bei einem Notruf die Adresse des Anrufers übermittelt wird. Sie lernen die verschiedenen Architektur-Varianten kennen, von Direct Routing mit eigenem SBC über Operator Connect bis zu Microsoft Calling Plans, und welche Vor- und Nachteile diese beim Notruf haben. Ich gehe auf Sonderfälle ein, etwa Home-Office oder internationale Standorte, und wie man auch dort compliant bleibt. Nicht zuletzt beleuchten wir Aspekte wie Resilienz (z.B. Notrufe bei Internetausfall) und interne Prozesse (Benachrichtigung eines Sicherheitsdienstes im Notfall, regelmäßige Tests, Dokumentation).

Am Ende soll Ihre Organisation vom anfänglichen „Wir sollten das Thema Notruf mal angehen…“ zum zufriedenen „Wir sind jetzt compliant, getestet und dokumentiert!“ gelangen. Das Management Summary fasst dafür die wichtigsten Handlungsempfehlungen zusammen:

• Rechtliche Pflicht & Sicherheit: Unternehmen müssen sicherstellen, dass aus jeder Teams-Nebenstelle jederzeit ohne Vorwahl ein Notruf (112/110) möglich ist und sofort zur richtigen lokalen Leitstelle gelangt. Dies ist nicht nur gesetzlich in §108 TKG vorgeschrieben, sondern auch Teil der Arbeitsschutzpflicht (DGUV Regel), um im Notfall schnelle Hilfe zu garantieren.
• Technische Lösung in Teams: Microsoft Teams bietet Notruf-Funktionalitäten wie dynamische Notfalladressen, standortbasierte Routing- und automatische Benachrichtigung interner Stellen. Diese sollten konsequent genutzt werden. Für jedes Büro und jeden Nutzer sind gültige Adressdaten zu hinterlegen. Mittels IP-Adressen und WLAN-Infos kann Teams den aktuellen Standort eines Anrufers erkennen und übermitteln.
• Architektur & Umsetzung: Je nach Telefonie-Architektur (Direct Routing mit eigenem SBC vs. Operator Connect vs. Microsoft Calling Plan) unterscheiden sich die Aufgaben. Ein zentraler SBC kann z.B. per ELIN-Verfahren die Absenderrufnummer manipulieren, damit die Leitstelle eine lokale Nummer sieht und zurückrufen kann. Alternativ übernehmen Telefonie-Provider diese Logik. Wichtig: Common Area Phones (fest installierte Telefone ohne Login) an strategischen Punkten stellen sicher, dass auch ohne PC oder Handy ein Notruf abgesetzt werden kann.
• Schritt-für-Schritt-Konfiguration: Die Implementierung umfasst u.a. das Anlegen von Notfall-Adressen in Teams, die Konfiguration von Notruf-Routingrichtlinien (z.B. 112 => lokale Route) und Benachrichtigungsrichtlinien (damit etwa der Werkschutz per Teams-Chat oder Anruf informiert wird). Dieser Artikel bietet eine detaillierte Anleitung inklusive PowerShell-Beispielen und Konfigurations-Snippets.
• Test und Betrieb: Ein Notruf-Setup ist keine Theorie – es muss praktisch erprobt werden. Für die Abnahme empfehle ich definierte Testcases je Standort (ohne die echten 112-Leitstellen zu überlasten, aber mit geeigneten Simulationen). Nach erfolgreichem Test werden Prozesse etabliert: Änderungen an Standorten oder Netzen erfordern Update der Notrufdaten; jährliche Notrufproben und Awareness-Schulungen der Mitarbeiter halten das System verlässlich.
• Sicherheit & Resilienz: Notruf muss auch bei Störungen funktionieren. Daher sollten kritische Komponenten redundant ausgelegt sein (z.B. zwei Internet-Uplinks, Ausfallsicherheit via Survivable Branch Appliance vor Ort für Notrufe bei Cloud-Ausfall). Zudem sind Stromausfälle zu bedenken: Switches und Telefon-Hardware gehören an eine USV, damit im Dunkeln nicht auch noch das Telefon verstummt.
• Wirtschaftlichkeit & Compliance: Die Investition in eine saubere Notruf-Lösung ist überschaubar (häufig sind die Funktionen in vorhandenen Lizenzen enthalten oder durch Provider abgedeckt) – und sie schützt vor potenziell hohen Folgekosten im Ernstfall. Vertragsseitig sollte mit Providern klar geregelt sein, wie Standortdaten gepflegt werden und welche Verantwortung der Anbieter übernimmt.

Kurz gesagt: Dieser Artikel liefert einen vollständigen Leitfaden, um Notrufe in Microsoft Teams rechtskonform und praxisgerecht umzusetzen. Als Ihr virtueller Berater mache ich Sie Schritt für Schritt mit allem vertraut, was Entscheider und Admins wissen müssen. Damit stellen Sie sicher, dass im Ernstfall jeder Ruf “112” über Teams nicht ins Leere läuft, sondern genau dort Hilfe auslöst, wo sie gebraucht wird. Jetzt aber genug der Vorrede – steigen wir ins Detail ein!

2. Grundlagen & Rechtsrahmen (Deutschland)

Bevor wir in die Technik eintauchen, lohnt ein Blick auf die rechtlichen Vorgaben und Grundlagen zum Notruf in Deutschland – denn diese bilden den Maßstab, an dem jede Lösung gemessen wird.

112 und 110 – gesetzlicher Auftrag: In Deutschland gibt es zwei offizielle Notrufnummern: 112 (Feuerwehr/Rettungsdienst, europaweit einheitlich) und 110 (Polizei, national). Ihre Erreichbarkeit ist durch §108 des Telekommunikationsgesetzes (TKG) strikt geregelt. Dort heißt es sinngemäß: Wer einen öffentlich zugänglichen Telefondienst anbietet, muss gewährleisten, dass Notrufe jederzeit und unverzüglich zur örtlich zuständigen Notrufabfragestelle geleitet werden. Übersetzt: Jeder, der Telefonie nach draußen ermöglicht – ob Telekom, VoIP-Anbieter oder im weiteren Sinne auch ein Unternehmen mit eigener Telefonanlage – muss sicherstellen, dass ein Anruf bei 112/110 ohne Hindernisse rausgeht und bei der richtigen Leitstelle landet. Notrufe sind außerdem kostenfrei und vorrangig zu behandeln (sie dürfen z.B. bei Netzlast nicht blockiert werden).

Herausforderung im VoIP-Zeitalter: Früher war “örtlich zuständig” einfach – ein analoger Festnetzanschluss ist fest an einen Ort gebunden, die Vorwahl verriet den Standort, und die Notruf-Leitstelle konnte den Anschluss zurückverfolgen. Bei Mobilfunk stellt die Funkzelle einen Anhaltspunkt. Bei moderner IP-Telefonie und Cloud-Anlagen verschwimmen jedoch die Grenzen. Mitarbeiter können mit ihrer Durchwahl theoretisch von überall telefonieren. Dadurch greift das traditionelle Routing nach Vorwahl ins Leere: Ein Hamburger Teams-Benutzer, der gerade in München ist, hat trotzdem eine 040-Rufnummer – würde man nur darauf achten, landete sein Notruf in Hamburg. Die Verordnung über Notrufverbindungen (NotrufV) und die Technische Richtlinie Notruf (TR Notruf) der Bundesnetzagentur adressieren dieses Problem. Sie fordern, dass bei “nomadischer Nutzung” von Telefonnummern möglichst genaue Standortinformationen übermittelt werden. Sprich: Wenn der Anrufer nicht an seinem Rufnummern-Standort sitzt, sollen andere Daten helfen, seinen aktuellen Ort zu ermitteln.

Standortübermittlung: In Deutschland erhält die Leitstelle beim Notruf die Anrufernummer (Caller ID) und in vielen Fällen automatisch einen Datensatz mit der hinterlegten Adresse. Bei klassischen Festnetznummern ist diese Adresse beim Netzbetreiber registriert (häufig die Installationsadresse des Anschlusses). Bei Mobilfunk wird die Funkzelle übermittelt und neuerdings auch GPS-Daten, sofern das Handy diese per AML (Advanced Mobile Location) senden kann. Für Voice-over-IP-Anschlüsse, insbesondere nomadische, sieht die Regulierung vor, dass der Betreiber eine Adresse des Kunden vorhält (“Klosterstraße 12, Berlin” z.B.) und diese im Notfall der Leitstelle bereitstellt – aber eben nur die hinterlegte Adresse. Ohne zusätzliche Technik geht man also erstmal davon aus, dass der Nutzer am offiziellen Anschlussort ist. Das ist natürlich ein gefährlicher Trugschluss, wenn die Person tatsächlich woanders ist. Daher erlaubt die NotrufV auch modernere Ansätze: Der Anruf kann an spezielle, bundesweite Notrufzentralen geroutet werden, die den Standort erst erfragen (“Wo befinden Sie sich?”) – in Deutschland gibt es so etwas allerdings bislang nicht flächendeckend, sodass in der Praxis weiterhin das Modell “Rufnummer -> Leitstelle” gilt.

Interne Telefonanlagen vs. öffentliche Dienste: Mancher IT-Leiter mag argumentieren: “Unsere Firmen-Telefonanlage ist doch kein öffentlicher Dienst, also betrifft §108 TKG uns gar nicht direkt.” Formal mag das Unternehmen nicht als Telekommunikationsanbieter im Sinne des Gesetzes gelten, solange die Telefonie nur intern für Mitarbeiter bereitgestellt wird. Aber Achtung: Sobald ein Unternehmen seinen Mitarbeitern das Raustelefonieren ins öffentliche Netz ermöglicht (also z.B. über Teams-Anbindung an die PSTN), übernimmt de facto der gewählte Netzbetreiber (Provider, Carrier) diese Pflicht. Dieser kann seine Pflicht jedoch nur erfüllen, wenn wir als Betreiber der Anlage entsprechend vorsorgen. Im Klartext: Unser Telefonie-Provider routet den Notruf korrekt – aber nur basierend auf den Informationen, die er von uns bekommt (z.B. die Absendernummer oder optional übermittelte Standortdaten). Haben wir nichts konfiguriert, geht der Notruf seinen Standardweg (meist zur Heimat-Leitstelle der Rufnummer). Insofern tragen wir als IT-Verantwortliche die Verantwortung, die Regeln des Gesetzes praktisch umzusetzen, damit unser Provider überhaupt korrekt handeln kann. Zusätzlich verlangen die Unfallverhütungsvorschriften, dass Arbeitgeber ihren Beschäftigten eine schnelle Hilfeleistung ermöglichen müssen. DGUV Vorschrift 1 (“Grundsätze der Prävention”) schreibt beispielsweise vor, dass „geeignete Meldeeinrichtungen“ bereitgestellt werden, damit ein Notruf unverzüglich abgesetzt werden kann. Das schließt ausdrücklich auch betriebliche Telefonsysteme ein: Es muss ohne Zeitverlust möglich sein, Hilfe herbeizurufen. Telefonanlagen müssen also so eingerichtet sein, dass 112 und 110 direkt und ohne Blockaden wählbar sind. Eine frühere Unsitte – Notrufe nur über eine externe Amtsnull zu erlauben – ist heute ein No-Go. Mitarbeiter dürfen niemals zuerst “0” wählen müssen, um ein Amt zu holen, wenn es um 112 geht! Moderne Anlagen und insbesondere Microsoft Teams verlangen das zum Glück auch nicht; dennoch sollten Administratoren sicherstellen, dass etwaige Wählpläne keine Barrieren für 112/110 darstellen.

Compliance heißt hier: Safety First. Missachtet ein Unternehmen diese Vorgaben, drohen vielfältige Risiken. Rechtlich könnte der Telefonie-Provider oder theoretisch sogar die Firma selbst belangt werden, wenn nachweisbar fahrlässig kein Notruf möglich war. Viel gravierender ist jedoch das menschliche Risiko: Im Brandfall, Unfall oder medizinischen Notfall zählt jede Minute. Kommt Hilfe verspätet oder falsch an, weil der Notruf nicht richtig geleitet wurde, kann das Leben kosten – und Verantwortliche im Unternehmen würden sich fragen lassen müssen, warum man die bekannten technischen Lösungen nicht implementiert hat.

Zusammengefasst bilden drei Ebenen den Rechtsrahmen: 1. Telekommunikationsrecht: §108 TKG plus Notrufverordnung fordern Verfügbarkeit und richtiges Routing von Notrufen; die Bundesnetzagentur konkretisiert dies in technischen Richtlinien (z.B. für Standortermittlung). 2. Arbeitsschutzrecht: Arbeitgeber müssen organisatorisch und technisch sicherstellen, dass Mitarbeiter im Notfall Hilfe rufen können (ArbSchG §10, DGUV Vorschrift 1 §25). Dazu zählt die Bereitstellung funktionsfähiger Notrufmöglichkeiten an jedem Arbeitsplatz – auch im Home-Office, sofern Mitarbeiter allein tätig sind. 3. Best Practices & Normen: International gibt es weitere Standards, die indirekt Vorbild sind. In den USA schreibt z.B. Kari’s Law vor, dass aus Telefonanlagen ohne Präfix 911 erreichbar sein muss und dass gleichzeitig ein internes Alarm (z.B. an die Security) erfolgt. Das RAY BAUM’s Act verlangt dort präzise Standortangaben beim 911-Call, selbst für Büros mit Multi-Line-Telefonanlagen. Während diese US-Gesetze in Deutschland nicht gelten, entsprechen ihre Inhalte im Wesentlichen unseren Zielen: direkte Erreichbarkeit des Notrufs, interne Alarmierung und Standortübermittlung. Microsoft Teams hat viele dieser Funktionen global implementiert, sodass wir sie auch hierzulande nutzen können.

Fazit: Die Pflicht und Erwartungshaltung ist klar – “Notrufe müssen immer und überall funktionieren.” Für uns bedeutet das, dass wir unsere Teams-Telefonie so konfigurieren müssen, dass 112/110 ohne Wenn und Aber durchgehen und der Anruf an der richtigen Stelle landet. Wie wir das technisch umsetzen und welche Optionen Microsoft Teams dafür bietet, behandeln die nächsten Kapitel.

3. Teams-Telefonie: Notruf-Fähigkeiten & Optionen

Microsoft Teams als Telefonanlage bringt von Haus aus einige Funktionen für Notrufe mit – jedoch müssen Administratoren diese richtig konfigurieren. Schauen wir uns an, was Teams in diesem Bereich kann und welche Optionen je nach Anbindungsart bestehen.

Basisfähigkeiten von Microsoft Teams (Phone System): Sobald Nutzer in Teams eine Telefonnummer zugewiesen bekommen (sei es über Direct Routing, Operator Connect oder Calling Plans), können sie damit grundsätzlich Notrufe wählen. Teams kennt die Nummern 112 und 110 (sowie andere internationale Notrufnummern wie 911 für USA) und behandelt solche Anrufe speziell. Das äußert sich etwa darin, dass der Teams-Client beim Wählen von 112 erkennt “Aha, ein Notruf” und – sofern konfiguriert – Zusatzinformationen anhängt. Auch kann Teams den Standort des Anrufers an die Cloud übertragen, um ihn ggf. weiterzugeben. Wichtig: Teams ersetzt keine offiziellen Behörden-Apps – es gibt z.B. keinen speziellen Notruf-Button wie bei manchen Notruf-Apps, aber es integriert sich in die normale Telefonfunktion.

Die folgenden Features stehen in Microsoft Teams für Notrufe zur Verfügung:

• Notfalladressen und -Standorte: In Teams lassen sich sogenannte Emergency Addresses hinterlegen – das sind physische Adressen (Straße, Hausnummer, Stadt usw.), optional mit einem “Ort” im Gebäude (z.B. 3. Stock, Raum 320). Jede Notfalladresse erhält eine eindeutige Standort-ID. Diese Adressen können Benutzern oder ganzen Standorten zugewiesen werden. Damit legen wir die statische Ortsinformation fest, unter der ein Nutzer normalerweise firmiert. Beispiel: Max Mustermann hat offiziell die Notfalladresse “Musterstr. 1, 40213 Düsseldorf, 2. OG” zugewiesen. Diese Adresse kann an die Leitstelle übermittelt werden, wenn Max den Notruf absetzt – unabhängig davon, wo er tatsächlich ist (daher statisch). Aber: Teams kann noch mehr – dazu gleich mehr unter “Dynamische Notrufe”.
• Dynamische Standortermittlung: Eine der wichtigsten Funktionen ist die dynamische Notruffunktion. Ist sie aktiviert, versucht Teams im Moment des Notrufs den aktuellen Standort des Clients zu bestimmen. Dafür gibt es zwei Ansätze:
• Netzwerkbasiert (internes Netz): Der Admin kann in Teams definieren: “Subnetz 10.1.5.0/24 = Büro München, Elisenstraße 3, 4. Stock”. Oder “WLAN-Zugangspunkt mit BSSID XY:ZT:… = Lagerhalle Dortmund, Westseite”. Wenn sich der Benutzer im Firmen-LAN oder -WLAN befindet, erkennt Teams anhand der IP-Adresse oder WiFi-ID, an welchem Standort er sitzt. Dann wird automatisch die korrekte hinterlegte Adresse für diesen Standort als Notfalladresse verwendet. Diese Daten pflegt der Admin vorab ein (mehr dazu im Kapitel Umsetzung).
• Client-basiert (extern/Remote): Befindet sich der Nutzer außerhalb des bekannten Firmennetzes (z.B. im Home-Office über eigenes WLAN oder unterwegs über Mobilfunk-Hotspot), greift Teams optional auf die Betriebssystem-Ortungsdienste zurück. Ist die Standortfreigabe am Gerät aktiv und erlaubt, bekommt Teams vom OS eine Adresse vorgeschlagen (etwa über GPS/WLAN-Ortung via Bing Maps). Diese Adresse zeigt der Teams-Client dem Benutzer an: “Wir haben Ihren möglichen Standort ermittelt: Beispielstraße 5, 12345 Ort – wird für den Notruf verwendet” – der Benutzer kann diese bestätigen oder anpassen, bevor der Anruf geht. Bestätigt er sie, wird sie als aktuelle Notfalladresse an den Notruf übertragen. Tut er nichts, kann Teams je nach Konfiguration entweder die automatisch vorgeschlagene Adresse senden oder im schlimmsten Fall nur die zuletzt bekannte statische Adresse verwenden.
• Notruf-Routing (Call Routing): Teams ermöglicht es Administratoren festzulegen, wie Notrufe geroutet werden, insbesondere bei Direct Routing. Über sogenannte Notruf-Routingrichtlinien kann man definieren, welche Rufnummern als Notruf gelten (z.B. 112, 110, 911, 999 etc.) und über welche Verbindung diese Anrufe geleitet werden. In einem einfachen Szenario mit Microsoft Calling Plan (bei dem Microsoft selbst der Netzbetreiber ist) übernimmt Microsoft automatisch das Routing zur richtigen Leitstelle – dort muss man in Teams nur angeben, welche Nummern Notruf sind, damit der Client z.B. 112 nicht versucht als +112 zu interpretieren (das erledigt Teams intern schon). Bei Direct Routing hingegen hat man mehr Konfigurationsaufwand: Hier legt man typischerweise fest, dass 112/110 immer über einen bestimmten SBC oder Trunk laufen, idealerweise den lokal zuständigen. Man kann z.B. eine Routingregel bauen „Wenn Notruf aus Standort Berlin, dann über Berliner SIP-Trunk raus“. (Keine Sorge – wie das genau eingerichtet wird, behandeln wir im Umsetzungs-Kapitel ausführlich.) Zusätzlich kann in diesen Richtlinien das Konzept ELIN berücksichtigt werden: d.h. wenn vorhanden, nutzt Teams ein ELIN-Gateway (Emergency Location Identification Number) – das ist praktisch ein Mechanismus, bei dem ein spezieller Gateway (in der Regel unser SBC) den Anruf mit einer hinterlegten Notruf-Rufnummer versieht. Das ELIN-Konzept schauen wir uns bei den Zielarchitekturen gleich an.
• Interne Benachrichtigung (Security Alert): Microsoft Teams bietet die Möglichkeit, beim Absetzen eines Notrufs automatisch firmeninterne Stellen zu benachrichtigen. Über die Notruf-Benachrichtigungsrichtlinie (Emergency Calling Policy) kann man konfigurieren, dass z.B. beim Wählen der 112 sofort eine Nachricht in Teams an eine definierte Benutzergruppe gesendet wird (etwa an Sicherheitsdienst oder Empfang). Diese Benachrichtigung enthält den Namen des Anrufers und – wenn ermittelt – seinen Standort. Zudem kann man einstellen, dass diese internen Helfer dem Gespräch automatisch zugeschaltet werden, entweder stumm (nur mithörend) oder offen (mit Sprechmöglichkeit). Beispiel: Ruft Herr Müller über Teams die 112, kann Teams parallel den Werkschutz-Konferenzraum anrufen und stumm zuschalten. Der Sicherheitsmitarbeiter sieht dann, wer da gerade den Notruf gewählt hat und kann mithören, was gesprochen wird. Er weiß dann z.B., dass es einen medizinischen Notfall im 4. Stock gibt und kann schon mal einen Ersthelfer losschicken. Alternativ oder zusätzlich kann eine Chatnachricht “Notruf durch Benutzer X, Standort Y” an definierte Personen abgesetzt werden. Diese Funktionen orientieren sich an den Vorgaben aus Kari’s Law (USA) und sind extrem hilfreich, um innerbetrieblich schnell reagieren zu können.
• Standortbasierte Richtlinien allgemein: Teams nutzt das Konstrukt Netzwerkstandorte (Network Sites), um sowohl das Routing als auch die Benachrichtigung policies ortsabhängig zu steuern. Wenn z.B. ein Benutzer, der normalerweise in Hamburg arbeitet, sich im Münchner Büro befindet (sprich, sein Client hängt im Netz, das als “München” definiert ist), dann greifen automatisch die Notruf-Regeln, die für München gelten – egal, welche Nummer er hat. Das heißt, wir können pro Standort verschiedene interne Notfallkontakte und verschiedene Routen definieren. Das ist z.B. dann relevant, wenn man mehrere Länder in einem Tenant hat oder wenn jedes Werk eigene Werkschutz-Teams hat, die nur im eigenen Werk alarmiert werden sollen.

Neben diesen Kernfähigkeiten variieren manche Details je nach PSTN-Konnektivitätsoption (also wie Teams an das Telefonnetz angebunden ist):

• Microsoft Calling Plans: Hier kauft man Rufnummern und Minutenkontingente direkt von Microsoft. Microsoft fungiert als Telefonanbieter und hat die Pflicht, Notrufe korrekt zu routen. Praktisch bedeutet das: Man muss für jede zugewiesene Telefonnummer eine gültige Adresse im Teams Admin Center hinterlegen (bei deutschen Nummern z.B. die Standortadresse des Nutzers). Microsoft stellt sicher, dass Anrufe an 112/110 an die örtliche Leitstelle gehen – im Hintergrund arbeiten sie dazu mit lokalen Netzpartnern zusammen. Allerdings kann Microsoft (Stand heute) nicht zaubern: Wenn der Benutzer mit einer Berliner Nummer in München ist und den Notruf wählt, wird Microsoft mangels anderer Infos die Berliner Leitstelle ansteuern – es sei denn, wir als Admin haben dynamische Notfalladressen eingerichtet. Daher: auch bei Calling Plans lohnt die Konfiguration der dynamischen Standortzuordnung in Teams. Die interne Benachrichtigungsfunktion steht uns voll zur Verfügung. ELIN-Konzepte entfallen hier, da Microsoft selbst die “Rückrufnummer” verwaltet (im Zweifelsfall die originale Rufnummer des Anrufers wird angezeigt).
• Operator Connect: Hier kommt die Telefonie von einem externen Provider, der per Cloud-Verbindung an Teams gekoppelt ist. Der Operator (z.B. Deutsche Telekom, Vodafone o.ä.) hält die Rufnummern und ist verantwortlich für Notrufe. In Operator-Connect-Szenarien gibt es meist im Vertrag die Verpflichtung, jeder Nummer eine Adresse zuzuordnen (oft im Provider-Portal zu pflegen). Einige Operator-Connect-Anbieter unterstützen auch “nomadic E911” Funktionen – das heißt, sie können von Microsoft dynamisch übermittelte Standortdaten verarbeiten. In der Praxis läuft es so: Teams ermittelt den Standort und übergibt diesen beim Wählen als zusätzliches SIP-Header-Info (PIDF-LO). Der Operator empfängt das und routet den Anruf zur passenden Leitstelle in der Region des übermittelten Standorts (anstatt stumpf nach der Rufnummer). Ob der jeweilige Anbieter das unterstützt, muss man erfragen; viele traditionelle Anbieter behandeln Notrufe noch statisch nach Rufnummer. Das Gute: Wir können trotzdem Teams’ Mechanismen nutzen, um zumindest intern den Standort anzuzeigen und unsere Leute zu informieren. Interne Notruf-Benachrichtigungen funktionieren unabhängig vom Provider, rein in Teams. Das Routing hingegen kann bei Operator Connect weniger granular von uns beeinflusst werden (Teams erlaubt dort keine eigenen PSTN-Routen für Notrufe – man verlässt sich auf den Operator). Wichtig für uns: alle relevanten Adressen aktuell beim Operator zu halten, falls dynamische Übergabe nicht möglich ist.
• Direct Routing (eigener SBC): In diesem Modell hat das Unternehmen entweder on-premises oder im Rechenzentrum einen Session Border Controller (SBC), der mit Teams verbunden ist. Darüber laufen alle Gespräche ins Telefonnetz. Notrufe via Direct Routing sind voll in unserer Kontrolle, was Vor- und Nachteile hat. Vorteil: Wir können sehr flexibel bestimmen, wie ein Notruf geroutet wird – z.B. je nach Standort auf unterschiedliche Ortsleitungen. Nachteil: Wenn wir es falsch machen, gibt es keinen Netzbetreiber im Hintergrund, der es “automatisch richtig” biegt. Hier muss die Notruf-Routingrichtlinie in Teams sauber eingerichtet werden, und unser SBC muss ggf. speziell konfiguriert werden (Stichwort ELIN). Auf Direct Routing setzen viele große Firmen, weil sie z.B. bestehende SIP-Trunks weiter nutzen. Microsoft Teams sendet beim Notruf auf dem SBC eine Kennzeichnung im SIP-Protokoll (“Emergency Call” Flag) und falls vorhanden die vom Teams-Client erkannte Adresse (als PIDF-LO Objekt). Unser SBC kann diese Infos auswerten. Ein typisches Szenario: Wir haben für jede Niederlassung eine eigene Notruf-Absendernummer (ELIN). Bemerkt der SBC einen Notruf mit Adresse “Frankfurt Office”, überschreibt er die abgehende Caller-ID mit der Frankfurt-Notrufnummer. Dadurch landet der Anruf garantiert in Frankfurt bei der Leitstelle, und diese sieht eine lokale Rufnummer, unter der sie zurückrufen kann. Der SBC hält die Zuordnung intern vor (so dass, wenn die Leitstelle diese Nummer zurückruft, er weiß, welcher Benutzer ursprünglich dahintersteckte). Direct Routing erfordert am meisten initiale Arbeit, bietet aber die umfassendsten Möglichkeiten – wir werden dies bei den Zielarchitekturen näher beleuchten.
• Teams Phone Mobile (Mobilfunkintegration): Relativ neu ist Teams Phone Mobile (ehemals auch “Operator Connect Mobile”). Dabei verschmilzt die mobile SIM-Karte eines Mitarbeiters mit der Teams-Telefonie: Man hat eine einzige Handynummer, die sowohl im Mobilnetz als auch in Teams funktioniert. Für Notrufe bedeutet das: Ruft der Mitarbeiter per Handy normal die 112 an, greift natürlich das Mobilfunknetz ein – das Telefon wählt über die SIM (selbst wenn in Teams-App eingegeben, leitet iOS/Android Notrufe in der Regel an die native Telefonfunktion weiter) und die Mobilfunkbetreiber können wie üblich den Anruf an die nächste Leitstelle geben (über Standort der Funkzelle und AML). Ruft der Benutzer aber in der Teams-App vom PC aus die 112, dann verhält es sich wie bei Operator Connect mit dem entsprechenden Anbieter – d.h. es läuft übers Telefonnetz des Operators. In der Praxis ist Teams Phone Mobile hinsichtlich Notruf der wohl sicherste Ansatz: im Büro haben alle ihr Handy (mit direkter 112-Funktion) und unterwegs sowieso. Allerdings setzt dieses Modell voraus, dass jeder Mitarbeiter eine vom Unternehmen gestellte SIM hat – was eher in Mobilfunk-orientierten Firmen Sinn ergibt und mit zusätzlichen Kosten verbunden ist.

Unabhängig von der Anbindungsart gilt: Teams muss korrekt konfiguriert werden, um seine Notruf-Fähigkeiten auszuspielen. Ab Werk ist kein Automatismus vorhanden, der z.B. alle Büro-Standorte kennt – das müssen wir bereitstellen. Standardmäßig wird ein 112-Anruf in Teams zwar nicht blockiert, aber ohne Konfiguration würde im Direct Routing Fall z.B. einfach der normale Abgang über den SBC passieren (womöglich mit falscher Absendernummer), oder im Calling-Plan-Fall ginge er mit der hinterlegten statischen Adresse raus (die ggf. nicht mehr stimmt). Es ist also entscheidend, die vorgesehene Teams-Features zu aktivieren: Notfalladressen anlegen, Netzwerke zuordnen, Policies definieren. Auch sollten wir die Nutzer informieren, was geht und was nicht: Microsoft Teams blendet z.B. bei Desktop-Clients einen Warnhinweis ein, wenn man sich außerhalb der Heimatregion befindet, sinngemäß: „Versuchen Sie keinen Notruf aus dem Ausland über Teams, nutzen Sie ein örtliches Telefon.“ Das ist ein wichtiger Punkt: Teams kann (derzeit) keine Wunder vollbringen, wenn jemand mit einer deutschen Nummer in Japan die 112 wählt – das wird nicht zur Feuerwehr Tokio durchkommen. Für solche Fälle muss in der Sicherheitsunterweisung klar sein: im Ausland immer die lokalen Notrufnummern über ein lokales Telefon oder Mobiltelefon wählen.

Zum Glück bewegen wir uns im Normalfall innerhalb Deutschlands oder der EU, wo 112 überall gilt. Und mit der richtigen Konfiguration kann Microsoft Teams gewährleisten, dass ein Notruf genauso zuverlässig funktioniert wie in der alten Telefonanlage – nur mit dem Unterschied, dass wir eben die neuen Möglichkeiten der Standortautomatik und internen Alarmierung haben. Im nächsten Kapitel entwickeln wir die Zielarchitektur(en), wie all diese Bausteine in einer Gesamtlösung zusammenspielen.

4. Zielarchitekturen (mit ASCII-Skizzen)

Wie könnte nun eine komplette Teams-Notruflösung architektonisch aussehen? In diesem Kapitel stelle ich mehrere Zielarchitekturen vor, die sich in der Praxis bewährt haben. Wir betrachten sowohl Varianten mit eigenem SBC (Direct Routing) als auch rein cloud-basierte Ansätze. ASCII-Skizzen illustrieren vereinfacht die jeweiligen Abläufe.

Direct Routing mit lokalem SBC und ELIN

Dies ist die komplexeste, aber auch mächtigste Architektur. Sie eignet sich für größere Unternehmen mit verteilten Standorten, die ihre bestehenden Telefonanschlüsse weiter nutzen oder volle Kontrolle wünschen.

Aufbau: Die Teams-Telefonie ist über einen Session Border Controller (SBC) an einen oder mehrere SIP-Trunks angebunden. Jeder Standort des Unternehmens ist entweder mit einem eigenen SBC verbunden oder alle Standorte gehen zentral über einen SBC (mit entsprechend vielen Rufnummern). Wichtig ist, dass jeder Standort eine oder mehrere Notruf-Callback-Nummern (ELINs) hat – das sind dedizierte Rufnummern, die nur für Notrufe verwendet werden. Der SBC kennt diese Nummern und weiß, welcher physischen Location sie entsprechen.

Ablauf eines Notrufs in diesem Szenario:

   [Teams Client] –(112 gewählt)–> [Teams Cloud] — Notruf an –> [SBC im Unternehmen]
        |                                (Teams übergibt Standort-ID „Standort FFM“)
        v
   SBC prüft: Standort = Frankfurt?
   SBC setzt abgehende CallerID = ELIN-Nummer Frankfurt (z.B. +49-69-1234-110)
        |
        v
   SBC leitet Call –> [PSTN-Netz] –> Übergabe an –> [Leitstelle Frankfurt 112]
         (Leitstelle sieht als Anrufer +49-69-1234-110 und erhält Adresse Frankfurt)
   <…Rückruf der Leitstelle landet über die ELIN beim SBC, der ihn an den Teams Client von Herrn X vermittelt…>

(Parallel dazu: Teams alarmiert intern die hinterlegte Sicherheitsgruppe via Chat/Anruf mit Info „Notruf ausgelöst von Herr X, Standort: Frankfurt Büro“).

In Worten: Der Benutzer wählt 112 in Teams. Der Anruf geht über die Cloud zum lokalen SBC. Teams hat dem SBC bereits mitgeteilt, welcher Standort erkannt wurde (aus unserer Konfiguration). Der SBC schaut in seiner Routing-Tabelle nach und findet: “Für Standort Frankfurt ist die ELIN +49-69-1234-110 zu verwenden und der PSTN-Ausgang in Frankfurt.” Er setzt also die Anrufernummer auf diese Frankfurter Nummer und schickt den Call ins öffentliche Netz, über den Frankfurter Telefonanschluss. Bei der Leitstelle kommt dadurch ein ganz normaler lokaler Notruf an: Absender z.B. 069/1234-110, registriert auf die Firmenadresse Frankfurt. Die Leitstelle schickt Hilfe dorthin. Würde der Anrufer während des Notrufs nichts mehr sagen können (z.B. bewusstlos werden), hätten die Rettungskräfte zumindest diese Adresse. Ruft die Leitstelle zurück, landet der Anruf ebenfalls auf +49-69-1234-110, und unser SBC weiß dank temporärer Zuordnung (“30-Minuten-Timer”) noch, dass dieser Rückruf zu dem ursprünglichen Teams-Benutzer gehört, und stellt das Gespräch durch (so kann die Leitstelle Rückfragen stellen). Intern haben zudem alle relevanten Personen mitbekommen, dass ein Notruf in Frankfurt abgesetzt wurde (und idealerweise wer und wo genau, sofern der Client das geliefert hat).

Diese Architektur erfordert eine sorgfältige Einrichtung von Netzwerkstandorten und -subnetzen in Teams (damit die Standort-ID stimmt) und eine entsprechende SBC-Programmierung. Viele SBC-Hersteller (AudioCodes, Ribbon etc.) bieten dafür spezielle Notruf-Funktionen oder “ELIN-Module” (teils lizenzpflichtig, wie angedeutet). Man kann das Routing aber auch mit regulären Dialplan-Regeln abbilden: z.B. im SBC “wenn Rufnummer = 112 und SIP-Header Location = FFM, dann setze From-Number = frankfurt-ELIN und route über Trunk FFM”.

Ein Vorteil hier: Lokale Ausfallsicherheit. Sollte die Cloud-Verbindung zu Teams gestört sein, kann man einen Survivable Branch Appliance (SBA) im Standort einsetzen – dieser ermöglicht den Clients, Notrufe (und ein paar andere Basisanrufe) auch ohne Teams-Cloud direkt über den SBC abzusetzen. So bleiben Standorte im Notfall nicht stumm.

Diese Direct-Routing-Architektur ist aufwendig, aber sie stellt sicher, dass alle gesetzlichen Anforderungen erfüllt werden und das Unternehmen flexibel bleibt. Viele meiner Kunden wählen diesen Weg, wenn sie Standorte in verschiedenen Regionen haben oder wenn bereits On-Prem-Infrastruktur vorhanden ist.

Operator Connect / Teams Phone Mobile (anbieterbasiert)

In dieser Zielarchitektur verlässt man sich stärker auf externe Telefonieanbieter. Der Aufbau ist schlanker: kein eigener SBC ist nötig, stattdessen liefert ein zertifizierter Provider die Anbindung an das PSTN und integriert sich via Operator Connect in Teams. Bei Teams Phone Mobile fungiert der Mobilfunkanbieter als solcher Provider.

Aufbau: Jeder Benutzer hat eine Telefonnummer vom Provider (entweder Festnetz oder Mobil). Teams leitet die Gespräche über die Cloud direkt an den Provider weiter (bzw. empfängt eingehende von dort). Der Provider ist für Notrufe der “Herr des Geschehens”.

Notruf-Ablauf: Nimmt man das Beispiel Operator Connect: – Der Teams Client wählt 112. Die Teams-Cloud erkennt dies als Notruf und sendet ihn an den Operator-Connect-Service des Providers, zusammen mit allen Daten, die sie hat (z.B. der vom Client gemeldeten aktuellen Adresse, sofern freigegeben). – Der Provider entscheidet, wohin der Anruf geht. Im einfachsten Fall routet er stur nach der Teilnehmernummer (d.h. ein Münchner Teilnehmer landet bei Münchner Leitstelle). Bessere Provider setzen die von Teams mitgelieferte Adresse ein: hat Teams gemeldet “Standort: Berlin”, dann routet der Provider den Call zur Berliner Leitstelle und übermittelt ggf. diese Adresse über sein System. – Die Leitstelle ruft bei Bedarf über die ursprüngliche Nummer zurück – dieser Rückruf geht dann über den Provider an Teams bzw. an den Nutzer.

Für uns als Administratoren sieht diese Architektur einfacher aus: Wir müssen vor allem dafür sorgen, dass alle Benutzerstandorte im Provider-System korrekt gepflegt sind und dass Teams die Standortdaten an den Provider schicken darf. Das bedeutet, wir konfigurieren ebenfalls in Teams alle Standorte und aktivieren External Location Lookup (Standortfreigabe) für die User. Intern in Teams können wir genauso die Sicherheitsbenachrichtigungen einrichten – das funktioniert ja unabhängig vom konkreten Abgang. Was wir nicht tun können: eigenes Routing erzwingen. Die Notruf-Routingrichtlinie in Teams dient in dem Fall nur dazu, Teams zu sagen “112 ist ein Notruf” (damit die App den Standort abfragt etc.), aber das eigentliche Wie übernimmt der Anbieter.

Wenn man Teams Phone Mobile (TPM) nutzt, ist das Prinzip ähnlich, nur dass hier im Mobiltelefonnetz noch ein Parallelweg existiert: Ein Notruf vom Hardware-Handy würde immer direkt über Mobilfunk gehen (was gut ist, falls Teams oder Internet ausfallen). TPM ist also eine Spezialvariante von Operator Connect, die maximale Mobilität bietet. Architektonisch hat man aber pro Land typischerweise genau einen Mobilfunkpartner, der die Nummern stellt.

Charakteristik: Diese Architektur ist herstellerneutral im Sinne von – man überlässt es dem Telefonie-Provider. Viele Unternehmen gehen diesen Weg, wenn sie keine Lust auf eigene Infrastruktur haben und darauf vertrauen, dass die Provider ihre Notrufpflicht sehr ernst nehmen (wovon auszugehen ist, da diese dazu gesetzlich verpflichtet sind). Allerdings sollte man genau die Vertragsbedingungen prüfen: Muss man Adressänderungen manuell melden? Unterstützt der Dienst dynamische Updates? Gibt es eine Haftungsbegrenzung? (Mehr dazu im Kapitel Wirtschaftlichkeit & Vertragsaspekte.)

Microsoft Calling Plan (vollständige Cloud-Telefonie)

Hier übernimmt Microsoft selbst die Rolle des Telekommunikationsanbieters. Architektonisch ist es dem Operator Connect sehr ähnlich, nur dass kein Drittanbieter dazwischen steckt.

Aufbau: Die Telefonnummern kommen von Microsoft (bzw. deren Partner). Alle Anrufe laufen über Microsofts Infrastruktur in die Netze.

Notruf-Ablauf: Wenn 112 gewählt wird, versucht Microsoft anhand der im Tenant hinterlegten Notfalladresse des Anrufers zu routen. Microsoft hat in jedem Land Partner-Carrier oder eigene Verbindungen zu den Notrufsystemen. In der EU gehen die Calls in der Regel über Partner inländisch raus. Wichtig: Microsoft benötigt akkurate Adressdaten je Nummer. Im Admin Center wird deshalb beim Zuweisen einer Calling-Plan-Nummer immer eine Adresse abgefragt und verifiziert (mittels Bing Maps API). Diese wird als “Registrierte Adresse” gespeichert. Dynamische Notrufe sind auch hier möglich: Teams kann wie gehabt einen aktuellen Standort ermitteln und an Microsoft übermitteln. Nur ist Microsoft (derzeit) in Deutschland noch auf das statische Routing fokussiert, weil unser Notrufsystem keine digitalen Ortsupdates von OTT-Anbietern erwartet. Daher gilt: Unbedingt die Adressen aktuell halten! Wenn ein Mitarbeiter dauerhaft ins Home-Office nach Bielefeld wechselt, muss seine registrierte Notrufadresse angepasst werden, sonst landet ein Notruf womöglich am alten Standort.

Interne Funktionen wie Sicherheitsbenachrichtigungen stehen auch bei Calling Plans zur Verfügung. Wir können sogar testweise dynamische Adressauflösung konfigurieren – schaden tut es nicht, und Microsoft nutzt diese Info zumindest, um im Zweifel dem Notruf-Telefonisten mitzuteilen “Caller gibt an, er sei in XY”.

Die Zielarchitektur “Calling Plan” ist am besten für kleine und mittlere Firmen geeignet, die keine komplexe Netzstruktur haben. Hier ist das Motto: Keep it simple – Microsoft macht das schon. Die Erfahrung zeigt allerdings, dass trotzdem ein Notrufkonzept erstellt werden muss (wer informiert wird intern, wie getestet wird etc.), und dass man die Limitierungen kennt (z.B. im Ausland oder bei Netzstörungen).

Zusätzliche Architektur-Bausteine: Notruftelefone, USV & Co.

Unabhängig von obigen Varianten gibt es einige Best Practices, die architektonisch ergänzt werden können:

• Notfallpunkte mit dedizierten Telefonen: Wie in Kapitel 1 erwähnt, empfiehlt es sich in Umgebungen ohne klassische Tischapparate pro Etage oder Bereich mindestens ein fest installiertes Telefon für Notrufe bereitzustellen. In Teams-Umgebungen realisiert man das mit einem preiswerten Teams-Telefon und einer Common Area Phone-Lizenz. Dieses Telefon ist ständig angemeldet (kein Benutzer-Login nötig) und erlaubt jederzeit abgehend 112 zu wählen. Eingehend ist es unter einer eigenen Durchwahl erreichbar – idealerweise genau der ELIN-Nummer des Standorts, falls man Direct Routing nutzt. Somit kann die Leitstelle beim Rückruf direkt dieses Gerät erreichen. Solche Telefone sollten auffällig platziert und gekennzeichnet sein (z.B. roter Hörer oder Schild “Notruftelefon”). Wie bei einem Feuerlöscher sollte jeder Mitarbeiter wissen, wo das nächste Notfalltelefon hängt.

   [Notfallpunkt: Teams-Telefon an der Wand] –(112)–> [Teams Cloud] –> PSTN –> Leitstelle
      (frei wählbar ohne Login; eingehend erreichbar unter Notruf-DID)

• Strom- und Netz-Redundanz: Die schönste Notruflösung hilft nichts, wenn bei einem Stromausfall alles tot ist. Architektonisch sollten daher die Komponenten, die für den Notruf essenziell sind, abgesichert sein. Das heißt: Switches, WLAN-Access-Points und der SBC vor Ort gehören an eine USV (unterbrechungsfreie Stromversorgung). So bleiben zumindest Telefonie und Netzwerk einige Zeit funktionsfähig. Für Standorte mit instabiler Internetanbindung lohnt eine Backup-Leitung (zweiter WAN-Uplink, ggf. 4G/5G-Router), über die im Notfall Teams weitertelefonieren kann. Und wie erwähnt, ein Survivable Branch Appliance (SBA) vor Ort kann im Cloud-Ausfall lokale Gespräche direkt routen. Dieses SBA-Modul ist quasi eine Mini-Teams-Komponente, die Notrufe und interne Anrufe puffert, bis die Cloud wieder da ist.
• Klare Zuständigkeiten & Monitoring: Architektonisch sollte auch vorgesehen werden, wer im Falle eines Notrufs was tut. Das ist zwar eher Prozess als Technik, aber es beeinflusst unsere Wahl der Komponenten: Wenn z.B. der Werkschutz eine eigene Leitstelle hat, könnte man entscheiden, alle internen Notrufe erstmal dorthin zu leiten (statt direkt 112). Dies kann man architektonisch umsetzen, ist aber heikel (rechtlich muss 112 erreichbar bleiben, auch will man bei echten Notfällen keine Zeit verlieren). Oft wird daher ein Mittelweg gewählt: interner Sicherheitsdienst per Teams-Benachrichtigung informieren, aber der 112-Call geht direkt nach extern. Wichtig: Die gewählte Architektur muss ins Sicherheitskonzept des Unternehmens passen. Entsprechend sollte das Notrufsystem in Überwachungssysteme integriert sein – z.B. könnten kritische Komponenten (SBC, Telefonserver) ein Alarm senden, falls sie ausfallen, damit die IT sofort reagieren kann.

Wir sehen: Es gibt nicht “die eine” Architektur, sondern je nach Voraussetzungen eine passende Mischung. In der Praxis erstelle ich oft Hybrid-Modelle: z.B. Zentrale per Direct Routing (mit SBC und ELIN), kleine Außenstellen ohne eigene Trunks per Calling Plan, mobile Mitarbeiter via Teams Phone Mobile. Entscheidend ist, dass am Ende jeder Standort und jedes Szenario abgedeckt ist. Im nächsten Kapitel kümmern wir uns darum, wie man diese architektonischen Ideen konkret in Microsoft Teams konfiguriert – Schritt für Schritt.

5. Umsetzung in Teams – Konfiguration Schritt für Schritt

Nun geht es an die praktische Umsetzung. Wir haben die Architektur und Optionen gewählt – jetzt müssen wir Microsoft Teams so konfigurieren, dass alles funktioniert. Die folgenden Schritte haben sich als Leitfaden bewährt:

1. Planung & Datensammlung: Bevor Sie in Teams etwas klicken, sammeln Sie alle relevanten Informationen. Erstellen Sie eine Liste aller Standorte Ihres Unternehmens mit vollständiger postalischer Adresse (für jeden später eine Notfalladresse). Notieren Sie für jeden Standort, welche IP-Subnetze (IPv4) und WLAN-Access-Points dort genutzt werden – diese Angaben erhalten Sie von Ihrer Netzwerkabteilung. Legen Sie fest, ob und welche ELIN-Rufnummern pro Standort verwendet werden sollen (bei Direct Routing): idealerweise pro Standort eine Notruf-DID (Durchwahl) im lokalen Ortsnetz. Definieren Sie zudem, wer im Notfall intern benachrichtigt werden soll (z.B. Sicherheitszentrale, Empfang, Betriebssanitäter – als Einzelpersonen oder als ein Team in Teams). Überprüfen Sie auch Ihre Wählpläne: Sind 112 und 110 womöglich als interne Kurzwahlen vergeben? Falls ja, ändern Sie das unbedingt, um Verwechslungen auszuschließen. Dieser Planungsschritt ist entscheidend, damit Sie später alle nötigen Daten parat haben.
2. Notfall-Adressen in Teams anlegen: Öffnen Sie das Teams Admin Center und navigieren Sie zu “Orte” (bzw. im englischen TAC unter Locations > Emergency Addresses). Hier fügen Sie für jeden Standort eine neue Adresse hinzu. Geben Sie Straße, Hausnummer, PLZ, Ort, Land ein und – falls verfügbar – auch einen Ort innerhalb des Gebäudes (Building, Floor, etc.). Nutzen Sie den integrierten Lageplan, um die Adresse zu validieren (Teams/TAC zeigt meist einen Bing-Maps Vorschlag). Speichern Sie die Adresse. Optional können Sie per PowerShell New-CsOnlineLisCivicAddress verwenden (gerade wenn Sie Geokoordinaten mitgeben wollen oder sehr viele Adressen per Skript importieren möchten). Beispiel PowerShell:

New-CsOnlineLisCivicAddress -Description „Frankfurt Büro“ -StreetName „Mainzer Landstr.“ -StreetNumber „123“ -City „Frankfurt am Main“ -PostalCode „60327“ -Country DE -Latitude 50.1109 -Longitude 8.6821

(Die Geokoordinaten sind optional, können aber für die Standortauflösung hilfreich sein). Vergewissern Sie sich, dass alle Adressen im System als “verifiziert” erscheinen – ungeprüfte Adressen kann Teams im Notfall nicht nutzen.

1. Netzwerk-Standorte & Subnetze konfigurieren: Wechseln Sie im Teams Admin Center zu “Netzwerk & Standorte” (Network & Locations). Legen Sie zunächst Ihre Netzwerkregion(en) an (z.B. eine Region “Deutschland” oder falls Sie global tätig sind, pro Land eine Region). Darunter legen Sie dann für jeden physischen Standort einen Netzwerkstandort (Network Site) an. Beispiel: Site Name: Frankfurt, Region: Deutschland, Beschreibung: “Hauptsitz Frankfurt”. Weisen Sie jeder Site die zuvor angelegte Notfalladresse zu – das dürfte im TAC automatisch abgefragt werden (alternativ per PowerShell Set-CsTenantNetworkSite -Identity Frankfurt -EmergencyCallRoutingPolicy ECRP-Default -EmergencyCallingPolicy ECP-Default – zu den Policies gleich mehr). Nun fügen Sie pro Standort alle zugehörigen Subnetze hinzu: Im TAC unter der jeweiligen Site “+Subnetz hinzufügen” wählen, z.B. 10.5.0.0/16 -> Frankfurt. Bei WLAN ist es etwas versteckter: WLAN-Access-Point-MAC-Adressen (BSSIDs) können ebenfalls Locations zugeordnet werden, das geht nur per PowerShell:

Set-CsOnlineLisWirelessAccessPoint -BSSID „AA:BB:CC:DD:EE:FF“ -LocationId <GUID der Notfalladresse Frankfurt>

(Hierfür braucht man vorher die LocationId jeder Adresse via Get-CsOnlineLisLocation). Wenn das WLAN sehr komplex ist und viele APs hat, kann man diesen Schritt zunächst überspringen und sich auf Subnetze konzentrieren – wichtig ist nur, dass Teams erkennt, wenn jemand im Büro-Netz ist vs. extern. Dafür reichen oft schon die Gateway-IP oder DHCP-Scope der Standorte. Zusätzlich sollten Sie die Trusted IP Adresses setzen: Das sind die öffentlichen IPs Ihrer Unternehmens-Internetanschlüsse. Per PowerShell z.B.:

New-CsTenantTrustedIPAddress -IPAddress 1.2.3.4 -MaskBits 32 -Description „Internet Breakout Frankfurt“

Dadurch weiß Teams: alle Clients, die über diese IP ins Internet gehen, befinden sich “im Unternehmensnetz” – dann versucht Teams vorrangig die interne Standortzuordnung (LIS) zu nutzen, anstatt die Windows-Standortdienste.

1. Notruf-Routingrichtlinie erstellen: Als nächstes richten wir die Call Routing Policy für Notrufe ein. Im Teams Admin Center finden Sie dies unter Voice > Emergency Policies > Reiter Routing-Richtlinien. Erstellen Sie eine neue Richtlinie, z.B. “ECRP-NotrufDE”. In dieser Richtlinie aktivieren Sie “Dynamische Notrufe” (damit Teams überhaupt die Standortdaten zieht). Dann fügen Sie die Notrufnummern hinzu: Für Deutschland mindestens “112” und “110”. Sie können beide hier als separate Einträge hinzufügen. Weisen Sie jeder Notrufnummer eine PSTN-Usage bzw. Route zu:
2. Im Direct Routing Szenario wählen Sie hier eine PSTN Usage, die auf die Notruf-Trunks zeigt (z.B. wir hatten vielleicht eine Voice Route “Notruf” definiert, die alle Anrufe mit +49 112/ auf den SBC schickt). Microsoft empfiehlt, hier direkt einen speziellen ELIN-Gateway*-Eintrag zu nutzen, sofern vorhanden. In der Praxis reicht es, wenn Ihre normale Voice Route den Nummernplan korrekt behandelt (z.B. “112” darf nicht durch die Normalisierung als +112 fehlgeleitet werden – Teams Clients senden seit neuestem 112 ohne Plus raus).
3. Bei Operator Connect/Calling Plan können Sie als PSTN Usage einen Standard-Eintrag belassen oder “Notruf” eintragen – da diese Policy dort nur zur Erkennung dient, ist die Route egal (der Hinweis im Interface, eine PSTN Usage zu benötigen, kann ignoriert werden, bzw. nehmen Sie etwas wie “International” oder erstellen einen Dummy namens “Emergency” für die Konsistenz).

In PowerShell sähe das z.B. so aus:

New-CsTeamsEmergencyCallRoutingPolicy -Identity „ECRP-NotrufDE“ -EmergencyNumbers @(
    New-CsTeamsEmergencyNumber -DialString 112 -DialMask 112 -PstnUsage „Notruf“) `
    -EnableEnhancedEmergencyServices $true

Hier aktivieren wir erweiterte Notdienste = dynamisch, und definieren 112-> Notruf-Usage. 110 würden wir analog hinzufügen oder per UI als zweiten Eintrag. Speichern Sie die Richtlinie.

1. Notruf-Benachrichtigungsrichtlinie einrichten: Wechseln Sie im Teams Admin Center zum Reiter “Calling-Richtlinien” unter Voice > Emergency Policies. Hier erstellen wir z.B. “ECP-Notruf-Alarm” (Emergency Calling Policy). In dieser Richtlinie definieren Sie pro Notrufnummer, wer und wie benachrichtigt wird. Tragen Sie also bei 112 als Notification Group z.B. eine Teams-Gruppe oder ein Verteiler mit den Sicherheitsverantwortlichen ein (Tipp: Legen Sie in Azure AD eine Mail-Enabled Security Group an wie “Notruf-Alarm-Gruppe”, mit den entsprechenden Personen). Optional können Sie auch eine Telefonnummer für Benachrichtigungsanrufe angeben – z.B. die Handy-Nummer des Sicherheitschefs oder eine externe Leitstelle, die zusätzlich angerufen werden soll. Als Benachrichtigungsmodus wählen Sie zwischen:
2. Nur Benachrichtigung senden: (dann erhalten die Group Members einen Teams-Chat mit Alarm, aber kein Anruf)
3. Zur Konferenz hinzufügen (stumm): (die Gruppenmitglieder werden vom System ins Notrufgespräch eingewählt und sind standardmäßig gemutet – sie können mithören, aber nicht stören)
4. Zur Konferenz hinzufügen (mit Sprechrecht): (die Mitglieder werden eingewählt und können sich auch direkt zu Wort melden – Vorsicht: Das kann die Leitstelle verwirren, hier sollte man nur geschulte Personen ungemutet lassen)

Für 112 empfiehlt es sich oft, die stumme Konferenz plus Chat zu nutzen, damit die Sicherheitszentrale mithören kann, aber die Kommunikation zwischen Anrufer und Leitstelle nicht durcheinander gebracht wird. Für 110 könnten Sie separat behandeln (z.B. vielleicht nur Chat, da Polizeinotrufe intern oft weniger relevant sind – je nach Unternehmen). Sie können auch einen Test-Notrufcode hier definieren, z.B. 999, und für diesen einstellen “keine Benachrichtigung” – so können Sie Testanrufe durchführen, ohne jedes Mal den Sicherheitsdienst aufzuschrecken (dazu gleich mehr im Test-Kapitel).

In PowerShell ließe sich das folgendermaßen abbilden (zum Verständnis, UI ist einfacher):

$en1 = New-CsTeamsEmergencyCallingExtendedNotification -EmergencyDialString „933“
New-CsTeamsEmergencyCallingPolicy -Identity ECP1 -Description „Test ECP1“

(Die genaue Syntax für Extended Notifications ist komplex und in der Dokumentation beschrieben; es würde z.B. -NotificationMode, -NotificationGroup etc. im New/Set-CsTeamsEmergencyCallingPolicy erfordern. Meiner Erfahrung nach geht es im Admin Center bequemer.)

1. Zuweisung der Richtlinien: Jetzt haben wir die nötigen Objekte – aber wir müssen sie noch den Benutzern und Standorten zuweisen. Dabei gilt: Standortgebundene Zuweisung hat Vorrang vor Benutzer-Zuweisung (wie in der Architektur beschrieben). Das heißt, wenn ein User, der eigentlich Policy X hat, sich an einem Netzwerkstandort mit Policy Y befindet, zieht Y. Daher ist es sinnvoll, die Notruf-Routing- und Calling-Policies gleich direkt den Netzwerkstandorten zuzuweisen. Gehen Sie im TAC zu “Netzwerk & Standorte”, wählen Sie einen Site (z.B. Frankfurt) und klicken auf “Notfallrichtlinien zuweisen”. Dort können Sie die zuvor erstellte Routing-Richtlinie (ECRP) und die Calling-Policy (ECP) auswählen. Tun Sie das für alle relevanten Sites (ggf. haben kleine Standorte die gleiche Policy – dann zuweisen). Zusätzlich weisen Sie jedem User, der feste spezifische Anforderungen hat, die Policy auch direkt zu (per PowerShell:

Grant-CsTeamsEmergencyCallRoutingPolicy -PolicyName ECRP-NotrufDE -Identity user@firma.de

und analog Grant-CsTeamsEmergencyCallingPolicy für die Benachrichtigungspolicy). Wenn Sie keine individuellen Unterschiede haben, können Sie auch einfach die Globale Richtlinie bearbeiten: Viele wählen den bequemen Weg, die globale Routing-Policy zu modifizieren (dort 112/110 etc. hinterlegen), dann hat jeder User das automatisch. Ich rate allerdings dazu, eigene Policies anzulegen – zur Klarheit und weil globale Policy keine unterschiedlichen Settings je Standort kann.

Kontrollieren Sie nach Zuweisung: Ein User im Büro sollte im Teams-Client (unter Einstellungen > Notrufe) nun ggf. sehen, dass ein Standort erkannt wurde, wenn er verbunden ist im Firmennetz. In der Teams Admin Benutzerverwaltung sehen Sie unter Policies die zugewiesenen Notruf-Policies.

1. Konfiguration des SBC bzw. Abstimmung mit Provider: Wenn Teams-seitig alles steht, richten Sie nun Ihre Telefonanlage bzw. Provider-Seite ein:
2. Bei Direct Routing (SBC): Implementieren Sie die besprochenen Dialplan-Regeln. Konkret: Sorgen Sie dafür, dass eingehende Calls vom Teams an 112/110 über den richtigen Trunk gehen. Das kann bedeuten, im SBC eine Routingregel “Anrufe mit Request-URI = sip:112@… -> Route = lokaler Gateway” einzurichten. Konfigurieren Sie die Manipulation der Absendernummer nach Standort: typischerweise per Script oder Tabelle. Einige SBCs erlauben ein Mapping “Location-ID -> Caller ID”, andere erwarten separate SIP URIs je Standort. Testen Sie unbedingt auf dem SBC, dass wenn ein Invite mit “112” und z.B. PIDF-LO “Frankfurt” reinkommt, er genau die gewollte Aktion durchführt. Aktivieren Sie auch die Funktion, die eingehende Anrufe auf die ELIN-Nummern zum ursprünglichen Anrufer zurückvermittelt (oft automatisch gegeben, wenn der SBC die Session 30 Minuten hält).
3. Bei Operator Connect/Calling Plan: Hier müssen Sie vor allem dafür sorgen, dass der Provider die korrekten Adresseinträge hat. Loggen Sie sich ins Provider-Portal ein (falls vorhanden) und überprüfen Sie die Notruf-Adressen pro Nummer. Viele Provider bieten die Option, mehrere Adressen zu hinterlegen (z.B. Haupt- und Nebenstandort je Nutzer). Stellen Sie sicher, dass Ihr Provider zumindest weiß, wer an welchen Standorten sitzt. Teilen Sie dem Provider mit, dass Sie nomadische Nutzung haben – manche geben einem dann spezielle Notruf-Lösungen an die Hand. In Deutschland ist das Thema bei vielen Carriern noch in Bewegung, aber Nachfragen schadet nicht.
4. Bei Teams Phone Mobile: Abstimmung mit dem Mobilfunkanbieter ist key. Glücklicherweise regelt dort vieles die SIM automatisch. Dennoch sollte auch hier jeder Nummer eine primäre Adresse zugeordnet sein (die meist dem Vertragsstandort entspricht).
5. Test & Validierung durchführen: (Eigentlich kein Teil der “Konfiguration”, aber unverzichtbar!) Bevor Sie das Notrufsystem in Betrieb nehmen, führen Sie Trockenübungen durch. Nutzen Sie ggf. einen internen Test-Notrufcode (wie oben erwähnt, z.B. 999), den Sie in Teams als Notrufnummer eingerichtet haben, aber den Sicherheitsalarm für diesen auf “None” gesetzt haben und den SBC so programmieren, dass er 999 statt 112 anruft – etwa eine unternehmensinterne Hotline. So können Sie durchspielen, ob der Standort und die Caller-ID korrekt gesetzt werden. Kontrollieren Sie im Teams Client eines Benutzers: Wird die Adresse erkannt und angezeigt, wenn er im Büro ist? Und verschwindet sie, wenn er z.B. über Mobilfunk-Hotspot arbeitet (was gut wäre, weil dann der OS-Standort greifen würde)? Rufen Sie testweise mit einem Mitarbeiter-Handy bei Ihrer eigenen Notruf-DID an, um zu sehen, ob es zum Teams-Benutzer durchgestellt wird (Simulation eines Leitstellen-Rückrufs). Achtung: Einen echten 112-Testanruf sollte man nur in Rücksprache mit der Leitstelle machen (man kann dort anrufen über die normale Nummer und fragen, ob ein Test möglich ist – in der Regel verstehen die das in Randzeiten). Manche Leitstellen bieten spezielle Testzeiträume an. Wenn Sie testen, halten Sie es extrem kurz und erklären sofort “Dies ist ein Testanruf zur Leitstellenprüfung, kein Notfall”. In vielen Fällen reicht es aber, anhand der eigenen Logs und eines “Trockenanrufs” zu sehen, dass alles passt – so sparen Sie den Leitstellen die unnötige Belastung.

Nach Abschluss dieser Schritte haben Sie Microsoft Teams so weit eingerichtet, dass es die juristischen und technischen Anforderungen erfüllt. Natürlich steckt der Teufel im Detail (PowerShell-Ausgaben kontrollieren, Schreibfehler in IP-Bereichen vermeiden etc.), aber unser Leitfaden deckt die Kernpunkte ab. Im nächsten Kapitel schauen wir uns an, wie man die Umsetzung abnimmt, testet und im laufenden Betrieb verwaltet.

6. Tests, Abnahme & Betrieb

Nach der Implementierung folgt der ebenso wichtige Teil: Testen, Abnahme und das Etablieren eines zuverlässigen Betriebs. Hier entscheidet sich, ob das schöne Konzept in der Praxis Bestand hat.

Testszenarien & Abnahme

Bevor die Lösung offiziell “abgenommen” wird, sollten umfassende Tests durchgeführt werden. Erstellen Sie am besten einen Testplan mit allen relevanten Szenarien: – Jeder Standort: Ein Testanruf, um zu prüfen, ob die richtige Leitstelle erreicht würde (bzw. im Test simuliert wird). – Unterschiedliche Netzumgebungen: Test im Büro (sollte interne Adresse nutzen), Test von extern (sollte ggf. OS-Standort ziehen). – Verhalten von Common Area Phones: Können Sie ohne Anmeldung 112 wählen? Klingeln diese Geräte beim Rückruf? – Interne Alarmierung: Wird die definierte Sicherheitsgruppe benachrichtigt, inkl. Standortinfo? – Fallback-Szenarien: Simulation eines Cloud-Ausfalls (z.B. Teams-Client im Offline-Modus) – funktioniert der Notruf über SBA/SBC dennoch?

Die größte Herausforderung ist, echte Notrufe zu testen, ohne Missbrauch der Notrufnummern zu begehen. Folgende Ansätze haben sich bewährt: – Gesprächsaufbau ohne echte 112: Nutzen Sie alternative Rufnummern mit gleicher Länge. Beispiel: In manchen Städten gibt es Ansagedienste (Zeitansage, Wetteransage) mit kurzen Nummern (z.B. “0180 4 112 112” oder ähnliche). Sie können temporär in Ihrer Notruf-Routingpolicy statt 112 eine Testnummer eintragen und am SBC so tun, als wäre 11833 der Notruf. Wenn Sie diese Nummer wählen, hören Sie dann die Zeitansage – das ist zwar inhaltlich irrelevant, aber Sie sehen im SBC-Log und am angezeigten Caller ID, ob die Mechanik funktioniert hat (wurde die Nummer richtig ersetzt? Welcher Absender kommt an?). – Mobiltelefon-Check: Eine pragmatische Methode: Rufen Sie von Teams aus das Mobiltelefon eines Kollegen an und schauen Sie, welche Absendernummer angezeigt wird. Konfigurieren Sie dazu temporär im SBC, dass auch normale Anrufe aus einem bestimmten Test-Teams-Account mit der Notruf-CallerID rausgehen (so müssen Sie nicht 112 wählen, um den Effekt zu sehen). Wenn auf dem Handy z.B. “069 1234 110” erscheint, wissen Sie, dass Ihr Mapping funktioniert. – Spezielle Testnummer 933: In den USA gibt es die 933 als Notruf-Test. Microsoft Teams greift das auf – in Tenants mit US-Emergency-Routing liest 933 eine “Your emergency location is…” Ansage vor. In Deutschland ist dies nicht offiziell vorhanden, aber man könnte testweise 933 als Notrufnummer definieren und auf eine eigene Echo-Nummer routen. – Leitstelle informieren: Wenn Sie einen echten 112-Test vornehmen wollen, unbedingt vorher die zuständige Leitstelle telefonisch kontaktieren (über die nicht-notruf Nummer der Feuerwehr/Polizei) und das Vorgehen erklären. Oft stimmen sie einem kurzen Test in einer ruhigen Minute zu. Dann können Sie tatsächlich 112 von Teams aus anrufen und die Leitstelle fragen: “Welche Adresse sehen Sie? Welche Rufnummer wird übermittelt?”. Viele Leitstellenmitarbeiter geben bereitwillig Auskunft, solange man es nicht regelmäßig macht. Aber bitte: Halten Sie solche echten Tests auf ein Minimum beschränkt!

Definieren Sie, wann die Abnahme erfolgt: Z.B. nachdem jeder Standort erfolgreich getestet und protokolliert wurde. Lassen Sie die Ergebnisse von den zuständigen Personen (IT-Leitung, Sicherheitsbeauftragter) gegenzeichnen. Eine Abnahmedokumentation sollte enthalten: Datum, Tester, getestetes Szenario, erwartetes Ergebnis, tatsächliches Ergebnis, und eine Bestätigung, dass die Notruffunktion den Anforderungen entspricht. Dieses Dokument legen Sie zu Ihren Compliance-Unterlagen – falls später jemand fragt, können Sie nachweisen, dass Sie ordnungsgemäß vorgesorgt haben.

Betrieb & Wartung

Ist das Notrufsystem in Betrieb, gilt es, dran zu bleiben. Folgende Punkte gehören zum täglichen (bzw. periodischen) Betrieb:

• Datenpflege bei Änderungen: Ändert sich etwas an Ihrer Infrastruktur, müssen Sie die Notruf-Konfiguration mitändern. Klassisches Beispiel: Die Firma mietet ein neues Stockwerk an und bekommt neue IP-Adressen – dann muss der IT-Admin daran denken, diese Subnetze in Teams dem Standort zuzuordnen, und eventuell neue Notfalladressen für die zusätzliche Etage anzulegen. Oder Sie wechseln den Telefonanbieter – dann müssen die Notrufnummern (ELINs) ggf. portiert oder neu beschafft und im SBC angepasst werden. Solche Änderungen sollten in Ihren Change-Prozessen ausdrücklich eine Station “Notruf-Funktion prüfen/anpassen” enthalten.
• Schulung und Awareness: Alle Technik nutzt wenig, wenn Mitarbeiter im Ernstfall nicht wissen, was zu tun ist. Daher gehört die Notruf-Thematik in die Mitarbeiter-Unterweisungen. Empfehlenswert: Jährlich im Rahmen der Arbeitsschutzunterweisung kurz erläutern, wie man über Teams den Notruf erreicht, wo fest installierte Notfalltelefone zu finden sind, und was bei einem Ausfall zu tun ist (z.B. “Wenn das Firmen-Netz down ist, nutzen Sie Ihr Handy für 112.”). Neue Mitarbeiter sollten gleich am Onboarding-Tag diese Info erhalten – etwa in einem IT-Starter-Kit: “Unsere Telefonanlage ist cloudbasiert. Notrufe können Sie damit absetzen, aber beachten Sie bitte XY…”. Manche Unternehmen hängen auch kleine Merkzettel an die Monitore oder in Büroräume, um im Stressmoment die Info parat zu haben.
• Regelmäßige Tests: Nur weil es heute funktioniert, heißt das nicht, dass es in drei Jahren noch klappt – vor allem wenn zwischendurch Änderungen waren. Planen Sie daher regelmäßige Funktionstests ein. Zum Beispiel: einmal pro Jahr ein kontrollierter Test je Standort (ähnlich einem Feueralarm-Probeplan). Dies kann im Rahmen von Safety-Drills oder IT-Notfallübungen geschehen. Notieren Sie die Ergebnisse der Tests. Auch interne Alarm-Empfänger (Security-Personal) sollten ab und zu einen Probealarm bekommen, um die Reaktionswege zu trainieren.
• Monitoring & Logging: Beobachten Sie die Telemetrie. Microsoft Teams liefert im Admin Center Call-Logs – dort könnten Sie filtern nach “112” oder “110” um zu sehen, ob Notrufe getätigt wurden. Der SBC sollte Alarme werfen, wenn ein Notruf rausging (viele SBCs können bei bestimmten Call-Tags oder Nummern E-Mails senden). So erfahren Sie als Administrator vielleicht sogar vor dem Sicherheitsdienst, dass irgendwo ein Notfall ist, und können Unterstützung anbieten (z.B. sicherstellen, dass der Call nicht versehentlich von einem Dialplan geblockt wurde – man möchte nicht erst bei der Auswertung nach einem Unfall merken, dass 112 aus irgendeinem Grund nicht rausging).
• Dokumentation & Audit: Halten Sie Ihre Doku aktuell. Bewahren Sie eine Kopie der Konfiguration (Screenshots der Teams-Einstellungen, SBC-Export der relevanten Routing-Einträge) an einem sicheren Ort auf. Im Falle eines Audits (z.B. durch die Berufsgenossenschaft oder internen Revision) können Sie so schnell zeigen: wir haben uns um das Thema gekümmert und alles belegt. Zudem ermöglicht eine gute Dokumentation schnellen Support: Wenn z.B. der Sicherheitsbeauftragte meldet “Herr X hat neulich vom Homeoffice aus den Notruf gewählt und die Polizei stand erst an der Firmenadresse – was war da los?”, dann können Sie anhand Ihrer Unterlagen und Logs nachvollziehen, ob der Nutzer vielleicht die Standortfreigabe deaktiviert hatte oder ob ein Config-Fehler vorliegt.
• Kontinuierliche Verbesserung: Nach einem realen Notruf-Ereignis im Unternehmen sollten Sie eine Nachbesprechung machen (sofern es die Situation zulässt), mit allen Beteiligten: Hat die Technik funktioniert? Waren die internen Abläufe passend? Oft lernt man aus echten Vorfällen Feinjustierungen – z.B. vielleicht war der interne Chat-Alarm zu unauffällig und man entscheidet sich künftig doch für einen parallelen Telefonanruf an den Werkschutz. Oder man merkt, dass Mitarbeiter unsicher waren, ob sie die 0 vorweg wählen müssen – daraus ergibt sich, dass man das in der nächsten Schulung nochmal deutlich klarstellt.

Zusammengefasst erfordert der Betrieb etwas Disziplin, aber nichts Unmögliches: Es sind regelmäßige Checks, Updates und Trainings – alles Punkte, die gut planbar sind. Die Sicherheit, im Ernstfall gerüstet zu sein, ist den Aufwand allemal wert. Im nächsten Kapitel widmen wir uns einigen Spezialfällen – Migrationen und Sonderkonstellationen –, bevor wir dann zu Wirtschaftlichkeit und Checklisten kommen.

7. Sicherheit & Resilienz

In einem Notrufsystem geht es nicht nur um initiale Funktion, sondern auch um Sicherheit (im Sinne von IT-Security und Datenschutz) sowie Resilienz (Widerstandsfähigkeit gegen Störungen). Dieser Abschnitt beleuchtet einige Aspekte, die über die pure Konfiguration hinausgehen.

Datenschutz und Missbrauchsschutz: Die Erfassung von Standortdaten und das Mitsenden an eine Leitstelle werfen natürlich Datenschutzfragen auf. Mitarbeiter könnten befürchten, durch Teams dauerhaft “getrackt” zu werden. Hier ist Aufklärung wichtig: Teams erfasst den Standort nur im Notruffall oder wenn der Nutzer zustimmt. Es gibt keine permanente Ortung im Hintergrund. Tatsächlich speichert der Teams-Client dynamisch ermittelte Adressen nur temporär und löscht sie beim Abmelden. Als Arbeitgeber sollten Sie transparent kommunizieren, dass Standortdaten ausschließlich zum Zweck der Notfallhilfe genutzt werden. Im Datenschutzkonzept kann dies unter “berechtigtes Interesse – Schutz von Leben und Gesundheit” aufgeführt werden. Wichtig: Die intern Benachrichtigten (z.B. Sicherheitsmitarbeiter) müssen diese Informationen vertraulich behandeln. Es geht nicht darum, aus Neugier Bewegungsprofile zu erstellen, sondern im Ereignisfall gezielt helfen zu können. Zugriff auf etwaige Protokolle (wer hat wann Notruf gewählt) sollte streng begrenzt sein. Empfehlenswert ist, diese Punkte mit dem Datenschutzbeauftragten und – falls vorhanden – dem Betriebsrat vorab abzustimmen, um Akzeptanz zu schaffen.

Außerdem sollte das System so gestaltet sein, dass Missbrauch erschwert wird. Beispiel: Jeder Mitarbeiter kann natürlich 112 wählen (muss er können), aber unnötige Testanrufe oder gar böswillige Falschnotrufe sollte man administrativ adressieren. Klären Sie in Schulungen, dass Spaßanrufe bei 112 kein Kavaliersdelikt sind. Durch die interne Alarmierung bekommt im Zweifel auch der Vorgesetzte mit, wenn jemand grundlos den Notruf betätigt – allein das schreckt schon ab. Technisch könnten Sie 112 nicht sperren (sollten Sie auch nicht), aber Sie können darauf vertrauen, dass die Hürde, tatsächlich die Feuerwehr zu rufen, hoch genug ist, dass hier kein “Übergebrauch” stattfindet.

Authentizität der Notrufinformationen: Ein potenzielles Sicherheitsrisiko ist Manipulation oder Fehler bei den übermittelten Daten. Stellen Sie sicher, dass nur autorisierte Admins die Notrufkonfiguration ändern können (Role-Based Access Control in Teams verwenden!). Ein falsch konfigurierter Standort kann im Ernstfall zu Fehlleitungen führen. Führen Sie Änderungen stets in einer Testumgebung oder mit Anrufen außerhalb der Stoßzeiten aus und kontrollieren Sie sie (Prinzip 4-Augen, gerade bei sensiblen Dialplan-Regeln). Ebenfalls sollten SBCs und Clients up-to-date gehalten werden – Sicherheitsupdates nicht vergessen, damit kein Angreifer Schwachstellen ausnutzen kann, um z.B. Notrufe umzuleiten.

Resilienz bei Ausfällen: Ein Notrufsystem muss auch unter ungünstigen Bedingungen funktionieren. Daher gilt es, einzelne Fehlerquellen abzufedern: – Internet- oder Cloud-Ausfall: Wie schon in Architektur und Betrieb angesprochen, empfiehlt sich für wichtige Standorte eine Backup-Connectivity (z.B. LTE-Failover). Zudem kann die Survivable Branch Appliance (SBA) vor Ort sicherstellen, dass auch ohne Verbindung zur Teams-Cloud der Anruf über den lokalen Gateway rausgeht. Beachten Sie: Der SBA-Ansatz deckt nur Direct Routing ab – bei Operator Connect oder Calling Plans haben Sie ohne Internet leider keine Verbindung. In solchen Fällen greift Plan B: Mobiltelefon. Mitarbeiter sollten angehalten sein, bei kompletter Systemstörung sofort zum Handy zu greifen für Notrufe. Hier kann die Firma unterstützen, indem sie Diensthandys bereitstellt oder zumindest sicherstellt, dass Mitarbeiter private Handys griffbereit haben dürfen (kein Verbot am Arbeitsplatz für Handys, was in manchen Bereichen relevant sein könnte). – Stromausfall: Wie redundant sind Ihre Standorte bei Strom weg? Wenn Telefone übers PoE an USV-gesicherten Switches hängen, schon mal gut. Denken Sie aber auch an WLAN-APs (falls Softphones auf Laptops ohne Ethernet genutzt werden) – ohne Strom kein WLAN. Eventuell lohnt es, ein, zwei strategische Access Points mit Notstrom auszustatten oder ein GSM-basierter Notfallapparat vorzuhalten. In kritischen Umgebungen (Chemielabore, Aufzüge, etc.) sollte man ohnehin unabhängige Notrufmittel haben (z.B. fest installierte Notruftaster oder Nottelefone, die direkt über das Mobilfunknetz oder klassische Leitungen kommunizieren). Prüfen Sie, ob solche separaten Systeme nötig sind. – Leitstellen-Ausfall: Dieser Fall ist sehr unwahrscheinlich, da Notrufzentralen hochverfügbar sind. Aber selbst wenn z.B. die zuständige Leitstelle ausfällt, werden Notrufe i.d.R. automatisch an eine benachbarte Leitstelle umgeroutet. Hier können wir als Unternehmen wenig tun außer Vertrauen ins System haben. Wir sollten aber in der internen Doku festhalten: Wenn man z.B. 112 wählt und nach 20 Sekunden niemand dran ist (extrem selten), sollte man Plan B versuchen (Polizei 110 oder Handy). Das gehört evtl. in die Schulung “Wie verhalte ich mich im Notfall”.

Integration ins Notfallmanagement: Das Notrufsystem sollte kein isoliertes IT-Ding sein, sondern Teil des gesamtheitlichen Notfall- und Krisenmanagements der Firma. Das bedeutet: – Die Sicherheits-/Facility-Abteilung kennt die Funktionsweise und weiß, was zu tun ist, wenn sie eine Teams-Alarmierung erhält (z.B. zuerst interne Kräfte hinschicken, parallel Empfang informieren, etc.). – Es gibt klare Prozesse, wer bei einem Notruf intern informiert wird und wer Meldung an Management gibt (z.B. Arbeitsunfall-Meldung). – Das System selbst sollte getestet sein im Zusammenspiel mit z.B. Brandmeldeanlagen oder Evakuierungsübungen. Beispielsweise: In einer Evakuierungsübung könnte man simulieren, dass jemand “verletzt” ist und einen internen Notruf absetzt – testet, ob die interne Rettungskette plus Teams-Benachrichtigung wie gedacht funktionieren. – Beachten Sie auch Sonderfälle wie Aufzugsnotrufe: Diese laufen meist autark (über fest installierte Module mit SIM-Karten, die direkt bei Notdiensten auflaufen). Solche Systeme sollten nicht auf Teams umgestellt werden – hier ist Resilienz wichtiger als Integration. Lassen Sie Aufzüge, Brandmelder und Co. auf ihren getrennten Wegen. Teams-Notrufe betreffen primär die individuelle Kommunikation der Mitarbeiter.

Fazit: Sicherheit & Resilienz heißt, sich Worst-Case-Szenarien auszumalen und Vorkehrungen zu treffen. Durch technische Redundanz (USV, SBA, zweiter Provider) und organisatorische Regeln (Handy als Backup, regelmäßige Übungen) wird das System robust. Gleichzeitig muss der Datenschutz gewahrt bleiben – klare Kommunikation und Beschränkung der Datenverwendung auf den Notfallfall schaffen hier Vertrauen. Insgesamt kann man sagen: Eine gut konfigurierte Teams-Telefonie kann ebenso sicher und resilient betrieben werden wie eine traditionelle Telefonanlage – man muss nur die richtigen Stellschrauben kennen. Im nächsten Kapitel betrachten wir noch Migrationen und Sonderfälle, um auch da gewappnet zu sein.

8. Migrationspfade & Sonderfälle

Die Realität in Unternehmen ist selten “Grüner Wiese”. Oft führen wir Notruf-Funktionen in Microsoft Teams ein, während noch ein Alt-System existiert oder spezifische Szenarien besondere Lösungen erfordern. Dieser Abschnitt gibt Hinweise zu typischen Migrationspfaden und Sonderfällen.

Migration von alter TK-Anlage zu Teams: Stellen Sie sich vor, Ihr Unternehmen hat bisher eine klassische Telefonanlage, und Sie migrieren schrittweise Benutzer zu Teams-Telefonie. In der Übergangszeit laufen zwei Systeme parallel. Wie stellt man hier den Notruf sicher? – Der Idealfall ist, beide Systeme separat notruf-fähig zu halten: Die verbleibende TK-Anlage konnte bisher 112, das bleibt so (ISDN/Analoganschlüsse nicht vorzeitig kappen). Gleichzeitig konfigurieren Sie Teams schon für die migrierten User mit Notruf (etwa über Direct Routing mit dem SBC). Falls Sie denselben SBC für beide nutzen, achten Sie darauf, dass Notrufe aus beiden Systemen korrekt rausgehen. – Eine häufige Übergangslösung ist, Notrufe aus Teams vorerst über die alte Anlage zu routen. Beispiel: Teams ist per Direct Routing mit dem alten PBX gekoppelt, und alle 112/110 Calls von Teams werden intern ans PBX übergeben, die sie dann wie gewohnt über ISDN ausleitet. Dies erfordert aber Integration und sollte nur kurzfristig sein – besser ist, so schnell wie möglich Teams eigenständig notruf-fähig zu machen. – Planen Sie den Zeitpunkt des Umschwungs sorgfältig: Oft werden Rufnummern portiert vom alten zum neuen Provider. Koordinieren Sie, dass an Portierungstagen jemand testet, ob 112 noch geht (ggf. war die Nummer kurz offline, oder Routen am SBC müssen angepasst werden). – Kommunizieren Sie intern in der Migrationsphase klar: Solange nicht sicher alles umgestellt ist, dürfen Mitarbeiter auch gern weiterhin das Notruf-Festnetztelefon nutzen, falls vorhanden. Lieber ein Anruf doppelt als gar nicht. – Sobald die alte Anlage außer Betrieb geht, testen Sie final mit Teams (ggf. realer Test mit Leitstelle), um die Endabnahme zu machen.

Migration zwischen Providern/Technologien: Vielleicht wechseln Sie nur den Telefonanbieter oder von Direct Routing zu Operator Connect. – Hier ist zu beachten, dass neue Anbieter oft eine eigene Notruf-Adresserfassung haben. Überschneiden Sie nach Möglichkeit keine Betriebsphasen ohne Notruf: Also erst wenn der neue Weg getestet und aktiv ist, den alten kündigen. – Beispiel: Sie wechseln von SIP-Trunk (Direct Routing) zu Microsoft Calling Plan. In der Übergangszeit könnten beide parallellaufen – weisen Sie einem Testuser schon mal eine Calling-Plan-Nummer zu und probieren Sie Notruf damit, bevor Sie alle umschalten. – Achten Sie bei Portierungen darauf, Notruf-Nummern nicht zu verlieren. Wenn Sie ELIN-Nummern verwendet haben, portieren Sie diese ebenfalls oder beschaffen Sie entsprechende in der neuen Umgebung. Aktualisieren Sie Ihre Teams-Routingregeln sofort, damit sie auf die neuen Trunks zeigen.

International verteilte Mitarbeiter: Ein Sonderfall ist, wenn Mitarbeiter in anderen Ländern arbeiten als dort, wo ihre Nummer registriert ist (z.B. ein deutscher Mitarbeiter lebt temporär in Frankreich, behält aber seine +49 Nummer in Teams). Teams warnt hier zu Recht: “Place emergency calls via local provider.” Denn unsere Teams-Konfiguration mag noch so gut sein – wenn der Benutzer in Frankreich 112 in Teams wählt, landet er ohne spezielle Vorkehrung bei einer deutschen Leitstelle oder der Anruf geht gar nicht erst raus (falls z.B. unser deutscher SBC keinen französischen Notruf vermittelt). – Für solche Fälle gibt es ein paar Ansätze: Policy Routing pro Standort – man könnte einen “Standort Frankreich” in Teams anlegen und dort eine Notruf-Routingpolicy zuweisen, die 112-Anrufe an einen französischen Operator Connect leitet. Das erfordert aber, dass man überhaupt einen PSTN-Zugang in FR hat und im Tenant nutzen darf (Lizenzthemen und technische Machbarkeit). – Pragmatiker-Lösung: Weisen Sie solchen Nutzern eine lokale Prepaid-SIM fürs Handy zu und instruieren Sie sie, im Notfall das Mobiltelefon zu nehmen. Oder nutzen Sie Teams Phone Mobile, falls verfügbar, mit lokalem Partner – dann übernimmt das Mobilnetz. – Generell gilt: Im Ausland immer die landesspezifische Notrufnummer wählen, wenn man unsicher ist. In der EU funktioniert zwar überall 112, aber z.B. in den USA müssen Europäer wissen, dass 112 auf Mobiltelefonen zwar auch geht (übersetzt zu 911), aber von unserem Teams ohne US-Konfiguration nicht ohne weiteres. – Wenn Ihr Unternehmen viele Global Nomads hat, könnten Sie als “Sonderausstattung” eine Art Notfall-Kurzwahl in Teams einrichten, die einen internen Ansprechpartner alarmiert, der dann Hilfe organisiert. Zum Beispiel ein Teams-Bot, wo man per Klick “Emergency” auslöst, und die Firmenzentrale ruft lokal Hilfe. Das ist allerdings aufwendig und rechtlich sensibel – im Zweifel sollte man sich auf die lokalen öffentlichen Notrufsysteme verlassen.

Home-Office und mobiles Arbeiten: Nach 2020 ist Home-Office alltäglich. Für Notrufe bedeutet dies: – Der Mitarbeiter zuhause hat zwar Teams, aber nicht die Firmeninfrastruktur um sich herum. Wir müssen also sicherstellen, dass der Notruf von dort aus funktioniert. Wie zuvor beschrieben, versucht Teams im Home-Office per WLAN/GPS den Standort zu ermitteln. Die Herausforderung: Viele Heim-User deaktivieren aus Datenschutzgründen die Standortdienste oder das Firmen-Laptop hat keine Berechtigung. Als Admin können Sie Gruppenrichtlinien nutzen, um Teams den Standortzugriff zu erlauben, aber es bleibt am Ende die Verantwortung des Users. Schulen Sie daher: “Wenn Sie daheim mit Teams 112 rufen, nennen Sie unbedingt gleich Ihre Adresse, falls das System sie nicht kennt.” Dieser Hinweis ist wichtig, denn der Dispatcher am Notruf kann nur sehen, was das System liefert – im Zweifel also die Firmenadresse, wenn der Home-User stur nichts sagt. – Ein weiterer Punkt: Strom & Internet im Home-Office. Fällt beim Mitarbeiter daheim der Strom aus (und damit WLAN-Router), ist Teams offline. Hier muss klar sein: dann bleibt nur das Handy oder Nachbarn. Arbeitsschutz-technisch ist das ein Grenzbereich – streng genommen müsste der Arbeitgeber sicherstellen, dass auch Home-Worker Notruf absetzen können. Praktisch verlässt man sich auf die allgemeine Versorgung (Mobilfunknetz). Sie könnten Home-Office-Kits mit LTE-Stick als Backup ausstatten, wenn Sie sehr fürsorglich sind. Meist reicht aber die Anweisung: “Bei größerer Störung bitte Handy nehmen für Notrufe.”

Interne Notrufnummern (Werkschutz, Erste Hilfe): Viele Unternehmen haben zusätzlich zur externen 112 eine interne Notrufnummer (z.B. 1122 oder 7777), die den Werkschutz oder Sanitäter im Haus erreicht. Vergessen Sie nicht, auch diese in Teams abzubilden. Nutzen Sie Dialpläne, um z.B. 7777 auf ein Teams-Telefon der Sicherheitszentrale zu routen oder als Call Queue an alle Ersthelfer-Handys. Hierbei gelten ähnliche Regeln: Die Nummer muss ohne Präfix wählbar sein und überall funktionieren (auch vom Teams-Mobile-App etc.). Schulen Sie die Mitarbeiter, wofür welche Notrufnummer gedacht ist (z.B. “Bei Feuer/medizinisch immer 112, bei kleineren Unfällen intern 7777” oder wie Ihre Policy lautet). Interne Notrufe können sinnvoll sein, um z.B. bei weniger kritischen Fällen zuerst interne Hilfe zu holen – aber bei Zweifeln sollte immer parallel 112 gerufen werden. Stellen Sie auch sicher, dass interne Notrufnummern nicht mit öffentlichen kollidieren – z.B. die 110 intern als Polizei-Werkschutz zu belegen wäre fatal, weil Mitarbeiter diese Nummer mit externer Polizei gleichsetzen.

Barrierefreiheit: Ein Sonderfall sind Mitarbeitende mit Hör- oder Sprachbehinderung. Über ein normales Telefon können sie schwer kommunizieren. Früher gab es Notruf-Fax oder TTY, heute in Deutschland die Möglichkeit, per SMS an die 112 eine Notfallmeldung abzusetzen (in einigen Bundesländern) oder spezielle Notfall-Apps für Gehörlose (z.B. Tess Relay-Dienste). Teams unterstützt solche spezifischen Verfahren nicht direkt. Hier sollte das Unternehmen individuelle Lösungen parat haben: Etwa die betroffenen Mitarbeiter mit einer geeigneten App auf dem Handy ausstatten und in der Notruf-Doku vermerken, wie der Ablauf ist (z.B. “Mitarbeiterin A sendet im Notfall Textnotruf via App X, der Sicherheitsdienst wird automatisch über Y informiert”). Dies ist ein sehr spezieller Bereich – falls relevant, ziehen Sie die Schwerbehindertenvertretung oder Experten hinzu, um eine passende Lösung zu finden. Wichtig ist, dass alle Mitarbeiter – unabhängig von Handicap – im Ernstfall Hilfe rufen können.

Zusammenführung unterschiedlicher Systeme: Haben Sie z.B. nach einer Firmenübernahme zwei Telefoniesysteme (und damit zwei Notrufkonzepte) parallel, sollten Sie möglichst rasch vereinheitlichen. Solange das nicht geschehen ist, halten Sie beide Systeme funktionsfähig und schulen Sie die Mitarbeiter je nach Standort. Es empfiehlt sich, bei einer Integration Priorität auf das Notrufthema zu legen – also lieber zuerst die Standorte in Teams migrieren, die bislang eine unsichere Notrufversorgung hatten. Oft ist das ein gutes “Verkaufsargument” für das Projekt: Wir verbessern mit Teams die Sicherheit (z.B. durch interne Alarmierung, die alte Anlage vielleicht nicht hatte).

Man merkt: Es gibt viele Sonderfälle – aber mit gesundem Menschenverstand und Kenntnis der technischen Möglichkeiten lässt sich jeder adressieren. Wichtig ist, die Sonderlocken in Ihrem Notfallkonzept zu dokumentieren: Was gilt im Home-Office? Was gilt auf Dienstreise? Was tun behinderte Mitarbeiter? etc. Die meisten dieser Fälle liegen außerhalb der direkten Teams-Konfiguration und erfordern organisatorische Lösungen. Aber Teams kann in vielen Bereichen unterstützen, wenn man es richtig einstellt. Damit sind wir beim letzten inhaltlichen Kapitel angekommen: Wie rechnen sich diese Lösungen, was gibt es vertraglich zu beachten – und schließlich folgt noch ein umfangreicher Anhang mit Checklisten, Beispielen und FAQ.

9. Wirtschaftlichkeit & Vertragsaspekte

Auch wenn Sicherheit an erster Stelle steht, müssen Projekte sich meist rechnen. Glücklicherweise ist die Umsetzung der Notruffunktion in Teams kein Kostentreiber, aber ein paar Überlegungen dazu und zu vertraglichen Punkten sind sinnvoll.

Kostenfaktoren der technischen Umsetzung: Microsoft Teams selbst bringt die Notruffunktionen ohne Aufpreis mit – es braucht keine zusätzliche Lizenz von Microsoft (die Funktionen sind in der Phone System Lizenz enthalten). Kosten entstehen eher indirekt: – SBC und Infrastruktur: Wenn Sie Direct Routing nutzen, haben Sie ggf. einmalig in einen SBC investiert (Hardware oder VM, vielleicht 4- oder 5-stellig in Euro). Für Notrufe kommt eventuell eine ELIN-Lizenz hinzu (einige SBC-Hersteller verlangen einen Aufpreis für das E911-Modul). Diese Kosten sind aber überschaubar (im Vergleich z.B. zu einer E3/E5 Lizenz pro Nutzer). – Telefonnummern und Leitungen: Sie brauchen pro Standort mindestens eine zusätzliche Telefonnummer als ELIN bzw. für Common-Area-Phones. Eine zusätzliche Ortsrufnummer kostet meist nur ein paar Euro im Monat. Die Bereitstellung einer separaten Notruf-Leitung pro Standort (falls man so plant) erzeugt monatliche Fixkosten – aber hier reden wir z.B. über einen Basis-SIP-Trunk mit vielleicht 2 Kanälen, also ebenfalls gering (10-20 € im Monat, je nach Anbieter). Selbst wenn man sehr redundant plant (z.B. zwei Carrier parallel für Ausfallsicherheit), bewegen wir uns in kleinen Beträgen relativ zur gesamten IT. – Endgeräte: Falls Sie entschieden haben, pro Etage ein Teams-Telefon für Notfälle anzubringen, müssen diese angeschafft werden. Ein einfaches Teams-Telefon kostet um die 100-200 €. Dazu Common-Area-Lizenzen (~$8 pro Gerät pro Monat). Wenn Sie 10 solcher Telefone installieren, sind das Einmalkosten von vielleicht 1.500 € plus 80 € laufend pro Monat – absolut vertretbar für die Sicherheit. – Implementierungsaufwand: Hier fließt Arbeitszeit Ihrer IT oder externer Dienstleister hinein. Das Schreiben von Dialplänen, das Einrichten von Policies, Tests etc. – schätzen wir, dass ein erfahrener UC-Consultant dafür einige Personentage benötigt. In Geldeinheiten vielleicht ein niedriger vierstelliger Betrag. Aber bedenken Sie: Diese Konfiguration ist einmalig. Danach fällt nur noch minimaler Pflegeaufwand an. – Schulungen & Dokumentation: Das sind “weiche” Kosten. Ein, zwei Stunden pro Jahr in Sicherheitsunterweisungen aufzuwenden oder Info-Material zu erstellen – das kostet intern Zeit, aber lässt sich kaum beziffern.

Dem gegenüber steht der Nutzen: einerseits die Compliance (Erfüllung gesetzlicher Pflichten, Vermeidung von Strafen), andererseits der Schutz von Leben und Sachwerten. Es ist schwierig, letzteres in Euro auszudrücken – aber man stelle sich nur vor, durch eine gut funktionierende Notrufalarmierung wird bei einem Herzinfarkt am Arbeitsplatz eine Minute schneller reanimiert, was das Leben rettet. Oder durch die interne Mitteilung über Teams kann ein Entstehungsbrand von der Werkfeuerwehr gelöscht werden, bevor die öffentliche Feuerwehr eintrifft – potenziell Hunderttausende Euro Schaden verhindert. Solche Fälle sind zum Glück selten, aber wenn, dann ist eine funktionierende Notrufkette unbezahlbar.

Risiken bei Nichtstun: Sollte ein Unternehmen die Notruffähigkeit vernachlässigen und es kommt zu einem Zwischenfall, drohen neben dem menschlichen Leid auch finanzielle Konsequenzen: – Haftungsfragen: Käme jemand zu Schaden, weil kein Notruf abgesetzt werden konnte oder falsch geleitet wurde, könnten Angehörige oder Unfallversicherung prüfen, ob Fahrlässigkeit vorlag. Das kann zu Schadensersatzforderungen führen. Zwar ist so ein Szenario komplex (und zum Glück selten), aber allein die juristischen Kosten wären erheblich. – Bußgelder: Die Bundesnetzagentur könnte theoretisch gegen den Provider oder das Unternehmen vorgehen, wenn Notrufpflichten verletzt wurden. In der Praxis ist mir kein Fall bekannt, wo ein Unternehmen für interne Notruf-Missstände bestraft wurde – meist konzentrieren sich die Regulierer auf die öffentlichen Anbieter. Dennoch: Will man wirklich ausprobieren, ob man der erste Präzedenzfall wird? – Reputationsschaden: Sollte bekannt werden, dass ein Notruf bei Ihnen nicht funktioniert hat (“Mitarbeiter erleidet Unfall – Telefonanlage versagte beim Notruf”), wäre das ein PR-Desaster. Kunden und Mitarbeiter verlieren Vertrauen. Solche Image-Schäden sind schwer zu beziffern, aber sicher teurer als die paar Tage Aufwand, die nötig gewesen wären, um es zu verhindern.

Vertragsaspekte mit Providern: Wenn Sie mit Telefonieanbietern arbeiten (sei es klassischer Carrier, Operator Connect Partner oder Microsoft selbst), sollten Sie einige Punkte vertraglich klären oder zumindest bewusst prüfen: – Notrufpflicht im Vertrag: In Deutschland muss jeder öffentlich Telefondienst Notrufe ermöglichen – das steht oft nicht explizit im Vertrag, da gesetzliche Pflicht. Dennoch schauen Sie ins Kleingedruckte: Manche VoIP-Anbieter schließen nomadische Nutzung aus oder weisen darauf hin, dass der Notruf nur an der angemeldeten Adresse gilt. Beispiel: Ein Cloud-PBX-Anbieter könnte sagen “Unser Dienst ist nur am Firmenstandort X vorgesehen; Nutzung woanders erfolgt auf Risiko des Kunden”. Solche Klauseln sollte man kennen. Ideal ist ein Anbieter, der nomadische Nutzung erlaubt und unterstützt – dann sind sie nämlich auf die Thematik vorbereitet. – Adressverwaltung: Klären Sie mit dem Anbieter, wie Adressdaten gepflegt werden müssen. Manche verlangen z.B., dass jede Nummer genau eine feste Adresse hat und Änderungen schriftlich mitgeteilt werden müssen. Andere bieten Portale, wo Sie Adressen selbst hinterlegen können. Wieder andere (wie Microsoft) erwarten die Adressen im Admin Center. Stellen Sie sicher, dass diese Prozesse praktikabel sind. Beispiel: Falls Ihr Unternehmen oft umzieht oder Arbeitsplätze rotieren, muss es möglich sein, Adressänderungen zeitnah einzupflegen – sonst hinkt die Datenbasis hinterher. – Haftung & SLA: Prüfen Sie die Service Level Agreements in Bezug auf Notruf. Viele Anbieter schließen Haftung für indirekte Schäden aus (was üblich ist). Aber interessant ist: Gibt es Garantien zur Erreichbarkeit des Notrufs? Einige Provider haben in ihren SLAs stehen, dass im Falle einer Störung die Notrufverbindungen bevorzugt aufrechterhalten werden oder über Ersatzwege geleitet werden. Falls Sie eine Auswahl zwischen Providern haben, könnte so ein Punkt den Ausschlag geben. – Auslandsnutzung: Wenn Sie internationale Offices haben, lohnt es sich, Verträge mit globalen Providern zu erwägen, die eine konsolidierte Lösung bieten. Es gibt Anbieter, die Notrufe in vielen Ländern über eine Plattform abwickeln (z.B. Bandwidth, Twilio, etc. für die USA, oder Deutsche Telekom mit NGN für EU-Länder). Ein Rahmenvertrag, der alle Standorte abdeckt, vereinfacht das Management. Aber Vorsicht: Oft müssen trotzdem je Land lokale Notrufkonzepte umgesetzt werden, weil die Rechtslage unterschiedlich ist. – Notfall-Vereinbarungen: Überlegen Sie, ob Sie mit einem Sicherheitsdienstleister Verträge schließen möchten, der im Notfall reagiert. Einige Firmen haben z.B. einen Vertrag mit einer Notruf- und Serviceleitstelle (NSL), die alarmiert wird, wenn intern etwas passiert (z.B. Alarmanlage, aber auch personal Emergency). Das ist in der Regel eher für Gebäudealarme. Für Personennotrufe verlässt man sich primär auf 112. Aber falls Ihr Standort abgelegen ist (z.B. Forschungsanlage auf dem Land) und Sie eine Werkschutzleitstelle 24/7 haben, könnte man auch vereinbaren, dass diese bei internen Notrufen immer informiert wird und eine Art First Responder schickt. Solche Verträge sind aber individuell. – Versicherung: Ein Vertragsthema am Rande: Überprüfen Sie, ob Ihre Betriebs-Haftpflicht solche Notfallszenarien abdeckt. Einige Versicherer bieten Rabatte, wenn man gute Notfallkonzepte hat (analog zu Brandschutz). Zwar ist das kein direkter IT-Vertrag, aber ein Punkt für das Risk Management: Durch die Investition in Notruf-Funktion könnten Sie argumentieren, dass das Risiko gemindert ist – vielleicht ein Pluspunkt im nächsten Audit.

Intern einkalkulieren: Planen Sie intern genug Budget und Ressourcen für: – Regelmäßige Wartungstests: Das kostet vielleicht pro Jahr ein paar Personentage (Testanrufe durchführen, Dokumentation updaten). – Schulung: Wie erwähnt, hin und wieder die Belegschaft zu informieren (kostet Arbeitszeit). – Modernisierung: Ihre Lösung muss mit der Zeit gehen. Vielleicht gibt es in Zukunft neue Anforderungen (z.B. EU-weite Einführung einer eCall-ähnlichen Standortmeldung auch für VoIP – da wäre evtl. ein Software-Update fällig). Halten Sie dafür ein kleines Pufferbudget. Meist sind das aber nur Softwareupdates, die in bestehenden Wartungsverträgen abgedeckt sind.

Summa summarum ist die Wirtschaftlichkeit klar gegeben: Für relativ geringe laufende Kosten erkaufen Sie sich die Gewissheit, gesetzeskonform zu sein und im Notfall schnell reagieren zu können. Anders formuliert: Der “Return on Investment” einer Notruf-Lösung zeigt sich im Idealfall nie – nämlich dann, wenn trotz implementierter Maßnahmen kein Notfall eintritt. Aber man kann ihn als Versicherung betrachten: Die Prämie ist gering, der mögliche Nutzen unendlich hoch.

Bezüglich Verträgen gilt: Frühzeitig mit allen Stakeholdern sprechen – IT, Legal, Provider, Security – damit es keine bösen Überraschungen gibt. Die allermeisten Provider kommen ihren Pflichten nach, aber im Zweifelsfall sorgen Sie selbst durch clevere Konfiguration vor. Damit sind wir inhaltlich fast am Ende. Abschließend habe ich im nächsten Kapitel noch praktische Checklisten, Tabellen und Vorlagen zusammengestellt, um Ihnen die Umsetzung zu erleichtern.

10. Checklisten, Tabellen & Vorlagen

Zum Abschluss präsentiere ich Ihnen hier kompakt Checklisten und Vorlagen, die Sie direkt verwenden oder anpassen können. Diese fassen die vorherigen Kapitel in greifbare Listen und Tabellen zusammen – ideal, um nichts zu übersehen.

Checkliste: Planung & Vorbereitung

• Standorte identifiziert: Alle physischen Standorte/Büros auflisten, inklusive vollständiger Adresse. (🔲 erledigt)
• Adressvalidierung: Jede Adresse in Online-Kartendienst geprüft (Schreibweise, Eindeutigkeit). (🔲)
• Netzwerkdaten gesammelt: Für jeden Standort alle IP-Subnetze (LAN) und WLAN-AP-Identifikatoren (BSSID) erfasst. (🔲)
• Telefonie-Anbindung pro Standort geklärt: Direct Routing (SBC vor Ort oder zentral?), oder Operator Connect/Calling Plan? (🔲)
• Notruf-Abgang je Standort definiert: z.B. welcher SIP-Trunk soll genutzt werden, braucht es lokale Amtsleitung? (🔲)
• ELIN-Nummern reserviert: Für jeden Standort ggf. eine Rückrufnummer (Durchwahl) beschafft, inkl. Registrierung beim Provider mit Standortadresse. (🔲)
• Interne Alarmempfänger bestimmt: Wer (Namen/Teams-Gruppe) soll intern benachrichtigt werden, wenn Notruf abgesetzt wird? Zustimmung/Briefing dieser Personen erledigt. (🔲)
• Regelwerk festgelegt: Dokumentiert, wann Mitarbeiter 112 vs. interne Nummer nutzen sollen, Verhalten im Home-Office, etc. (🔲)
• Rollen & Berechtigungen: Zuständiger Admin benannt, Berechtigung im Teams Admin Center für Notruf-Konfig geprüft. (🔲)

Checkliste: Umsetzung in Microsoft Teams

• Notfalladressen angelegt: Alle Standorte als Emergency Address in Teams hinzugefügt (Admin Center oder PowerShell). (🔲)
• Geocodes gesetzt: Adressen verifiziert und (wo unterstützt) Geokoordinaten hinterlegt. (🔲)
• Netzwerkregionen & -standorte eingerichtet: Regionen (z.B. pro Land) und Sites (pro Standort) angelegt. (🔲)
• Subnetze & WLAN zugewiesen: Jedes internes IP-Subnetz dem richtigen Standort zugeordnet; WLAN-APs per PowerShell zugewiesen. (🔲)
• Trusted IPs definiert: Öffentliche IP-Adressen der Firmengateways als vertrauenswürdig konfiguriert (nomadische Erkennung). (🔲)
• Emergency Call Routing Policy erstellt: Notruf-Routingrichtlinie mit 112, 110 etc. angelegt; dynamische Notrufe aktiviert; PSTN-Routen/PSTN-Usage korrekt zugewiesen (bei Direct Routing auf Notruf-Trunk/ELIN-Gateway). (🔲)
• Emergency Calling (Notification) Policy erstellt: Richtlinie für Benachrichtigungen angelegt; Notrufnummern (112,… ggf. 110) mit Notification-Gruppe und Modus konfiguriert; Testnummer ohne Alarm definiert (falls gewünscht). (🔲)
• Policy-Zuweisung Standorte: Routing- und Notification-Policy den Netzwerk-Standorten zugewiesen (bzw. globale Policy angepasst). (🔲)
• Policy-Zuweisung Benutzer: Falls nötig, einzelnen Nutzern spezifische Notruf-Policies zugewiesen (Ausnahmen). (🔲)
• Dialplan gecheckt: Wählpläne/Normalisierung in Teams stellen sicher, dass 112/110 nicht durch andere Regeln verfälscht werden (z.B. keine Strip-Zero nötig). (🔲)
• Client-Einstellungen geprüft: An einem Client pro Standort kontrolliert, ob unter Einstellungen > Notrufe ein Standort angezeigt wird, wenn verbunden im Firmennetz. (🔲)
• SBC/Gateway konfiguriert: SBC-Regeln implementiert (112-> Leitweg, CallerID-Ersatz auf ELIN, Rückruf-Routing); Operator Connect/Provider-Einstellungen geprüft (Notrufadressen hinterlegt). (🔲)

Checkliste: Test & Abnahme

• Interner Testlauf durchgeführt: Mit Testcode (z.B. 999) oder alternativer Methode die komplette Kette pro Standort simuliert. (🔲)
• Adresse/Caller-ID validiert: Bei Tests kontrolliert, dass Leitstelle die korrekte Adresse und eine durchstellfähige Nummer bekommen würde (ggf. durch Testanruf bei eigener Handynummer). (🔲)
• Interne Alarmierung geprüft: Sicherheitsgruppe hat Benachrichtigung erhalten und verifiziert (Rückmeldung: “Alarm angekommen um HH:MM”). (🔲)
• Dokumentation erstellt: Abnahmedokument ausgefüllt (siehe Vorlage unten), von Verantwortlichen unterschrieben. (🔲)
• Mitarbeiter informiert: Rundmail oder Intranet-Beitrag veröffentlicht: “Teams-Telefonie Notruf jetzt verfügbar – so verhalten Sie sich im Notfall …”. (🔲)
• Notfalltelefone montiert: Falls vorgesehen, physische Geräte installiert und getestet (Wählton, Abgehend 112 ok). Sichtbare Kennzeichnung angebracht. (🔲)
• Beschilderung/Sticker angebracht: Bei Bedarf Aufkleber an Geräten: “Notruf 112 ohne Vorwahl von hier möglich” etc. (🔲)
• Fallback kommuniziert: Mitarbeiter wissen, was bei Netzausfall zu tun (Handy, manuelles Alarmmittel). (🔲)
• Regel für regelmäßigen Test definiert: z.B. “vierteljährlich Testcall durch IT” im Kalender eingeplant. (🔲)
• Abnahme durch Geschäftsführung/Sicherheitsbeauftragten: Erfolgt am [Datum], Ergebnis: System einsatzbereit. (🔲)

Vorlage: Standort-Notruf-Übersicht

Nutzen Sie diese Tabelle, um alle wichtigen Daten je Standort zu dokumentieren:

Legende: ELIN = Emergency Location Identification Number (Rückrufnummer Leitstelle). “Interne Alarmempfänger” können Team-Namen, Personen oder auch “–” falls keiner.

Tipp: Halten Sie diese Tabelle aktuell und speichern Sie sie zentral (z.B. im ISMS oder bei den Notfallplänen). So haben im Ernstfall alle Beteiligten einen schnellen Überblick.

Vorlage: Abnahmeprotokoll Notrufsystem

Dokumentieren Sie die erfolgreiche Inbetriebnahme mit einem Abnahmeprotokoll. Beispiel:

• Projekt: Einführung Notruf-Funktion Microsoft Teams Telefonie
• Datum Abnahmetest: 15.11.2025
• Tester: Max Mustermann (IT) und Sabine Schulz (Sicherheitsbeauftragte)
• Testfälle:
• Standort Frankfurt – Testanruf 112 (Simuliert über 11833) -> Ergebnis: Leitstelle hätte Adresse “Mainzer Landstr. 123” erhalten, interne Alarmierung erfolgte (OK).
• Standort München – echter Anruf mit Voranmeldung Leitstelle -> Ergebnis: Leitstelle bestätigte Empfang richtige Adresse, Rückrufnummer ok (OK).
• Home-Office Benutzer – Test über 999 -> Ergebnis: Teams forderte Standortfreigabe, interne Alarm nicht zutreffend (N/V), Nutzerunterweisung erforderlich.
• Festgestellte Mängel: Home-Office Standort nicht automatisch – Maßnahmen: Schulung User, Hinweis in Doku.
• Freigabe: Die Notruffunktion wird hiermit in Betrieb genommen. Sie erfüllt die Anforderungen (TKG §108, interne Vorgaben) mit o.g. Einschränkungen.
• Unterschriften: IT-Leitung (M. Mustermann), Arbeitssicherheit (S. Schulz)

(N/V = nicht verfügbar, hier bewusst kein interner Alarm für Home-User vorgesehen)

Sie können dieses Muster an Ihre Bedürfnisse anpassen. Wichtig ist, schriftlich festzuhalten, dass Sie die Funktion getestet haben – das zeigt Verantwortungsbewusstsein und hilft bei späteren Reviews.

Sonstige Tabellen/Vorlagen

Zum Abschluss noch zwei kleine Übersichten, die hilfreich sein können:

Wichtige Notrufnummern international (Auswahl): – 112 – Europäische Notrufnummer (EU-Staaten, u.a. Deutschland; parallel in DE: 110 Polizei) – 911 – Notrufnummer in USA/Canada (bei Reise dorthin relevant; in USA leitet 112 auf 911 um bei Mobilfunk) – 999 – Notrufnummer in Großbritannien (112 funktioniert auch dort) – 000 – Notruf in Australien
(Tipp: Falls Ihre Mitarbeiter global unterwegs sind, könnte eine kleine Tabelle im Intranet helfen, welche Nummer wo gilt.)

Beispielhafte Kostenübersicht Notruf in Teams:

Die obige Tabelle dient nur als Beispiel zur Veranschaulichung.

Mit diesen Checklisten und Vorlagen sind Sie bestens gerüstet, um Ihr Teams-Notrufprojekt zu planen, umzusetzen und zu dokumentieren. Als nächstes folgt noch ein praxisnaher Konfigurations-Anhang mit technischen Beispielen, gefolgt von einem umfangreichen FAQ und Glossar.

11. Praxisnaher Konfig-Anhang (inkl. PowerShell- und SBC-Beispiele, YAML/CSV, ASCII-Skizzen)

In diesem Anhang finden Sie technische Beispiele, die die Umsetzung greifbar machen. Sie dienen als Anhaltspunkte – passen Sie Befehle an Ihre Umgebung an.

PowerShell-Beispiele für Teams-Konfiguration

Viele Einstellungen lassen sich via PowerShell schneller durchführen oder automatisieren. Hier einige nützliche Cmdlets:

• Notfalladresse anlegen: (alternativ zum Admin Center)
   

           New-CsOnlineLisCivicAddress -Country DE -City „Frankfurt am Main“ -PostalCode „60327“ `
  -StreetName „Mainzer Landstrasse“ -StreetNumber „123“ -Description „Frankfurt HQ“

           Nach Ausführen erhalten Sie eine AddressObjectId (GUID). Diese brauchen wir für Subnet-Zuordnung. Sie können optional -Latitude/-Longitude angeben. Wenn die Adresse erkannt wird, ist sie automatisch Verified.

• Vorhandene Notfalladressen listen:
   

           Get-CsOnlineLisCivicAddress | ft Description,Country,City,PostalCode,IsVerified

           So sehen Sie, ob alle Adressen korrekt verifiziert sind.

• Netzwerkstandort anlegen: (wenn nicht über TAC gemacht)
   

           New-CsTenantNetworkSite -Identity „Frankfurt“ -NetworkRegionID „Deutschland“ `
  -Description „Hauptsitz Frankfurt“

           Hinweis: NetworkRegion “Deutschland” muss vorher via New-CsTenantNetworkRegion erstellt sein.

• Subnetz zu Network Site zuordnen:
   

           New-CsTenantNetworkSubnet -Subnet 10.10.0.0/16 -NetworkSiteID „Frankfurt“ -Description „FR-HQ LAN“

           Damit weiß Teams: IP 10.10.x.x = Standort Frankfurt. Wiederholen für alle Subnetze.

• WLAN AP zuordnen: (kein TAC-Pendant, nur PS)
   

           # BSSID = MAC des AP
$loc = Get-CsOnlineLisLocation | ? {$_.Description -eq „Frankfurt HQ“}
Set-CsOnlineLisWirelessAccessPoint -BSSID „AABBCCDDEEFF“ -LocationId $loc.LocationId -Description „FR-HQ 1stFloor AP1“

           Das holt sich zuerst die LocationId der Adresse “Frankfurt HQ” und weist dann einen AP zu. Mühsam bei vielen APs – nutzen Sie CSV-Import:

Beispiel CSV waps.csv:
 

BSSID,LocationID,Description
AABBCCDDEEFF,<GUID_FRA>,FR-HQ 1stFloor AP1
GGHHIIJJKKLL,<GUID_FRA>,FR-HQ 2ndFloor AP2

Import:
 

Import-CSV .\waps.csv | % { Set-CsOnlineLisWirelessAccessPoint -BSSID $_.BSSID -LocationId $_.LocationID -Description $_.Description }

• Trusted IP setzen: (für VPN/öffentliche IPs)
   

           New-CsTenantTrustedIPAddress -IPAddress 203.0.113.10 -MaskBits 32 -Description „InternetOut FRA“

           (Beispiel-IP ersetzen). Achtung: Damit diese Funktion wirkt, muss Tenant-weit die Option “Standortberechtigungsmodus für externe Standorte” aktiviert sein (-ExternalLocationLookupMode Enabled in einer Policy, s.u.).

• Notruf-Routing-Policy via PS:
  Leider bietet Microsoft kein Cmdlet, mit dem man in einem Rutsch Notrufnummern inkl. Masken und PSTN-Usage definiert (Stand 2025). Man muss mit dem Parameter -EmergencyNumbers arbeiten:
   

           $num1 = New-CsTeamsEmergencyNumber -DialString 112 -DialMask 112 -PstnUsage „Emergency“
$num2 = New-CsTeamsEmergencyNumber -DialString 110 -DialMask 110 -PstnUsage „Emergency“
New-CsTeamsEmergencyCallRoutingPolicy -Identity „ECRP-DE“ -EmergencyNumbers @($num1,$num2) -EnableEmergencyCalling $true

           Hier wurden beide Nummern hinzugefügt und einer PSTN Usage Emergency zugewiesen (diese muss es geben, z.B. auf den SBC-Routen). -EnableEmergencyCalling $true entspricht Dynamische Notrufe aktivieren.

• Notruf-Notification-Policy via PS:
  Hier wird’s komplexer, da mehrere Parameter für jede Nummer gesetzt werden können (Gruppen, Mode etc.). Beispiel für eine Nummer:
   

           $extNotif = New-CsTeamsEmergencyCallingExtendedNotification -EmergencyDialString 112 -NotificationMode „UnmuteConference“ -PhoneNumber „+49691234123“
New-CsTeamsEmergencyCallingPolicy -Identity „ECP-Alarm“ -NotificationUris „team-sicherheit@firma.de“ -ExtendedNotifications @($extNotif) -ExternalLocationLookupMode Enabled

           Dieser Befehl erstellt eine Policy ECP-Alarm, die 112-Anrufer wie folgt behandelt: Benachrichtigt die Gruppe mit Adresse team-sicherheit@firma.de und ruft gleichzeitig die externe Nummer +49 69 1234123 an; Konferenzmodus erlaubt ungemutetes Sprechen (UnmuteConference). Außerdem wird die OS-Standortsuche aktiviert (ExternalLocationLookupMode). Für 110 könnten Sie ein zweites $extNotif erstellen und das Array erweitern. – Zugegeben, dies ist komplex – oft geht man lieber übers Admin Center (dort kann man je Notrufnummer die Felder eingeben).

• Policy zuweisen:
   

           Grant-CsTeamsEmergencyCallRoutingPolicy -Identity user@firma.de -PolicyName „ECRP-DE“
Grant-CsTeamsEmergencyCallingPolicy -Identity user@firma.de -PolicyName „ECP-Alarm“

           Oder für Sites:
 

           Set-CsTenantNetworkSite -Identity „Frankfurt“ -EmergencyCallRoutingPolicy „ECRP-DE“ -EmergencyCallingPolicy „ECP-Alarm“

SBC-Konfigurationsbeispiel (Audiocodes/Ribbon)

Jeder SBC hat eigene Syntax. Hier ein pseudocode-haftes Beispiel, was eingestellt werden muss – übertragen Sie die Logik in Ihr System:

• Dial Plan / Routing:
• Eingehend von Teams: Regel: Wenn Anruf von Teams an Nummer “112” ankommt, dann -> Routing an PSTN-Gateway entsprechend Standort. Das kann man umsetzen, indem man pro Standort unterschiedliche SIP-Listening Ports oder Signalisierungsgruppen nutzt (Teams kann per Policy je nach Netzwerk verschiedene Ziele ansteuern). Alternativ trägt Teams im SIP-Header (Call-Info) den Standort ein – manche SBCs können anhand eines Headers entscheiden. Im Zweifel definieren Sie: Alle 112/110 gehen immer über einen bestimmten trunk.
• Abgehend zum PSTN: Für Notrufe sicherstellen, dass keine Carrier-spezifischen Wählregeln blocken. Z.B. muss “112” als gültige Nummer raus dürfen, ggfs. Prefix entfernen oder konvertieren gemäß Anbieterformat (einige SIP-Trunks erwarten z.B. “112” ohne +49 oder so – in DE eigentlich als 3-stellige Notruf übermittelt).
• Caller ID Manipulation (ELIN):
• Ein Routing-Eintrag, der greift vor dem Senden an PSTN: Wenn Ziel = 112 oder 110, dann ersetze From-Number. Womit ersetzt? Das SBC muss anhand des Teams-Standorts entscheiden. Möglichkeiten:
  • Nutzen Sie unterschiedliche PSTN-Trunks je Standort, und konfigurieren pro Trunk eine feste Calling Number. Z.B. Anrufe, die über Trunk “Frankfurt” rausgehen, setzen automatisch die Absendernummer “0691234110”.
  • Oder nutzen Sie conditional manipulation: IF From-Teams-User in Gruppe Frankfurt THEN set Caller = 0691234110.
  • Bei Audiocodes SBC könnte man z.B. eine IP->Tel Regel erstellen:
     

           RULE: Teams_Frankfurt_112
  IF (SourceIPGroup==Teams_FRA) AND (DialedNumber IN (112,110))
  THEN (Replace Caller=+49691234110, Send To Trunk=FRA_SIP)

           und analog für München etc. (Pseudo-Syntax zur Verdeutlichung).

• Bei Ribbon SBCs würde man wohl in der Transformation Table pro Site die Notruf-CLI setzen.

• Rückrufe: Der SBC sollte eingehende Anrufe an diese ELIN-Nummern wiederum an Teams leiten oder sogar direkt an den ursprünglichen Anrufer. Oft geschieht dies über eine Mapping-Tabelle, die eine ELIN einer internen Durchwahl zuordnet, gültig für 30 Minuten nach Notruf. Viele SBCs haben dafür ein E911-Modul, ansonsten kann man Workarounds bauen (z.B. Anruf an ELIN führt in eine IVR “Wenn Sie zurückgerufen werden, drücken Sie 1” – nicht elegant, besser Modul nutzen).
• Ausfallszenarien:
• Alternate Routing: Definieren Sie eine Backup-Route, falls der primäre Trunk nicht verfügbar ist. Z.B. 112 -> erst PSTN1, falls busy/fail -> PSTN2 (zweiter Provider). Aber Achtung: Wenn PSTN2 ein ganz anderer Ort ist, wird dortige Leitstelle erreicht – daher nur einsetzen, wenn z.B. Provider1 down, aber dann lieber falsche Leitstelle als gar keine Verbindung.
• Survivability (SBA): Falls Sie eine Survivable Branch Appliance haben, konfigurieren Sie dort ebenfalls Notruf-Routing lokal. Meist bedeutet das: Der SBA hat einen lokalen Gateway (z.B. ISDN oder Mobilfunk) und wählt 112 über diesen aus, falls er autonom ist.
• Notruf-Testzugang: Manche SBCs bieten die Möglichkeit, aufgrund eines speziellen Headers oder einer anderen Rufnummer eine Simulation zu fahren. Nutzen Sie das ggf., um Testanrufe intern umzuleiten.
• Sicherheitsmaßnahmen: Sperren Sie ausgehend ungewöhnliche Nummern, aber nicht 112/110. Stattdessen könnten Sie eingehend von Teams auf SBC filtern, dass nur legitime IPs von Microsoft zugreifen – damit kein Angreifer von außen versucht, Fake-Notrufe abzusetzen.
• Logging: Aktivieren Sie auf dem SBC ausführliches Logging für Notrufe. Evtl. sysloggt er ein Event “Emergency Call dialed” mit Details. Das hilft beim Review.

Je nach SBC-Hersteller gibt es Templates für “Emergency Call Handling” – schauen Sie in die Doku Ihres Produkts.

YAML/CSV-Beispiele

Hier noch zwei strukturierte Daten-Beispiele, falls Sie Ihre Konfiguration als Code/Tabellen verwalten wollen:

• YAML – Standortkonfiguration Beispiel:

EmergencyLocations:
  – Name: Frankfurt_HQ
    Address: „Mainzer Landstr. 123, 60327 Frankfurt“
    ELIN: „+49691234110“
    TeamsSite: „Frankfurt“
    PSTNTrunk: „DE-FRA-SIP“
    InternalAlert: „Security-FRA-Team“
  – Name: Munich_Office
    Address: „Sonnenstr. 5, 80331 München“
    ELIN: „+4989555112“
    TeamsSite: „Muenchen“
    PSTNTrunk: „DE-MUC-SIP“
    InternalAlert: „Empfang-MUC“

Diese YAML-Struktur wäre z.B. denkbar, um alle wichtigen Infos pro Standort in einer Datei vorzuhalten – daraus ließen sich Skripte generieren, die das System konfigurieren.

• CSV – Subnetz-Import Beispiel:

Sie haben 20 Standorte mit je 5 Subnetzen – manuell eintippen wäre mühselig. Bereiten Sie eine CSV vor:
 

SubnetID,MaskBits,SiteID
10.10.0.0,16,Frankfurt
10.20.5.0,24,Muenchen
192.168.1.0,24,Berlin

und importieren Sie alle auf einmal:
 

Import-CSV .\subnets.csv | % { New-CsTenantNetworkSubnet -Subnet $_.SubnetID/$($_.MaskBits) -NetworkSiteID $_.SiteID }

So sind mit einem Befehl alle Subnetze verteilt. Ähnlich können Sie für LIS-Standort-Zuordnungen CSV-Dateien nutzen (siehe Wireless AP Beispiel oben).

ASCII-Skizzen Revisited

Zur besseren Veranschaulichung finden Sie hier nochmal zwei ASCII-Diagramme, die typische Abläufe zeigen:

• Ablauf Direct Routing Notruf mit ELIN (simplifiziert):

Teams-Client (User in MUC) –112–> Teams Cloud –INVITE–> Unternehmens-SBC
   SBC sieht: User aus München, Notruf
   SBC setzt Caller = +4989555112 (ELIN MUC)
   SBC –> SIP-Trunk MUC –> PSTN –> Notrufleitstelle München  🔔
                                   (Leitstelle sieht 089555112, Adresse München)
<< Leitstelle ruft +4989555112 zurück >>
   PSTN –> SBC empfängt Anruf, mappt +4989555112 -> User Durchwahl
   SBC –> Teams Cloud –> klingelt beim ursprünglichen Teams-User ✅
Parallel: Teams schickt Alert an „Empfang-MUC“ (Chat + Anruf) 📢

• Notruf aus dem Home-Office (Calling Plan Beispiel):

Teams-Client (User zu Hause) –112–> Teams Cloud ☁️
   Teams fragt Windows: „Standortinfo?“ 🌐
   Windows liefert: „Musterweg 12, 12345 Musterdorf“
   Teams hängt diese Adresse ans SIP INVITE an
   –> Microsoft PSTN (Calling Plan) nimmt Call entgegen
      Microsoft schaut: Nummer = +49 69…, gemeldeter Ort = Musterdorf
   –> Routing zur zuständigen Leitstelle für Musterdorf 📞
                                    (Leitstelle erhält +4969… als Nummer,
                                     und kann bei Microsoft falls nötig Adresse erfragen)
Intern: Teams schickt E-Mail an Sicherheitsteam: „Notruf User X extern (Adresse: Musterweg 12)“. ✉️

Die ASCII-Grafiken zeigen: egal ob im Büro (über eigenen SBC) oder remote (über Cloud), Teams kann den Notruf routen – die Mechanik dahinter unterscheidet sich, aber das Ergebnis soll stimmen.

Damit endet der technische Anhang. Im nächsten Kapitel beantworten wir noch häufig gestellte Fragen (FAQ) und erklären wichtige Begriffe im Glossar.

12. FAQ – Häufige Fragen & Antworten

Frage 1: “Können wir Notrufe in Teams auch deaktivieren? Unsere Mitarbeiter sollen im Notfall lieber das Handy nehmen.”
Antwort: Technisch kann man den Notruf nicht “abschalten” – 112/110 sind fest im System verankert. Man könnte höchstens per Dialplan versuchen, 112 in Teams ins Leere laufen zu lassen, aber das wäre grob fahrlässig und gesetzlich bedenklich. Empfehlen würde ich das keinesfalls. Besser: Ermöglichen Sie den Notruf in Teams korrekt und schulen Sie die Mitarbeiter parallel, dass Mobiltelefone ein zusätzlicher Weg sind. Redundanz schadet nicht.

Frage 2: “Müssen unsere Benutzer eine Amts-Null oder Vorwahl wählen, um 112 zu erreichen?”
Antwort: Nein. In Teams (wie in den meisten modernen Telefonanlagen) wird 112 direkt erkannt. Es darf keine zusätzliche “0” nötig sein. Wenn Ihr bisheriges System das so hatte, verabschieden Sie sich davon. Teams entscheidet anhand der Nummernlänge und Ihrer Notruf-Policy, dass 112 ein externer Notruf ist.

Frage 3: “Was passiert, wenn jemand auf Geschäftsreise im Ausland über Teams 112 wählt?”
Antwort: Das ist kritisch. Teams wird versuchen, den Notruf gemäß Ihrer Konfiguration zu routen – aber Ihre Konfiguration ist vermutlich auf das Heimatland ausgerichtet. Eine Benutzerin mit deutscher Nummer in Frankreich würde also womöglich eine deutsche Leitstelle erreichen oder scheitern. Daher: In Auslandsfällen klar kommunizieren, immer lokale Mittel nutzen (Handy mit lokaler SIM oder Hoteltelefon). Die Teams-App selbst gibt i.d.R. einen Warnhinweis aus, wenn man im Ausland ist.

Frage 4: “Wie genau ermittelt Teams meinen Standort im Notfall?”
Antwort: Wenn Sie im Firmennetz sind, anhand Ihrer IP bzw. dem WLAN, gematcht gegen die Standortdatenbank, die der Admin hinterlegt hat. Sind Sie extern (z.B. Home-Office), kann Teams die Standortdienste des OS nutzen – etwa GPS/WLAN-Ortung von Windows oder die Ortsfreigabe auf dem Smartphone. Teams nimmt diese Angaben (die Sie eventuell bestätigen müssen) und hängt sie ans Gespräch. Der Provider oder die Leitstelle bekommen diese Info als Datensatz oder im Gespräch übermittelt.

Frage 5: “Sendet Teams meinen Aufenthaltsort ständig an Microsoft?”
Antwort: Nein. Die Standortinfo wird nur bei einem Notruf aktiv vom Client geholt (oder wenn Sie manuell in Teams auf “Standort teilen” klicken, z.B. in einer Nachricht). Microsoft nutzt die Info nur, um den Notruf zu routen und ggf. in der Benachrichtigung an interne Helfer anzuzeigen. Eine ständige Überwachung findet nicht statt.

Frage 6: “Wir haben Mitarbeiter ohne festen Telefonapparat (nur PC). Können die trotzdem 112 wählen, auch wenn sie eigentlich keine Berechtigung für externe Anrufe haben?”
Antwort: Ja. Teams lässt standardmäßig Notrufe immer zu, selbst wenn ein Anrufblock oder keine Outbound-Lizenz da ist. Das heißt, ein User ohne “Telefonie-Paket” (Calling Plan) kann zwar keine normalen Anrufe, aber 112 würde Teams trotzdem versuchen zu senden (via vorhandene Verbindung). Allerdings: Hat jemand gar keine Telefonie in Teams (z.B. rein internes Teams ohne PSTN), dann geht’s natürlich nicht. Solchen Mitarbeitern sollte man alternativ ein anderes Mittel an die Hand geben (z.B. Firmenhandy oder ein Notruftelefon im Büro).

Frage 7: “Wie stellt die Leitstelle fest, wo genau im Gebäude ich bin? Die Adresse alleine ist ja groß, ggf. mehrere Stockwerke.”
Antwort: Bei klassischen Notrufen übermitteln Telefonanlagen normalerweise nur die Adresse des Gebäudes. Feinheiten (Stockwerk, Raum) muss meist der Anrufer selbst durchgeben. Teams erlaubt zwar, einen “Ort” (z.B. 3. Stock, Raum 301) mitzuschicken – und wir konfigurieren das auch – aber die aktuellen Leitstellen-Systeme in Deutschland bekommen diesen Detailgrad meist nicht automatisch. Das interne Sicherheitsteam, sofern alarmiert, sieht solche Details aber in Teams (weil wir sie in der Notfalladresse hinterlegt haben). Es kann dann z.B. den Rettungskräften am Eingang sagen: “Der Notruf kam aus dem 3. Stock, Raum 301”.

Frage 8: “Können wir einstellen, dass bei einem Notruf automatisch eine Sirene im Gebäude angeht oder alle Computer eine Meldung anzeigen?”
Antwort: Teams selbst hat so eine Funktion nicht (es ruft/benachrichtigt definierte Personen/Gruppen). Aber man könnte via Graph-API einen Workflow bauen, der einen Popup am PC triggert – das erfordert jedoch Drittanwendungen. Für Sirenen/Alarmanlagen sind meist separate Systeme zuständig (Brandmeldeanlage etc.). Eine Integration wäre denkbar (z.B. über einen Webhook von Teams an ein Gebäudeleitsystem), aber das sprengt den Standardumfang. Kurz: Out of the box – nein, nur personengebundene Benachrichtigungen.

Frage 9: “Wenn jemand versehentlich die 112 wählt und sofort auflegt – was passiert dann?”
Antwort: In Leitstellen ist es üblich, bei “Hangup” sofort zurückzurufen, um zu prüfen, ob ein Notfall vorliegt. Wenn unser System richtig konfiguriert ist, würde der Rückruf dann idealerweise beim gleichen Teams-Benutzer klingeln (bzw. dessen Telefon). Intern bekämen die hinterlegten Personen trotzdem die Alarmnachricht und könnten nachschauen. Am besten ist es natürlich, so einen Fehlanruf direkt der Leitstelle zu melden (z.B. nochmal anrufen und sagen “Entschuldigung, Fehlalarm, alles ok”), damit keine Einsatzkräfte unnötig losgeschickt werden.

Frage 10: “Wie oft sollen wir Notrufe testen? Dürfen wir überhaupt 112 ‘testweise’ anrufen?”
Antwort: Am besten gar nicht die echten 112/110 ohne Grund anrufen – außer in Abstimmung mit der Leitstelle (siehe Kapitel Tests). Nutzen Sie die empfohlenen Testmethoden (z.B. andere Nummern, interne Simulation) für regelmäßige Checks. Ich empfehle, mindestens 1x pro Jahr pro Standort einen Test durchzuführen und nach größeren Änderungen auch ad-hoc Tests. Die Leitstellen verstehen, dass Firmen das prüfen wollen, aber man sollte es nicht übertreiben. Mit guter Simulation kriegt man 95% der Sicherheit auch ohne echten Call hin.

Frage 11: “Wer haftet, wenn trotz aller Maßnahmen ein Notruf fehlschlägt?”
Antwort: Juristisch kompliziert. Primär ist der Telekommunikationsanbieter verpflichtet, Notrufe durchzustellen (und könnte belangt werden, wenn er systematisch versagt). Aber auch das Unternehmen hat Fürsorgepflicht. In der Praxis würde im Schadensfall sicherlich geschaut, ob Sie alles “angemessene” getan haben (daher: Dokumentation Ihrer Maßnahmen!). Eine konkrete Haftung müsste ein Gericht klären. Um das nicht auszutesten, sorgen wir lieber dafür, dass es gar nicht fehlschlägt. 😉

Frage 12: “Können wir die Notfall-Benachrichtigungen auch an externe Stellen schicken (z.B. Wachdienst oder auf ein Handy als SMS)?”
Antwort: Teams kann per Policy eine externe Telefonnummer anrufen und in die Notrufkonferenz holen – das wäre der Weg, z.B. den Wachdienst aufs Handy anzurufen. SMS oder E-Mail direkt an Externe geht nicht automatisch von Teams aus bei Notruf, da müsste man via Graph was basteln. Aber ein Anruf auf ein Handy (der dann stumm dazugeschaltet ist) ist möglich, indem man in der Emergency Calling Policy eine “Number to dial” einträgt. Beachten: Der Angerufene kann nicht zurücksprechen, außer Sie wählen den unmute-Modus, was aber bei Externen nicht geht (die bleiben immer gemutet). Für SMS könnten Sie höchstens einen Dienst zwischenschalten, der einen Anruf annimmt und in SMS umwandelt – das wäre sehr custom.

Frage 13: “Was ist, wenn zwei Leute gleichzeitig aus Teams die 112 wählen? Reicht unser Trunk dann?”
Antwort: Normalerweise ja, sofern Ihr SIP-Trunk mindestens so viele Leitungen hat wie gleichzeitige Notrufe zu erwarten sind. Meist sind Notfälle Einzelereignisse – gleichzeitig 5 Leute rufen passiert höchstens bei Großschadenslagen. Wenn Sie ganz sicher gehen wollen, dimensionieren Sie die Sprachkanäle etwas höher (oder erlauben Überspill zu einem zweiten Trunk). Moderne Cloud-Anschlüsse haben oft flexible Kanäle (z.B. alle Mitarbeiter teilen sich 30 simultane Calls). Wichtig ist vor allem, dass keine künstlichen Limits konfiguriert sind, die Notrufe treffen könnten. Übrigens: Falls wirklich 100 Leute gleichzeitig 112 wählen (z.B. alle sehen einen Brand) – die Leitstelle würde dann 100 Anrufe bekommen, was sie auch herausfordert. Aber das liegt außerhalb Ihrer Kontrolle.

Frage 14: “Gibt es in Teams eine Möglichkeit, Notrufe zentral zu protokollieren (für Auswertung)?”
Antwort: Es gibt kein spezielles Notruf-Log in Teams. Aber Sie können über das Call Detail Record (CDR) im Teams Admin sehen, wenn eine 112 gewählt wurde – das erscheint dort als ausgehender Anruf an “112” über den entsprechenden Trunk. Außerdem behalten die internen Alarm-Empfänger hoffentlich eine Notiz oder E-Mail. Wenn Ihr SBC ein Syslog für Notrufe hat, könnten Sie das archivieren. Wichtig: Aufbewahrung solcher Daten unterliegt Datenschutz – nur berechtigte Personen sollten Zugriff haben. Aber ja, man kann technisch nachvollziehen, ob und wann Notrufe getätigt wurden (im Nachhinein).

Frage 15: “Unterstützt Microsoft Teams diese EU-weite AML-Funktion (Advanced Mobile Location)?”
Antwort: AML ist eine Smartphone-Funktion: Bei einem Handynotruf sendet das Gerät per SMS die GPS-Daten an die Leitstelle. Teams an sich hat so etwas nicht integriert. Teams vertraut auf die beschriebenen Mechanismen (hinterlegte Adresse oder OS-Standort). Wenn Sie Teams Phone Mobile nutzen (also Anruf über Mobilfunknetz), greift AML automatisch, weil es ja ein Handy-Call ist. Bei reinen Teams-VoIP Calls leider nein – hier sind wir auf die statischen/dynamischen Daten angewiesen.

Frage 16: “Brauchen wir einen speziellen Notruf-Vertrag mit Microsoft oder dem Telefonanbieter?”
Antwort: Mit Microsoft nicht – es gibt nur die normalen Lizenzbedingungen, in denen auch steht, dass Notrufe möglich sind (und Microsoft haftet dort sehr begrenzt, by the way). Mit Ihrem Telefonieanbieter haben Sie automatisch die Notrufverpflichtung drin, da gesetzlich vorgeschrieben. Sie müssen also nichts zusätzlich buchen. Allerdings bieten manche Provider Zusatzservices an, z.B. “Nomadic E911 Service” in den USA oder ähnliches, was Aufpreis kosten kann. In Deutschland ist das selten. Prüfen Sie ggf. Angebote, aber nötig ist es nicht – man kann alles mit Bordmitteln lösen.

Frage 17: “Wie lange dauert es, bis so ein Notrufaufbau geht? Geht das über die Cloud nicht langsamer?”
Antwort: Die Latenz durch die Cloud ist vernachlässigbar. Ein Teams-Anruf dauert vielleicht 1-2 Sekunden Verbindungsaufbau. Die längste Komponente ist oft, bis jemand abhebt. Leitstellen heben meist nach 5-10 Sekunden (oder schneller) ab. Also nein, spürbar langsamer als vom Festnetz ist es nicht. Wichtig: Wenn Teams die Standortfreigabe vom User braucht (bei erstmaliger Nutzung), dann könnte der User erstmal klicken müssen – das verursacht natürlich Verzögerung durch den Menschen. Daher raten wir, diese Freigabe am besten vorab einzuholen (Windows fragen lassen und zustimmen, bevor ein echter Notfall eintritt).

Frage 18: “Kann ich die Benachrichtigungen auch in anderen Tools bekommen (z.B. PagerDuty, E-Mail an Gruppe)?”
Antwort: Nativ: Teams schickt Chat und Voice in Teams selbst. Es gibt keine eingebaute E-Mail-Benachrichtigung für Notruf. Aber man kann mit etwas Aufwand was bauen: Microsoft Graph API kann sogenannte Change Notifications für Notrufevents senden. Damit könnten Entwickler einen Webhook einrichten, der bei Notruf ein Event bekommt und z.B. eine E-Mail generiert oder in ein anderes Alarmierungstool einspeist. Das erfordert jedoch Programmierung. Für die meisten reicht die Teams-interne Alarmierung.

Frage 19: “Wenn unser Internetprovider ausfällt und wir kein Backup haben – ist das ein Regelverstoß, weil dann Notrufe nicht gehen?”
Antwort: Streng genommen sollte ein Notruf immer möglich sein. Wenn Ihre gesamte Standort-Konnektivität weg ist, sind aber auch klassische VoIP/Telefonanlagen tot – das ist kein spezielles Teams-Problem. Die BNetzA fordert von Providern, Kunden auf diese Gefahr hinzuweisen (Stichwort: “Hinweis auf Stromabhängigkeit von VoIP”). Als Firma sollten Sie ebenfalls einen Plan haben: z.B. Notfall-Handys vorhalten. Aber Sie verstoßen nicht automatisch gegen Gesetze, wenn der Internetanschluss mal ausfällt – das kann passieren. Wichtig ist, dass Sie Mitarbeiter auf Alternativen hinweisen (Mobiltelefon, Feueralarmmelder etc.) und nach Möglichkeit Redundanzen schaffen, wenn die Gefahr hoch ist (z.B. LTE-Fallback fürs Internet).

Frage 20: “Wie unterscheidet Teams zwischen internen Nummern und externen, z.B. wenn wir dreistellige Durchwahlen haben und jemand ‘112’ intern vergeben hat?”
Antwort: Teams hat das Konzept von Dial Plans und Normalization. Wenn Sie dreistellige Durchwahlen haben, würde “112” tatsächlich als interne Durchwahl interpretiert, es sei denn Sie definieren eine Notrufnormalisierung. Die beste Praxis: 112 und 110 nie als interne Nummern verwenden. Sollte es doch so sein, ändern Sie das intern (Konflikt vermeiden). In Teams können Sie mittels Dialplan eine Regel erstellen, die 112 immer als +49112 wählt, um sicher als Notruf rauszugehen. In unserem früheren Beispiel (Kapitel 3) hat der Admin auch eine erste Normalisierungsregel “110 -> +495251110” definiert, damit das nicht als interne Nummer bleibt. Also: Teams entscheidet nach Länge und Ihren Regeln. 3-stellig kann sowohl intern sein als auch Notruf – Ihre Konfiguration gibt hier den Ausschlag. Priorisieren Sie Notrufe (im Dialplan zuerst behandeln).

Diese 20 Fragen decken typische Unsicherheiten ab. Wenn Ihre spezielle Frage hier nicht dabei ist, kann ich Ihnen im Glossar oder persönlich weiterhelfen. Apropos Glossar – im nächsten Abschnitt erkläre ich noch die wichtigsten Fachbegriffe rund ums Thema, kurz und knackig.

13. Glossar

112 / 110: Die in Deutschland geltenden Notrufnummern. 112 erreicht europaweit Feuerwehr und Rettungsdienst, 110 die Polizei. Beide sind kostenlos und ohne Vorwahl erreichbar. 112 funktioniert in vielen Ländern als allgemeiner Notruf (z.B. EU, UK, etc.).

AML (Advanced Mobile Location): Automatische Standortübermittlung bei Mobilfunk-Notrufen. Moderne Smartphones senden bei einem Notruf per SMS ihre GPS-Koordinaten an die Leitstelle (verfügbar in vielen Ländern, z.B. EU-Länder). Betrifft primär Handy-Anrufe, nicht VoIP.

BSSID: Basic Service Set Identifier – die MAC-Adresse eines WLAN-Accesspoints. Teams kann über BSSIDs den Standort bestimmen, wenn jeder AP einem Ort zugeordnet wird.

Common Area Phone: Ein Telefon, das nicht an einen Benutzer gebunden ist, sondern als Gemeinschaftsapparat dient (z.B. im Flur, Lobby). In Teams mit einer Common Area Phone-Lizenz betrieben. Praktisch für Notfalltelefone, da keine Anmeldung nötig und von jedem nutzbar.

Direct Routing: Anschluss von Teams ans Telefonnetz über einen eigenen Session Border Controller (SBC). Ermöglicht flexible Kontrolle (eigene SIP-Trunks, eigene Routingregeln). Für Notrufe heißt das: das Unternehmen (bzw. sein SBC) ist für die Notrufausleitung verantwortlich.

Dyn. Notruf / Dynamische Notruffunktion: Teams-Feature, bei dem während des Anrufs der aktuelle Standort des Users ermittelt wird (per Netzwerk oder Geräteortung) und zur Anrufweiterleitung verwendet wird. Gegensatz: statischer Notruf (fest hinterlegte Adresse pro Benutzer).

E112: Umgangssprachlich für “Enhanced 112” – Nutzung moderner Standortdaten bei Notruf 112 (entspricht dem, was in USA E911 ist). Europa forciert E112-Funktionen, z.B. AML. In unserem Kontext: Weitergabe genauerer Adressinfos an Leitstellen.

E911: “Enhanced 911”, US-Begriff für Notrufsystem mit Zusatzdaten (Ort, Rückrufnummer). In den USA müssen VoIP-Systeme E911 unterstützen – Microsoft Teams bietet deshalb Funktionen wie dynamische Adressen und interne Alerts, die wir in DE ebenfalls nutzen können (auch wenn gesetzlich nicht exakt so vorgeschrieben wie in USA).

ELIN (Emergency Location Identification Number): Eine spezielle Rufnummer, die einem Standort zugewiesen ist und beim Notruf als Absendernummer übertragen wird. Dient dazu, dass die Leitstelle einen eingehenden Notruf einer bestimmten Adresse zuordnen kann und bei Rückruf diese Nummer gewählt werden kann. Beispiel: ELIN +49 30 5555 112 für Standort Berlin, egal welcher User dort den Notruf absetzt.

Notrufabfragestelle: Offizieller Begriff für die Leitstelle, die Notrufe entgegennimmt (PSAP auf Englisch). In Deutschland sind das Feuerwehr-/Rettungsleitstellen bzw. Polizeileitstellen.

Notrufverordnung (NotrufV): Deutsche Verordnung, die Details zu Notrufen regelt (Ergänzung zum TKG). Legt z.B. fest, wie Standorte beschrieben werden, dass Netzbetreiber Datenbanken führen müssen etc. Für Firmen wichtig: nomadische Nutzung von Telefonnummern wird dort erwähnt – Provider sollen soweit möglich dynamische Standorte übermitteln.

Operator Connect: Anbindung von Telefonie an Teams durch einen externen Operator (Telefonanbieter), über Microsoft-Schnittstellen. Der Anbieter routet Gespräche ins PSTN. Für Notrufe: der Operator übernimmt weitgehend das Routing zur richtigen Leitstelle, basierend auf den bei ihm hinterlegten Adressen oder von Teams gelieferten Daten.

PSAP (Public Safety Answering Point): Englisch für Notruf-Leitstelle. Ort, wo Notrufe auflaufen und disponiert werden. Im Glossar, weil Microsoft-Dokumentation den Begriff nutzt.

RAY BAUM’s Act: US-Gesetz, ergänzt Kari’s Law, fordert genaue Standortangabe (Dispatchable Location) bei Notrufen aus Multi-Line-Telefonsystemen. Microsofts dynamische Notruffunktion wurde u.a. implementiert, um dieses Gesetz in USA zu erfüllen. Indirekt profitieren wir in DE von den Funktionen, die dadurch entstanden.

SBA (Survivable Branch Appliance): Eine zusätzliche Komponente/Appliance in Teams-Umgebungen, die bei Ausfall der Cloud Telefonie am Standort das Telefonieren (und Notrufe) lokal weiter ermöglicht. Im Prinzip ein lokaler Mini-Telefonserver, der einige Stunden/ Tage autark laufen kann. Wichtig für Standorte mit schlechter Redundanz – damit Notrufe auch bei WAN-Ausfall möglich bleiben.

SBC (Session Border Controller): Netzwerktechnisches Gerät/System, das VoIP-Telefonie zwischen unterschiedlichen Netzen vermittelt (z.B. Teams Cloud und Telefonnetz). Über den SBC laufen bei Direct Routing alle Anrufe. Für Notruf: Der SBC kann Nummern umschreiben (ELIN) und Routen bestimmen.

Standort (Location) in Teams: Kann verwirrend sein: Netzwerk-Standort meint eine definierte Site im Netz für Routing; Notfall-Standort bzw. Notfall-Adresse meint die physische Adresse. Im Admin Center werden Adressen als “Standorte” aufgeführt. Unser Glossar: Standort = physischer Ort.

TKG §108: Paragraph 108 des Telekommunikationsgesetzes. Regelt in Deutschland die Notrufverpflichtung: jederzeit, kostenlos, zur örtlich zuständigen Stelle. Er ist die rechtliche Basis, warum wir all das hier tun. 😉

VoIP: Voice over IP – Internettelefonie. Unsere Teams-Telefonie ist VoIP-basiert. Bei VoIP sind Ortsinformationen nicht implizit vorhanden (anders als bei Festnetzanschlüssen), daher der ganze Aufwand mit Notruf-Policies.

Nomadische Nutzung: Verwendung eines Telekommunikationsdienstes unabhängig vom ursprünglich gemeldeten Standort. Z.B. eine Cloud-Telefonnummer wird “nomadisch” genutzt, wenn der User heute hier, morgen dort einloggt. Nomadische Nutzung ist erlaubt, stellt aber Anforderungen an die Notruf-Abwicklung (siehe NotrufV). Teams ist im Kern eine nomadische Telefonanlage – wir machen sie durch unsere Konfiguration ortsbereit.

Dies sind die wichtigsten Begriffe. Weitere Abkürzungen wie PSTN (Public Switched Telephone Network, klassisches Telefonnetz) oder BG (Berufsgenossenschaft) wurden im Text verwendet; ich gehe davon aus, diese sind bekannt oder aus dem Kontext klar. Im Zweifelsfall gerne nachfragen!

14. Mein Beratungsangebot (mit drei konkreten Paketen à 1.500 €/PT zzgl. MwSt)

(Hinweis: In dieser Ich-Perspektive spreche ich nun direkt als Berater zu Ihnen.)

Sie haben diesen Artikel bis hierher gelesen – Respekt! 🙂 Wenn Sie jetzt sagen “Klingt wichtig, aber ganz schön komplex – können wir uns da Hilfe holen?”, dann lautet meine Antwort: Sehr gerne. Ich, Ulrich B. Boddenberg, stehe bereit, um Sie bei Teams-Telefonie und Notruf-Konzepten zu unterstützen.

Ich biete drei konkrete Beratungspakete an (individuell anpassbar). Mein Tagessatz beträgt 1.500 € pro Personentag (PT) zzgl. MwSt. Hier die Pakete:

Paket 1: Notruf-Quick-Check & Workshop – Umfang: 2 PT (à 1.500 €)
Wir analysieren in einem kompakten Workshop Ihre aktuelle Telefonie-Situation und die Anforderungen (rechtlich, technisch). Ich überprüfe, ob Ihr System schon notruf-fit ist, und erstelle mit Ihnen gemeinsam ein Grobkonzept. In einem halbtägigen Workshop mit allen Stakeholdern (IT, Sicherheit, Management) klären wir die offenen Fragen. Ergebnis: Sie erhalten einen Maßnahmenplan und Entscheidungshilfen, ob und wie Sie das Notruf-Thema angehen. Investition: 3.000 € (für 2 Tage Beratung).

Paket 2: Umsetzung & Abnahme – Umfang: nach Aufwand, ca. 5 PT
Hier setze ich (oder mein Team) die besprochenen Schritte in Ihrer Microsoft-Teams-Umgebung um. Wir konfigurieren gemeinsam die Notfall-Adressen, Policies, testen die Routingwege und schulen Ihr IT-Personal on-the-job. Inbegriffen ist auch die Begleitung eines Live-Tests (z.B. Koordination mit einer Leitstelle für einen kontrollierten Testanruf) und die Erstellung der Dokumentation/Abnahmeprotokoll. Dieses Paket nehme ich meist mit ~5 Beratungstagen in Anspruch (entspricht 7.500 €, falls 5 PT). Sie können entscheiden, ob Sie nur unterstützende Beratung wollen (dann weniger PT) oder “Hands-on” Implementierung durch uns.

Paket 3: Betriebsbegleitung & Schulung – Umfang: flexibel (z.B. 1 PT pro Quartal)
Nach der Einrichtung lassen wir Sie nicht allein. In diesem Paket biete ich regelmäßige Audits und Unterstützung an. Zum Beispiel: Vierteljährlich einen halben Tag Remote-Check der Teams-Konfiguration, ob Updates nötig sind; Jährlich ein Vor-Ort-Termin (1 PT) für einen Notruf-Probealarm und Auffrischungsschulung der Mitarbeiter. Ebenso stehe ich bei Fragen oder Änderungen (neuer Standort? Providerwechsel?) beratend zur Seite. Abgerechnet wird nach tatsächlichem Aufwand zum Tagessatz. Sie können ein Kontingent buchen – etwa 4 PT pro Jahr für 6.000 € – und wir rufen es bedarfsgerecht ab.

Natürlich lassen sich die Pakete kombinieren oder anpassen. Mein Ziel ist es, herstellerneutral und pragmatisch die für Sie beste Lösung umzusetzen. Sie erhalten kein BlaBla, sondern konkrete Hilfe – vom Konzept bis zum “Go Live” und darüber hinaus.

Interesse? Dann freue ich mich auf ein unverbindliches Gespräch. Sie finden meine Kontaktdaten auf meiner Website – und vielleicht arbeiten wir bald gemeinsam daran, dass auch in Ihrem Unternehmen gilt: “Wir sind compliant, getestet und dokumentiert!”

Weitere Beiträge zum Thema SharePoint und Teams