Outlook Assessment Test
Ich werde immer wieder gefragt, was ich eigentlich so mit einem Netzwerk Assessment alles tue. Am Beispiel von Exchange Online möchte ich mit wenigen PowerShell-Befehlen ihnen zeigen, wie eine einfache einmalige Prüfung erfolgen kann und Sie dabei zugleich ihre Konfiguration prüfen können. Zudem lernen wir etwas mehr über das Backend.
Outlook Assessment Test
https://www.youtube.com/watch?v=GEC4Zq2pNHE
Diese Seite gibt es auch als Video
Wie arbeitet Exchange Online?
Es ist ihnen sicher bekannt, dass Outlook mit Exchange Online über MAPI/HTTP kommuniziert. Das sehen Sie schon im Outlook Verbindungsstatus.
Outlook ist nun nicht gerade das zeitkritische Protokoll. Teams mit Audio/Video stellt durchaus höhere Ansprüche an Netzwerk und Latenzzeit aber HTTPS gegen https://outlook.office365.com ist ein sehr einfaches und dankbares Protokoll, um Funktionsweise, Laufzeiten, Gegenstellen und Fehlkonfigurationen zu erkennen.
Alle Tests wurden mit der Powershell 7.1.3 durchgeführt.
DNS
Ich starte erst einmal mit einer DNS-Anfragen auf diesen Namen. Natürlich kann eine Firma jeglichen HTTPS-Verkehr auch über einen HTTP-Proxy leiten, aber Microsoft rät natürlich dazu, die Office 365 Endpunkte auszunehmen, denn ein Proxy bedeutet Umwege, ggfls. Verzögerungen für Authentifizierung und Inspektion und letztlich ist es ja nur der Zugriff auf ihre eigene Daten. Ich kenne selbst keine Firma, die den Zugriff auf interne Exchange Server früher über einen HTTP-Proxy geleitet hat.
Wenn die Namensaufsung schon nicht funktioniert, dann gibt es zumindest Gesprächsbedarf und Verbesserungspotential.
PS C:\> Resolve-DnsName outlook.office365.com | ft name,type,ttl,namehost,ip4address,IP6Address Name Type TTL NameHost ip4address IP6Address ---- ---- --- -------- ---------- ---------- outlook.office365.com CNAME 9 outlook.ha.office365.com outlook.ha.office365.com CNAME 9 outlook.ms-acdc.office.com outlook.ms-acdc.office.com CNAME 9 AMS-efz.ms-acdc.office.com AMS-efz.ms-acdc.office.com AAAA 4 2603:1026:c03:6026::2 AMS-efz.ms-acdc.office.com AAAA 4 2603:1026:206:8::2 AMS-efz.ms-acdc.office.com AAAA 4 2603:1026:206:1::2 AMS-efz.ms-acdc.office.com AAAA 4 2603:1026:200:63::2 AMS-efz.ms-acdc.office.com A 4 52.97.200.146 AMS-efz.ms-acdc.office.com A 4 40.101.12.2 AMS-efz.ms-acdc.office.com A 4 52.97.135.114 AMS-efz.ms-acdc.office.com A 4 52.97.201.98
Sie sehen hier schon sehr gut, dass Microsoft den Namen "outlook.office365.com" als CNAME erst auf outlook.ha.office365.com auflöst, was wiederum ein CNAME auf "outlook.ms-acdc.office.com" ist, der dann zu "AMS-efz.ms-acdc.office.com" führt. Dieser letzte Namen zeigt mir, dass Microsoft meinen Zugriff in Amsterdam auflaufen lässt und hinter dem Namen allein vier IPv6 und vier IPv4-Adressen in dem Moment geliefert werden.
Wenn ich den Aufruf wiederhole, dann kommen die gleichen Namen aber andere IP-Adressen. Microsoft nutzt hier also DNS Round Robin, um mehrere IP-Adressen von Frontend-Servern zu verteilen. Drauf gehe ich später noch einmal genauer ein.
Einfacher HTTP-Request
Ich starte nun erst einmal einen einfachen HTTP-Requests, bei dem ich mit der HTTP-Methode "HEAD" mir nur den Header des Webservers liefern lassen.
PS C:\> Invoke-Webrequest https://outlook.office365.com -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck StatusCode : 401 StatusDescription : Unauthorized Content : {} RawContent : HTTP/1.1 401 Unauthorized Server: Microsoft-IIS/10.0 request-id: 64f7a138-5733-abf3-bc20-0fc40e3d07a5 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-CalculatedFETarget: … Headers : {[Server, System.String[]], [request-id, System.String[]], [Strict-Transport-Security, System.String[]], [X-CalculatedFETarget, System.String[]]…} RawContentLength : 0 RelationLink : {}
Das hat schon mal funktioniert und lieferte mir natürlich einen 401-Fehler. Aber mehr möchte ich gar nicht haben. Eine Authentifizierung habe ich nicht geplant.
Header und Servername
Interessanter ist die Inspektion der Header, die vom Webserver geliefert werden:
PS C:\> (Invoke-WebRequest https://outlook.office365.com -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck).headers Key Value --- ----- Server {Microsoft-IIS/10.0} request-id {8ed3ae9a-e0d1-b567-b919-b7451e1fb327} Strict-Transport-Security {max-age=31536000; includeSubDomains; preload} X-CalculatedFETarget {AS8PR04CU005.internal.outlook.com} X-BackEndHttpStatus {401, 401} Set-Cookie {ClientId=0345C2E8767A42A688BE8C053FE5309F; expires=Wed, 06-Jul-2022 19:02:10 GMT; path=/;SameSite=None; secure, ClientId=0345C2E8767A42A688BE8C053FE5309F; expires=Wed, 06-Jul-2022 19:02:10 GMT; path=… WWW-Authenticate {Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@*", token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https… X-FEProxyInfo {AS8PR04CA0138.EURPRD04.PROD.OUTLOOK.COM} X-CalculatedBETarget {AM6PR0502MB3800.eurprd05.prod.outlook.com} X-RUM-Validated {1} X-Content-Type-Options {nosniff} X-BeSku {WCS5} X-OWA-DiagnosticsInfo {0;0;0} X-BackEnd-Begin {2021-07-06T19:02:10.085} X-BackEnd-End {2021-07-06T19:02:10.086} X-DiagInfo {AM6PR0502MB3800} X-BEServer {AM6PR0502MB3800} X-UA-Compatible {IE=EmulateIE7} X-Proxy-RoutingCorrectness {1} X-Proxy-BackendServerStatus {401} X-FEServer {AS8PR04CA0138, AM3PR05CA0134} Report-To {{"group":"NelOfficeUpload1","max_age":7200,"endpoints":[{"url":"https://exo.nel.measure.office.net/api/report?TenantId=&FrontEnd=Cafe&DestinationEndpoint=AMS"}],"include_subdomains":true}} NEL {{"report_to":"NelOfficeUpload1","max_age":7200,"include_subdomains":true,"failure_fraction":1.0,"success_fraction":0.01}} Date {Tue, 06 Jul 2021 19:02:09 GMT} Content-Length {0}
Es ist unschwer zu erkennen, dass hier ganz viele zusätzliche Informationen zu erhalten sind wie z.B. reale Servernamen. ich beschränke mich im weiteren einfach mal auf den Header "X-DiagInfo". Sicher wäre auch das Feld "X-MSEdge-Ref" und viele andere Felder interessant. Sie können aber schon erahnen, dass Microsoft dahinter nicht das einfache klassische "Frontend/Backend"-Konstrukt betreibt, welches OnPremises eingesetzt wird. Über folgende Zeile bekomme ich den BEServer, welcher meine Anfrage beantwortet hat:
PS C:\> (Invoke-WebRequest https://outlook.office365.com -Method head -SkipCertificateCheck -SkipHttpErrorCheck).headers."X-DiagInfo" AM6PR04MB4967
Bedenken Sie, dass die Gegenseite noch nichts von mir weiß, d.h. weder Benutzername noch Mailadresse o.ä. anhand er die Anfragen zum passenden Postfachserver routen könnte.
Verteilung der BE-Server
Aber nichts sollte mich daran hintern, die gleiche Abfrage ganz schnell hintereinander zu machen.
PS C:\> 1..10 | % {(Invoke-WebRequest https://outlook.office365.com -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck).headers."X-DiagInfo"} AM4PR0401MB2225 AM5PR0701MB2339 AM6PR10MB2487 VI1PR0202MB2688 DB8PR03MB5674 AM6PR03MB6117 AM0PR04MB6628 AS8P251MB0183 VI1PR09MB3662 DB9P251MB0121
Ich habe also keine "Verzögerung" o.ä. eingebaut. Auch die Nutzung von "X-FEProxyInfo" ergibt ein ähnliches Bild.
PS C:\> 1..10 | % {(Invoke-WebRequest https://outlook.office365.com -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck).headers."X-FEProxyInfo"} DU2PR04CA0248.EURPRD04.PROD.OUTLOOK.COM VI1PR0501CA0010.EURPRD05.PROD.OUTLOOK.COM DU2PR04CA0230.EURPRD04.PROD.OUTLOOK.COM HE1PR0802CA0021.EURPRD08.PROD.OUTLOOK.COM AS8PR05CA0004.EURPRD05.PROD.OUTLOOK.COM AM0PR07CA0013.EURPRD07.PROD.OUTLOOK.COM AM6P195CA0050.EURP195.PROD.OUTLOOK.COM HE1PR0701CA0045.EURPRD07.PROD.OUTLOOK.COM
Jede Anfrage landet auf einem anderen Server. Beim NSLookup/Resolve-DNSName sehen Sie aber, dass der TTL bis zu 10 Sekunden lang ist. Ich muss also davon ausgehen, dass per DNS entweder andere IP-Adressen geliefert werden oder Loadbalancer dahinter sind. Per WireShark habe ich dann gesehen, dass mein Client immer auf die gleiche IPv6-Adresse zugegriffen hat.
Auch wenn der TTL sehr klein ist wurde immer die gleiche IP-Adresse genutzt aber die Antwort kam von unterschiedlichen Servern. Insofern ist auch die Frage vom Anfang schon beantwortet, ob Microsoft mit Loadbalancern arbeitet. Selbst ein direkter Test über eine IPv4-Adresse lieferte immer andere Server.
PS C:\> 1..10 | % {(Invoke-WebRequest https://40.101.12.82 -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck).headers."X-DiagInfo"} AM0PR03MB3908 AM4PR0301MB2146 AM6PR03MB5733 AM6PR03MB4439 AM6PR03MB6086 AM6PR03MB5395 AM0PR03MB5585 AM0PR03MB3746 VE1PR03MB5949 VI1PR0302MB3184
Auch die Auswertung des Headers "X-FEProxyInfo" liefert immer andere Felder.
Erste Zeitmessung
Auf dieser Seite soll es ja auch um die Zeitmessung gehen. Daher reichere ich den Code noch um ein Measure-Command an.
PS C:\> (measure-command {(Invoke-WebRequest https://outlook.office365.com -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck)}).TotalMilliseconds 189,2467 PS C:\> (measure-command {(Invoke-WebRequest https://outlook.office365.com -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck)}).TotalMilliseconds 129,2467 PS C:\> (measure-command {(Invoke-WebRequest https://outlook.office365.com -Method HEAD -SkipCertificateCheck -SkipHttpErrorCheck)}).TotalMilliseconds 125,4265
Der erste Aufruf kann etwas länger dauern, wenn z.B. der Name erst noch mittels DNS aufgelöst werden soll. Aber ansonsten sollten die Werte im Bereich 50-150ms liegen.
In einem Assessment kann es sinnvoll sein, diese Abrufzeiten häufig und regelmäßig erfassen und speichern.
Deutlich längere Laufzeiten können natürlich an einer schlechten Leitung liegen. Erwarten Sie keine kurzen Zeiten, wenn Sie im ICE-WLAN sind oder per UMTS arbeiten. Aber es kann auch ein Konfigurationsfehler sein, z.B. dass Sie alle Pakete erst durch ein VPN schleusen. Die Empfehlungen von Microsoft sind für Teams klarer als für Outlook aber auch HTTP-Anfragen sollten nicht zu lange dauern.
Falscher DNS-Server
In vielen Assessments stellen wir fest, dass Firmen einen der PublicDNS Provider als DNS-Server nutzen. Die Anbieter suggerieren eine deutlich schnellere Namensauflösung als übliche Provider, die sogar näher stehen und versprechen eine Blockade von Malware-Sites. Auch die Nutzung des Firmen-DNS-Servers beim Einsatz eines VPN wird gerne genutzt, um die interne Namensauflösung sicher zu stellen. In allen Fällen wird aber übersehen, dass die Antworten dann so kommen, als wäre ihr Client an dem Standort des DNS-Servers. Das hat durchaus nachteilige Effekte.
PS C:\> (Resolve-DnsName outlook.office365.com | where {$_.namehost})[-1].namehost AMS-efz.ms-acdc.office.com PS C:\> (Resolve-DnsName outlook.office365.com -server 9.9.9.9 | where {$_.namehost})[-1].namehost SXF-efz.ms-acdc.office.com PS C:\> (Resolve-DnsName outlook.office365.com -server 1.1.1.1 | where {$_.namehost})[-1].namehost HHN-efz.ms-acdc.office.com PS C:\> (Resolve-DnsName outlook.office365.com -server 8.8.8.8 | where {$_.namehost})[-1].namehost AMS-efz.ms-acdc.office.com PS C:\> (Resolve-DnsName outlook.office365.com -server 114.114.114.114 | where {$_.namehost})[-1].namehost MDW-efz.ms-acdc.office.com
Ein Extrembeispiel für Europa ist hier z.B. ein öffentlich erreichbarer DNS-Server in China unter der IP-Adresse 114.114.114.114
PS C:\> (measure-command {(Resolve-DnsName outlook.office365.com -server 114.114.114.114 | where {$_.namehost})[-1].namehost}).totalmilliseconds 133,7501 PS C:\> (measure-command {(Resolve-DnsName outlook.office365.com | where {$_.namehost})[-1].namehost}).totalmilliseconds 59,564
Natürlich dauert schon die DNS-Auflösung deutlich länger. Aber wenn sich dann mein Outlook Client mit dem Server "MDW-efz.ms-acdc.office.com" verbindet, dann sehen Sie die extrem verlängerte Laufzeit:
PS C:\> (measure-command {(Invoke-WebRequest https://MDW-efz.ms-acdc.office.com -Method head -SkipCertificateCheck -SkipHttpErrorCheck)}).TotalMilliseconds 864,9537 PS C:\> (measure-command {(Invoke-WebRequest https://MDW-efz.ms-acdc.office.com -Method head -SkipCertificateCheck -SkipHttpErrorCheck)}).TotalMilliseconds 713,6292
Die Antwortzeiten sind meist nie unter 700ms und teilweise sogar mehrere Sekunden. Was hier passiert ist einfach zu erklären, wenn Sie den Flughafencode "MDW" mit dem Begriff "IATA" in eine Suchmaschine ihrer Wahl einwerfen:
Wenn Sie in China sind, dann bekommen Sie einen Exchange Frontend-Server in Chicago mit der entsprechenden Laufzeit. Das gleichen Spiel funktioniert natürich auch umgekehrt, wenn ein deutscher Mitarbeiter in den USA ist und per VPN den DNS-Server der Firma in Deutschland fragt und z.B. Frankfurt als Antwort bekommt.
Routing über Internet nach Chicago?
Im schlimmsten Fall würde nun ein Client über das nicht QoS-gesicherte Internet und verschiedene Peerings zum MGN - Microsoft Global Network laufen. Hier kommt ihnen aber Microsoft entgegen, indem alle Office 365 und Azure Subnetze über Routing-Protokolle (BGP) veröffentlicht werden.
C:\>tracert -4 MDW-efz.ms-acdc.office.com Routenverfolgung zu MDW-efz.ms-acdc.office.com [52.96.164.146] über maximal 30 Hops: 1 2 ms 1 ms 1 ms fritz.box [192.168.178.1] 2 8 ms 5 ms 6 ms 100.124.1.18 3 8 ms 6 ms 6 ms 100.127.1.131 4 7 ms 6 ms 5 ms 100.127.1.132 5 10 ms 7 ms 6 ms 185.22.46.145 6 * * 15 ms ams-ix-1.microsoft.com [80.249.209.20] 7 13 ms 14 ms 14 ms ae21-0.icr01.ams21.ntwk.msn.net [104.44.232.164] 8 111 ms 109 ms 110 ms be-100-0.ibr01.ams21.ntwk.msn.net [104.44.22.235] 9 113 ms 109 ms 110 ms be-14-0.ibr01.lon24.ntwk.msn.net [104.44.30.108] 10 112 ms 109 ms 197 ms be-1-0.ibr01.lon22.ntwk.msn.net [104.44.16.55] 11 110 ms 111 ms 110 ms be-10-0.ibr01.nyc30.ntwk.msn.net [104.44.18.152] 12 112 ms 110 ms 109 ms be-8-0.ibr03.bl20.ntwk.msn.net [104.44.19.194] 13 108 ms 108 ms 109 ms be-7-0.ibr01.cle02.ntwk.msn.net [104.44.30.6] 14 110 ms 112 ms 204 ms be-11-0.ibr01.ch2.ntwk.msn.net [104.44.29.251] 15 114 ms 110 ms 111 ms ae100-0.icr01.ch2.ntwk.msn.net [104.44.11.253] 16 * * * Zeitüberschreitung der Anforderung. 17 * * * Zeitüberschreitung der Anforderung. 18 * * * Zeitüberschreitung der Anforderung. 19 * * * Zeitüberschreitung der Anforderung. 20 * * * Zeitüberschreitung der Anforderung. 21 109 ms 107 ms 110 ms 52.96.164.146
Es ist gut zu sehen, dass der Client in Europa beim nächsten Peering "AMS-IX-1.microsoft.com" im MSN landet aber dann über London (be-14-0.ibr01.lon24.ntwk.msn.net) und New-York (be-10-0.ibr01.nyc30.ntwk.msn.net) in die USA läuft.
Hier gibt es im MGN - Microsoft Global Network scheinbar noch keine Optimierung, damit ein Client einen lokalen Frontend-Server erreicht. Das wird vermutlich irgendwann dann per Anycast-Routing bereitgestellt.
Zusammenfassung
Damit Outlook und andere Cloud-Dienste optimal funktionieren können, ist nicht nur eine schnelle Leitung erforderlich sondern auch eine korrekte Konfiguration von Firewall, IP-Routing, DNS, Proxy-Server und Client. Diese Konfiguration sollte auch immer mal wieder wieder, am besten automatisiert, überprüft werden. Denn nichts ist so variabel wie das Internet und der Client, der an verschiedenen Stellen die Dienste nutzt.
Wäre es nicht interessant, ein Werkzeug zu habe, der Konfigurationsfehler und Erreichbarkeitsprobleme ermittelt? Sprechen Sie mich einfach an Kontakt
Weitere Links
- PublicDNS Provider
- DoH - DNS over HTTPS - DNS Abfragen per HTTPS statt UDP/TCP und die Auswirkungen auf die Cloud
- DNS im Netzwerk
- Office 365: DNS-Routing
- Office 365 DNS Details
- Office 365 Network Assessment -Kurzfassung
- MGN - Microsoft Global Network
- Anycast-Routing