(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Analysetools für Microsoft Exchange Server – Ein Rückblick

 

Letztes Änderungsdatum des Themas: 2006-02-13

In diesem Artikel finden Sie einige Hintergrundinformationen zur Familie der Microsoft Exchange Server-Analysetools, der Entwicklung der Technologie und der Verwendung bis zum heutigen Zeitpunkt. Darüber hinaus wird Ihnen das Team vorgestellt, das hinter den Tools steht, und wir werden darüber reden, wohin die Reise bei der Weiterentwicklung dieser Tools gehen wird.

Bei Microsoft arbeiten wir hart daran, den Kundendienst und -support zu optimieren, indem wir so genannte KritSits, d. h. kritische Situationen, identifizieren, wenn eine Kunde dringend Unterstützung zur Behebung eines Problems benötigt, das die Bereitstellung von Diensten für Endbenutzer unterbricht und wichtige Unternehmensvorgänge behindert. Wenn eine KritSit eröffnet wird, arbeitet ein ganzes Team, bestehend aus Microsoft-Mitarbeitern aus den Bereichen Microsoft-Kundendienst und -support, Microsoft Services, unserer Consultingsparte, Kundenmanagement und Produktentwicklung, zusammen, um den Betrieb des Kunden so schnell wie möglich wiederherzustellen.

Gegen Ende 2003 fielen uns im Exchange Server-Team drei wichtige KritSit-Trends für Exchange Server auf:

  • Die Häufigkeit auftretender KritSits stieg an.
  • Mehr als 60 Prozent aller Exchange Server-KritSits wurden von Konfigurationsproblemen verursacht, nicht von Fehlern des Produkts.
  • In manchen KritSit-Fällen hatten nur wenige Monate zuvor bereits andere Kunden dasselbe KritSit-Problem erlebt.

Das frustrierende an dieser Situation war, zu sehen, wie eine einfache Änderung der Konfiguration zu so dramatischen Auswirkungen auf kritische Bereiche einer elektronischen Messagingumgebung führen konnte. Dass ähnliche KritSits bei mehreren Kunden auftraten, konnte die Stimmung nur noch verschlechtern. Wir brauchten dringend ein Tool, das Exchange-Server programmatisch analysierte und jedes Problem kennzeichnete, von dem bekannt war, dass es Leistung, Skalierbarkeit und Verfügbarkeit negativ beeinflusste.

Im Januar 2004 schickte ich eine E-Mail an Jon Avner, einen der führenden Entwickler im Exchange-Team, um ihm eine Idee für ein derartiges Tool zu unterbreiten. Zufälligerweise hatte Jon sich bereits gleichzeitig mit derselben Fragestellung beschäftigt, so dass schon nach nur wenigen Tagen die Spezifikation und Funktionalitätsbeschreibung des Tools per E-Mail geklärt war. Über ein Wochenende arbeitete Jon dann das aus, was die erste Version des Microsoft Exchange Server-Best Practices Analyzer Tools werden sollte – von uns auch gerne das ExBPA-Tool genannt.

Zu diesem Zeitpunkt verstanden wir noch nicht wirklich, wie groß die Bedeutung der Technologie war, die wir da gerade geschaffen hatten. Jon verfügte aufgrund seiner jahrelangen Entwicklungserfahrung über die Einsicht, ein allgemeines Framework zu erzeugen, das sich praktisch auf jedes Szenario, Exchange oder andere Produkte, anwenden ließ. Ich hatte mich mehrere Jahre mit dem Design und der Problembehandlung von großen Exchange-Topologien beschäftigt und brachte so das Hintergrundwissen und die Erfahrung ein, um sofort eine Liste von Tests zusammenstellen zu können, die das Tool durchführen können sollte.

Jons Tool war ausgezeichnet in der Lage, Daten aus vielen verschiedenen Namespaces zu sammeln: Active Directory-Verzeichnisdienst, Registrierung, Microsoft Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) und anderen. Wenn ein Kunde ein Problem hatte, forderte ein Kundendienst und -support-Techniker dessen Administrator auf, das Tool auszuführen. Im Anschluss daran analysierte der Supporttechniker die umfangreichen Informationen des Tools, um zu versuchen, die tatsächliche Ursache für das Problem des Kunden zu diagnostizieren.

Zwar sammelte das Tool eine große Menge ausgezeichneter Informationen, doch benötigten wir eine Möglichkeit, um diese automatisch zu segmentieren und zu analysieren. An diesem Punkt bezogen wir die Dienste von Jack Bennetto mit ein, einem Automationsspezialisten, der sich hervorragend mit XPath (XML Path Language) auskennt, einer umfangreichen Sprache, die zum Navigieren in der Hierarchie von XML-Dokumenten eingesetzt wird. Innerhalb weniger Wochen entwickelte Jack ein Analysemodul, das wir mit Jons Sammelmodul kombinierten. Mit Jacks neuem Modul waren wir in der Lage, eine Reihe von „Regeln“ aufzustellen, die auf Grundlage eines vorgegebenen Schwellenwerts eine Meldung generieren würden. Wenn der gesammelte Wert außerhalb des akzeptablen Bereichs lag, würde eine Regel aktiviert.

Alles lief prima, und wir entschieden uns, unser neues Tool über die interne Exchange-Topologie hier bei Microsoft laufen zu lassen. Das funktionierte leider nicht besonders gut. Der Durchlauf des Tools benötigte mehr als 24 Stunden. Das war viel zu lange. Schließlich sollte dieses Tool Kunden helfen, deren E-Mail vollständig zusammengebrochen war. Wir benötigten die Hilfe eines Spezialisten für Leistungsoptimierung, der wusste, wie das Tool beschleunigt werden konnte. Hier trat nun Kevin Chase auf den Plan, einer der besten Debugging-Spezialisten, den Sie bei Microsoft finden werden. Nachdem Kevin ein paar Änderungen vorgenommen hatte, dauerte die Datensammlung für unsere globale Exchange-Topologie nur noch zwei Stunden, wobei ein einzelner Server bereits in weniger als fünf Minuten überprüft werden konnte.

Das Tool funktionierte nun wirklich gut, doch seine Analysemöglichkeiten waren noch recht eingeschränkt. Somit benötigten wir einen umfassenderen Regelsatz, der auf die gesammelten Daten angewendet werden konnte. Glücklicherweise waren die Regeln für die Sammlung und Analyse von Daten in einer XML-Datei gespeichert, so dass wir diese ganz einfach aktualisieren konnten, ohne den Code neu kompilieren zu müssen.

Nachdem wir das Tool an mehreren Kundenstandorten getestet hatten, wurde schnell klar, dass E-Mail-Probleme nicht isoliert als alleine von der Exchange Server-Software verursacht zu betrachten waren. In vielen Fällen treten E-Mail-Probleme auf, weil die zugrunde liegende Infrastruktur, wie zum Beispiel das Betriebssystem oder das Namensauflösungsschema, nicht ordnungsgemäß funktionierte. Wir erweiterten also den Wirkungsbereich der Regeln auf solche Abhängigkeiten. Wir mussten uns gemäß einem ganzheitlichen Ansatz das gesamte Ökosystem ansehen, nicht nur Exchange und seine Komponenten, die unter Exchange ausgeführt werden, sondern auch Anwendungen, die aufgesetzt auf Exchange ausgeführt werden. An diesem Punkt kamen die unabhängigen Softwarehersteller (Independent Software Vendor, ISV) ins Spiel, die nun einen Regelsatz für ihre Software bereitstellen sollten.

Doch die ganze harte Arbeit und Zusammenarbeit zahlte sich aus. Anfang September 2004 wurde das Exchange Server Best Practices Analyzer Tool v1.0 als kostenloser Download veröffentlicht.

Ein wesentlicher Faktor für den Erfolg von Exchange Server Best Practices Analyzer war unsere Fähigkeit, schnell auf Kundenbedürfnisse und Produktaktualisierungen reagieren zu können. Jede Woche finden wir bessere Möglichkeiten, um ein Exchange-System zu betreiben. Die Best Practices-Regeln, die im Exchange Server Best Practices Analyzer codiert sind, stammen aus einer Vielzahl unterschiedlicher Quellen: unserem eigenen Entwicklungsteam, Microsoft-IT, Kundendienst und -support, Microsoft Services und Kunden. Der Zweck von Exchange Server Best Practices Analyzer besteht darin, all dieses Wissen in einer einzigen Anwendung zu vereinen und zu codieren. Heute führt das Tool weit über 1500 Konfigurationstests auf jedem Exchange-Server durch, der überprüft wird. Es verrät uns, ob ein Server Probleme mit der Bewältigung der Arbeitslast hat, ob Ihre Software, unabhängig davon, ob es Microsoft oder eine Drittherstellersoftware ist, veraltet ist, und ob es Best Practices gibt, die Sie implementieren sollten.

Wir aktualisieren die Regeldatenbank jeden Monat, so dass unsere Kunden wissen, dass sie die aktuellsten und zuverlässigsten Informationen erhalten, wie Exchange Server optimal bereitzustellen und auszuführen ist. Bis heute wurden 700000 Exemplare von Exchange Server Best Practices Analyzer heruntergeladen.

Eine der Designphilosophien, die von Anfang an hinter Exchange Server Best Practices Analyzer gestanden hat, ist die Bedienfreundlichkeit. Ein Administrator muss nicht viel über das Tool wissen, um es auszuführen. Exchange Server Best Practices Analyzer erkennt automatisch Exchange-Server, erkennt, wie diese Server eingesetzt werden, und findet heraus, welche Versionen von Exchange Server und Windows installiert sind.

Eine Analyse der KritSit-Fälle in der Folgezeit zeigte, dass Exchange Server Best Practices Analyzer signifikante Wirkungen zeigte: Die Anzahl von konfigurationsbedingten Problemen nahm zügig ab. Nun lagen die hauptsächlichen Probleme der Kunden in den Bereichen Leistung und Wiederherstellung nach Datenverlusten. Für diese Problematiken ließ sich Exchange Server Best Practices Analyzer aber nicht einsetzen. Ein gutes Problembehandlungstool, das in der Lage ist, die Grundursache eines Problems in kürzest möglicher Zeit herauszufinden, benötigt eine assistentenähnliche Benutzeroberfläche. Das Best Practices Analyzer-Modul ließ sich zu diesem Zweck nicht verwenden, da es nur startet, Daten sammelt und analysiert und wieder beendet, und dies alles mit einem Minimum an Benutzerinteraktion bzw. ganz ohne. Kurz gesagt, wir brauchten einen neuen Mechanismus, um Benutzereingaben anzufordern, die einen abweichenden Arbeitsablauf bei der Problembehandlung unterstützen würden. Zur Konstruktion dieses neuen Mechanismus stießen zwei neue Mitglieder zu unserem Team: Nicole Allen, eine Exchange-Problembehandlungsspezialistin, und Weiguo Zhang, der Leiter der Entwicklung in unserem Sustained Engineering-Team. Dieses Team erzeugt die Hot Fixes und Service Packs für das Produkt Exchange. Sie machten sich an die Konstruktion und Implementation eines endlichen Zustandsautomaten, einem Modul, das den Arbeitsablauf und die Verzweigungslogik unterstützt, die für ein interaktives Problembehandlungstool notwendig sind. Das endgültige Ergebnis war das „Assistentenmodul“ (Wizard Engine), das parallel arbeitet und in das Best Practices Analyzer-Modul integriert wurde.

Dank der harten Arbeit von Nicole, Weiguo und den anderen konnten wir im November 2005 zwei neue Mitglieder der Analysetoolfamilie für Exchange Server einführen:

  • Microsoft Exchange Server Performance Troubleshooting Analyzer Tool
  • Microsoft Exchange Server Disaster Recovery Analyzer Tool

Heute verfügen wir auf der Grundlage des Feedbacks unserer drei Analysetools über ein besseres Verständnis der gängigen Probleme, die in einer Exchange-Umgebung auftauchen. Unser höchstes Ziel ist es, Exchange Server gegenüber solchen Problemen zu stärken, so dass es eine Art Selbstschutzmechanismus entwickelt, der vor Dienstausfällen schützt. Wir haben damit begonnen, diese Erfahrungen in die nächste Version des Exchange Server-Produkts, Codename Exchange Server 2007, zu integrieren. Im Folgenden finden Sie ein paar Beispiele für die Themenbereiche, an denen wir arbeiten:

  • Automatisches Festlegen von kritischen Standardeinstellungen   Heutzutage müssen einige unserer Kunden ihre Server sofort abstimmen, sobald sie Exchange Server installieren. Viele der Parameter, die sie dabei abstimmen, sind uns bereits bekannt. Wäre es nicht großartig, wenn das Produkt diese Änderungen bereits bei der Installation automatisch vornehmen würde?
  • Implementieren eines Bereichs für Außerkraftsetzungen   Zwar mögen manuelle Außerkraftsetzungen, die normalerweise in der Registrierung stattfinden, noch für einige Komponenten von Exchange notwendig sein, doch sollte der Benutzer nicht in der Lage sein, einen unsinnigen Wert einzugeben. Das Produkt sollte sich selbst schützen, selbst wenn es außer Kraft gesetzt wurde.
    noteAnmerkung:
    Ein solches Szenario ist gängiger, als Sie vielleicht denken. Zahlreiche Knowledge Base-Artikel zu Microsoft handeln zum Beispiel davon, wie die Registrierung bearbeitet wird, und geben Empfehlungen, die normalerweise in Dezimalwerten angegeben werden. Im Registrierungs-Editor ist jedoch der Standardeingabetyp für Daten „hexadezimal“. Es ist also nur zu einfach, einen Wert einzugeben, der fehlinterpretiert werden kann. So kann beispielsweise die Eingabe des Werts 31000 unwissentlich zu einem tatsächlichen Wert von 200704 führen.

Exchange Server 2007 wird robuster als frühere Versionen von Exchange Server sein. Teilweise dank der hier von mir beschriebenen Arbeit, doch auch in Zukunft werden Analysetools für Exchange Server ihre Daseinsberechtigung nicht verlieren. Aus diesem Grunde sind diese Tools Bestandteil des regulären Softwarepakets für Exchange Server 2007. Das ursprüngliche Team besteht immer noch mit Jon, Jack, Kevin, Nicole, Weiguo und mir, die wir unsere meiste Zeit damit verbringen, neue Wege zu erforschen und zu implementieren, um Exchange Server zum besten Messagingprodukt zu machen, das auf dem Markt erhältlich ist.

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.