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

Sie möchten wissen, wie gut ihr Netzwerk für die veränderten Anforderungen aufgestellt ist?
Mit einem Netzwerk Assessment erarbeiten Sie einen individuellen Maßnahmenplan
https://www.rimscout.com/de/netzwerk-assessment/

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 On-Premises 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