End2End EWS

Auf der Seite End2End-MSXLatenz beschreibe ich, wie man per WMI von Exchange Daten der Client ermitteln kann. Das ist mit Exchange 2007 und höher so nicht mehr per WMI möglich. Allerdings gibt es durchaus andere Logs, die man auswerten könnte.. Diese Seite beschäftigt sich aber mit einem Skript, welche simmer wieder den Posteingang liest und damit sowohl die Erreichbarkeit des Service als auch eine Geschwindigkeit des Service überprüfen kann.

Dieses Skript nutzt EWS, um sich mit einem Postfach zu verbinden und immer wieder eine Mail zu lesen. (Ohne Cached-Mode). Es misst den Zeitbedarf dafür und meldet größere Abweichungen von Mittelwert. Auch hier ist es problemlos möglich, quasi im Sekundentakt die Mail zu lesen und Probleme sehr schnell zu erkennen und diese im Eventlog zu melden. Damit hat eine nachgeschaltete Überwachungssoftware dann in der Regel keine Probleme mehr einen Alarm auszulösen.

Warum ein eigenes Skript?

Microsoft hat mit "Test-Outlook" und "Test-WebService" vergleichbares per PowerShell. Diese Commandlets laufen aber nur auf Exchange Server und nicht von einem beliebigen PC. Zudem brauchen diese Zugriffe ziemlich lange, da Sie den kompletten Verbindungsaufbau durchführen. Mein Skript hingegen baut einmal die Verbindung auf und liest dann immer und immer wieder schnell die erste Mail aus dem Posteingang und kann damit eine lückenlose schnelle Überwachung und Performance-Messung auch aus der Ferne über ein LAN, WAN, WLAN gewährleisten. Und es kann auch "echtes Postfach" überwachen und nicht nur die Systemmailbox.

Allerdings sollten Sie auch im Hinterkopf behalten, dass so ein häufiges lesen nicht "zu oft" passieren darf. Exchange wehrt sich schon bei übermäßiger Beanspruchung (Thema Budget und Throttling). Einen DoS sollten Sie damit besser nicht versuchen. Die so oft gelesenen Daten werden aber von Exchange natürlich bevorzugt im Cache gehalten.

Funktionsweise

Der Code baut im wesentlichen auf der Funktion von Test-EWS auf. Meinem kleinen Tool und Mustervorlage zum Überprüfen von EWS und Sicht dann immer nach der ersten Mail im Postfach. So wird jedes mal eine EWS-Anfrage ausgelöst.

Genau genommen sind es zwei Aktionen, das aus mir nicht ganz verständlichen Gründen immer erst eine anonyme Anfrage gestellt wird, auf die die EWS.DLL dann authentifiziert das zweite Mal fragt. Der Request zeigt schön die Aktion:

Sie sehen hier aber auch, dass zur Anmeldung "Basic Auth" zum Einsatz kommt. Ich war zu dem Zeitpunkt "extern" und EWS nutzt wohl noch nicht ADFS. Interessant finde ich hier auch den Eintrag "ResponseTime", zu dem ich keine weiteren Informationen habe. Es könnte sein, dass EWS hier an den Server mit dem Post die Latenzzeit des vorherigen Aufrufs übersendet. Das Kernprogramm sieht wie folgt aus:

Die Variable "$inbox" wird vorher schon instanziert, so dass ich hier dann einfach jede Sekunde eine Messung macht und die Daten nach 10 Messungen an eine CSV-Datei anhänge. Die enthält dann folgende Daten:

"beserver","timestamp","durationmin","durationmax","durationavg"
"VI1PR0402MB3646","06.03.2018 13:32:25","386,5109","452,201","412,8508"
"VI1PR0402MB3646","06.03.2018 13:32:35","369,1626","448,7712","416,47995"
"VI1PR0402MB3646","06.03.2018 13:32:46","387,8168","1052,8737","565,58746"
"VI1PR0402MB3646","06.03.2018 13:32:56","403,5637","458,0882","427,45375"
"VI1PR0402MB3646","06.03.2018 13:33:06","361,0322","476,3444","427,47761"
"VI1PR0402MB3646","06.03.2018 13:33:16","398,3042","538,8762","465,66"

Ca. alle 10 Sekunden wird eine Zeile angehängt, die neben dem Backend Server auch die Dauer des Abrufs (min/max/avg) protokolliert wird. Die Werte lassen sich dann gut in Power Bi

Sie sehen hier einen deutliche Verschlechterung der durchschnittlichen aber und der maximalen Antwortzeit. Letztlich war dies durch einen Netzwerkwechsel verursacht, bei dem der gleichen Client einen anderen Provider verwendet hat. Das Zeit natürlich auch ein Problem. Wenn der Client dies nicht durch eine Netzwerkunterbrechung mitbekommen hat, dann gibt es auch keinen Grund eine neue DNS-Anfrage zu starten. Der in dieser Zeit angesprochenen Office 365 Zugänge waren also nicht optimal. 1000ms Latenzzeit ist nicht gut. Die anderen Werte zeigen aber eine durchschnittliche zügige Verbindung, bei denen es manchmal aber zumindest eine Transaktion gibt, die deutlich länger braucht.

Analyse HTTPHeader

Wenn Sie sich die HTTP-Request Header anschauen, dann fällt mir noch was auf:

Die Daten bekommen Sie auch per Powershell bei einer anonymen Anfrage gegen outlook.office365.com

$result.Service.HttpResponseHeaders

Key                  Value
---                  -----
Transfer-Encoding    chunked
Content-Encoding     gzip
Vary                 Accept-Encoding
request-id           1c8b3ec4-6cf2-4fa8-ac8d-490ed3eb1e4a
X-CalculatedFETarget VI1P195CU001.internal.outlook.com
X-BackEndHttpStatus  200,200
X-FEProxyInfo        VI1P195CA0007.EURP195.PROD.OUTLOOK.COM
X-CalculatedBETarget VI1PR0402MB3646.eurprd04.prod.outlook.com
x-EwsHandler         FindItem
X-DiagInfo           VI1PR0402MB3646
X-BEServer           VI1PR0402MB3646
X-FEServer           VI1P195CA0007,AM3PR04CA0146
Cache-Control        private
Content-Type         text/xml; charset=utf-8
Date                 Sat, 10 Mar 2018 11:32:15 GMT
Set-Cookie           exchangecookie=0491d47b6b6a45beaa330f3ce618b930; path=/
Server               Microsoft-IIS/10.0
X-AspNet-Version     4.0.30319
X-Powered-By         ASP.NET

Bei Office 365 gibt es eventuell zwei kaskadierte FE-Server. Anscheinend werden meine Anfrage erst durch einen Zugangs-Frontend geroutet, der diese dann über einen weiteren Frontend zum Backend zustellt. Aber das ist dann wieder ein anderes Kapitel.

Beispiel mit Office 365

Beim Zugriff auf Office 365 zeigt sich, wie Microsoft die Last der Clientzugriffe verteilt. ein EWS-Client landet bei einem "naheliegenden" Frontend, der dann aber nicht direkt zu dem Backend geht, der die aktive Datenbank für das Postfach hält. dann müssten ja alle Frontends weltweit den aktuellen Status aller Postfächer und Datenbanken kennen. Anscheinend wertet der erster Frontend nur aus, in welchem Datacenter das Postfach ist um den Zugriff als Proxy dorthin zu senden. Interessanterweise ist der erste Frontend mit jedem Request ein anderer Server und erst der zweite Frontend ist dann immer der gleiche, der die Daten dann zum immer gleichen Backend weiter gibt.

PS C:\End2End> .\end2end-ews.ps1
End2End-EWS: Start
 Loading EWS DLL
 Username:
 Domain  :
 Password: <not visible>
 UseDefaultCredentials: False
End2End-EWS:Checking Autodiscover for Mailbox
End2End-EWS:Connecting to Inbox for SMTP user1@uclabor.de
 Number of Unread Messages :  7118
End2End-EWS: Start Monitoring Loop
End2End-EWS (1):FE1:AM6P194CA0061   FE2:VI1PR0701CA0069   BE:VI1PR04MB5024   RTT(ms)156
End2End-EWS (2):FE1:AM6P194CA0061   FE2:VI1PR07CA0178     BE:VI1PR04MB5024   RTT(ms)152
End2End-EWS (3):FE1:AM6P194CA0061   FE2:VI1PR0701CA0069   BE:VI1PR04MB5024   RTT(ms)172
End2End-EWS (4):FE1:AM6P194CA0061   FE2:VI1PR07CA0156     BE:VI1PR04MB5024   RTT(ms)137
End2End-EWS (5):FE1:AM6P194CA0061   FE2:VI1PR0701CA0069   BE:VI1PR04MB5024   RTT(ms)134
End2End-EWS (6):FE1:AM6P194CA0061   FE2:VI1P195CA0096     BE:VI1PR04MB5024   RTT(ms)140
End2End-EWS (7):FE1:AM6P194CA0061   FE2:VI1P195CA0071     BE:VI1PR04MB5024   RTT(ms)129
End2End-EWS (8):FE1:AM6P194CA0061   FE2:VI1PR07CA0174     BE:VI1PR04MB5024   RTT(ms)131
End2End-EWS (9):FE1:AM6P194CA0061   FE2:VI1PR0701CA0069   BE:VI1PR04MB5024   RTT(ms)157

Wenn ich aber schon im richtigen DataCenter bin, dann ist der FE1 leer.

Hier sehen Sie auch die normale Antwortzeit meiner Requests. Per Default werden die letzten 10 Messwerte zusammen gefasst und als Min/MAX/Avg-Werte in eine CSV-Datei archiviert.

PRTG Integration

Wenn eine PRTGPushURL mit angegeben ist, dann sendet das Skript die Daten auch noch an einen PRTG-Probe zur Speicherung als Sensordaten.

Über mehrere Stunden sind die Daten schon interessant:

Noch deutlicher sind die Anfragen über mehrere Tage hinweg.

Download

 

Das Skript ist aktuell noch kein öffentlicher Download. Es wird von mir und Net at Work Consultants bei Kunden eingesetzt und muss erst noch ein paar Monate seine Dauertauglichkeit beweisen. Aktuell gibt es noch immer Sonderfälle, die die Messung verfälschen und noch nicht gelöst sind.

Weiterentwicklung

Für die Performance-Überwachung bezüglich der Netzwerkverbindung gibt es hier wohl kaum noch Potential für weitere Änderungen. Denkbar wäre aber z.B. auch die Auswertung der Backend-Server und wann und wie sich diese Wechseln. So könnten Sie vielleicht einen Eindruck gewinnen, wie Microsoft intern seine Server umbaut oder ihr Postfach umzieht.

Aktuell prüft das Skript auch genau einen Posteinfang. Mit EWS-Impersonation könnte man mehrere Postfächer abfragen und damit eben der Performance auch einen Erreichbarkeitscheck umsetzen. Allerdings wird man so nicht alle Postfächer eines Unternehmens überwachen wollen. Irgendwann wird auch Office 365 den Client per Throttling ausbremsen und die Daten werden schlechter.

Weitere Links