Eigentlich konnte man schon direkt nach dem Erscheinen von Exchange 2003 seine E-Mails mit seinem mobilen Endgerät nicht nur beim Exchange Server abholen (Pull), sondern sich diese auch zustellen lassen (Push). Das ursprüngliche Verfahren von Microsoft (Always Up To Date oder AUTD) basierte jedoch auf SMS-Benachrichtigungen und war je nach Mobilfunkprovider überhaupt nicht nutzbar oder mit recht hohen Kosten verbunden. Mit dem Service Pack 2 hat Microsoft also ein komplett neues Verfahren geschaffen, um nun im zweiten Anlauf Push Mail mit Exchange ohne zusätzliche Software oder besondere Service-Infrastrukturen zu ermöglichen. Dieses Verfahren läuft nun unter dem Begriff Exchange Direct Push und ist Inhalt dieses Artikels.
Nutzbare Endgeräte
Nutzbar ist Direct Push zunächst nur mit Endgeräten, die mit Windows Mobile 5.0 und dem Messaging and Security Feature Pack (MSFP) ausgestattet sind. Beim Erscheinen dieses Artikels sollten solche Geräte bei den Mobilfunkprovidern verfügbar sein, und in den meisten Fällen ist auch ein entsprechendes Update für die Geräte geplant, auf denen Windows Mobile ohne MSFP läuft. Direct Push lässt sich sowohl mit PDAs als auch mit SmartPhones nutzen, die unter dem Microsoft-Betriebssystem laufen. Für einige andere Geräte, wie zum Beispiel denen von Palm oder dem Nokia Communicator, gibt es von der Firma Dataviz die Software RoadSync, die es ermöglicht, diese Geräte ebenfalls mit dem Exchange Direct Push zu nutzen.
Konfiguration der Endgeräte
Auf dem Endgerät selber gibt es nur wenig zu konfigurieren, das von der bekannten Konfiguration für ActiveSync abweicht. Ein Gerät, das Direct Push nutzen kann, verhandelt das Protokoll automatisch mit dem Server. Dafür muss man im Zeitplan für die Synchronisation die Option Bei Elementeingang auswählen.
Konfiguration auf dem Server
Direct Push wird unter den Globalen Einstellungen (Global Settings) des Exchange-Servers im Exchange System Manager konfiguriert. Sie müssen sich dazu die Eigenschaften des Objekts Mobile Dienste beziehungsweise Mobile Services anzeigen lassen. Hier wählen Sie die Option Enable Direct Push over HTTP(s) aus. Die Option Enable up-to-date notifications via SMTP and text messaging sollten Sie nicht aktivieren, da es sich hier um die alte AUTD-Variante handelt.
Ob Ihr Server richtig arbeitet, können Sie im Event Log überprüfen. Nachdem der erste Client versucht hat, mit dem Server zu kommunizieren, müssen im Event Log die Ereignisse mit den IDs 3002 und 3025 und der Quelle Server ActiveSync auftauchen.
Grundlagen der Kommunikation
Die Verbindung zwischen Client und Server wird zunächst vom Client aus aufgebaut. Denn nur wenn das Endgerät eingeschaltet ist und über eine IP-Verbindung und somit eine IP-Adresse verfügt, kann die Kommunikation überhaupt stattfinden. Ohne den ersten Verbindungsaufbau vom Endgerät her wüsste der Server überhaupt nicht, an welche IP-Adresse er die Mails pushen soll.
Steht die erste Verbindung, so ist es die Aufgabe des Clients, diese aufrechtzuerhalten. Deswegen schickt der Client regelmäßig auch dann ein kleines Datenpaket zum Server, wenn keine neuen E-Mails beim Server vorhanden sind. Wie häufig der Client dieses tut, hängt vom gewählten Heartbeat-Intervall ab. Auf Protokollebene gibt es nun einen neuen Befehl namens PING,eine Erweiterung des bisherigen ActiveSync-Befehlssatzes. Wie alle anderen ActiveSync-Befehle wird auch das PING über einen http POST-Befehl vom Client an den Server geschickt.
Protokolldetails
Natürlich sind alle Funktionen für die Nutzung von Direct Push in den Exchange Server eingebaut. Um das Protokoll zu verstehen, muss man aber wissen, dass es eine Art Exchange Active-Sync-Prozess (EAP) gibt, der quasi zwischen dem Endgerät und dem eigentlichen Exchange Server (genau genommen dem Informationsspeicher) vermittelt.
Bei der ersten Verbindung nach dem Einschalten schickt der Client nun den PING-Befehl. Falls in diesem Befehl ein Heartbeat-Intervall oder eine Liste der zu synchronisierenden Ordner enthalten ist, speichert der EAP diese Informationen in der versteckten Datei AUTDSTATE.XML im Postfach des Anwenders. So muss der Client diese Informationen nur dann erneut übertragen, wenn sie sich ändern, und die benötigte Bandbreite wird auf ein Minimum reduziert. Fehlt also die entsprechende Information im PING-Befehl, so verwendet der EAP die bereits im Postfach gespeicherten Informationen.
Nun meldet sich der EAP beim Informationsspeicher an und registriert sich über den DAVBefehl SUBSCRIBE für Änderungen an den relevanten Ordnern. Sollten zu diesem Zeitpunkt Änderungen seit dem letzten SYNC zwischen Endgerät und Exchange Server passiert sein, antwortet der EAP auf den PING-Befehl mit dem Status 2. Das bedeutet für das Endgerät, dass es nun synchronisieren muss, um die Änderungen zu empfangen. Falls keine Änderungen vorhanden sind, wartet der EAP weiter auf Benachrichtigungen vom Exchange-Informationsspeicher.
Falls der EAP innerhalb des Heartbeats eine Änderungsbenachrichtigung erhält, schickt er ebenfalls eine Antwort mit Status 2 an das Endgerät. Falls nach Ablauf des Heartbeats keine Änderungen am Postfach des Benutzers passiert sind, schickt der EAP eine Antwort mit dem Status 1 an das Endgerät und hört auf, das Postfach des Anwenders auf Änderungen zu überwachen. Der Client muss sich also innerhalb des Heartbeats immer wieder per PING beim Server melden, um die Verbindung aufrechtzuerhalten.
Heartbeat-Intervall
Das Heartbeat-Intervall wird vom Client bestimmt. Um die Lebensdauer der Batterie möglichst hoch zu halten und möglichst wenig Datenverkehr zu generieren, strebt der Client nach dem höchstmöglichen Heartbeat-Intervall. Das tatsächliche Intervall ermittelt der Client anhand der Zuverlässigkeit des Netzwerks, eventuellen Firewall-Timeouts und anderen Faktoren.
In der Standardkonfiguration beträgt das Minimum 1 Minute und das Maximum 45. Diese Einstellungen können Sie in der Registry unter HKLM\SYSTEM\CurrentControlSet\Services\Mas-Sync\Parameters ändern. Bitte beachten Sie aber, dass das Maximum fest auf 59 Minuten verdrahtet ist. Das liegt daran, dass der DAV-Befehl SUBSCRIBE einen Timeout von 60 Minuten hat.
Exchange-Frontend und Firewalls
Falls Sie Frontend-Server einsetzen, müssen Sie beachten, dass der EAP auf dem Frontend läuft, die Benachrichtigung über Änderungen im Postfach aber vom Backend getriggert wird. Daher muss vom Backend zum Frontend der UDP Port 2883 offen sein. Falls dieser Port in Ihrer Umgebung problematisch ist, können Sie in der Registry unter HKLM\SYSTEM\CurrentControlSet\Services\MasSync\Parameters auch einen anderen Port festlegen. Am besten, Sie überprüfen mit dem Befehlt netstat –ano oder dem Tool PortQry, ob Ihr Frontend auf dem festgelegten Port auf UDP-Pakete hört.
Besonderes Augenmerk müssen Sie auch auf Ihre Firewall richten. Während des Heartbeat-Intervalls kann es sein, dass das Endgerät und der EAP nicht miteinander kommunizieren müssen. Viele Firewalls sind so konfiguriert, dass sie eine inaktive Verbindung nach einigen Minuten kappen, was im Falle von Direct Push kontraproduktiv ist. Da der Heartbeat bis zu 59 Minuten betragen kann, sollten Sie inaktive ActiveSync-Verbindungen auf Ihrer Firewall erst nach einer Stunde kappen. Falls Ihnen das zu lange erscheint, sollte der Wert zumindest nicht kleiner als 15 Minuten gesetzt werden. Weitere Informationen hierzu enthält der Artikel 905013 in der Knowledge Base.
Heartbeat und Kosten überwachen
Der EAP merkt sich die jeweils letzten 200 gemeldeten Heartbeat-Intervalle und bildet aus diesen einen Durchschnitt. Sinkt der Durchschnitt unterhalb eines bestimmten Wertes, wird eine entsprechende Warnung in das Event Log geschrieben. Bei welchem Wert die Warnung erzeugt wird und wie viele Heartbeats der Server in die Betrachtung einfließen lassen soll, können Sie ebenfalls in der Registrierung einstellen, und zwar unter HKLM\SYSTEM\CurrentControlSet\Services\MasSync\Parameters.
Gerade wenn Sie Direct Push erstmalig einführen, sollten Sie den Heartbeat im Auge behalten. Denn ein niedriger Heartbeat-Wert bedeutet vor allem, dass sehr häufig Pakete zwischen dem mobilen Endgerät und dem Server ausgetauscht werden. Und in der Menge können sich diese Pakete sehr schnell zu größeren Kosten addieren. Das trifft vor allem dann zu, wenn zusätzlich die Verbindung an sich, also die GPRSVerbindung am Endgerät, immer wieder zusammenbricht. Denn einige Provider runden den GPRS-Verkehr pro Verbindung am Ende auf 100 K auf und rechnen nicht nach tatsächlichem Volumen ab. So können die Mobilfunkkosten regelrecht explodieren, obwohl man gefühlt vielleicht gar nicht so viele Daten austauscht.
Troubleshooting
Um möglichen Fehlern auf die Schliche zu kommen oder von einer funktionierenden Konfiguration Daten für spätere Analysen zu sammeln, sollten Sie zunächst auf dem mobilen Endgerät die Protokolldateien aktivieren. Diese Möglichkeit ist ein wenig versteckt. Sie müssen dazu in ActiveSync die Optionen aufrufen, den Exchange Server auswählen und dann auf Einstellungen klicken. Im zweiten Dialogfeld (wo Sie auch Ihre Benutzerdaten eingeben) klicken Sie auf Erweitert und wählen dann unter Ereignisprotokollierung die Option Kurz oder Ausführlich aus. Die Protokolldateien werden dann im Pfad Windows\ActiveSync erstellt. Speziell für die Überwachung von PING gibt es eigene Dateien mit dem Namen Ping Exchange Server x.txt, wobei x für eine fortlaufende Nummer steht. Hier sollten Sie einen Eintrag wie diesen finden:
POST Microsoft-Server-
ActiveSync?User=administrator&DeviceId=6F24CAD599A5BF
1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=Ping
MS-ASProtocolVersion: 2.5
Diesen und die anderen POST-Befehle finden Sie auch im IIS-Log auf dem Frontend-Server.
Auch das IIS-Log auf dem Backend-Server liefert gute Dienste. Hier sollten Sie vor allem darauf achten, ob nach Eingang des PING die Datei AUTDSTATE.XML tatsächlich generiert wird. Ein Eintrag im Log sieht dann ungefähr so aus:
PUT /exchange/Administrator@1b1domain.lab/
NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/PocketPC/
6F24CAD599A5BF1A690246B8C68FAE8D/AutdState.xml
Die Datei selber können Sie sich im Internet Explorer ansehen. Dazu müssen Sie einen Webordner öffnen und dann den Befehl http://server/exchange/user/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/Autd-State.XML eingeben. Dabei müssen Sie natürlich Ihren eigenen Server und Benutzernamen verwenden. Ebenfalls im Backend-Log sollten die SUBSCRIBE-Befehle auftauchen, die ungefähr wie folgt aussehen: SUBSCRIBE/exchange/Administrator@infowan.lab/Inbox/.
Ob tatsächlich die entsprechenden UDP-Pakete zwischen Frontend und Backend ausgetauscht werden, können Sie mit NETMON überprüfen.
Zusammenfassung
Die Protokolländerungen für Direct Push im Rahmen des ActiveSync-Protokolls sind wie erläutert minimal. Trotzdem haben sie eine große Wirkung. Da vor allem beim Beginn der Nutzung einige Besonderheiten auftreten können, ist vor allem das Troubleshooting über die Logfiles eine gute Möglichkeit, Fehler auszumerzen. Achten Sie unbedingt darauf, dass Sie die Konfiguration hinsichtlich Timeouts und Heartbeats optimiert haben, bevor Sie die Endgeräte in großem Umfang an Ihre Benutzer verteilen, um unangenehme Überraschungen bei den Kosten zu vermeiden.