I blogged back in April this year on what you might consider taking into account when choosing a remote email solution. It goes to show how quickly things move in this space that I already feel the need to revise the comments I made in that post: for example I cited the three major players in the space to be Microsoft, RIM and Nokia – Nokia recently effectively declared its withdrawal from this space when they announced that they would no longer be developing the Intellisync Mobile Suite platform, instead throwing their lot in with Microsoft and the Server ActiveSync protocol.

I also cited that one of the major criteria any potential solution would need to fulfil was the ability of the solution to sit “behind the firewall”, whereas the prevalence of cost-efficient, hosted Exchange and BES services combined with the myriad of access methods to Exchange as well as the much wider range of supported client devices mean that this is no longer necessarily even a consideration.

Updates have also been released for the Blackberry platform, both for the server products and the handhelds.

Therefore, in this post I will summarise the remote email market as I see it today, the mobility features provided by the major vendors as well as the pros and cons of those solutions.

Much of what I wrote in my last post on this subject does still hold true, however, when choosing a remote email solution:

·         All communication between the client device and the email server should be secure

·         The solution should not tie you into a particular client platform or device, nor a particular mobile network operator – the solution should be agnostic of the client device type as well as the means of connecting to the Internet

·         Users should have the ability to read, forward and edit email attachments

·         Users should have the ability to access the Global Address List of corporate contact list

·         Users should have the ability to choose whether or not to download full email messages and attachments

·         The solution should ideally use the native PIM application on the client device to minimise the need for additional staff training, unless the alternative client offers superior features

·         The solution should offer “push” functionality so that devices are updated “in real time”, as opposed to schedule-based synchronisation or SMS “wake-up” messages

·         The solution should offer the ability to remotely “wipe” client devices and enforce password usage on those devices

·         The solution should not rely on “Desktop Redirectors” – applications which sit on a PC on the local network, monitoring the mail server for changes in the user’s mailbox and redirecting them when they are detected. These solutions require that a PC remain switched on in the office at all times, defeating the object of having a “remote” email solution

·         The solution should be available abroad

The key players in the mobile email space currently, in my opinion, are Microsoft, Research In Motion (RIM) and IBM.

Microsoft

Microsoft added push functionality to Exchange with the release of Service Pack 2 for Exchange 2003, a free download available via Microsoft Update, and AKU-2 for Windows Mobile 5, a free update available from the manufacturer of the Windows Mobile device in the form of a ROM update.

Remote synchronisation with Exchange from a Windows Mobile device had been available since 2000 with the release of the Microsoft Mobile Information Server (MMIS), requiring that a middleware server be deployed alongside the Exchange server. This functionality was incorporated into the initial release of Exchange 2003 and allowed users of Windows Mobile 2003 to synchronise manually, or on a schedule.

Service Pack 2 for Exchange 2003 added push functionality, meaning that supported Windows Mobile 5 devices could be updated in real time with no user interaction required, provided that they had a cellular connection to the Internet.

This functionality was expanded with the release of Exchange 2007, and yet again with Service Pack 1 for Exchange 2007 and the release of Windows Mobile 6.1.

Today, if using a Windows Mobile device running version 6.1 of the operating system in conjunction with a Microsoft Exchange 2007 server with Service Pack 1 installed, the following functionality is available to the user:

·         Full mailbox synchronisation, including Contacts, Calendar, Tasks, Mail (including all subfolders within the user’s mailbox on a per-folder selection basis)

·         A maximum message size and attachment size limit can be specified

·         A date range can be specified during which mail and calendar items will be synchronised

·         A schedule can be defined during which mailbox changes will be ‘pushed’ to the device, outside of which synchronisation can be initiated manually

·         When composing a new mail from the device, the user can select contacts from their own Contacts folder, or from the Global Address List

·         Users can also search their entire mailbox for a specific mail based on certain criteria should they have lost track of it

·         Users can set and edit their Out Of Office status from the client device

The following functionality is available to the administrator:

Individual Server ActiveSync policies can be defined on a per-user basis:

A Server ActiveSync mailbox policy can define whether ‘non-provisionable’ devices are supported (ie, devices other than those running the Windows Mobile operating system)

A policy can be defined requiring that client devices have a password set on them:

Message size and attachment size limits can be defined:

A policy can be defined controlling what hardware elements on the client device are available to the user:

Software functionality on the device can also be controlled from the server:

These include:

• Allow Browser – defines whether Internet Explorer can be opened
• Allow Consumer Mail – defines whether users can create POP or IMAP accounts
• Allow unsigned applications – defines whether users can run programs that have not been signed with a certificate trusted by the Windows Mobile operating system
• Allow unsigned installation packages – defines whether the user can install applications that have not been signed with a certificate trusted by the operating system

The administrator can also expressly allow or block specific applications from the server.

Both the user and the administrator can remotely ‘kill’ a device from the Exchange server. The administrator can do so via the Exchange Management Console:

The user can do via Exchange Outlook Web Access from any web browser:

Exchange 2003 SP2 also offers the ability to remotely wipe client devices, but requires that the Server ActiveSync Web Administration Tool be downloaded and installed:

http://www.microsoft.com/downloads/details.aspx?FamilyID=e6851d23-d145-4dbf-a2cc-e0b4c6301453&displaylang=en

And is accessed via https://<exchange_server>/mobileadmin/:

Exchange 2003 SP2 does not offer the ability to define a per-user activesync policy, or the ability to remotely control hardware or software elements on client devices. I have summarised the abilities of the different platforms at the end of this post.

Installation

There is no need to install any additional software onto any Windows Mobile 2003 or later device to enable it to synchronise with an Exchange 2003 SP2 or later server, the necessary client software already being part of the client operating system.

The setup procedure consists of simply entering the external (ie Internet-facing) name of the Exchange server (if you are unsure what name to use, it is the same address used by Outlook Web Access, normally in the form https://mail.domain.com

(there is no need to add the “/exchange” portion of the OWA address)

Thanks to Microsoft’s masterstroke decision to license the Server ActiveSync protocol to other device manufacturers, varying degrees of the above functionality is also available on other client platforms:

Nokia

http://www.hughsymonstelecom.co.uk/Files/nokia/e71_017.jpg

Nokia’s Mail For Exchange application is a free download for the Symbian Series 60 platform (at the time of writing the Nokia E and N series range of devices), available here:

http://www.businesssoftware.nokia.com/mail_for_exchange_downloads.php

Currently the Mail For Exchange application offers limited functionality – it does not provide the ability to synchronise subfolders of the user’s mailbox, but it does provide a contact search option.

I have blogged on the Mail For Exchange client here:

http://blog.devicewire.com/blogs/devicewire/archive/2008/08/22/setting-up-the-nokia-e71-for-microsoft-exchange-push-email.aspx

Apple iPhone

http://www.hughsymonstelecom.co.uk/Files/iphone/iphone009.jpg 

The iPhone has been enormously successful. It does have limitations: it does not have MMS capability, the ability to synchronise with Exchange is also reduced, but it is clear from the success of the device that all of this is less important to many users than the sheer usability of the device – the quality of the screen on the device and the ability to truly experience mobile web browsing mean that users are willing to overlook its other limitations.

Version 2.0 of the iPhone software includes a licensed version of the Sever ActiveSync  protocol enabling push-based synchronisation with Microsoft Exchange.

Whilst subfolder synchronisation is supported, it is not possible to move mails between folders. Neither is Task synchronisation supported.

I have blogged about the iPhone’s capabilities here:

http://blog.devicewire.com/blogs/devicewire/archive/2008/07/14/using-the-apple-iphone-with-microsoft-exchange.aspx

DataViz RoadSync

DataViz was one of the very first companies to license the Server ActiveSync protocol from Microsoft and have developed their own client for devices that do not inherently support direct synchronisation with Exchange. This includes Windows Mobile 2003, Symbian Series 80 (Nokia Communicator 9300 and 9500, for example) and Java MIDP 2.0 devices. There is also a RoadSync client available for devices that do support Server ActiveSync, but which provides greater functionality. For example the RoadSync client for the Nokia E series provides the ability to synchronise subfolders, which the Nokia Mail For Exchange does not currently.

I have blogged about the RoadSync client here:

http://blog.devicewire.com/blogs/devicewire/archive/2008/10/11/dataviz-roadsync.aspx

Outlook

It is also important to note that Exchange does not only offer mobility options for PDA-style devices: Outlook Anywhere technology (or RPC over HTTP to give it its proper name) enables an Outlook 2003 or later client to connect to an Exchange server securely via any Internet connection and provide the same functionality to the user as if they were connected locally via the LAN. I have blogged about this here:

http://blog.devicewire.com/blogs/devicewire/archive/2008/09/27/microsoft-small-business-server-2008-part-1.aspx

http://blog.devicewire.com/blogs/devicewire/archive/2008/09/28/configuring-outlook-anywhere-access-to-sbs2008.aspx 

http://blog.devicewire.com/blogs/devicewire/archive/2008/10/10/enabling-rpc-over-https-on-a-single-exchange-2003-server.aspx

Architecture

To enable Server ActiveSync functionality, the Exchange Server must be available from the Internet – that is to say it requires a public, or “routable” IP address.

Client-Server communications are secured by 128-bit SSL encryption. If the Exchange Server has a “self-issued” (or non root-trusted) certificate installed on it, then the root certificate of the certifying authority used needs to be installed on the client device, no matter what platform it is running, and the certificate needs to be configured correctly in terms of the naming convention used, I have blogged about this procedure in depth in the Devicewire Forum:

http://forum.devicewire.com/forums/thread/176.aspx

http://blog.devicewire.com/blogs/devicewire/archive/2008/09/27/microsoft-small-business-server-2008-part-1.aspx

Regardless of the platform used, all client devices using the Server ActiveSync protocol can be hard reset from the Exchange server.

I stated above that in order to enjoy “push” functionality from the Exchange server, the client device must have a cellular connection to the Internet. Whilst almost all PDAs these days can connect to the Internet via WiFi, or can share a connected PC’s link, when connected in this way Server ActiveSync will only synchronise on a schedule.

This is because Server ActiveSync is not a true push-based technology. Rather the client will poll the Exchange server on a pre-defined interval of approximately 30 seconds or so. This internal is known as the ‘heartbeat’ interval and is defined by the cellular operator and communicated to the device when it first connects to the GPRS / 3G network. If the client is not able to determine this heartbeat interval (ie it is not connecting via a cellular network) then it will revert to a default synchronisation schedule.

Blackberry

The Blackberry solution is developed by a Canadian company, Research In Motion (RIM), and is largely regarded as the de facto standard for the remote email industry.

The Blackberry solution supports not only Microsoft Exchange, but also IBM Lotus Domino as well as Novell Groupwise.

The Blackberry solution can only be used with Blackberry client devices, or on a limited basis with devices running the licensed Blackberry Connect software, available for both the Windows Mobile and Symbian platforms, and requires that a middleware server be deployed alongside the mail server: the Blackberry Enterprise Server, or BES.

At the time of writing, the current BES software release is 4.1.6, with version 5.0 waiting in the wings. If using the latest BES software in conjunction with a handset running the latest device software version (currently 4.5), the following functionality is available to the user:

·         Full mailbox synchronisation, including Contacts, Calendar, Tasks, Mail (including all subfolders within the user’s mailbox on a per-folder selection basis)

·         A maximum message size and attachment size limit can be specified

·         A date range can be specified during which mail and calendar items will be synchronised

·         A schedule can be defined during which mailbox changes will be ‘pushed’ to the device, outside of which synchronisation can be initiated manually

·         When composing a new mail from the device, the user can select contacts from their own Contacts folder, or from the Global Address List

·         Users can also search their entire mailbox for a specific mail based on certain criteria should they have lost track of it

·         Users can set and edit their Out Of Office status from the client device

Should users wish to edit some of the above settings, they will need to do so via a web site, the Blackberry Web Desktop Manager, which is an optional component that needs to be installed on the BES by the administrator. Otherwise, all administration of the handheld devices is done by the administrator on the BES via the ‘IT Policy’.

Release 4.1.6 of the BES server brought with it the ability to view emails in native HTML format, whereas before Blackberry handhelds would convert all messages to plain text – not always useful if someone has sent you table or column-based text.

Because both the server software and the client operating system is developed in-house by RIM, the Blackberry solution offers the administrator complete control over all aspects of the device’s functionality, from disabling the camera, WiFi or SMS capability all the way down to specifying the types of links that can be accessed within the device’s browser:

IT Policies can be defined on a per-user, or per-group basis.

A password policy can be defined on the handheld, and devices can also be remotely ‘killed’ from the server:

And a delay can be specified of up to 60 minutes should you not want to kill the handheld immediately (say, a user thinks they might have lost their device but they want to go home first to check it isn’t by the bed). Queued kill commands can also be cancelled.

The type of email attachments that can be received by the device can also be defined on the server:

Installation

The BES software is not complicated to install, but it does require that specific permissions be configured on the Exchange server before it will work properly, and it is here that some people come across problems – especially as Microsoft released a hotfix for Exchange 2003 that stopped the default BES deployment from working not so long ago. You can find detailed information on installing BES for both Exchange 2003 and 2007 in the Devicewire Forum:

http://forum.devicewire.com/forums/102/ShowForum.aspx

The BES also requires that a separate server be purchased, as well as a Microsoft Windows Server license. For larger installations (say, over 500 users), then it is recommended that a Microsoft SQL Database be used, which will obviously need to be licensed. By default, the installation wizard will install a local copy of the Microsoft SQL Desktop Engine (MSDE) which is fine for smaller installations.

In addition to the BES software, RIM have also released the Blackberry Professional Software (BPS), formerly known as the “BES Express”, which, provided that you have a valid device PIN number, can be downloaded free of charge from the Blackberry web site and allows you to use a single device. BPS can be installed on the Exchange server itself without the need for a separate server.

Architecture

Unlike Exchange, the BES does not need a public IP address. It does need to have a connection to the Internet, but does not need to be available from the outside world and no inbound firewall ports to be opened. This is a major boon for IT administrators for whom security is a primary concern.

The BES solution is able to accomplish this by virtue of the fact that RIM has deployed a number of “RIM Relays” throughout the globe, acting as proxy servers to manage the exchange of data between BES servers and the handheld devices.

When a handheld device is powered on, it registers with the Relay using a unique PIN number. The BES also registers with the Relay using a unique identifier, known as an SRP key. Data is then sent between the server and handheld device via the Relay.

This does of course mean that you are utterly dependent on the RIM Relay infrastructure being available, and there have been incidents in the US (Europe was not affected) where they have experienced outages, sometimes of up to whole days in length.

Blackberry devices do require a cellular connection to connect – although newer handhelds do have WiFi capability, this is only for Internet access or for connectivity to the BES locally via the LAN. This approach does mean, however, that Blackberry is true IP push, one of the few solutions that can claim to be.

The BES server requires a connection to the RIM Relay on TCP port 3101, and all client-server communications are encrypted using 256-bit AES encryption.

Blackberry handhelds can be configured to route all web browsing traffic through the BES server, meaning that any access policies defined on the LAN (either via DNS or firewall restrictions) are automatically applied also to the handhelds.

One of the USPs for the Blackberry solution is the way in which client devices can be setup up by the user without the need for complicated server information being entered on the device. This is known as the ‘Enterprise Activation’ process, and requires that the user simply enter their own email address, and a password that can be given to the user over the phone, via email to their desktop, etc.

The handheld then sends a special command message to the email address entered, which is detected automatically by the BES server and the link between the handheld and the user’s mailbox is established automatically.

I have blogged in detail about this process here:

http://blog.devicewire.com/blogs/devicewire/archive/2008/05/31/how-does-the-blackberry-enterprise-activation-process-work.aspx

IBM

Lotus Domino has significant adoption as a messaging and collaboration platform in the Enterprise. I did not include IBM specifically in the last post as at the time there was no means of synchronising with a Domino server from a client device without employing a middleware product, like Blackberry or Nokia Intellisync. Blackberry can still be used alongside Domino, but with the release of version 8.0.1 of the Domino product IBM have included the Lotus Notes Traveler functionality, which enables remote synchronisation of mail, contacts, calendar and tasks data with a Windows Mobile PDA.

I admit that that is pretty much all I know about the solution so far, not being a Domino guru, but I have downloaded a trial version of the software so expect another blog post soon!

Summary

I have distilled the above information into a feature comparison chart, which lists the different mobile platforms as well as the functionality available with the different server products.

I have included the Symbian Series 40 platform as, whilst no means exists that I know of currently to synchronise directly (or indirectly) with Exchange (other than setting it up as a POP or IMAP connection), I believe Nokia will expand their Mail For Exchange client to this platform in the near future.