"Solving the Phone Sync Problem End-To-End": Tech Details On Microsoft's New Push Email

[Janak Parekh]

<div class='os_post_top_link'><a href='http://blogs.technet.com/exchange/archive/2005/06/07/406035.aspx' target='_blank'>http://blogs.technet.com/exchange/a.../07/406035.aspx</a><br /><br /></div><i>"...we offered an always up-to-date (AUTD) solution based on text messaging at that time, but I wasn’t happy with what was required in terms of provisioning and the server-side enforcement of latency so as to mitigate the impact of AUTDv1 on server performance. What to do. Around this time, we had begun looking into what it would take to offer an up-to-date mobile email solution ("AUTD," from here on) that competed with the likes of RIM, Good, et al. I liked the up-to-date nature of their solutions but had not personally adopted them for reasons of device choice (again with the form factor), setup costs (in terms of money, deployment overhead, and operational overhead), or both. Being on the Exchange team, we’ve always got two sets of customers: the administrative staff and end users, and we wanted to build a solution that worked well for both."</i><br /><br />This is an excellent technical post on how exactly the new push email mechanism in Exchange 2003 SP2 interfaces with Windows Mobile 5.0's Messaging and Security Feature Pack. For those of you who are sysadmins, you'll definitely want to read this (as well as Geekzone's thoughts on the subject, linked to as the Source). Highlights include the fact that the solution they've designed doesn't need any access except on ports 80 and 443. I can't wait to see how this works in practice, but the design as stated sounds pretty thorough. 8)

[Zidane]

This seems like a very nice implementation. Now, if we could get something like this for those of us who do not use Exchange.

[Mike Wagstaff]

The device issues an HTTP request to Exchange, which asks Exchange to report any changes that occur in the mailbox of the requesting user within a specified time limit
Maybe I'm misreading the article, but this doesn't sound like a true push technology to me.

Of course, as the article goes on to explain, that's not necessarily a bad thing. Nevertheless, it's interesting to see the continued reliance on the client to request the data.

The requests might only contain a very small amount of data, but I also wonder how this would work with GPRS costs compared to true push solutions...?

[Zidane]

The cost will ultimately be determined by the interval between HTTP headers. Send them too frequently and you could start to see the cost rise. But, if you don't send them often enough, you could get dropped packets (when wandering in and out of cells).

I think the main difference from how RIM works is that this seems to be relying on existing TCP/IP frameworks to track a mobile device (which is impossible as the article mentions) while RIM seems to be tracking the device at the cellular level, the same way your cellular provider does with your cellphone.

In order to be compatible with the most devices (including those that are getting WM5 upgrades) this looks like it's really the only solution for MS.