Teams-Anrufprotokolle auswerten: Call Records statt Bauchgefühl

WISSEN Alles zur Teams-Telefonie: Direct Routing, SBC, Wählpläne, Routing, Notruf und Betrieb an einem Ort. › Teams-Telefonie	BERATUNG Du willst aus Anrufdaten eine regelmäßige Betriebsauswertung machen? Wir bauen sie mit dir auf, mit Leserechten und Augenmaß. › Beratung zur Teams-Telefonie	SCHULUNG Für Admins, die SIP-Codes, Anruflisten und CQD selbst lesen und daraus die richtigen Schlüsse ziehen wollen. › Schulung Teams-Telefonie

 

„Teams geht ständig nicht.“ Diesen Satz hörst du in der Kaffeeküche, im Ticketsystem und irgendwann auch von der Geschäftsführung. Was du nie hörst: wann, wo, über welchen SBC und mit welchem Fehlercode. Bauchgefühl ist ein fantastisches Werkzeug für die Wahl des Mittagessens. Für die Fehlersuche in der Teams-Telefonie ist es ungefähr so nützlich wie eine Wünschelrute im Rechenzentrum.

Dabei liegen die Fakten längst bereit. Microsoft protokolliert jeden Anruf: als callRecord in Microsoft Graph, als Zeile in der Direct-Routing- oder PSTN-Anrufliste und als Qualitätsdatensatz im Call Quality Dashboard. Wer Teams Call Records auswerten kann, ersetzt „ständig“ durch eine Zahl und „irgendwie“ durch ein Gateway. Dieser Beitrag gehört zur Serie rund um die Teams-Telefonie und zeigt dir, welche Daten es gibt, wie lange sie leben, welche Rechte du brauchst und wie du aus Tausenden Einzelanrufen ein Muster machst, je Standort, je Gateway und je Fehlercode.

FAKTEN · Das Beispiel in diesem Beitrag Erfundener Tenant Contoso (contoso.com) mit Zentrale in Frankfurt und Standorten in Köln, Berlin, Hamburg und München. Direct Routing über sbc1.contoso.com und sbc2.contoso.com in Frankfurt sowie sbc-koe.contoso.com und sbc-muc.contoso.com. Rufnummern im Muster +49 69 555 0100. Alle Zahlen in Tabellen und Skizzen sind erfunden und dienen nur der Anschauung.

 

Das Symptom: Alle meckern, keiner weiß Genaues

So klingt es im Helpdesk

„Seit dem Update gehen meine Anrufe nicht mehr raus.“ (Welches Update? „Na, DAS Update.“)

„Bei mir bricht es immer ab.“ (Immer heißt: zweimal letzte Woche.)

„Köln ist kaputt.“ (Köln ist eine Stadt mit einer Million Einwohnern. Etwas genauer wäre schön.)

„Die Kunden sagen, sie kommen nicht durch.“ (Welche Kunden, welche Nummer, wann?)

„Das ist bestimmt das Netz.“ (Das Netz ist immer schuld, bis jemand nachsieht.)

Auf der Admin-Seite sieht es nicht besser aus. Du nimmst ein Ticket, stellst einen Anruf nach, er funktioniert. Ticket geschlossen, Problem bleibt. Drei Tage später kommt das nächste Ticket von einem anderen Standort, mit einer anderen Beschreibung, und du weißt nicht, ob es dasselbe Problem ist oder ein neues. Die Teams-Telefonie bekommt einen Ruf, den sie vielleicht gar nicht verdient, oder einen Fehler, den niemand je in Summe gesehen hat.

Warum Einzelfälle in die Irre führen

Ein einzelner gescheiterter Anruf sagt fast nichts. Er kann am Anrufer liegen, am Ziel, am Mobilfunknetz der Gegenseite, an einer falsch gewählten Nummer oder tatsächlich an deiner Konfiguration. Erst die Häufung verrät die Ursache: Scheitern Anrufe nur über ein Gateway, nur an einem Standort, nur zu einer bestimmten Uhrzeit oder nur mit einem bestimmten SIP-Code, dann hast du eine Spur. Scheitern sie gleichmäßig verteilt mit 486 und 487, dann haben deine Anwender einfach Gesprächspartner, die besetzt sind oder nicht abnehmen. Das ist ärgerlich, aber kein Fall für dich.

WICHTIG · Die Frage, die du zuerst stellst Nicht „Was ist kaputt?“, sondern „Was ist anders?“. Anders als letzte Woche, anders als am Nachbarstandort, anders als am zweiten SBC. Ein Muster ist immer ein Unterschied. Ohne Vergleichsgröße ist jede Fehlerzahl nur eine Zahl.

 

Welche Daten es gibt und wie lange sie leben

Technisch entsteht für jeden Anruf an mehreren Stellen ein Protokoll. Die Kette Benutzer › Wählplan › Normalisierung › Voice Routing Policy › PSTN Usage › Voice Route › SBC hinterlässt am Ende eine Spur: welcher Benutzer, welche Nummer, welches Gateway, welcher finale SIP-Code. Die Medien hinterlassen eine zweite Spur mit Paketverlust, Jitter und Roundtrip. Die Spuren liegen aber in verschiedenen Töpfen, mit verschiedenen Feldern und vor allem mit verschiedenen Verfallsdaten.

Microsoft Graph callRecords

Ein callRecord entsteht, nachdem ein Anruf oder eine Besprechung beendet ist. Er beschreibt einen Peer-to-Peer-Anruf oder einen Gruppenanruf mit seinen Teilnehmern, darunter Sitzungen (sessions) und Segmente (segments), und in den Segmenten die Medienströme mit Qualitätswerten. Das ist die detaillierteste Quelle für die Frage „Wie klang es?“ und „Über welche Netze lief es?“. Der Haken: Laut Microsoft-Dokumentation bleibt ein callRecord 30 Tage verfügbar, ältere Datensätze liefert die API nicht mehr. Die Liste lässt sich nach startDateTime und nach der ID eines Teilnehmers filtern; Sitzungen und Teilnehmer bekommst du erst über den Abruf eines einzelnen Datensatzes.

Direct-Routing- und PSTN-Anruflisten

Für die Frage „Kam der Anruf überhaupt zustande?“ sind die Anruflisten die bessere Quelle. Microsoft Graph bietet dafür die Funktionen getDirectRoutingCalls und getPstnCalls, das Teams Admin Center zeigt dieselben Daten im PSTN-Nutzungsbericht mit den Registerkarten für Calling Plans und Direct Routing. Eine Zeile entspricht einem Anruf. Für Direct Routing stehen darin unter anderem der Benutzer, Anrufer- und Zielnummer, der Anruftyp, Einladungs-, Start-, Fehler- und Endzeit, der finale SIP-Code, der Microsoft-Subcode, die Beschreibung, der FQDN des SBC, ob Media Bypass aktiv war, die Azure-Region für Signalisierung und Medien sowie eine Correlation ID für den Microsoft-Support.

Wichtig für die Zahlen: Der Bericht im Admin Center bildet die Aktivität laut Dokumentation in der Regel mit 24 bis 48 Stunden Verzögerung ab. Die Aufbewahrung richtet sich nach dem Land des Benutzers. Für Deutschland nennt Microsoft 150 Tage bei Direct Routing und 180 Tage bei Calling Plans. Fehlt beim Benutzer der Nutzungsort, gilt das Land des Tenants. Die Graph-Funktionen liefern 1.000 Zeilen pro Seite und verweisen über @odata.nextLink auf die nächste. Bei getPstnCalls darf der Zeitraum zwischen Beginn und Ende höchstens 90 Tage betragen.

Call Quality Dashboard und Teams Admin Center

Das Call Quality Dashboard (CQD) bekommt seine Daten nahezu in Echtzeit, laut Microsoft meist innerhalb von 30 Minuten nach Gesprächsende, und hält sie zwölf Monate vor. Personenbezogene Felder wie IP-Adresse, UPN, Rufnummer oder Standortbezeichnung werden nach 28 Tagen gelöscht, die Daten bleiben danach anonym auswertbar. Seine Stärke spielt das CQD aus, wenn du Gebäudedaten hochgeladen hast: Dann ordnet es Streams Standorten und Subnetzen zu und unterscheidet Firmennetz von Heimnetz. Ohne Gebäudedaten ist für das CQD alles „draußen“. Wie du das CQD für Qualitätsthemen nutzt, steht ausführlich in Sprachqualität in Teams: QoS, CQD und Troubleshooting.

Im Teams Admin Center findest du zusätzlich die Anrufanalyse je Benutzer und für Direct Routing das Integritätsdashboard sowie zu jedem Anruf im Direct-Routing-Bericht den SIP-Ablauf als Leiterdiagramm. Das ist ideal für den Einzelfall, aber kein Werkzeug für Muster über Wochen.

Quelle	Beantwortet	Aufbewahrung (DE)	Zugriff
Graph callRecords	Wie klang es, welche Netze, welche Geräte	30 Tage	App mit CallRecords.Read.All
Graph getDirectRoutingCalls	Kam der Anruf zustande, über welchen SBC, welcher SIP-Code	150 Tage	App mit CallRecords.Read.All
Graph getPstnCalls	Calling Plans und Operator Connect: Dauer, Ziel, Kosten	180 Tage	App mit CallRecords.Read.All
PSTN-Nutzungsbericht im Admin Center	wie oben, mit CSV-Export und SIP-Ablauf	wie die Graph-Anruflisten	Admin-Rolle
Call Quality Dashboard	Qualität je Gebäude, Subnetz, Client, Trend	12 Monate, personenbezogen 28 Tage	Admin-Rolle, Berichtsleser ohne personenbezogene Felder

 

WARNUNG · Rufnummern mit Sternchen sind kein Fehler In den PSTN- und Direct-Routing-Berichten, im Export und in den Graph-Anruflisten werden externe Rufnummern je nach Land gekürzt. Für Deutschland ersetzt Microsoft die letzten drei Ziffern durch Sternchen, also etwa +49 30 555 12***. Gruppieren nach exakter Zielnummer funktioniert deshalb nicht, gruppieren nach Vorwahl oder Zielland sehr wohl. Eigene Nummern deines Tenants bleiben vollständig.

 

Berechtigungen: Leserechte genügen

Die Graph-Endpunkte für callRecords, getDirectRoutingCalls und getPstnCalls unterstützen ausschließlich die Anwendungsberechtigung CallRecords.Read.All. Eine delegierte Berechtigung, mit der du dich als Benutzer anmeldest, gibt es dafür nicht. Du brauchst also eine App-Registrierung in Entra ID, der ein Administrator diese eine Berechtigung erteilt und zustimmt. Melde die App mit einem Zertifikat an statt mit einem geheimen Schlüssel, der irgendwann in einem Skript auf einem Netzlaufwerk landet. Schreibrechte braucht keine Auswertung. Wer für einen Anrufbericht Directory.ReadWrite.All vergibt, hat das Prinzip der geringsten Rechte nicht verstanden und bekommt es irgendwann vom Penetrationstester erklärt.

Für die Portale gelten Admin-Rollen. Laut Microsoft sehen Teams-Administrator, Teams-Kommunikationsadministrator, Teams Communications Support Engineer und globaler Leser im CQD auch die personenbezogenen Felder. Berichtsleser und Teams Communications Support Specialist sehen die Daten ohne diese Felder. Wer nur Trends je Standort braucht, kommt mit dem Berichtsleser gut zurecht und schont gleichzeitig den Datenschutz. Benutzer, die einer Verwaltungseinheit zugeordnet sind, sehen personenbezogene Felder nicht, selbst wenn ihre Rolle es sonst erlauben würde.

Die offiziellen Details findest du in Arbeiten mit der Anrufdatensatz-API in Microsoft Graph und im Microsoft Teams-PSTN-Nutzungsbericht.

Diagnose Schritt für Schritt: vom Einzelanruf zum Muster

Die Auswertung folgt immer demselben Ablauf: holen, anreichern, klassifizieren, gruppieren, bewerten. Die Befehle unten sind rein lesend. Sie verändern nichts im Tenant und eignen sich deshalb auch für den ersten Blick in einer fremden Umgebung.

Schritt 1: Inventar mit dem MicrosoftTeams-Modul

Bevor du Anrufe zählst, musst du wissen, wohin sie gehören. Welcher SBC steht wo, welche Route nutzt welches Gateway, welche Voice Routing Policy gehört zu welchem Standort? Diese Zuordnung brauchst du in Schritt 2.

Connect-MicrosoftTeams   # Gateways mit Status Get-CsOnlinePSTNGateway | Select-Object Identity, Enabled, SipSignalingPort, MaxConcurrentSessions   # Routen: welches Muster über welches Gateway Get-CsOnlineVoiceRoute | Select-Object Identity, Priority, NumberPattern, OnlinePstnUsages, OnlinePstnGatewayList   # Richtlinien und ihre PSTN Usages Get-CsOnlineVoiceRoutingPolicy | Select-Object Identity, OnlinePstnUsages

 

Benenne Richtlinien und Usages nach Standorten, etwa VRP-Frankfurt oder PU-Hamburg-National. Dann ist die spätere Zuordnung trivial. Heißen sie „Policy1“ bis „Policy7“, wird die Auswertung zur Archäologie.

Schritt 2: Anrufliste holen und anreichern

Für Direct Routing holst du die Anrufliste über Microsoft Graph. Das Beispiel nutzt das Modul Microsoft.Graph.Authentication mit Zertifikatsanmeldung und folgt dem @odata.nextLink, bis alle Seiten geladen sind. Zeitangaben sind UTC; der Beginn ist inklusive, das Ende exklusive.

Connect-MgGraph -ClientId "<App-ID>" -TenantId "<Tenant-ID>" ` -CertificateThumbprint "<Fingerabdruck>" -NoWelcome   $von = "2026-10-11T00:00:00Z" $bis = "2026-11-10T00:00:00Z" $uri = "https://graph.microsoft.com/v1.0/communications/callRecords/" + "getDirectRoutingCalls(fromDateTime=$von,toDateTime=$bis)"   $zeilen = [System.Collections.Generic.List[object]]::new() do { $antwort = Invoke-MgGraphRequest -Method GET -Uri $uri -OutputType PSObject $zeilen.AddRange([object[]]$antwort.value) $uri = $antwort.'@odata.nextLink' } while ($uri) $zeilen.Count

 

Die Zeilen enthalten den Benutzer, aber nicht seinen Standort. Den holst du dir über die Richtlinie. Achtung: Ist eine Voice Routing Policy über eine Gruppe zugewiesen, zeigt Get-CsOnlineUser sie nicht unbedingt an. Die wirksame Zuweisung liefert Get-CsUserPolicyAssignment. Ein leeres Feld bedeutet: Der Benutzer hängt an der globalen Richtlinie.

$standort = @{} Get-CsOnlineUser -Filter {EnterpriseVoiceEnabled -eq $true} | ForEach-Object { $vrp = $_.OnlineVoiceRoutingPolicy $standort[$_.UserPrincipalName] = if ($vrp) { "$vrp" } else { "Global" } }   # Einzelfall mit Gruppenzuweisung prüfen Get-CsUserPolicyAssignment -Identity anna.schmidt@contoso.com ` -PolicyType OnlineVoiceRoutingPolicy

 

Schritt 3: Klassifizieren, bevor du zählst

Der häufigste Auswertungsfehler: Alles, was nicht erfolgreich war, wird als Störung gezählt. Dann hat der Standort mit den meisten ungeduldigen Anrufern die schlechteste Quote. Trenn deshalb Verhalten von Technik. Die Zuordnung unten ist eine Arbeitshypothese für die Gruppierung, keine Diagnose; im Einzelfall entscheiden Microsoft-Subcode und SIP-Ablauf. Was die einzelnen Codes bedeuten, erklärt SIP-Fehlercodes in Teams Direct Routing verstehen.

Code	Bedeutung	Klasse	Muster deutet auf
486, 487, 603	besetzt, vom Anrufer abgebrochen, abgelehnt	Verhalten	meist nichts, außer die Werte springen plötzlich
480	vorübergehend nicht erreichbar	Verhalten oder Technik	eingehend: Ziel nicht angemeldet, Weiterleitung fehlt; abgehend: Gegenseite
404, 484	Nummer unbekannt, unvollständig	Konfiguration	Normalisierung, Wählplan, Nummernformat am SBC
408	Zeitüberschreitung	Technik	SBC nicht erreichbar, Firewall, Failover
488	nicht akzeptabel, meist Codec oder SDP	Technik	Codec-Liste, Media-Einstellungen eines SBC
500, 503, 504	Server- oder Gatewayfehler	Technik	SBC überlastet, Trunk zum Provider, TLS und Zertifikate

 

Schritt 4: Gruppieren je Gateway, je Standort, je Code

Jetzt wird es interessant. Die folgenden Zeilen zählen technisch gescheiterte Anrufe je Gateway und berechnen eine Quote. Danach dasselbe je Standort und je Stunde. Drei Blickwinkel, ein Datensatz.

$technisch = 404, 408, 484, 488, 500, 503, 504   # Quote je Gateway $zeilen | Group-Object trunkFullyQualifiedDomainName | ForEach-Object { $tech = @($_.Group | Where-Object { $technisch -contains $_.finalSipCode }).Count [pscustomobject]@{ Gateway = $_.Name; Anrufe = $_.Count; Technisch = $tech Quote = [math]::Round(100 * $tech / $_.Count, 1) } } | Sort-Object Quote -Descending | Format-Table   # Kreuztabelle Gateway und Code, nur gescheiterte Anrufe $zeilen | Where-Object { -not $_.successfulCall } | Group-Object trunkFullyQualifiedDomainName, finalSipCode | Sort-Object Count -Descending | Select-Object Count, Name -First 15   # Je Standort (über die Richtlinie aus Schritt 2) $zeilen | Where-Object { $technisch -contains $_.finalSipCode } | Group-Object { $standort[$_.userPrincipalName] } | Sort-Object Count -Descending   # Je Stunde (UTC), um Tageszeitmuster zu finden $zeilen | Where-Object { $technisch -contains $_.finalSipCode } | Group-Object { ([datetime]$_.inviteDateTime).ToUniversalTime().Hour } | Sort-Object Name

 

Das Ergebnis sieht im Contoso-Beispiel so aus wie in der Skizze unten. Der Blick in die Kreuztabelle beantwortet die Frage, die keine Einzelanalyse beantworten kann: Liegt es am Standort oder am Gerät? Beide Frankfurter SBC stehen im selben Netz. Nur einer produziert 488. Also ist es nicht das Netz in Frankfurt.

TIPP · Quoten statt Anzahlen 78 Fehler klingen dramatisch, sind bei 2.770 Anrufen aber 2,8 Prozent. Vier Fehler an einem kleinen Standort mit 40 Anrufen sind dagegen zehn Prozent. Vergleiche deshalb immer Quoten und setz eine Mindestmenge, ab der du eine Quote überhaupt ernst nimmst. Unter ein paar Dutzend Anrufen ist jede Prozentzahl eher Stimmung als Statistik.

 

Schritt 5: Den Einzelfall nachstellen

Ein Muster ist eine Hypothese. Bestätigt wird sie am konkreten Anruf. Nimm aus der auffälligen Gruppe zwei oder drei Beispiele und sieh sie dir im Teams Admin Center an: Im Direct-Routing-Bericht öffnest du über den finalen SIP-Code den SIP-Ablauf zwischen SBC und SIP-Proxy. Dort siehst du, wer welche Nachricht geschickt hat und wer den Anruf beendet hat. Für Qualitätsfragen holst du den callRecord mit Sitzungen und Segmenten, solange er noch keine 30 Tage alt ist.

$id = "<callRecord-ID>" $cr = Invoke-MgGraphRequest -Method GET -OutputType PSObject -Uri ( "https://graph.microsoft.com/v1.0/communications/callRecords/$id" + "?`$expand=sessions(`$expand=segments)") $cr.sessions.segments.media.callerNetwork | Select-Object subnet, connectionType, wifiBand, networkTransportProtocol

 

Eine Zeile aus der Direct-Routing-Liste und ein callRecord lassen sich übrigens nicht über die ID verbinden. Microsoft weist ausdrücklich darauf hin, dass die ID einer Anruflistenzeile nicht als callRecord-ID taugt. Für die Zuordnung bleiben Benutzer und Zeitpunkt.

AUS DER PRAXIS · Ein Maschinenbauer mit zwölf Standorten Die Beschwerden kamen aus allen Richtungen, die Stimmung war eindeutig: „Teams-Telefonie taugt nichts, die alte Anlage lief wenigstens.“ Die Auswertung von 30 Tagen Direct-Routing-Liste zeigte etwas anderes. 94 Prozent aller technischen Fehler kamen von einem einzigen SBC, und zwar ausschließlich bei abgehenden Anrufen in ein bestimmtes Mobilfunknetz, ausschließlich mit 488. Elf Standorte waren unauffällig. Ursache war eine Codec-Liste, die bei einem Firmware-Update auf Werkseinstellungen zurückgefallen war. Eine Änderung, ein Test, Ruhe. Und die gefühlte Katastrophe schrumpfte auf das, was sie war: ein Konfigurationsfehler an einem Gerät.

 

AUS DER PRAXIS · Mein eigener anynode-SBC Auch bei mir war das Bauchgefühl gut: Der eigene anynode-SBC lief, Anrufe kamen an, alles bestens. Die Gruppierung nach Stunde zeigte dann einen kleinen, aber hartnäckigen Haufen von 408 immer in derselben Nachtstunde. Ursache war die Zwangstrennung des Internetanschlusses mit neuer öffentlicher Adresse. Nachts ruft selten jemand an, deshalb hatte es nie jemand bemerkt. Ohne Auswertung hätte ich es bis zum ersten wichtigen Anruf um drei Uhr morgens auch nicht.

 

WERKZEUG · So findet es der Teams-Telefonie Diagnostiker Der Teams-Telefonie Diagnostiker liest die Anrufdaten über eine App-Registrierung mit reinen Leserechten und schreibt im Nur-Lese-Modus nichts in deinen Tenant. Im Bereich Anrufqualität zeigt er die SIP-Fehlercodes je Gateway mit Erfolgsquote und technischen Fehlern für 7 und 30 Tage sowie den Anteil schlechter Audiostreams je Standort. Auffälligkeiten erscheinen als Befunde mit Prüffall, zusammengefasst in der Ampel, und lassen sich als Bericht ausgeben. Mehr dazu auf der Seite Teams-Telefonie Diagnostiker. Du kannst ihn 15 Tage kostenlos testen.

 

Behebung: aus dem Muster wird eine Maßnahme

Die Auswertung selbst behebt nichts. Sie sagt dir aber, wo du anfangen musst, und verhindert, dass du an fünf Stellen gleichzeitig schraubst. Die Tabelle ordnet typische Muster den wahrscheinlichen Ursachen zu.

Muster	Wahrscheinliche Ursache	Nächster Schritt
Ein Gateway, ein Code, alle Standorte	Einstellung oder Zustand dieses SBC	Konfiguration und Firmware des SBC prüfen, mit zweitem SBC vergleichen
Ein Standort, viele Codes	Richtlinie, Wählplan oder Routing dieses Standorts	Rufweg für Beispielnummern mit Test-CsEffectiveTenantDialPlan und Richtlinien nachvollziehen
404 oder 484 gehäuft bei bestimmten Zielen	Normalisierung oder Nummernformat	Normalisierungsregeln und Ausgangsübersetzung am SBC prüfen
408 oder 503 in Wellen	SBC zeitweise nicht erreichbar, Failover	OPTIONS-Status, Firewall und Failover-Reihenfolge prüfen
504 schlagartig ab einem Datum	Zertifikat oder Root-CA am SBC	Zertifikatskette und TLS prüfen
Erfolg ok, aber Beschwerden über Klang	Netz, Medienweg	CQD und callRecords je Subnetz auswerten

 

Für die einzelnen Muster gibt es eigene Beiträge: Teams-Anruf geht nicht raus: den Rufweg Schritt für Schritt prüfen für den Rufweg, Normalisierungsregeln in Teams: typische Fehler und wie du sie findest für 404 und 484, Teams SBC inaktiv: OPTIONS-Ping und Verbindungsstatus prüfen und SBC-Failover in Teams funktioniert nicht für 408 und 503, SIP 504 nach dem Zertifikatswechsel: Root-CAs am SBC aktualisieren für den plötzlichen 504 und Abgehackte Sprache in Teams: Jitter, Paketverlust und Roundtrip für alles, was zwar verbindet, aber schlecht klingt.

Vorgehen mit Rückweg

Ausgangswert festhalten: Quote je Gateway und Standort für die letzten sieben Tage notieren.

Vorher sichern: Die betroffene Einstellung exportieren, etwa mit Get-CsOnlinePSTNGateway oder Get-CsTenantDialPlan in eine Datei, die SBC-Konfiguration als Backup.

Eine Änderung: Nur eine Ursache pro Schritt beheben, sonst weißt du hinterher nicht, was gewirkt hat.

Messen: Nach 24 bis 48 Stunden erneut auswerten. Die Berichte hängen hinterher, Graph und SBC-Logs eher nicht, aber eine Nacht Abstand schadet nie.

Rückweg: Verschlechtert sich die Quote oder tauchen neue Codes auf, die gesicherte Einstellung zurückspielen und neu bewerten.

WARNUNG · Nicht nach Gefühl zurückrollen Ein einzelner Beschwerdeanruf nach der Änderung ist kein Beweis, dass sie geschadet hat. Ein einzelner erfolgreicher Testanruf ist auch kein Beweis, dass sie geholfen hat. Entscheide anhand derselben Quote, mit der du das Problem gefunden hast. Sonst bist du schneller wieder beim Bauchgefühl, als dir lieb ist.

 

Vorbeugung: Auswertung als Routine statt als Feuerwehr

Die 30 Tage der callRecords sind der eigentliche Grund, warum Auswertungen zur Routine gehören. Wer erst schaut, wenn die Beschwerde eskaliert ist, findet die Daten vom Anfang des Problems nicht mehr. Ein wöchentlicher Lauf, der die Anrufliste abholt und die Kennzahlen in eine eigene Ablage schreibt, verlängert dein Gedächtnis über die Aufbewahrung von Microsoft hinaus.

Wöchentlich: Quote technischer Fehler je Gateway und Standort, Vergleich mit der Vorwoche.

Monatlich: Kreuztabelle Gateway und Code, Anteil schlechter Streams je Gebäude aus dem CQD.

Nach jeder Änderung: Firmware, Zertifikat, Routing, Wählplan: dieselben Kennzahlen 48 Stunden später erneut.

Schwellen: Lege fest, ab welcher Quote du handelst. Ohne Schwelle ist jede Zahl Diskussionsstoff.

Gebäudedaten im CQD pflegen: Neue Subnetze nachtragen, sonst landen neue Standorte im Topf „Nicht zugeordnet“.

Die Auswertung ergänzt die Erkennung von Änderungen an der Konfiguration, wie sie in Konfigurationsdrift in der Teams-Telefonie erkennen beschrieben ist: Drift sagt dir, was sich geändert hat, die Anrufdaten sagen dir, ob es jemand gemerkt hat. Beides zusammen gehört in die Microsoft Teams Telefonie-Governance.

WICHTIG · Datenschutz gleich mitdenken Anruflisten enthalten Namen, Rufnummern und Zeitpunkte. Wer daraus eine regelmäßige Auswertung macht, sollte vorher klären, wer sie sehen darf, wie lange die Ablage aufbewahrt wird und ob der Datenschutz und, falls vorhanden, der Betriebsrat einzubinden sind. Für Trends je Gateway und Standort brauchst du keine Namen. Aggregiere früh und lösche Rohdaten, die du nicht mehr brauchst.

 

WEITERLESEN · Passend dazu › Teams-Telefonie Probleme: die zehn häufigsten Ursachen › SIP-Fehlercodes in Teams Direct Routing verstehen › Eingehende Anrufe kommen in Teams nicht an › Netzwerkstandorte und Subnetze in Teams richtig pflegen › Teams-Telefonie nach der Einführung retten: ein Plan in fünf Schritten

 

FAQ: Teams Call Records auswerten

Wie lange kann ich Teams-Anrufdaten zurückverfolgen?

Das hängt von der Quelle ab. callRecords in Microsoft Graph sind 30 Tage verfügbar. Die Direct-Routing-Anrufliste bewahrt Microsoft für Benutzer in Deutschland 150 Tage auf, die PSTN-Liste für Calling Plans 180 Tage. Das CQD hält Daten zwölf Monate, personenbezogene Felder aber nur 28 Tage.

Welche Berechtigung braucht eine App für Call Records?

Die Anwendungsberechtigung CallRecords.Read.All mit Administratorzustimmung. Sie gilt für callRecords, getDirectRoutingCalls und getPstnCalls. Delegierte Berechtigungen werden für diese Endpunkte nicht unterstützt.

Warum fehlen in der Anrufliste die letzten Ziffern der Rufnummern?

Microsoft kürzt externe Rufnummern aus Datenschutzgründen je nach Land. In Deutschland werden die letzten drei Ziffern durch Sternchen ersetzt. Das gilt für die Berichte im Admin Center, den Export und die Graph-Anruflisten.

Ist 487 ein Fehler, um den ich mich kümmern muss?

In aller Regel nicht. 487 bedeutet, dass die Anfrage beendet wurde, meist weil der Anrufer aufgelegt hat, bevor jemand abnahm. Interessant wird 487 nur, wenn der Anteil plötzlich deutlich steigt, etwa weil Anrufe zu lange klingeln, bevor eine Weiterleitung greift.

Kann ich eine Zeile aus der Direct-Routing-Liste mit einem callRecord verknüpfen?

Nicht über die ID. Microsoft dokumentiert, dass die ID einer Anruflistenzeile nicht für den Abruf eines callRecords verwendet werden kann. Eine Zuordnung über Benutzer und Zeitpunkt ist möglich, aber nicht eindeutig.

Reicht der Export aus dem Teams Admin Center nicht aus?

Für eine einmalige Analyse oft schon. Der CSV-Export enthält alle wichtigen Felder, zusätzlich die Shared Correlation ID, die es nur im Export gibt. Für eine wiederkehrende Auswertung ist der Abruf über Graph bequemer, weil er sich ohne Klicken planen lässt.

Welche Rolle brauche ich für das Call Quality Dashboard?

Für Trends reicht der Berichtsleser, der die Daten ohne personenbezogene Felder sieht. Wer einzelne Benutzer, IP-Adressen oder Rufnummern sehen muss, braucht etwa den Teams Communications Support Engineer oder den Teams-Kommunikationsadministrator.

Fazit: Zahlen schlagen Anekdoten

Teams protokolliert jeden Anruf, du musst nur hinsehen, bevor die Daten verfallen. callRecords für die Qualität, die Direct-Routing- und PSTN-Anruflisten für Erfolg und Fehlercodes, das CQD für Trends je Gebäude. Mit einer App-Registrierung, die nur lesen darf, ein paar Zeilen PowerShell und der Disziplin, Verhalten von Technik zu trennen, wird aus „Teams geht ständig nicht“ ein Satz wie „sbc1 liefert seit Dienstag 488“. Mit dem einen kannst du nichts anfangen, mit dem anderen ein Ticket lösen.

Wenn du die Auswertung dauerhaft im Betrieb verankern willst oder zuerst einen unabhängigen Blick auf deine Zahlen brauchst, hilft dir die Beratung zur Teams-Telefonie. Und wer die Codes und Werkzeuge selbst sicher lesen will, findet in der Schulung Teams-Telefonie den passenden Einstieg.