Business users have come to rely
on having access to email anywhere and anytime. Exchange
Server 2003 has long provided features
to support mobile email users, including an Always Up-To-Date (AUTD)
capability, which works in tandem with
Exchange ActiveSync (EAS) to automatically synchronize a wireless
mobile device to an Exchange user's
mailbox data. New features in Exchange
2003 Service Pack 2 (SP2) significantly
enhanced Exchange's mobility functionality, particularly in the areas of
security and synchronization through
Direct Push technology. (For a look at
another new mobility feature in
Exchange 2003 SP2, see "Exchange
2003 SP2's GAL Lookup Feature.") We'll explore how EAS, AUTD, and
Direct Push technology work to push
email from an Exchange server to a
mobile device while conserving band-
width and minimizing wireless data
charges.
EAS: The Basis for Direct Push
EAS has been part of Exchange 2003
since the original Exchange 2003
release to manufacturing (RTM). EAS
is a synchronization protocol based
on HTTP and XML that's optimized to
deal with high-latency and low-bandwidth networks as well as low-capacity clients (i.e., clients that have low
memory, storage, and CPU). Among
the benefits of EAS are that it works
with the four main data types (contacts, tasks, email, calendar; is built into
Exchange; doesn't require software installed on the desktop PC; and provides
a familiar setup process through
Exchange System Manager (ESM).
Other useful features in EAS include
options for filtering, truncation, smart
reply, and forwarding. These features
are all designed to save bandwidth for
the mobile device because they let
you allow only a certain amount of
email to be downloaded (e.g., 3K, 5K,
headers only). The smart reply and
forwarding features prevent the
device from having to download an
entire message just to reply to it.
Instead, you add your reply content
on the device, then as the mail passes
through the email server, Exchange
adds the rest of the original message
to the reply, again saving bandwidth.
EAS also allows attachment blocking
with the option to allow downloading
of attachments on request. (I recommend choosing this option because it
avoids the problem of a large attachment swamping your connection.)
EAS Architecture
EAS's basic architecture hasn't
changed much since Exchange 2000
Server and Microsoft Mobile Information Server (MIS) 2002, which provided synchronization between
Exchange 2000 and devices running Pocket PC 2002. Figure 1 shows a typical EAS configuration. You can see that EAS uses the
standard Exchange infrastructure
that an organization has in place,
which means that EAS can integrate easily with existing systems.
EAS can use an existing firewall; to
enable it to do so, you simply need
open either port 80 or, if you're
using Secure Sockets Layer (SSL),
which Microsoft recommends, port
443. Also note the simplicity of the
configuration, which requires no
additional components other than
the mobile device.
Now let's look at how EAS works
under the covers. When you initiate a
connection to the server from your
mobile device, the traffic from the
device will arrive at your firewall. As
long as you've set up port forwarding
for standard firewalls or, if you're using
Internet Security and Acceleration
Server (ISA Server), the traffic will be
passed through to your front-end
Exchange server, creating a TCP connection. The device then talks to the
Microsoft IIS virtual directory Microsoft-Server-ActiveSync. The functions
of the Microsoft-Server-ActiveSync
directory are implemented by an
Internet Server API (ISAPI) filter that
controls the connection. The user is
then authenticated, and Exchange initiates a query via the DSAccess service
to find the user properties in Active
Directory (AD) and determine
whether the user is allowed to use
EAS. If so, the front-end Exchange
server locates the back-end Exchange
server, which holds the user's mailbox.
At this point, EAS passes the connection to the back-end server, but instead
of passing the connection to the
Microsoft-Server-ActiveSync virtual
directory on the back-end server,
makes the connection to the Exchange
virtual directory on the back-end
server. You can see how in this process
EAS uses the Microsoft Outlook Web
Access (OWA) architecture and WWW
Distributed Authoring and Versioning
(WebDAV) commands already in
Exchange to connect a mobile device
to Exchange.
This redirection and use of OWA
brings up a couple of issues. First, for
EAS to work you must set up authentication correctly, with basic authentication at the front-end Exchange
server and Integrated Windows authentication on the back-end/Exchange
virtual directory. Second, because of
the need for basic authentication on
the front-end server, SSL is highly recommended. To clarify, if you're passing traffic directly through your
firewall to your front-end server, the
SSL certificate should be installed on
the front-end server as a regular Web
certificate. If you're using ISA to publish EAS, you need to ensure that the
certificate is installed on the front-end
server as before but is also available
on the ISA server, so that it can be
used during the Web listener setup.
The use of SSL to secure the connection from the mobile device to the
front-end server creates its own set of
conditions. First, you can use only certificates that specify the host name;
wildcard certificates aren't supported.
Most importantly, the device must
trust the SSL certificate's issuer, otherwise synchronization won't work.
You'll need to either use a certificate
from a trusted Certificate Authority
(CA), such as CyberTrust, Entrust,
thawte, or VeriSign, or you must
import your own private CA's root certificate to every device. (For a full list
of root CAs trusted by Window Mobile 5.0 devices using the Windows Mobile 5.0 Messaging and Security Feature
Pack—MSFP—see the table at https://partner.microsoft.com/global/partner/40027352.) Should you choose to use
your own CA, getting a root certificate
onto a device can be problematic,
since networks often lock devices at
the application level to prevent software from being installed. Prior to the
release of the MSFP, you could add a
root certificate to a device. But with
the MSFP, doing so has become
almost impossible, unless your
mobile service provider provides a
signed application to do this for you,
such as Orange in the UK. In the end,
this limitation might influence your
device purchase, or you might simply
choose to use an already trusted CA.
How Direct Push Works
Before Exchange 2003 SP2, you had
two choices for synchronizing a
mobile device with a mailbox: You
could manually configure EAS on the
mobile device to issue synchronization on a scheduled basis, or you
could use Exchange's AUTD technology. With AUTD, the Exchange server
sends an email message to an SMTP-to-Short Message Service (SMS) gate-
way, which then sends an SMS
message to the device to tell it to initiate synchronization. The problem
with scheduled synchronizations is
that you can't schedule them for intervals of less than five minutes, which
means you won't always have the latest information on your device.
Another problem is that, especially if
your mobile operator is outside of
North America, you'll be charged each
time a new session is established—which occurs each time new data
travels over the wire.
The idea behind AUTD is good, but
the technology hasn't worked well in
reality, at least not in Europe where
few mobile operators provide the necessary SMTP/SMS gateway that AUTD
requires. Microsoft IT became aware
of this problem when it deployed Exchange 2003–based mobile messaging
in the worldwide Microsoft organization, which prompted it to rectify the
problem in Exchange 2003 SP2's Direct
Push technology. DirectPush (aka AUTD
v2) is an IP-based synchronization technology and provides these benefits:
- A standard data plan is the only subscription you need to synchronize
with Exchange (which must work
globally).
- You don't need to deploy additional
infrastructure in your Exchange
environment.
- Direct Push doesn't require SMS
notification.
- You don't need to perform any special configuration on a mobile
device to use Direct Push.
To use Direct Push, you need a device
that supports Windows Mobile 5.0
with the MSFP installed. (For a list of
Windows Mobile 5.0–enabled devices,
see Jason Langridge's blog at http://blogs.msdn.com/jasonlan/default.aspx.)
It's important to note that,
although the DirectPush feature is
enabled by default in mobile devices
that have the MSFP installed, mobile
devices that don't have the MSFP installed can still perform synchronizations by using either the manual or
scheduled methods or via AUTD. This
will no longer be the case in Exchange
Server 2007, which will no longer
include the original AUTD SMS-based
functionality, only DirectPush. Once
you've upgraded to Exchange 2003
SP2, a handy feature lets a device that
previously used the old AUTD sync
automatically switch over to using
Direct Push after the upgrade.