Microsoft keeps on pushing

Paul Ockenden | 20 Jul 2007

Paul Ockenden Ditches his blackberry for a month and finds out the benefits and the pitfalls of using Microsoft’s push email system.

For the first time in ages I switched from using Blackberry’s push email system to Microsoft’s push email system, for a whole month, in order to give it a thorough testing. This was a deliberate choice because, unlike most other push email solutions, Microsoft’s doesn’t require an extra server. Microsoft’s push system isn’t really a shrinkwrapped product at all: the underlying technology is referred to as “Direct Push”, but rather than being something that arrives in a box or on a CD it’s simply a method for connecting two existing Microsoft products – Exchange Server and Pocket Outlook. There’s no extra software to buy or install, and hence no additional servers required. That makes it sound like a bit of a no-brainer, since most alternative push email systems cost a fair bit and, as I just mentioned, they’ll all require their own dedicated server. Surely a zero-cost, zero-install solution is the way to go?

You’ll need to get SSL working, the first step being to create a Certificate Signing Request.

For some companies, it almost certainly will be, but it isn’t quite so simple as the Microsoft marketing machine would have you believe. For a start, your company needs to have deployed the correct version of Microsoft Exchange for it to work, namely Exchange Server 2003. Actually, you have to go one step further, because you’ll also need to have installed Service Pack 2 to get the Direct Push email system working. Prior to SP2, an alternative push email system was available, but frankly it was a bit of a hack (actually a huge hack), which relied on the mail server sending an SMS message to the mobile handset to say a new mail was available, whereupon the mobile would connect to retrieve it. It thus relied on the mobile phone networks’ email-to-SMS gateways. Of course, if you’re lucky, you might have splashed out on Exchange 2007, but there are relatively few early adopters out there yet.

There are several problems with this approach, the chief being that not all networks offer such a gateway and, even when they do, they’re notoriously unreliable. Another potential pitfall for SMS-based push solutions is that some networks charge 25c for each SMS sent via their gateways, which might sound reasonable for people only receiving a few messages per day, but what if a rogue script runs riot and sends you thousands of emails? Or, what if you annoy someone in a newsgroup and they mail-bomb you with hundreds of thousands? It isn’t just your mail server that would explode, but also your mobile phone bill.

Microsoft’s previous attempt at push email is therefore best avoided, but the latest incarnation is actually quite good. It doesn’t rely on SMS at all, the mobile and the server instead talking to each other via a standard HTTPS (port 443) connection. They can even talk using normal port 80 HTTP, although that isn’t something I’d encourage for obvious reasons of security, both encryption and authentication.

I mentioned that to get Direct Push running requires a specific software environment on your mail server, and the same is true of the handset, be it a PDA-style device or a smartphone. It needs to be running one of the connected flavours of Windows Mobile 5, but, in addition, it needs to have the Messaging and Security Feature Pack (MSFP) installed. This wasn’t included when Windows Mobile 5 first shipped, but has since been made available as an update. You’ll often find it described as an AKU 2 update and, unfortunately, it isn’t a simple install because you actually need to re-flash the ROM in your mobile device.

This seems to be a significant weakness of Windows Mobile 5 – most other mobile OS platforms allow core operating system components to be patched or replaced without performing the mobile equivalent of open-heart surgery. Windows Mobile demands a complete ROM upgrade, which means that every single handset variant requires its own special version of the AKU 2 update – and if the same hardware is sold under a different badge by different mobile networks then each will supply its own ROM upgrade. You’ve obviously got to be very careful to apply the correct update to your device or you could end up owning a shiny, expensive paperweight.

Luckily, any handsets manufactured within the past few months will probably have AKU 2 already installed, so this whole MSFP thing becomes less of an issue if you’re buying new kit. But for a company that already deploys a fleet of mobiles, getting them all upgraded to the correct version of Windows Mobile 5 can be a bit of a headache.

Assuming you’ve got the correct version of Exchange Server and that your mobile devices are all running AKU 2, how do you get this push email thing working? As I said above, it’s important to do all communication via SSL, so if you haven’t already done so you’ll need to install a secure server certificate into the copy of IIS on your Exchange Server (or your front-end server if you’re running a multi-server configuration). This is the normal process you’d go through in setting up any secure website: generate a certificate signing request (CSR); send it off to a certificate authority (CA); then install the returned certificate into IIS, making sure you enable port 443 (HTTPS) traffic in the properties of the default website. At this point, you should find that you have Outlook Web Access (OWA) running and be able to connect to it over HTTPS using a web browser.

The next step is to enable mobile access within Exchange Server. In the Exchange System Manager, go to Global Settings, right- click Mobile Services and select Properties. This will open up a dialog where you should check the box labelled “Enable User Initiated Synchronization”, which allows mobile devices to sync with Exchange Server. Don’t mess with the “Enable up-to-date notifications via SMTP and Text Messaging” checkbox – that’s the older SMS-based method, and for all the reasons mentioned above you really won’t want to use it. But do check the box for “Enable Direct Push over HTTP(S)”, as this is the magic spell you need to get the handheld and server talking.

You’ll need to switch on Direct Push, but you should probably leave the SMS-based push email method disabled.

You also need to update your users to allow them to use wireless synchronisation, so inside Active Directory Users and Computers find those users you want to have mobile access, and within the Exchange Features tab, under Mobile Services, enable “User Initiated Synchronization”.

At this point, you should probably also configure a minimum security policy for the mobile devices you’ll be allowing access to your Exchange Server infrastructure. You won’t get the vast number of security options you’d find with a BlackBerry setup, but there are some useful ones you really should set, like a minimum password length and an inactivity time-out. After all, you don’t want someone picking up a lost mobile and gaining access to your corporate mail system. To set them, fire up the Exchange System Manager and under Global Settings | Mobile Services | Properties click on Device Security, where you’ll see various options.

That’s about it for the server. Next, you’ll need to get the handheld talking to Exchange. Start ActiveSync on the device and select the menu option Add Server Source. If you’ve previously had a go at setting up a connection to Exchange Server, this will be Configure Server. Type in the address where the Exchange Server can be found (or an IP address if you prefer), your username, password and domain name, and then choose those items you want to be wirelessly synchronised. There are options available for Calendar and Email items, both of which are worth exploring – you’ll find their options pretty obvious. If everything has gone according to plan, you should now have emails appearing instantly on your mobile phone.

Most of the configuration tasks are done within Exchange System Manager, but this one is in Active Directory Users and Computers.

So with the somewhat tricky server setup all done, and the mobile configured to talk to Exchange Server, how does it perform in practice? I ditched my BlackBerry for a month and have been running only Direct Push on a Windows Mobile-based smartphone. I’d have to say that the user experience is nice enough, although there are certain things I miss from my BlackBerry. I kept holding down letter keys to get capitals, for example, but after a week or so I relearned to use the shift key.

One important security difference is that with Direct Push I needed to open an inbound port in my corporate firewall. Admittedly, this is only port 443 (and were I a serious user of OWA that port would already be open), but it did feel a little strange having to do this, since with a BlackBerry your only connection is outbound. Running cost is always an important consideration, and I found that where my BlackBerry had typically been consuming around 5 or 6MB per month (I’m a really heavy email user), with Direct Push this jumped to more than 25MB. I was quite shocked at this difference, but I guess that if you’re on an “all you can eat” plan it won’t be a problem. Besides, Direct Push allows you to use any ordinary data plan, whereas with a BlackBerry you’ll typically have to pay your mobile provider extra per month for access to the special BlackBerry APNs and the BlackBerry Network Operations Center.

In an enterprise environment, one of the most important considerations is platform stability and, to be honest, that isn’t something you ever think about if you run a BlackBerry. That’s not the case with Windows Mobile, though, and I found myself having to reset the device a couple of times each week. Sometimes it would lock up, other times it would simply lose all contact with the Exchange Server, but a swift poke up the reset hole would generally sort it out. The Microsoft platform also has serious weaknesses when it comes to stuff like security policies: with a BlackBerry setup, for example, you can disable the card slot on the mobile, disable the mobile web browser, change the homepage and lots of other things. Policy support with Windows Mobile is nowhere near as thorough.

Security policy support is rudimentary, but still worth setting up.

I did like the fact that with Direct Push I had complete access to my mailbox, whereas with BlackBerry it will only show me recent emails, and the way that Direct Push handles folders is much better and more intuitive too. Overall, I was impressed with Direct Push – not impressed enough to move my own day-to-day usage away from BlackBerry, but impressed enough to recommend it to companies with fairly limited budgets.