Mobile messaging and Exchange Server 2003 SP2

Apart from a short post announcing the arrival of Exchange Server 2003 service pack 2 (SP2), I haven’t written much on the topic. Often the first service pack for a product brings functionality that didn’t quite make it in time for the release. Second service packs are more likely to include features that have become significant in the market – for Windows XP that was security and for Exchange, that’s mobile messaging and tackling UCE – but SP2 also brings a number of other improvements:

  • Probably the most significant change for small businesses (and branch office deployments) is the increased storage potential for Exchange Server 2003 standard edition (now limited to 75GB, rather than the 16GB limit that existed previously). Of course, enterprise edition is still “unlimited”, but for those organisations running the standard edition, 16GB might only have been a few mailboxes!
  • SP2 also enhances some of the management tools – particularly with a “panic button” to prevent public folder replication (a lengthy process that was previously difficult to stop once started).
  • The Exchange Server 2003 intelligent message filter (IMF) – previously a separate download, it is now included in SP2. SP2 also supports SenderID – the proposal from Microsoft and others for validation that a message did actually originate from the organisation from which it claims to be.
  • Finally, on the mobile messaging front, SP2 adds direct push support, device and message security, and support for device policy provisioning.

I’m planning a separate post on tacking unsolicited commercial e-mail (UCE – commonly known as spam) using the IMF so here I’ll concentrate on the mobile messaging improvements in SP2.

At last week’s IT Forum ’05 highlights (part 2) event, Ewan Dalton (one of the Microsoft Exchange team members) demonstrated some of the new mobile technologies. I was quite impressed – up until now, Windows Mobile users only really had POP/IMAP/HTTP e-mail whilst Blackberry users were bragging about their instant delivery (“push” e-mail). Actually, none of it is instant – there’s actually a polling mechanism in place and push does involve some pulling (as does it for Blackberry), but even so it’s pretty good.

The ActiveSync direct push process works as follows:

  1. The mobile device sends a request to the Exchange Server front end server.
  2. The server holds the request pending until the heartbeat interval expires (default 15 minutes) – effectively keeping a connection open, but with no traffic).
  3. If no mail arrives before the heartbeat interval expires, the device sends another request but if new mail arrives in the meantime, the server notifies the device that changes have occurred in the mailbox.
  4. Upon receiving a response from the server, the device immediately issues a synchronisation request to pull e-mail. Once synchronised, the process restarts at step 1.

In practice, I’m told that mail will probably be on the mobile device before it would arrive in Outlook in cached mode.

When asked about the cost of keeping the device connection open using the heartbeats, Microsoft replied that their testing indicates an extra 1MB of traffic per month; however, because the new ActiveSync is using GZIP compression, traffic levels have dropped by 50%, so it could actually result in lower bandwidth charges.

Another improvement with SP2 is the new mobile device policy functionality, allowing organisations to enforce device security requirements, e.g. password length, complexity, inactivity timeout, refresh interval and also the ability to wipe the device after a specified number of attempts (the handset would still be usable, but it would no longer contain any data). All of this can optionally be overridden with exceptions (e.g. for older devices which do not support the policy). Certificates are also supported in place of username and password/PIN combinations; however these need to be provisioned over a corporate network (not the mobile operator’s network).

Microsoft also demonstrated the ability to wipe a device when chosen from a list of devices associated with a user, sending a dummy contact which effectively applies a new policy and wipes the device. Because this is a notification, not an SMS message, it is effective immediately.

Using a traditional middleware approach (e.g. BlackBerry Server for Microsoft Exchange), device support is limited and the network operator has to be involved in mail delivery:

Mobile middleware

With Windows Mobile and Exchange Server 2003 SP2, there is no middleware and devices connect via HTTPS straight into the corporate infrastructure:

Windows Mobile

In practice, this looks something like the following:

Windows Mobile in the Enterprise

Microsoft recommend using a domain-joined ISA Server with one NIC in the corporate network and another in a DMZ (i.e. behind another firewall) to pre-authenticate user requests. In this manner the front-end server no longer has to be located inside the DMZ and there are less firewall ports to be opened for Active Directory connectivity, decreasing the attack surface for the corporate network.

For scalability, Microsoft quote their own metrics from internal deployment.

  • Worldwide, the software giant has 106,000 user mailboxes with four front end hubs. About 25% of these mailboxes use mobile devices – and two thirds of these are smart phones with the remaining third running Pocket PC Phone Edition.
  • In Redmond alone, there are 60,000 mailboxes with all mobile services running on three Exchange Server 2003 SP2 servers (dual CPU and 2GB RAM). This breaks down to 20,000 simultaneous HTTP sessions per server (although they do concede that a more realistic benchmark would be 10-15,000 sessions). The same servers are used for Outlook Web Access (OWA) and Outlook RPC over HTTP.
  • ActiveSync uses a single HTTPS connection.
  • OWA uses 3 or 4 connections.
  • RPC over HTTP typically uses between 10 and 12 connections.
  • In the Europe, Middle East and Africa (EMEA) region, 9000 users are supported from one 5-node Exchange Server cluster in Dublin. Two of these are front end servers but one would be sufficient – the second is for resilience.
  • In order to use the new Exchange Server mobile functionality there are some device and server requirements:

    • The device must be running Windows Mobile 5.0 (older devices will work, but will not benefit from the SP2 improvements). Also, the messaging security feature pack (MSFP) is required for much of the new functionality – this is part of the adoption kit ROM update 2 (AKU2), currently being tested by network operators and expected to ship during March/April 2006. Device manufacturers can use an image update to refresh older Windows Mobile 5.0 devices that are already on the market.
    • The front end server needs to have Exchange Server 2003 SP2 installed. In addition, Microsoft recommend that the IIS and firewall HTTPS timeout is increased for the ActiveSync virtual directory (to between 15 and 30 minutes).

    Other OEMs are licensing Exchange technologies so the new features will be supported on a broader range of devices (Palm, Nokia, Motorola, etc.). Another option is the use of third-party software, like the Java-based DataViz RoadSync.

    Unusually feature-packed (for a service pack), SP2 is expected to be the last major functional improvement for Exchange Server 2003 but it brings a whole host of valuable functionality. Watch this space for more about the next version of Exchange Server (codenamed Exchange 12).

    3 thoughts on “Mobile messaging and Exchange Server 2003 SP2

    Leave a Reply