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 Add-on 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 |
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 |
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 |
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 |
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 |
7/8 |
|
Der Server sendet die Daten im Rahmen der Antwort
HTTP/1.1 200 OK |
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.
- EASLog
- 905013 on "Enterprise firewall configuration für Exchange ActiveSync Direct Push Technology
-
http://blogs.technet.com/b/exchange/archive/2006/04/03/424028.aspx
- 304340 The ISA Server response to client options requests is limited to a predefined set
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.
-
EASLog
Auswertung von IISLog auf ActiveSync Zugriffe - More on Exchange ActiveSync Reporting with Log Parser - COM object
available
http://msexchangeteam.com//archive/2006/03/03/421149.aspx
- LogParser
- Und andere Links
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
- Pushdienste
- MobileAdmin
- Exchange ActiveSync Server
- ActiveSync Fehlercodes
- Exchange ActiveSync mit Zertifikaten
Zusätzliche Hinweise zur Arbeit mit Zertifikaten - 905013 on "Enterprise firewall configuration für Exchange ActiveSync Direct Push Technology
- 912127 After you enable Always-Up-To-Date notifications in Exchange Server 2003 SP2, asynchronous event sinks in the mailbox store do not run
- TechNet BLOG Eintrag zu AUTD
http://msexchangeteam.com//archive/2005/06/07/406035.aspx
-
AUTD: Direct Push is just a heartbeat away
http://blogs.technet.com/b/exchange/archive/2006/04/03/424028.aspx
Sehr ausführlicher Detailartikel. -
Understanding Direct Push
http://technet.microsoft.com/en-us/library/aa997252.aspx - Daniels Blogcast
Exchange ActiveSync mit Windows Mobile 5.0 und dem MSFP
Direct Push Email mit Windows Mobile 5.0 und dem MSFP
GAL Lookup mit Windows Mobile 5.0 und dem MSFP
Device Policy Enforcement mit Windows Mobile 5.0 und dem MSFP
Local Wipe mit Windows Mobile 5.0 und dem MSFP
Remote Wipe mit Windows Mobile 5.0 und dem MSFP - Informationen zu Exchange 2003 SP2
http://blogs.technet.com/dmelanchthon/archive/2005/06/06/405942.aspx - Windows Mobile 5.0 Messaging and Security Feature Pack
http://www.Microsoft.com/windowsmobile/business/5/ - AUTD Troubleshooter
http://www.Microsoft.com/downloads/details.aspx?FamilyId=7718A338-A9F5-43D6-9E20-141189283C82&displaylang=en - Exchange Server AUTD Binding Cleanup
http://www.Microsoft.com/downloads/details.aspx?familyid=7FCE5D4D-5D92-4210-9B96-A7FEDCA38325&displaylang=en - 822176 Troubleshoot Exchange 2003 Always-Up-To-Date Notification
- 833745 Exchange Server 2003 Always-up-to-date Notifications do not work with your mobile device
- 841995 The Always-up-to-date Notifications feature may not work with mobile devices in Exchange Server 2003 SP1
- 873291 How to change the batching timer to control the Always-up-to-date Notification feature in Exchange Server 2003
- 905013 Enterprise firewall configuration für Exchange ActiveSync Direct Push Technology
- Microsoft Exchange Server ActiveSync Certificate-Based Authentication Tool
http://www.Microsoft.com/downloads/details.aspx?FamilyID=82510e18-7965-4883-a8c3-f73f1f4733ac&DisplayLang=en - AKU2 / MSFP and SP2 DirectPush configuration
http://msgoodies.blogspot.com/2006/01/aku2-msfp-and-sp2-directpush.html - A Comparison of RIM Blackberry 4.0 and Microsoft Windows Mobile 5.0 Messaging
and Security Feature Pack Enterprise Mobile Solutions
http://download.microsoft.com/download/f/7/7/f77a4fb4-a617-481d-a1e5-ef321b621aaf/MobileDevicePlatforms-ComparisonofRIMandWindowsMobile.pdf
Marketing und Firmenpartnerschaften zu AUTD
- Vodafone and Microsoft Collaborate to Deliver Comprehensive E-Mail
Solution für Business
http://www.Microsoft.com/presspass/press/2006/feb06/02-12MSVodaphonePR.mspx - Vodafone startet zur CeBIT weitere Push-Lösung: Windows Mobile E-Mail
von Vodafone
http://www.vodafone.de/unternehmen/presse/80063_80896.html
Ab Mai 2006 soll man für 23,20 Euro bis zu 100 MByte übertragen können. - T-Mobile to Offer Microsoft Direct Push E-Mail Services on Windows
Mobile-Based Devices in the Netherlands
http://www.Microsoft.com/presspass/press/2006/feb06/02-12TMobNedPR.mspx - Microsoft Announces Global Partner Support für its Mobile Messaging
Solutions
http://www.Microsoft.com/presspass/press/2006/feb06/02-12GlobalPartnerSupportPR.mspx - Microsoft Windows Mobile-Based Smartphones to Run on Low-Cost Texas
Instruments Platform
http://www.Microsoft.com/presspass/press/2006/feb06/02-12TIDrivePR.mspx