Netzwerkstandorte und Subnetze in Teams richtig pflegen

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Standorte, Subnetze und Notrufadressen sind über Jahre gewachsen und keiner traut sich ran? Wir räumen die Topologie mit dir auf. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die Netzwerktopologie, LIS und dynamischen Notruf selbst sicher pflegen wollen. › Schulung Teams-Telefonie

 

Es gibt Fehler, die laut sind: Das Telefon klingelt nicht, der SBC ist rot, das Helpdesk brennt. Und es gibt Fehler, die leise sind. Ein Subnetz, das in Teams keinem Netzwerkstandort zugeordnet ist, gehört zur zweiten Sorte. Telefonieren klappt meistens trotzdem. Bis jemand die 112 wählt und die Leitstelle nicht erfährt, in welchem Gebäude der Kollege gerade umgefallen ist. Oder bis das Controlling fragt, warum ausgerechnet der neue Standort keine einzige schlechte Verbindung hat. Antwort: Er taucht in keiner Auswertung auf. Er existiert für Teams schlicht nicht.

Dieser Beitrag gehört zur Serie rund um die Teams-Telefonie. Er setzt voraus, dass du grob weißt, wofür Netzwerkstandorte da sind, und geht direkt auf das Problem: Woran erkennst du nicht zugeordnete Subnetze, wie prüfst du Regionen, Standorte, Subnetze und vertrauenswürdige IP-Adressen mit PowerShell, wie behebst du es ohne Kollateralschaden, und wie verhinderst du, dass das nächste WLAN-Projekt dieselbe Lücke wieder aufreißt. Wie Notruf in Teams grundsätzlich aufgebaut ist, steht in Notruf in Microsoft Teams konfigurieren.

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com) mit Standorten in Frankfurt (FRA), Köln (CGN), Berlin (BER), Hamburg (HAM) und München (MUC). Direct Routing über sbc1.contoso.com und sbc2.contoso.com, Rufnummern im Muster +49 69 555 0100. Interne Netze 10.10.0.0/16 (Frankfurt), 10.20.0.0/16 (Köln), 10.30.0.0/16 (Berlin), 10.50.0.0/16 (Hamburg), 10.60.0.0/16 (München). In Köln hat das Netzteam ein neues WLAN mit 10.70.0.0/16 gebaut und das Teams-Team, ganz klassisch, nicht informiert. Öffentliche Adressen stammen aus den Dokumentationsbereichen 198.51.100.0/24 und 203.0.113.0/24. Alles erfunden.

 

Das Symptom: Teams weiß nicht, wo du bist

So klingt es im Helpdesk

Nicht zugeordnete Subnetze melden sich selten direkt. Sie verkleiden sich als andere Probleme. Die typischen Sätze:

„Bei mir steht kein Notrufstandort.“ Oder schlimmer: Es steht der Standort von letzter Woche da. Der Client hat für sein aktuelles Netz keinen Treffer bekommen.

„Im Erdgeschoss geht es, im zweiten Stock nicht.“ Zwei Etagen, zwei Subnetze, nur eins davon ist in Teams eingetragen.

„Seit dem neuen WLAN ist alles komisch.“ Der Klassiker. Neues Netz, neue Adressbereiche, in Teams hat sie keiner nachgezogen.

„Teams sagt, der Anruf sei wegen der Einstellungen der Organisation nicht erlaubt.“ Wer standortbasiertes Routing nutzt, bekommt diese Meldung, wenn der Client an einem unbekannten Ort sitzt und der SBC das nicht erlaubt.

„Im Bericht fehlt Köln.“ Anrufe aus dem neuen Netz landen in Auswertungen unter „unbekannt“ oder beim falschen Standort.

So sieht es der Admin

Auf Admin-Seite ist das Bild genauso diffus: In der Anrufanalyse einzelner Anrufe fehlt der Standort, Notrufrichtlinien wirken bei manchen Benutzern und bei anderen nicht, und im Teams Admin Center sieht unter Locations › Network topology alles vollständig aus. Vollständig ist dort allerdings nur, was jemand eingetragen hat. Was fehlt, zeigt dir keine Liste der Welt, sondern nur der Abgleich mit dem echten Netz.

WICHTIG · Warum das kein Schönheitsfehler ist Ein fehlendes Subnetz kostet im Alltag selten einen Anruf. Es kostet im Ernstfall die Adresse beim Notruf. Der Notruf selbst geht in der Regel trotzdem raus, denn 110 und 112 hängen an der Notruf-Routingrichtlinie des Benutzers und an deinem Routing, nicht an der Topologie. Aber die Leitstelle erfährt dann bestenfalls die hinterlegte Standardadresse, nicht das Gebäude, in dem der Mensch gerade sitzt. Was in so einem Fall genau passiert und was die Leitstelle dann sieht, steht in Notrufadresse fehlt in Teams: was bei 112 wirklich passiert.

 

Wie der Fehler entsteht: Region, Standort, Subnetz, Trusted IP

Die Kette ist kurz, aber jedes Glied kann reißen. Teams ermittelt den Standort eines Clients nicht über GPS und nicht über den Wohnort im Active Directory, sondern ausschließlich über das Netz. Dafür gibt es vier Bausteine, die du im Teams Admin Center unter Locations › Network topology oder per PowerShell pflegst.

Baustein	Was er ist	Typischer Fehler	Prüfen mit
Netzwerkregion	Logische Klammer um mehrere Standorte, z. B. DE-Nord. Wird von standortbasiertem Routing und Notruf gemeinsam genutzt.	Selten falsch, aber oft wild benannt.	Get-CsTenantNetworkRegion
Netzwerkstandort	Ein Ort mit eigener Infrastruktur: Büro, Gebäude, Campus. Gehört zu genau einer Region. Trägt Notruf-, Notruf-Routing- und Roaming-Richtlinien sowie den LBR-Schalter.	Standort ohne Subnetze, oder Richtlinie fehlt.	Get-CsTenantNetworkSite
Subnetz	Internes IP-Netz (IPv4 oder IPv6), das genau einem Standort zugeordnet ist.	Neues Netz nicht eingetragen, falsche Maske, falscher Standort.	Get-CsTenantNetworkSubnet
Vertrauenswürdige IP	Öffentliche Adresse oder Adressbereich, über den euer Netz ins Internet geht.	Neuer Internetanschluss, IPv6 vergessen, Cloud-Proxy schreibt Adressen um.	Get-CsTenantTrustedIPAddress
LIS-Subnetz	Eigener Eintrag im Location Information Service, der einem Subnetz eine Notrufadresse zuordnet. Getrennt von der Topologie.	Subnetz in der Topologie, aber nicht im LIS.	Get-CsOnlineLisSubnet

 

Der Türsteher: vertrauenswürdige IP-Adressen

Bevor Teams überhaupt nach einem Subnetz schaut, prüft es die öffentliche IP-Adresse, mit der der Client bei Microsoft ankommt. Steht sie nicht in der Liste der vertrauenswürdigen IP-Adressen, stuft Microsoft den Client als „an unbekanntem Ort“ ein. Ende der Diskussion. Das interne Subnetz kann noch so ordentlich gepflegt sein, es wird gar nicht erst angeschaut. Darum ist ein neuer Internetanschluss am Standort ein genauso zuverlässiger Auslöser wie ein neues WLAN.

Zwei Feinheiten aus der Microsoft-Dokumentation: Hat euer Netz sowohl IPv4- als auch IPv6-Adressen im Internet, musst du beide als vertrauenswürdig eintragen, denn der Abgleich hängt davon ab, mit welchem Protokoll der Client ankommt. Und Cloud-Proxy-Dienste, die die Quelladresse der Teams-Clients verändern, werden für diese Abfrage ausdrücklich nicht unterstützt. Wer Teams-Verkehr durch einen solchen Dienst schickt, hat damit ein strukturelles Problem, kein Konfigurationsproblem. Dasselbe gilt sinngemäß für VPN-Tunnel ohne Split Tunneling; mehr dazu in Teams-Telefonie über VPN: Split Tunneling richtig einrichten.

Der Standort: Subnetz rein, Richtlinien raus

Passt die öffentliche Adresse, sucht Teams das interne Subnetz, in dem die Client-Adresse liegt. Jedes Subnetz darf genau einem Standort gehören, ein Standort darf beliebig viele Subnetze haben. Findet Teams einen Treffer, bekommt der Client die Richtlinien dieses Standorts: Notrufrichtlinie, Notruf-Routingrichtlinie, Netzwerk-Roaming-Richtlinie und den Status für standortbasiertes Routing. Eine Notrufrichtlinie am Standort schlägt dabei laut Microsoft die Richtlinie, die dem Benutzer direkt zugewiesen ist. Findet Teams keinen Treffer, fällt der Client auf seine benutzerbezogenen Richtlinien zurück und gilt für Location-Based Routing als unbekannt.

Die Adresse: LIS ist ein eigenes Buch

Jetzt kommt die Stelle, an der sich die meisten verlaufen. Die Notrufadresse kommt nicht aus dem Netzwerkstandort, sondern aus dem Location Information Service (LIS). Microsoft sagt das sehr deutlich: Wer Subnetze in Netzwerkstandorten verwendet, muss sie im LIS noch einmal definieren, damit dynamische Adressen entstehen. Das LIS kennt dabei vier Arten von Netzkennungen und nimmt den ersten Treffer in dieser Reihenfolge: WLAN-Zugangspunkt (BSSID), Switch mit Port, Switch, Subnetz.

Und es rechnet anders. Beim Netzwerkstandort zählt, ob die Client-Adresse im eingetragenen Bereich liegt. Das LIS dagegen berechnet aus Client-Adresse und gemeldeter Präfixlänge eine Netz-ID, und genau diese Netz-ID muss als Subnetz im LIS stehen. Microsofts eigenes Beispiel: Ein Client mit 10.10.10.150/25 hat die Netz-ID 10.10.10.128. Trägst du im LIS ein großzügiges 10.10.0.0 ein, trifft das diesen Client nicht.

FAKTEN · Was Microsoft zu Netzwerkeinstellungen festlegt Jeder Netzwerkstandort gehört zu genau einer Netzwerkregion. Ein Subnetz gehört zu genau einem Standort, ein Standort kann mehrere Subnetze haben. IPv4 und IPv6 werden unterstützt. Für standortbasiertes Routing hat IPv6 beim Abgleich Vorrang. Vertrauenswürdige externe IP-Adressen kannst du laut Microsoft in unbegrenzter Zahl anlegen. Passt die öffentliche Adresse nicht, gilt der Client als unbekannt. BSSID und Switch-Daten fragt der Client beim LIS trotzdem ab, den Subnetz-Abgleich nicht. Änderungen an Netzwerkeinstellungen können bis zu vier Stunden brauchen, bis sie bei den Clients ankommen. Der Teams-Webclient unterstützt dynamischen Notruf nicht. Nachzulesen bei Microsoft: Netzwerkeinstellungen für Cloud-Sprachfeatures und Konfigurieren dynamischer Notrufe.

 

Wer hängt alles an der Topologie?

Funktion	Was sie vom Standort braucht	Folge bei fehlendem Subnetz
Dynamischer Notruf (Richtlinien)	Standort-Treffer für Notrufrichtlinie und Notruf-Routingrichtlinie	Benutzerrichtlinie bzw. globale Richtlinie gilt, Sicherheitsdienst wird ggf. nicht benachrichtigt
Dynamischer Notruf (Adresse)	LIS-Treffer über BSSID, Switch, Port oder Subnetz	keine dynamische Adresse, im besten Fall die statisch hinterlegte
Location-Based Routing	Standort mit LBR-Status, SBC mit Standort	Client gilt als unbekannt, PSTN-Anrufe je nach SBC-Einstellung blockiert
Local Media Optimization	Trusted IPs, Standorte und Subnetze, SBC mit Standortzuordnung	Medien laufen nicht auf dem kurzen Weg, Hairpinning über andere Standorte
Netzwerk-Roaming-Richtlinie	Standort-Treffer, Netzwerkkonfigurationssuche in der Besprechungsrichtlinie	Bandbreiten- und Videoeinstellungen des Standorts gelten nicht

 

Location-Based Routing ist in Deutschland selten im Einsatz, weil es vor allem für Länder mit Vorgaben gegen Toll Bypass gedacht ist. Die anderen Zeilen treffen dagegen fast jeden, der Direct Routing mit mehreren Standorten betreibt. Wie Medienwege über Standorte hinweg umgeleitet werden, wenn die Topologie nicht stimmt, beschreibt Hairpinning in Teams: wenn Anrufe Umwege über andere Standorte nehmen; die Grundlagen zu Media Bypass und Local Media Optimization stehen in Teams Media Bypass und Local Media Optimization.

Diagnose Schritt für Schritt

Alle Befehle in diesem Abschnitt lesen nur. Du brauchst das Modul MicrosoftTeams und eine Rolle, die Teams-Einstellungen lesen darf. Die Reihenfolge folgt dem Weg, den auch der Client nimmt: erst Türsteher, dann Standort, dann Adresse.

Schritt 1: Bestand der Topologie ausgeben

Connect-MicrosoftTeams   Get-CsTenantNetworkRegion | Format-Table NetworkRegionID, Description   Get-CsTenantNetworkSite | Format-Table NetworkSiteID, NetworkRegionID, EnableLocationBasedRouting, EmergencyCallingPolicyName, EmergencyCallRoutingPolicyName, NetworkRoamingPolicyName   Get-CsTenantNetworkSubnet | Sort-Object NetworkSiteID | Format-Table SubnetID, MaskBits, NetworkSiteID, Description   Get-CsTenantTrustedIPAddress | Format-Table IPAddress, MaskBits, Description

 

Lies die Ausgabe nicht als Inventar, sondern als Fragenkatalog. Hat jeder Standort mindestens ein Subnetz? Hat jeder Standort, an dem Menschen sitzen, eine Notruf-Routingrichtlinie? Steht für jeden Internetausgang eine vertrauenswürdige Adresse in der Liste, auch für den Backup-Anschluss und für IPv6? Und passt die Beschreibung noch, oder steht da „Provisorium 2021“?

Schritt 2: Standorte ohne Subnetz und Subnetze ohne LIS-Eintrag finden

$sites = Get-CsTenantNetworkSite $subnets = Get-CsTenantNetworkSubnet $lis = Get-CsOnlineLisSubnet   # Standorte, denen kein einziges Subnetz zugeordnet ist $sites | Where-Object { $_.NetworkSiteID -notin $subnets.NetworkSiteID } | Select-Object NetworkSiteID, NetworkRegionID   # Subnetze der Topologie, die im LIS fehlen (keine Notrufadresse) $subnets | Where-Object { $_.SubnetID -notin $lis.Subnet } | Select-Object SubnetID, MaskBits, NetworkSiteID

 

Die zweite Abfrage ist bewusst grob. Sie findet Subnetze, die im LIS gar nicht vorkommen. Sie findet nicht den feineren Fall aus der Skizze oben, in dem das LIS eine andere Netz-ID erwartet, als in der Topologie steht. Dafür brauchst du die tatsächlichen Präfixlängen aus dem Netz, also Schritt 4.

Schritt 3: die öffentliche Adresse des Standorts gegenprüfen

Frag das Netzteam, über welche öffentlichen Adressen jeder Standort ins Internet geht, und zwar alle: Hauptleitung, Backup-Leitung, IPv6-Präfix, Gast-WLAN, falls dort Teams-Geräte hängen. Vergleiche die Liste mit Get-CsTenantTrustedIPAddress. Ein schneller Plausibilitätstest: In der Anrufanalyse eines betroffenen Anrufs im Teams Admin Center siehst du je Teilnehmer die Netzwerkdetails. Stimmt die dort gezeigte Umgebung nicht mit dem überein, was der Benutzer erzählt, hast du den ersten Verdächtigen.

WARNUNG · Achtung bei SD-WAN und zentralem Breakout Viele Unternehmen leiten den Internetverkehr aller Standorte über eine zentrale Firewall oder einen Cloud-Dienst. Dann kommen alle Clients mit derselben öffentlichen Adresse bei Microsoft an. Das ist für die Trusted-IP-Prüfung kein Problem, solange die Adresse in der Liste steht. Verändert ein Cloud-Proxy aber die Quelladressen der Teams-Clients, funktioniert die Netzwerksuche laut Microsoft nicht. Dann hilft kein Subnetz-Eintrag, sondern nur eine Ausnahme für Teams-Medien und -Signalisierung.

 

Schritt 4: liegt die Client-Adresse in einem bekannten Subnetz?

Am Client selbst liest du Adresse und Präfixlänge mit Get-NetIPAddress aus. Ob diese Adresse in einem der eingetragenen IPv4-Subnetze liegt, prüft das folgende Skript. Es rechnet nur lokal und ändert nichts.

# Auf dem betroffenen Client: Get-NetIPAddress -AddressFamily IPv4 | Format-Table IPAddress, PrefixLength, InterfaceAlias   # In der Admin-Sitzung: function Test-ImSubnetz([string]$Ip, [string]$Netz, [int]$Bits) { $a = [System.Net.IPAddress]::Parse($Ip).GetAddressBytes(); [Array]::Reverse($a) $n = [System.Net.IPAddress]::Parse($Netz).GetAddressBytes(); [Array]::Reverse($n) $ai = [BitConverter]::ToUInt32($a, 0); $ni = [BitConverter]::ToUInt32($n, 0) $m = [uint32](([uint64]4294967295 -shl (32 – $Bits)) -band 4294967295) return (($ai -band $m) -eq ($ni -band $m)) }   $clientIp = '10.70.12.34' Get-CsTenantNetworkSubnet | Where-Object { $_.SubnetID -notmatch ':' -and (Test-ImSubnetz $clientIp $_.SubnetID $_.MaskBits) }

 

Kommt nichts zurück, ist das Subnetz in Teams unbekannt. In unserem Contoso-Beispiel liefert die Adresse 10.70.12.34 aus dem neuen Kölner WLAN genau dieses Nichts. Kommen mehrere Treffer zurück, hast du überlappende Einträge und solltest nachsehen, ob sie zum selben Standort gehören. Für die Notrufadresse rechnest du zusätzlich die Netz-ID aus Adresse und PrefixLength aus und suchst sie im LIS: Bei 10.70.12.34 mit /22 ist das 10.70.12.0.

Schritt 5: Gegenprobe im Teams Admin Center und im Client

Locations › Network topology: Registerkarten Network sites und Trusted IPs. Hier siehst du auch, welche Richtlinien an welchem Standort hängen.

Locations › Networks & locations: die LIS-Seite mit Subnetzen, WLAN-Zugangspunkten, Switches und Ports samt zugeordneter Notrufadresse.

Anrufanalyse eines Benutzers: Netzwerkdetails des betroffenen Anrufs, um Adresse und Umgebung des Clients nachzuvollziehen.

Der Client selbst: Im Telefoniebereich zeigt Teams an, welchen Notrufstandort es ermittelt hat. Fehlt dort etwas oder steht ein falscher Ort, hast du die Bestätigung aus Anwendersicht.

AUS DER PRAXIS · Ulis eigener anynode-SBC und der neue Anschluss Bei mir selbst war es kein WLAN, sondern ein Providerwechsel. Neuer Glasfaseranschluss, neue öffentliche Adresse, der anynode-SBC lief nach Anpassung der Firewall sofort wieder sauber, Anrufe gingen rein und raus. Zwei Wochen später fiel mir beim Testen auf, dass mein Teams-Client keinen Notrufstandort mehr anzeigte. Ursache: Die alte Adresse stand noch als vertrauenswürdig drin, die neue nicht. Die Telefonie hat das nicht interessiert, der Notruf schon. Seitdem steht „Trusted IPs prüfen“ auf meiner Checkliste für jeden Leitungswechsel, direkt unter „Firewall-Regeln anpassen“.

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Die Ansicht Anrufqualität im Teams-Telefonie Diagnostiker ordnet die Audiostreams des gewählten Zeitraums den Standorten zu. In der Tabelle stehen je Standort die Subnetze, die Zahl der Streams, Paketverlust, Jitter, Roundtrip und die öffentliche Adresse. Streams aus Netzen, die keinem Standort zugeordnet sind, erscheinen als eigene Zeile „Nicht zugeordnet“ mit dem jeweiligen Subnetz. So siehst du, welches Netz fehlt und wie viel Verkehr darüber läuft, bevor du irgendetwas änderst. Für den Einzelfall zeigt der Benutzer-Steckbrief Standort, Notrufstandort und Netz am Standort eines Benutzers sowie die Befunde, die ihn betreffen. Auffälligkeiten im Netz erscheinen zusätzlich als Befund im Bereich Netz der Ampel. Mehr dazu auf der Seite Teams-Telefonie Diagnostiker. Du kannst ihn 15 Tage kostenlos testen.

 

Behebung: Subnetz zuordnen, Adresse nachziehen, Rollback bereithalten

Vorher: Bestand sichern

Bevor du schreibst, exportierst du. Das kostet zehn Sekunden und erspart dir im Zweifel die Frage, wie es vorher aussah.

$stamp = Get-Date -Format 'yyyyMMdd-HHmm' Get-CsTenantNetworkSite | Export-Clixml ".\sites-$stamp.xml" Get-CsTenantNetworkSubnet | Export-Csv ".\subnets-$stamp.csv" -NoTypeInformation -Encoding UTF8 Get-CsTenantTrustedIPAddress | Export-Csv ".\trustedip-$stamp.csv" -NoTypeInformation -Encoding UTF8 Get-CsOnlineLisSubnet | Export-Csv ".\lis-subnets-$stamp.csv" -NoTypeInformation -Encoding UTF8

 

Fall 1: Subnetz fehlt am Standort

Für das neue Kölner WLAN ordnest du das Subnetz dem Standort CGN zu. Ein Subnetz kann nur einem Standort gehören. Ist es irgendwo anders falsch eingetragen, korrigierst du die Zuordnung mit Set-CsTenantNetworkSubnet, statt einen zweiten Eintrag zu versuchen.

New-CsTenantNetworkSubnet -SubnetID "10.70.0.0" -MaskBits 16 ` -NetworkSiteID "CGN" -Description "Köln WLAN Gebäude B"

 

Fall 2: Notrufadresse für das Subnetz fehlt

Dann trägst du die Netz-IDs ins LIS ein, und zwar so, wie die Clients sie melden. Liefert das WLAN-Netz Adressen in /22-Blöcken, brauchst du je Block einen Eintrag mit der passenden Notrufadresse. Die Standort-ID der Adresse holst du dir vorher mit Get-CsOnlineLisLocation.

Get-CsOnlineLisLocation | Format-Table LocationId, Description, City   Set-CsOnlineLisSubnet -Subnet "10.70.12.0" -LocationId "<LocationId Köln Gebäude B>" ` -Description "Köln WLAN Gebäude B, 2. OG"

 

Wo WLAN-Zugangspunkte oder Switches per LLDP sauber gepflegt sind, ist die genauere Adresse über BSSID oder Switch-Port ohnehin die bessere Wahl, weil das LIS diese Kennungen vor dem Subnetz prüft. Wie du einen Notrufstandort testest, ohne echte Einsätze auszulösen, beschreibt Notruf in Teams testen, ohne die Leitstelle zu verärgern.

Fall 3: öffentliche Adresse fehlt

New-CsTenantTrustedIPAddress -IPAddress "203.0.113.32" -MaskBits 29 ` -Description "Köln Glasfaser neu"

 

TIPP · Rollback in einer Zeile pro Änderung Remove-CsTenantNetworkSubnet -Identity "10.70.0.0" nimmt die Standortzuordnung zurück, Remove-CsOnlineLisSubnet -Subnet "10.70.12.0" den LIS-Eintrag, Remove-CsTenantTrustedIPAddress -Identity "203.0.113.32" die vertrauenswürdige Adresse. Hast du einen bestehenden Eintrag mit Set-Cmdlets geändert, stellst du ihn aus dem Export von vorhin wieder her. Rechne in beide Richtungen mit Verzögerung: Microsoft nennt bis zu vier Stunden, bis Änderungen an Netzwerkeinstellungen bei den Clients ankommen. Wer nach zehn Minuten den Erfolg prüft und dann panisch zurückrollt, hat am Ende zwei halbe Zustände.

 

Befund	Ursache	Behebung	Rollback
Kein Standort, Trusted IPs leer oder veraltet	neuer Anschluss, IPv6 fehlt	New-CsTenantTrustedIPAddress	Remove-CsTenantTrustedIPAddress
Kein Standort, Trusted IP passt	Subnetz nicht in Topologie	New-CsTenantNetworkSubnet	Remove-CsTenantNetworkSubnet
Falscher Standort	Subnetz dem falschen Standort zugeordnet	Set-CsTenantNetworkSubnet	Set-CsTenantNetworkSubnet mit altem Wert
Standort ok, keine Adresse	Netz-ID fehlt im LIS oder passt nicht	Set-CsOnlineLisSubnet	Remove-CsOnlineLisSubnet
Standort ok, Richtlinie fehlt	Notruf-Routingrichtlinie nicht am Standort	Set-CsTenantNetworkSite	Set-CsTenantNetworkSite mit altem Wert

 

Notrufrichtlinien am Standort sind kein Ersatz für eine sauber zugewiesene Richtlinie am Benutzer. Wer sich darauf verlässt, dass der Standort schon alles regelt, landet bei Clients an unbekannten Orten in der globalen Richtlinie. Wie sich das anfühlt, wenn ein Notruf dann nicht über die erwartete Route geht, beschreibt Dynamischer Notruf in Teams funktioniert nicht.

Vorbeugung: damit das nächste WLAN nicht wieder unsichtbar ist

Nicht zugeordnete Subnetze sind fast nie ein Technik-, sondern ein Prozessproblem. Das Netzteam plant, das Teams-Team erfährt es aus dem Ticket. Ein Maschinenbauer mit zwölf Standorten hat bei uns in einer Bestandsaufnahme mehrere Dutzend Subnetze gefunden, die in keinem Teams-Standort standen, und dazu einige, die es seit Jahren nicht mehr gab. Passiert ist nichts. Was vor allem daran lag, dass in dieser Zeit niemand 112 wählen musste.

Netzänderung heißt Teams-Änderung. Jedes neue Subnetz, jeder neue Internetanschluss und jeder neue WLAN-Controller bekommt im Change-Prozess ein Pflichtfeld: Teams-Topologie und LIS nachgezogen?

Eine Quelle für die Wahrheit. Exportiere die Subnetzliste aus deinem IP-Adressmanagement und gleiche sie regelmäßig per Skript mit Get-CsTenantNetworkSubnet und Get-CsOnlineLisSubnet ab.

Sprechende Namen. Standort-IDs wie CGN oder HAM, Beschreibungen mit Gebäude und Etage. „Neu“ ist keine Beschreibung.

Beide Protokolle denken. Wer IPv6 einführt, trägt öffentliche IPv6-Präfixe als vertrauenswürdig ein und prüft, wie Clients ihre Präfixlänge melden.

Monatlich auf „unbekannt“ schauen. Steigt der Anteil von Anrufen ohne Standort, ist irgendwo ein Netz dazugekommen.

Abnahme mit echtem Client. Nach jeder Netzänderung einen Client im neuen Netz starten und prüfen, ob Notrufstandort und Standortrichtlinien stimmen. Dabei an die vier Stunden Verzögerung denken.

Diese Punkte gehören in deine Betriebsdokumentation und in die Verantwortungsmatrix zwischen Netz- und Teams-Team; wie das organisatorisch aussehen kann, beschreibt Microsoft Teams Telefonie-Governance. Wenn die Topologie über Jahre gewachsen ist und erst einmal gerade gezogen werden muss, ist das ein guter Anlass für die Beratung zur Teams-Telefonie. Und wer Änderungen dauerhaft im Blick behalten will, findet in Konfigurationsdrift in der Teams-Telefonie erkennen Ansätze für die regelmäßige Kontrolle.

WEITERLESEN · Passend zu diesem Thema › Notruf in Microsoft Teams konfigurieren › Notrufadresse fehlt in Teams: was bei 112 wirklich passiert › Dynamischer Notruf in Teams funktioniert nicht › Notruf in Teams testen, ohne die Leitstelle zu verärgern › Hairpinning in Teams: wenn Anrufe Umwege über andere Standorte nehmen › Teams Media Bypass und Local Media Optimization › Teams-Telefonie über VPN: Split Tunneling richtig einrichten › Teams-Telefonie Probleme: die zehn häufigsten Ursachen

 

FAQ: Netzwerkstandorte und Subnetze in Teams

Brauche ich Netzwerkstandorte, wenn ich keinen dynamischen Notruf nutze?

Für die reine Telefonie über Direct Routing nicht. Sobald du aber dynamischen Notruf, Local Media Optimization, Location-Based Routing oder die Netzwerk-Roaming-Richtlinie einsetzt, sind sie Pflicht. Und für Notruf an mehreren Standorten kommst du in der Praxis kaum ohne sie aus.

Reicht es, die Subnetze im LIS einzutragen?

Für die Notrufadresse ja, für die Standortrichtlinien nein. Microsoft unterscheidet ausdrücklich: Wer nur dynamische Adressen braucht, kommt mit vertrauenswürdigen IP-Adressen und LIS aus. Wer Notruf dynamisch aktivieren oder den Sicherheitsdienst standortabhängig benachrichtigen will, braucht zusätzlich Netzwerkstandorte.

Darf ich ein großes Subnetz wie 10.0.0.0/8 für alles eintragen?

Für einen einzelnen Standort technisch ja, sinnvoll ist es nicht. Ein Subnetz gehört genau einem Standort, damit wären alle Clients an diesem einen Standort. Und im LIS trifft ein so großer Eintrag kaum einen Client, weil dort die exakte Netz-ID zählt.

Wie lange dauert es, bis eine Änderung wirkt?

Microsoft nennt bis zu vier Stunden, bis Änderungen an Netzwerkeinstellungen bei den Clients ankommen. Der Client fragt beim Start, regelmäßig und bei einem Netzwechsel neu an.

Was passiert im Homeoffice?

Die öffentliche Adresse eines Heimanschlusses steht nicht in deinen vertrauenswürdigen IPs, der Client gilt damit als unbekannt. Dynamische Adressen über das Firmennetz gibt es dort nicht, die Benutzerrichtlinien greifen. Läuft Teams-Verkehr durch das VPN, kommt der Client dagegen mit der öffentlichen Adresse der Zentrale an. Ist der VPN-Adresspool dann einem Standort zugeordnet, sitzt der Benutzer für Teams scheinbar in der Zentrale – genau das willst du für den Notruf nicht.

Warum zeigt Teams einen Standort, aber keine Notrufadresse?

Weil Standort und Adresse aus zwei Abfragen kommen. Der Standort passt, wenn die Adresse im Subnetz liegt. Die Adresse kommt aus dem LIS und braucht die exakte Netz-ID, eine BSSID oder einen Switch-Eintrag. Bei IPv6-Clients mit /128 aus statusbehaftetem DHCPv6 beschreibt Microsoft genau diesen Fall.

Gelten die Netzwerkstandorte auch für die Auswertungen im Call Quality Dashboard?

Nicht automatisch. Das CQD bezieht Standortinformationen aus den Gebäudedaten, die du dort hochlädst. Pflege beide Listen aus derselben Quelle, sonst stimmen Notruf und Auswertung nicht überein. Mehr zum CQD steht in Sprachqualität in Teams: QoS, CQD und Troubleshooting.

Fazit: Die Topologie ist nur so gut wie die letzte Netzänderung

Netzwerkregionen, Standorte, Subnetze und vertrauenswürdige IP-Adressen sind schnell angelegt. Das Problem ist nicht der erste Tag, sondern das dritte Jahr: neue Etage, neues WLAN, neuer Anschluss, und niemand denkt an Teams. Die Diagnose dauert mit Get-CsTenantNetworkSite, Get-CsTenantNetworkSubnet, Get-CsTenantTrustedIPAddress und einem Blick ins LIS keine Stunde. Die Behebung ist ein Einzeiler pro Netz. Teuer wird es nur, wenn du es erst merkst, wenn jemand 112 wählt.

Merke dir die Kette: Türsteher, Standort, Adresse. Wer sie in dieser Reihenfolge prüft und die Pflege an den Netzwerk-Change koppelt, hat ein Thema weniger, das im Ernstfall leise schiefgeht. Und wenn du das Ganze einmal grundsätzlich für alle Standorte planen willst, ist das Festpreispaket Grobkonzept Teams-Telefonie ein guter Startpunkt.