During our Exchange Unplugged Tour I've been explaining how the Direct Push technology works in Exchange 2003 Service Pack 2. 

The Exchange team wrote a great blog on this which few people seem to have seen - http://blogs.technet.com/exchange/archive/2005/06/07/406035.aspx

The Summary is that when we designed this technology we considered the following

  • The deployment of AUTD must be turn-key for the administrative staff.  Just install Exchange, check a checkbox or two, and you’re off and running.
  • The deployment of AUTD must not require a business relationship between any of Microsoft, the enterprise deploying AUTD, or the mobile operator.
  • The solution must not require a network operations center (NOC).
  • Since, by and large, mobile devices are not internet-routable without a NOC and without having first contacted an internet-resident peer, the means by which AUTD works must be initiated by the device.
  • Enterprise administrators will laugh at us if we ask them to open inbound ports on their networks other than 80 (HTTP) and 443 (HTTPS).  Some of them laugh at us, anyway.
  • There must be no notion of “dropped” notifications.
  • The device side of the solution must not require any provisioning beyond what the user must already do in order to setup ActiveSync.

Within this definition of the problem, we came up with the following solution:

  • 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.  The URL of this HTTP request is the same as that of other AirSync commands ("/Microsoft-Server-ActiveSync") with some differing query string parameters.  The body of the HTTP request allows the client to specify those folders that Exchange should monitor for changes.  Typically, these will be the Inbox, Calendar, Contacts, and Tasks folders.
  • Upon receiving this request, Exchange will monitor the specified folders until either the time limit expires or a change (such as the arrival of a piece of email) occurs in one of those folders, whichever comes first.  Exchange will then issue a response to this request that notes in which folders the changes occurred.  Of course, this will be empty if the time limit elapsed before any changes occurred.
  • Upon receiving an empty response, the device simply re-issues the request.  This loop of issuing a request for change notifications, receiving an empty response, and re-issuing the request for change notifications is called "the heartbeat."
  • Upon receiving a non-empty response, the device issues a synchronization request against each folder in the response.  When those complete, it re-issues the request for change notifications.

With this approch we remove the need for a relay or Network Operations Centre (NOC) avoiding the need to relay data and also add cost to the overall solution.  We still however provide the exact same experience of other mobile email 'push' solutions. 

There seems to be lots of mis-conceptions out there that are being circulated by various parties about this architecture - I've outlined a few of them below.

1) Scaleability - I've seen some of our competitors make false statements about the fact that our solution will massively impact the network and firewall and it won't scale.  This is totally wrong - we have over 45,000 Windows Mobile Device users in Microsoft using this technology already – we support them from 2 Servers in Redmond with just 4 employees supporting the whole service. .  Those Servers are dual pentium - 2GB RAM machines.    We have a public document showing Microsoft IT’s own scaleability experience with our product http://download.microsoft.com/download/1/a/5/1a572c42-10b5-469d-9acb-cedd2e634985/WindowsMobile_e-mail_scalability.doc

2) Having an incoming firewall port is bad - Opening port 443 (SSL) is actually not such a big deal that some of our competitors make out.  Port 443 is the same port used for Outlook Web Access and RPC/HTTPS - a large majority of customers already provide this service over the Internet or through a private APN/VPN.  There will always be a small majority who won't want to do this - but it is a small majority.  

3) We don't use SMS (short message service) anymore!!! - The previous Always Up to Date solution (AUTD) used SMS as a trigger mechanism - we use IP in the Exchange 2003 SP2 solution - not SMS - a few people still seem to think we use SMS - we don't.