Ein Skript zum Beheben von Problemen mit Exchange ActiveSync

Veröffentlichung des Originalartikels: 01.02.2012

• ActiveSyncReport-Skript
• Herunterladen

Das Exchange-Supportteam erhält relativ häufig Anfragen zu Fällen, bei denen mit dem Exchange ActiveSync-Protokoll (EAS) arbeitende mobile Geräte zu viele Anforderungen an den Exchange-Server senden, was dazu führt, dass die Serverressourcen zur Neige gehen, und im Prinzip einem Denial-of-Service-Angriff (DOS) entspricht. Im schlimmsten Fall steht dann der Server auch nicht mehr anderen Benutzern zur Verfügung, die zum Herstellen der Verbindung möglicherweise nicht EAS verwenden. Wir haben dieses Problem und mögliche Abhilfemaßnahmen im folgenden Knowledge Base-Artikel dokumentiert:

2469722 Herstellen einer Verbindung über Exchange ActiveSync aufgrund fehlender Exchange-Ressourcen nicht möglich

Jüngstes Beispiel dieses Problems waren Apple iOS 4.0-Geräte, die alle 30 Sekunden eine vollständige Synchronisierung versuchten (siehe TS3398). Ein weiteres Beispiel können Geräte sein, die die Antwort "Postfach voll" vom Exchange-Server nicht ordnungsgemäß verarbeiten, was zu mehreren Neuverbindungsversuchen führt. Dies kann auf solchen Geräten dafür sorgen, dass mehr als 60 Mal in einer Minute versucht wird, sich mit dem Postfach zu verbinden und zu synchronisieren, was Akkus in die Knie zwingt und Leistungsprobleme auf dem Server verursacht.

Das Verwalten mobiler Geräte und Ausbalancieren verfügbarer Serverressourcen bei verschiedenen Clienttypen kann eine knifflige Aufgabe für IT-Administratoren sein. Herauszufinden, welche Geräte für Probleme durch einen Ressourcenrückgang auf einem Exchange 2010/2007-Clientzugriffsserver oder Exchange 2003-Front-End-Server verantwortlich sind, ist kein einfacher Job. Wie im zuvor genannten Artikel erwähnt, können Sie mit Log Parser nützliche Statistiken aus Protokollen von Internetinformationsdienste (IIS) extrahieren (siehe den folgenden Hinweis) , doch die meisten Administratoren haben weder die Zeit noch das Wissen zum Entwerfen von Abfragen zum Extrahieren von Informationen aus solch langen Protokollen.

Zweck dieses Beitrags ist es, der Exchange-Community ein neues PowerShell-Skript vorzustellen, mit dem Geräte bestimmt werden können, die das Problem des Ressourcenschwunds verursachen, das beim Ausmachen von Leistungstrends hilft und für eine fortlaufende Überwachung automatisch Berichte generiert. Das Skript ermöglicht Ihnen einfache und schnelle Detailuntersuchungen der EAS-Aktivitäten Ihrer Benutzer, was eine gewaltige Aufgabe sein kann, wenn man es mit IIS-Protokollen zu tun hat, die mehrere Gigabyte groß sein können. Das Skript vereinfacht auch das Bestimmen von Benutzern mit mehreren EAS-Geräten. Sie können mithilfe des Skripts in Zeiträumen mit normaler EAS-Aktivität einen Basiswert ermitteln und diesen anschließend zu Vergleichs- und Berichtszwecken heranziehen, wenn sich die Dinge nicht wie gewünscht entwickeln. Ferner bietet das Skript eine Autoüberwachungsfunktion, über die Sie E-Mail-Benachrichtigungen empfangen können.

Hinweis: Das Skript funktioniert mit IIS-Protokollen für Server mit Exchange 2010, Exchange 2007 und Exchange 2003.
Die gesamte Kommunikation zwischen mobilen Geräten mithilfe des EAS-Protokolls und Microsoft Exchange wird in IIS-Protokollen auf Servern mit den Rollen Clientzugriffsserver/und Front-End-Server im W3C-Format aufgezeichnet. Die für die Protokollierung aktivierten W3C-Standardfelder sind bei IIS 6.0 und 7.0/7.5 unterschiedlich (IIS 7.0 hat dieselben Felder wie IIS 7.5). Dieses Skript funktioniert mit beiden Versionen.

IIS-Protokolle

Da EAS mit HTTP arbeitet, werden alle EAS-Anforderungen in IIS-Protokollen aufgezeichnet, was standardmäßig aktiviert ist. Mitunter deaktivieren Administratoren die IIS-Protokollierung, um Speicherplatz auf Servern zu sparen. Über die folgenden Schritte können Sie prüfen, ob die Protokollierung aktiviert ist, und den Speicherort der Protokolldateien finden:

IIS 7

1. Erweitern Sie in IIS-Manager den Servernamen, z. B. ExchangeServer (Contoso\Administrator)
2. Doppelklicken Sie in der Ansicht Features im Abschnitt IIS auf Protokollierung.

IIS 6

1. Klicken Sie in IIS-Manager mit der rechten Maustaste auf den Namen der Website (die zumeist Standardwebsite heißt), und wählen Sie Eigenschaften aus.
2. Klicken Sie auf die Registerkarte Website.

Wofür sind mobile Geräte bei der Kommunikation mit dem Server zuständig?

Bevor wir uns die Einzelheiten des Skripts ansehen, lassen Sie uns einige wichtige Anforderungen an mobile Geräte überprüfen, die EAS für die Kommunikation mit Microsoft Exchange verwenden.

• Wenn das mobile Gerät eine unerwartete Antwort vom Server erhält, ist es die Aufgabe des Geräts, die Antwort zu verarbeiten und in angemessenen Abständen eine Wiederholung auszuführen. Darüber hinaus sind Geräte zuständig für die Verarbeitung von Timeouts, die außerhalb von IIS auftreten und durch Netzwerkwartezeiten verursacht werden können.
• Mit jeder Anforderung, die ein Gerät an IIS/Exchange sendet, muss es auch den Benutzer-Agent melden.

Was wird bei Verwenden dieses Skripts angezeigt?

Das Skript nutzt Microsoft Log Parser 2.2 zum Analysieren von IIS-Protokollen und Generieren von Ergebnissen. Es erstellt verschiedene SQL-Abfragen für Log Parser basierend auf den verwendeten Parametern (siehe die nachfolgende Tabelle). Es gibt einen früheren Blogbeitrag Exchange 2003 - Active Sync reporting zu Log Parser, in dem ähnliche Punkte angesprochen werden. Die Informationen in diesem Beitrag gelten auch für Exchange 2010 und 2007. Seit diesem Blogbeitrag wurden dem EAS-Protokoll weitere Befehle hinzugefügt, die auch von diesem neuen Skript beim Verarbeiten der Protokolle verwendet werden.

Hier ist eine Liste der EAS-Befehle, die das Skript in den Ergebnissen zurückgibt:

Sync, SendMail, SmartForward, SmartReply, GetAttachment, GetHierarchy, CreateCollection, DeleteCollection, MoveCollection, FolderSync, FolderCreate, FolderDelete, FolderUpdate, MoveItems, GetItemEstimate, MeetingResponse, Search, Settings, Ping, ItemOperations, Provision, ResolveRecipients, ValidateCert

Weitere Einzelheiten zu den einzelnen EAS-Befehlen finden Sie auf der MSDN-Website unter ActiveSync HTTP Protocol Specification.

Zusätzlich zu diesen Befehlen werden die folgenden Parameter ebenfalls vom Skript protokolliert.

1. Benutzer

2. Benutzername

3. Gerätetyp

4. Geräte-ID

5. Benutzer-Agent

6. sc-bytes: Nur verfügbar, wenn Sie dieses Tag in der IIS-Protokollierung aktiviert haben.

7. cs-bytes: Nur verfügbar, wenn Sie dieses Tag in der IIS-Protokollierung aktiviert haben.

8. time-taken (in Millisekunden): Nur verfügbar, wenn Sie dieses Tag in der IIS-Protokollierung aktiviert haben.

9. Gesamtanzahl der Anforderungen von der Geräte-ID

10. Gesamtanzahl aller 4xx-Statuscodes

11. Gesamtanzahl aller 5xx-Statuscodes (weitere Informationen finden Sie im KB-Artikel 318380 für IIS 6.0 und KB-Artikel 943891)

12. Statuscode 409 (Konflikt): Am Anforderungs-URI kann eine Auflistung erst dann erfolgen, nachdem eine oder mehrere Zwischenauflistungen erstellt wurden. Der Server darf diese Zwischenauflistungen nicht automatisch erstellen. (Referenz: [RFC 4918](https://tools.ietf.org/html/rfc4918#section-9.8.5 "Abschnitt 9.8.5 (Statuscodes) in 'RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)'

    "))

13. Statuscode 500: Nachdem das Gerät den Befehl OPTIONS gesendet hat, kann es möglicherweise vom Server eine Antwort vom Typ 500 mit dem Fehler "MissingCscCacheEntry" erhalten. Dies kann aufgrund eines Problems mit der Affinität erfolgen, wenn ein dem Internet zugewandtes Clientzugriffsserver-Array als Anforderung als Proxy an ein internes Clientzugriffsserver-Array weiterleitet. Wenn das dem Internet zugewandte Clientzugriffsserver-Array die Anforderung an das interne Array sendet, antwortet der Clientzugriffsserver mit dem ersten 401-Code. Bei der nächsten Kommunikation wird die Anforderung von einem anderen Clientzugriffsserver im internen Array verarbeitet. Die Behebung des Affinitätsproblems mit dem internen Clientzugriffsserver-Array ist die Lösung.

14. Statuscode 503: Der Server kann die Anforderung aufgrund einer temporären Überbelastung oder einer Wartung des Servers derzeit nicht verarbeiten. Die Annahme ist, dass diese Bedingung vorübergehend vorliegt und nach einer kurzen Verzögerung nicht mehr auftritt. Falls bekannt, wird die Länge der Verzögerung ggf. in einem Retry-After-Header angegeben. Sind keine Retry-After-Informationen vorhanden, muss der Client die Antwort wie eine Antwort vom Typ 500 verarbeiten.
    https:// Hinweis: Das Vorhandensein des Statuscodes 503 impliziert nicht, dass der Server diesen bei einer Überlastung verwenden muss. Einige Server verweigern ggf. einfach den Verbindungsaufbau. (Referenz: RFC 2616) https://

15. Statuscode 507 (zu wenig Speicherplatz): Dieser Statuscode bedeutet, dass die Methode nicht auf die Ressource angewendet werden konnte, da der Server nicht in der Lage ist, die für die Erfüllung der Anforderung erforderliche Darstellung zu speichern. Diese Bedingung liegt zumeist vorübergehend vor. Wenn die Anforderung, die diesen Statuscode erhalten hat, das Ergebnis einer Benutzeraktion war, darf die Anforderung erst wiederholt werden, nachdem sie im Rahmen einer gesonderten Benutzeraktion angefordert wurde. (Referenz: [RFC 4918](https://tools.ietf.org/html/rfc4918#section-11.5 "Abbschnitt 11.5 (507 Insufficient Storage) in 'RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)'

    "))

16. Statuscode 451: Exchange 2007/2010 gibt eine HTTP-Antwort vom Typ 451 an einen EAS-Client zurück, wenn festgestellt wird, dass das Gerät einen "besseren" Clientzugriffsserver für die Verbindung mit EAS verwenden sollte. Die Logik zum Bestimmen des "besseren" Clientzugriffsservers basiert auf Active Directory-Standorten und darauf, ob ein Clientzugriffsserver als dem Internet zugewandt gilt. Wenn die ExternalUrl-Eigenschaft für das virtuelle Microsoft-Server-ActiveSync-Verzeichnis angegeben ist, gilt dieser Clientzugriffsserver für die EAS-Verbindung als dem Internet zugewandt. ( Referenz: TechNet-Artikel Exchange ActiveSync hat den Fehler "HTTP 451" zurückgegeben und Grundlegendes zu Proxyfunktion und Umleitung)

17. Fehler "TooManyJobsQueued": Weitere Informationen zu "TooManyJobsQueued" finden Sie im zuvor erwählten KB-Artikel: 2469722

18. Budgetüberschreitung: Ein Budget ist der Grad des Zugriffs, den ein Benutzer oder eine Anwendung für eine bestimmte Einstellung hat. Ein Budget gibt an, wie viele Verbindungen einem Benutzer zur Verfügung stehen oder wie viele Aktivitäten ein Benutzer pro einminütigem Zeitraum ausführen darf. (Referenz: TechNet- Artikel)

19. Es folgt eine Untergruppe der allgemeinen Statuscodes:

    InvalidContent, ServerError, ServerErrorRetryLater, MailboxQuotaExceeded, DeviceIsBlockedForThisUser, AccessDenied, SyncStateNotFound, DeviceNotFullyProvisionable, DeviceNotProvisioned, ItemNotFound, UserDisabledForSync

Welche Aufgaben können Sie mit diesem Skript ausführen?

Sie können Protokolle mit diesem Skript auswerten, um die folgenden Details abzurufen:

1. Zugriffe nach Benutzer/Geräte-ID (Benutzer/Geräte mit der maximalen Anzahl von an den Server gesendeten Anforderungen)
2. Zugriffe pro Stunde/Tag (dient zum Bestimmen der Häufigkeit gesendeter Anforderungen nach Benutzer/Gerät, der Zeitwert wird in Sekunden eingegeben)
3. Zugriffe nach Gerät mit angegebenem Schwellenwert (hier können Sie einen Grenzwert für Zugriffe/Anforderungen angeben, z. B. alle Benutzer die 1000 Anforderungen pro Stunde/Tag usw. senden)
4. CSV-Export der Ergebnisse
5. HTML-Bericht der Ergebnisse
6. E-Mail-Berichte für die Überwachung (CSV-/HTML-Format)

Voraussetzungen:

Um dieses Skript verwenden zu können, muss Folgendes auf Ihrem Computer installiert sein:

• Log Parser 2.2.
• Windows PowerShell 2.0 (ist unter Windows 7 und Windows 2008 R2 standardmäßig installiert)

Skriptparameter

Wie wird das Skript verwendet?

Es folgen einige Beispiele (mit Befehlen) dazu, wie Sie das Skript verwenden können und warum Sie diese befolgen sollten.

Mehr als 1000 Zugriffe

Mit dem folgenden Befehl werden alle IIS-Protokolle im Ordner W3SVC1 analysiert und nur die Benutzer und Geräte gemeldet, die mehr als 1000 Zugriffe aufweisen.

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000

[In diesem Befehl befindet sich das Skript ActiveSyncReport.ps1 am Stamm von Laufwerk C. Der Parameter -IISLog gibt den Standardspeicherort der IIS-Protokolle an. Der Parameter -LogparserExec verweist auf den Speicherort der ausführbaren Anwendungsdatei von Log Parser. Der Parameter -ActiveSyncOutputFolder gibt den Speicherort an, an dem die Ausgabe- oder Ergebnisdatei gespeichert werden soll. MinimumHits mit dem Wert 1000 ist der in der obigen Tabelle erklärte Skriptparameter.]

Ausgabe:

Ein Gerät, das über 1000 Anforderungen pro Tag sendet, gilt als stark genutzt. Wenn die Zugriffe (Anforderungen) 1500 überschreiten, kann ein Problem mit dem Gerät oder der Umgebung vorliegen. In diesem Fall müssen die Aktivität des Geräts und seines Benutzers eingehender untersucht werden.

Bei einem Fall aus der Praxis haben wird festgestellt, dass mehrere Benutzer sehr häufig über EAS auf ihren Exchange-Server zugriffen (+25000 Zugriffe, 1000 Zugriff pro Stunde), was für einen starken Rückgang der Ressourcen auf dem Server sorgte. Bei eingehender Untersuchung stellten wir fest, dass alle Anforderungen dieser Benutzer in einem Fehler vom Typ 507 auf Postfachservern im Back-End resultierten. Im Gespräch mit diesen EAS-Benutzern ergab sich, dass sie in diesem Zeitraum das Größenlimit ihrer Postfächer (25 MB) erreicht hatten und versuchten, E-Mail aus verschiedenen Ordnern zu löschen, um den Grenzwert wieder zu unterschreiten. In diesen Fällen wird auch gegebenenfalls eine HTTP-Antwort vom Typ 503 (TooManyJobsQueued) in den IIS-Protokollen für EAS-Anforderungen angezeigt. Siehe dazu auch den KB-Artikel: 2469722

Isolieren einer bestimmten Geräte-ID

Mit dem folgenden Befehl werden alle IIS-Protokolle im Ordner C:\IISLogs analysiert, wobei nach der Geräte-ID xxxxxx gesucht wird, deren stündliche Statistik angezeigt wird.

.\ActiveSyncReport.ps1 -IISLog " C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports –DeviceID xxxxxx -Hourly

Ausgabe:

Anhand dieser Informationen können Sie einen Benutzer/ein Gerät auswählen und stündliche Trends ausmachen. Dies kann Ihnen helfen zu bestimmt, ob es sich um eine Benutzer- oder programmgesteuerte Aktion handelt.

Als praktisches Beispiel mussten wir in einem Fall herausfinden, welche Geräte Kalenderelemente änderten. Hierzu untersuchten wir die Benutzer-/Geräteaktivität und sortierten diese anhand von Befehlen, die an den Server gesendet wurden. Danach konzentrierten wir uns darauf, welche Benutzer/Geräte den MeetingResponse-Befehl sendeten sowie auf dessen Häufigkeit, Zeitraum und andere dazugehörige Details. Dadurch konnten wir das Problem auf die entsprechenden Benutzer und ihre kalenderbezogenen Aktivitäten eingrenzen, um dieses Kalenderproblem besser in den Griff zu bekommen.

Ein weiterer zu untersuchender gerätebezogener Befehl und Fehler ist der Befehl Options. Wenn dieser für ein Gerät nicht funktioniert, wird der HTTP-Fehlercode 409 im IIS-Protokoll zurückgegeben.

Isolieren eines einzelnen Tages

Mit dem folgenden Befehl werden nur die Dateien analysiert, die im Ordner W3SVC1 als Datum den 24.12.2011 haben, und nur die Zugriffe gemeldet, deren Anzahl 1000 übersteigt.

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 –Date 12-24-2011

Ausgabe:

Anhand dieser Informationen können Sie die Benutzer bestimmen, die sehr viele Anforderungen senden. Innerhalb der Spalten können Sie außerdem die Typen von Befehlen erkennen, die diese Benutzer senden. Dadurch können zielgerichtete und effiziente Problembehandlungsmethoden entwickelt werden.

Wonach Sie suchen sollten

Beim Analysieren von IIS-Protokollen mithilfe des Skripts sollten Sie nach einem bestimmten Befehl suchen, der immer wieder gesendet wird. Die Häufigkeit, mit der bestimmte Befehle gesendet werden, ist wichtig. Auch Befehle, die häufig nicht erfolgreich sein, sind sehr wichtig und sollten eingehender untersucht werden. Außerdem sollten Sie die Wartezeiten zwischen der Ausführung bestimmter Befehle untersuchen und vergleichen. Allgemein sind Befehle, deren Ausführung längere Zeit dauert oder die zu verzögerten Antworten vom Server führen, verdächtig und sollten weiter untersucht werden. Eine Ausnahme stellt allerdings der PING-Befehl dar, dessen Ausführung länger dauert und den Sie häufig im Protokoll finden werden, was aber zu erwarten war.

Wenn ein Gerät kontinuierlich mit Fehlercode 403 keine Verbindung herstellen kann, ist das Gerät möglicherweise nicht für den Zugriff über EAS aktiviert. Mitunter beschweren sich Benutzer mobiler Geräte über Verbindungsprobleme, ohne zu merken, dass sie ihre Anmeldeinformationen nicht richtig eingeben (was auf mobilen Geräten durchaus vorkommen kann). Wenn Sie Protokolle durchforsten, können Sie sich auf diese Benutzer konzentrieren und werden gegebenenfalls feststellen, dass das Gerät des Benutzers nach Aufrufen des Befehls Provision einen Fehler aufweist.

Erstellen von Berichten für die Überwachung

Sie können einen Bericht erstellen oder eine E-Mail mit solchen Berichten und Details der Benutzeraktivität generieren.

Mit dem folgenden Befehl werden alle IIS-Protokolle im Ordner W3SVC1 analysiert und nur die Zugriffe gemeldet, deren Anzahl 1000 überschreitet. Außerdem wird ein HTML-Bericht der Ergebnisse erstellt.

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 -HTMLReport

Mit dem folgenden Befehl werden alle Dateien in den Ordnern C:\Server1_Logs und D:\Server2_Logs analysiert und eine E-Mail mit dem generierten Bericht an "user@contoso.com" gesendet.

.\ActiveSyncReport.ps1 -IISLog "C:\Server1_Logs",”D:\Server2_Logs” -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -SendEmailReport -SMTPRecipient user@contoso.com –SMTPSender user2@contoso.com -SMTPServer mail.contoso.com

Wir hoffen, dass dieses Skript für Sie nützlich ist. Lassen Sie uns wissen, wie es Ihnen die Arbeit erleichtert und was wir sonst noch in dieser Richtung für Sie tun können.

Konstantin Papadakis und Brian Drepaul

Beshttps:// Dank an:
M. Amir Haque, Will Duff, Steve Swift, Angelique Conde, Kary Wall, Chris Lineback und Mike Lagase

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter A script to troubleshoot issues with Exchange ActiveSync