Exchange 2003 always up-to-date (AUTD)

Die hier beschriebene Funktion ist erst ab Exchange 2003 SP2 verfügbar und erfordert ein entsprechendes mobiles Endgerät mit einer Verbindung zum Internet und einen aus dem Internet erreichbaren Exchange 2003 Server (Siehe MSFP)

AUTD sorgt dafür, dass sie auf ihrem PocketPC immer aktuell sind, d.h. neue Mails, Änderungen bei Terminen etc. sofort auch unterwegs aktualisiert werden. Wenn Sie aber auf dem PocketPC etwas ändern, dann wird dies nicht sofort auf den Server repliziert.

Understanding Direct Push
http://technet.microsoft.com/en-us/library/aa997252.aspx

Mit Exchange 2000 hat Microsoft den Mobile Information Server verkauft, der den mobilen Anwendern einen Abgleich ihres Postfach auf einem  mobilen Client mittels mittels ActiveSync erlaubt hat. Ab Exchange 2003 wurde der Exchange ActiveSync Server ein Bestandteil des Servers und erlaubte nicht nur die Replikation per HTTP sondern auch den Zugriff mit reduziertem Browser auf  Outlook Mobile Access. Damit ist zwar schon viel erreicht aber es fehlte bislang immer noch die Funktion, dass der Mitarbeiter auf dem mobilen Gerät eine Information über neue Elemente aktiv benachrichtigt wurde.

Dies war bislang nur so möglich, dass der mobile Client immer wieder eine Replikation per HTTP angefordert wurde oder der Exchange Server über eine SMS den Client zu einer Replikation aufgefordert hat. Beide Wege sind kostenintensiv, da speziell im europäischen Raum der SMS-Versand ein Kostenfaktor ist und auch die regelmäßige Replikation per Funktechnik sehr schnell teuer wird.

Zwar zeichnet sich seit 2005 immer mehr ab, dass die Mobilfunkprovider ihre Preismodell anpassen, so haben die Entwickler von Exchange 2003 einen alternativen Weg gesucht und mit Exchange 2003 SP2 auch veröffentlicht.

AUTD - Was waren die Überlegungen ?

Die Hintergründe und Überlegungen zum neuen Verfahren hat Sami Khoury auf dem TechNet Blog http://msexchangeteam.com//archive/2005/06/07/406035.aspx sehr ausführlich die Überlegungen und prinzipielle Funktionsweise der neuen Funktionen von Exchange 2003 SP2 erläutert.

Zwar geht viel Text auf seine Verärgerung über die mehrmalige Pflege von Kontakten in den verschiedenen Mobiltelefonen drauf, aber die Quintessenz ist, dass eine Replikation mit den Outlook Kontakten und später auch dem Kalender gesucht und über die Nokia Synchronisation auch auf dem Desktop möglich war. Aber sehr schnell was auch dies nicht mehr ausreichend, da nicht immer der PC vorhanden oder online war. Das mag für Rufnummernlisten noch ausreichend sein, aber als Terminplaner kann ein Mobilteil nicht dienen, wenn er Stunden oder Tage veraltet ist.

Erst ein Mobilteil mit Windows Mobile erlaubte die Replikation mit dem Server aber eben nicht die zeitnahe günstige Übertragung von Aktualisierungen auf den Client. Und das war die Geburtsstunde von Exchange AUTD.

Die wesentlichen Faktoren dabei waren:

  • Einfach zu installieren
    ähnlich wie ActiveSync und andere Funktionen von Exchange sollte die Installation einfach sein
  • Keine Provider oder Verträge mit Drittherstellern
    Ein weitere Ziel war, dass keine Zwischenstationen oder Installationen beim Mobilfunkprovider oder bei einem anderen Dienstleister erforderlich sind, die zusätzliche Verträge und Kosten bedeuten sollten. Einen solchen Ansatz wählte z.B.: die Blackberry Lösung.
  • Geeignete Protokolle zur Kommunikation
    Viele mobile Geräte können zwar im Internet "Surfen" aber andere Ports sind oft gesperrt oder aus anderen Gründen nicht erreichbar. So scheidet RPC zwischen Client und Server aus. Auch Sie als Exchange Server Administrator möchten ihren Server natürlich nicht ungesichert im Internet zu veröffentlichen.

Schlicht es soll einfach, billig und für jedermann einzurichten und einsetzbar sein, solange ein kompatibles mobiles Endgerät vorhanden und ein Exchange 2003 Server mit entsprechenden Namen über das Internet erreichbar ist.

AUTD - So funktioniert es !

Das im Internet für Datenzugriffe gebräuchliche Protokoll ist HTTP bzw. HTTPS. Es wird nicht nur von Webbrowsern zum klassischen surfen im Internet benutzt, sondern auch immer mehr Dienste nutzen HTTP als universelles Transportmedium. SOAP und WebDAV aber auch Outlook 2003 mit RPC over HTTP und der Exchange ActiveSync Server nutzen HTTP. Da liegt es nahe auch AUTD über dieses Protokoll zu fahren.

Nun wissen wir alle, dass HTTP in dieser Konstellation vom Client zu initiieren ist und der Server nur antwortet. Das können wir schon von Outlook Webzugriff, OMA und natürlich auch Exchange ActiveSync Server. Neu durch AUTD ist nun aber eine leicht geänderte Verhaltensweise des Servers auf eine Anfrage.

Normalerweise versucht ein Server eine Anfrage so schnell wie möglich zu beantworten. Bei AUTD hingegen beantwortet der Server die Anfrage erst, wenn es etwas dem Client mitzuteilen gibt oder ein Timeout zuschlägt. Als Timeout werden Werte bis zum 20 Minuten gehandelt. Der Client stellt seine Anfrage, die eine Liste der zu überwachenden Ordner auf dem Exchange Server enthält. Der Server stellt für diese Ordner eine Überwachung ein und sendet die Antwort erst, wenn sich etwas geändert hat.

Was bedeutet das am Beispiel einer ActiveSync Verbindung, bei der nach drei Minuten eine neue Mails im Postfach ankommt:

Achtung: Die hier gemachten Annahmen bezüglich Datenmenge und Bedarf sind nicht repräsentativ, da Sie stark von ihrer Nutzung und dem Verhalten der finalen Versionen von Exchange 2003 SP2 und Windows Mobile 5 abhängig sind.

Um ohne AUTD aktuell zu bleiben, wird davon ausgegangen, das das PocketPC zur Hauptzeit alle 5 Minuten eine Synchronisation ausführt. Eine Benachrichtigung per SMS ist nicht aktiv, da die zumindest in Deutschland eine teure Wahl ist.

Beschreibung ActiveSync alt ActiveSync mit AUTD
Kommunikation im Überblick

Bei ActiveSync ALT repliziert sich der Client alle 5 Minuten mit dem Server, während bei AUTD von einer Idle-Time von 20 Minuten ausgegangen wird.

Beide Clients starten zur gleichen Zeit.

3 Minuten nach dem Start wird eine neue Mail im Postfach eingeliefert.

ActiveSync bekommt diese Mail erst nach 5 Minuten (dem nächsten Replikationsinverfall) übertragen, während bei AUTH der Server sofort die Nachricht als Antwort auf die noch ausstehende Anfrage an den Client übermittelt. Die Datenmenge für die Mail selbst ist vergleichbar. Allerdings benötigt das alte ActiveSync für den regelmäßigen vollständigen Abgleich mehr Bytes als AUTD.

In der Folgezeit gibt es keine Änderungen , so dass AUTD das 20 Minuten Intervall nutzen kann, während der klassische Client weiterhin alle 5 Minuten auf Verdacht repliziert.

Schnelligkeit der Mail

2 Minuten nach Eintreffen

kurz nach dem Eintreffen

Datenvolumen für die 23 Minuten Serie

4,4 kByte

1,9 kByte

Hochgerechnetes Datenvolumen für 24 Stunden Synchronisation

24x60 Replikationen a 0,6k = 864 kByte

24x3 Timeoutanforderungen a 0,2 k = 14,4kByte

Bei der ersten Betrachtung könnten Sie nun sagen, dass das neue Verfahren doch wieder ein Polling des Clients bedeutet, nur dass die Intervalle auf 20 Minuten gedehnt werden können. Der kleine aber wichtige unterschied ist aber, dass beim klassischen Polling der Client regelmäßig fragt und sofort eine Antwort bekommt. Wenn der Client nicht fragt, bekommt er die Information über eine Veränderung erst bei der nächsten Frage. Das von Microsoft "Heartbeat" genannte Verfahren jedoch verzögert die Antwort auf eine Anfrage bis sich etwas getan hat oder der Timeout abläuft. Wenn also eine Veränderung auf dem Server stattfindet, dann erhält der Client sofort die Antwort auf seine Frage. Damit wird der Client quasi in Echtzeit über ein Update informiert und benötigt trotzdem ganz wenig Bandbreite. An den Bildern erkennen Sie dies daran, dass links beim klassischen Modell die Pause immer zwischen einer Antwort und der nächsten Frage des Clients ist während rechts die Pause immer zwischen der Anfragen und der Antwort des Server ist. Der kleine aber wichtige unterschied, der zwischen Polling und Heartbeat unterscheidet aber letztlich richtig viel Geld spart und Aktualität bringt. Allerdings muss auch hier der Client "always on" sein, d.h. das ganze trägt nur mit GPRS oder einem anderen Tarif, der nach Volumen geht und ein Paket nicht unbedingt im 100kbyte Block abgerechnet wird.

AUTD und Timeout

Nun ist es ja so, dass der Client permanent eine TCP-Verbindung zum Exchange Server offen hält,  damit Exchange eine Rückantwort über diesen Kanal senden kann. Es erfolgt ja kein Verbindungsaufbau von Exchange zum Smartphone. Nur haben TCP/IP-Verbindungen das Problem, dass diese nicht nur am Leben erhalten werden, sondern auch einem Timeout unterliegen. Auch Firewalls und Filter überwachen solche Verbindungen und beenden inaktive Verbindungen nach einiger Zeit. Entsprechend muss diese Konfiguration angepasst werden, damit eine Firewall eine Verbindung nicht beendet.

Aber auch der Provider für die GRPS-Verbindung wird irgendwann eine offene aber inaktive Verbindung beenden, um Kosten und Ressourcen zu sparen. Zuletzt müssen Sie natürlich auch ihrem Webserver (IIS) mitteilen, dass der Timeout etwas länger sein darf.

Der PocketPC muss daher irgendwie ermitteln können, ob die Verbindung noch steht und wie lange der Timeout ist. Dazu nutzt ActiveSync folgende Logik:

  • Startwert 28 Minuten
    ActiveSync geht von einem TCP/IP-Timeout von 28 Minuten aus, d.h. alle 28 Minuten fordert der Client erneut per HTTP Daten an. Wenn dies erfolgreich ist, verbleibt er dabei.
  • Fehler Fallback auf 8 Minuten
    Bekommt er aber die Meldung, dass die bestehende TCP/IP-Verbindung schon abgebaut wurde, dann fällt er auf einen 8 Minuten Takt herunter. Dies kann nicht konfiguriert werden.
  • Ansteigend bis Timeout
    Dann wird der Timeout in den Schritten 8,13,18,23,28 angehoben, bis er wieder fehlschlägt.
  • Letzter gültiger Weg
    Nach dem letzten Fehlschlag fällt ActiveSync wieder auf den letzten erfolgreichen Wert zurück

In einem Bild sieht das dann wie folgt aus. Durch einen Wechsel der Funkzelle ändert sich z.B. der Timeout des Providers.

Offen ist dabei natürlich, was passiert, wenn wieder ein Providerwechsel erfolgt und der Timeout wieder höher ist. Ab wann "merkt" dies der PocketPC und geht wieder auf 28 Minuten hoch ?

Angeblich gibt es PocketPCs mit einer AddOn Software, die z.B. eine inaktive GRPS-Verbindung selbständig trennt. Damit kann ActiveSync natürlich nicht sparsam arbeiten.

AUTD - etwas detaillierter

Da AUTD einfach auf HTTP bzw. HTTPS aufsetzt, ist es zumindest beim Einsatz der unverschlüsselten Verbindung per HTTP natürlich auch einfach möglich, die übertragenen Daten zu analysieren und das Volumen zu ermitteln. Mit Packetyzer habe ich einfach mal den Traffic zwischen einem Endgerät und dem Server mitgeschnitten (ohne SSL) und man sieht sehr gut, was passiert:

Die Pakete etwas genauer bedeuten (Die Daten wurden mit einem IPAQ 5450 und Windows 2003 SE erzeugt, welcher mit dem Programm RoadSync auch "DirectPush"-tauglich gemacht wurde. Die Pakettraces wurden zur Lesbarkeit gekürzt und Kennworte entfernt

Paket DeltaTime Bedeutung

1

entfällt

Der Client hat bereits eine TCP/IP-Verbindung aufgebaut (Handshake hier nicht sichtbar) und fordert die verfügbaren Optionen des Server an

OPTIONS /Microsoft-Server-ActiveSync?User=mobil02&DeviceId=401A39840000F17E0&DeviceType=RoadSyncClient HTTP/1.1
MS-ASProtocolVersion: 2.5
Connection: Keep-Alive
User-Agent: Microsoft-SmartPhone/3.0
Authorization: Basic Anmeldedaten_entfernt
Content-Length: 0

2

2,6 ms

Exchange antwortet mit einem 200 OK und einigen Daten zu Exchange ActiveSync, d.h. die Version und verfügbaren Optionen.

HTTP/1.1 200 OK
Public: OPTIONS, POST
Allow: OPTIONS, POST
MS-Server-ActiveSync: 6.5.7638.1
MS-ASProtocolVersions: 1.0,2.0,2.1,2.5
MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,CreateCollection,
DeleteCollection,MoveCollection,FolderSync,FolderCreate,FolderDelete,FolderUpdate,
MoveItems,GetItemEstimate,MeetingResponse,ResolveRecipients,ValidateCert,Provision,
Search,Notify,Ping

3

371 ms

Der Client fordert nun ein Update beim Eintreffen einer neuen Mail an. Sie erkennen das am CMD=Ping in der URL

POST /Microsoft-Server-ActiveSync?User=mobil02&DeviceId=401A39840000F17E0&DeviceType=RoadSyncClient&Cmd=Ping HTTP/1.1
MS-ASProtocolVersion: 2.5
User-Agent: Microsoft-SmartPhone/3.0
Authorization: Basic Anmeldedaten_entfernt
Content-Type: application/vnd.ms-sync.wbxml
Content-Length: 179

..j.. EH.540..IJK.2098981c9205938-
407b..L.Email...JK.2098981c9205938-
32fc..L.Calendar...JK.2098981c9205938-
32fd..L.Contacts.....

4/5

1 min 48 sek

Erst nach 1 Min, 48 Sekunden kommt eine neue Mail im Postfach an und Exchange beantwortet die Anfragen.

HTTP/1.1 200 OK
Content-Type: application/vnd.ms-sync.wbxml
Content-Length: 56
MS-Server-ActiveSync: 6.5.7638.1

..j.. EG.2..IJ.2098981c9205938-407b....

6

 

Nun fordert der Client aktiv die neue Mail über eine Synchronisation an.

POST /Microsoft-Server-ActiveSync?User=mobil02&DeviceId=401A39840000F17E0&DeviceType=RoadSyncClient&Cmd=Sync HTTP/1.1
MS-ASProtocolVersion: 2.5
User-Agent: Microsoft-SmartPhone/3.0
Authorization: Basic Anmeldedaten_entfernt
X-MS-PolicyKey: 1
Content-Type: application/vnd.ms-sync.wbxml
Content-Length: 128

..j.E\OP.Email..K.{AB233B3F-F030-43AE-9E85-30316547F161}4..R.2098981c9205938-407b....U.50..WX.2..Y.1..[.1.....

7/8

 

Der Server sendet die Daten im Rahmen der Antwort

HTTP/1.1 200 OK
Content-Type: application/vnd.ms-sync.wbxml
Content-Length: 326
MS-Server-ActiveSync: 6.5.7638.1

..j.E\OP.Email..K.{AB233B3F-F030-43AE-9E85-30316547F161}5..R.2098981c9205938-407b..N.1..VGM.1:4..]..V."testuser@example.com" <testuser@example.com>..X."Carius, Frank" <frank.carius@example.com>..T.Test..O.2006-09-27T17:14:33.000Z..Q.mobil02..R.1..U.0..N.0..L.Betreff
..S.IPM.Note.SMIME.MultipartSigned..y.28591........

9

 

Paket 9 ist dann wieder die nächste Anfrage des Clients und entspricht im wesentlichen dem Paket 3

Die DirectPush-Funktion von Exchange ist daher gar nicht mal so kompliziert sondern besteht wirklich nur nur korrekt formatierten HTTP/HTTPS Anfragen den den Exchange Server. Eine genauere Dekompilierung der Inhalte ist jedoch nicht Ziel dieser Webseite. Allerdings sollten Sie erkennen können, wie wichtig eine Absicherung per SSL ist, damit die Authentifizierung (Base64) und der Inhalt gesichert ist.

Wenn man dann im IIS-Log die fraglichen Anfragen dieses einen Clients ausfiltert, dann erkennt man z.B. folgende Einstellungen (Hier am Beispiel RoadSync). Der Client stellt alle 9 Minuten seine Anfrage neu. gegen 17:12:47 muss die Verbindung unterbrochen worden sein, weil er hier wieder eine "OPTIONS"-Anfrage stellt.

ActiveSync von Windows Mobile 5 hat hier ein etwas anderes Verhalten, indem es die Zeit dynamisch ermittelt.

Mobiler Admin und AUTD

Eine wesentliche und wichtige Funktion dieser neuen Erweiterung ist auch die Steuerung des Clients vom Exchange Server aus. Der Exchange Server kann den Client nicht nur über neue Nachrichten informieren, sondern auch aus der Ferne Zurücksetzen und die Inhalte löschen. Das ist insbesondere wichtig, um gestohlene oder verlorene Endgeräte unbrauchbar zu machen oder zumindest die Daten und den Zugang zum Firmennetzwerk zu unterbinden.

Dazu ist aber nicht nur Windows Mobiles 5 sondern auch das "Messaging ans Security Feature Pack" auf dem mobilen Endgerät sein. Diese ist nicht Bestandteil der ersten Windows Mobile 5 Auslieferungen und wird es anscheinend auch nicht als Update von Microsoft geben. Es ist Aufgabe der Hersteller ihres PDA, ein Update von Windows Mobile 5 mit diesen Erweiterungen zum Download als Flashupdate bereit zu stellen. Es ist keine Software, die Sie nachinstallieren können. Wenn dem so wäre, dann könnte Sie ja auch einfach wieder deinstalliert werden.

Für den Administrator selbst muss es natürlich auch eine Software geben, um eben solch ein Endgerät aus der Ferne zu löschen. Diese "Mobile Admin" genannte Anwendung ist eine Webanwendung, die ebenfalls nicht Bestandteil von Exchange 2003 SP2 ist, sondern als getrennter Download erhältlich sein wird.

AUTD und HTTP Timeouts

Da sie nun wissen, wie AUTD arbeitet, können Sie sich sicher schon vorstellen, welche Probleme eine Firewall hier machen kann. Der Client macht nur ganz wenig Verkehr und zwischen einer Anfrage und der Antwort durch den Server können und sollten sogar Minuten vergehen. Entsprechend kann es natürlich sein, dass die Firewall die HTTP-Verbindung schon lange als beendet ansieht und die Antwort dann nicht mehr passieren lässt. Prüfen Sie daher, wie sie bei ihrer Firewall den Session Timeout für TCP-Verbindungen vergrößern können.

Beim ISA-Server ist das relativ einfach. Dort verwenden Sie in der Regel einen "Web Listener" um die HTTP-Anfragen auf den internen Exchange oder Frontend Server zu leiten. Unter den Einstellungen des erweiterten Eigenschaften des Web-Listeners können Sie den Timeout einstellen.

Ein Wert von 30 Minuten (= 1800 Sekunden) könnte für viele Fälle nützlich sein. Sinnvoll kann es jedoch sein, einen eigenen Listener über ActiveSync zu konfigurieren, damit nicht auch andere Webservices (z.B. OWA, Sharepoint etc.) dieses Verbindungslimit haben, was natürlich die Sitzungstabelle des ISA-Servers vergrößert.

Kontrollieren Sie einfach mal das Eventlogs ihren Exchange Server auf die Ereigniskennung 3033

Ereignistyp: Warnung
Ereignisquelle: Server ActiveSync
Ereigniskategorie: Keine
Ereigniskennung: 3033
Datum: 30.10.2007
Zeit: 15:30:17
Benutzer: MSXFAQ\Administrator
Computer: SRV01
Beschreibung:
Der Durchschnittswert für das am häufigsten verwendete [200] Taktintervall ist kleiner oder gleich [540]. Vergewissern Sie sich, dass die Firewallkonfiguration ordnungsgemäß mit Exchange ActiveSync und der Direct Push-Technologie funktioniert. Vergewissern Sie sich insbesondere, dass die Firewall so konfiguriert ist, dass Anforderungen an Exchange ActiveSync nicht ablaufen, bevor sie verarbeitet werden können. Weitere Informationen zum Konfigurieren der Firewalleinstellungen bei der Verwendung von Exchange ActiveSync finden Sie im Microsoft Knowledge Base-Artikel 905013, "Enterprise Firewall Configuration für Exchange ActiveSync Direct Push Technology" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905013).

Exchange prüft also schon alleine den Durchschnittswert für die Anfragen.

Aber auch ohne diese Warnung ist es sehr wichtig, die IISLogs auszuwerten.

AUTD und Perfmon

Natürlich hat Microsoft auch im Bereich der Performance Counter neue Zähler für AUTD aufgenommen. Somit können Sie sehr einfach die Nutzung durch Anwender erfassen.

Eine genauere Auswertung erlaubt aber die Auswertung der IIS-Protokolle über die Zugriffe.

AUTD - für Entwickler

Mit diesem Verständnis kann ein Entwickler natürlich auch diese neue Funktion von Exchange 2003 wunderbar für eigene Zwecke verwenden. Zwar kann schon heute ein Entwickler über WebDAV einen Event auf einem Ordner hinterlegen, so dass Exchange den Prozess über eine Änderung informiert. Dazu nutzt aber Exchange ein UDP-Paket, was nicht immer durch Firewalls oder das Internet übertragen wird. AUTD ist hingegen ein Weg, rein über HTTP/HTTPS zeitnah über neue Einträge in einem überwachten Ordner informiert zu werden. Insofern ein sehr viel flexiblerer Weg.

Allerdings wird erst die Zukunft zeigen, ob diese Schnittstelle genutzt werden wird, das sie erst ab Exchange 2003 SP2 zur Verfügung steht und natürlich mit einer zukünftigen Version schon wieder angepasst werden könnte.

Weitere Links

Marketing und Firmenpartnerschaften zu AUTD