Wireless PDA Access to Exchange

Know your options

Email has become a tool that users expect to have at hand no matter where they are—hence the proliferation of PDAs. Providing users with wireless access so that they can use these handheld devices to access email on the go is fast becoming a necessity. But the variety of access options, not to mention the plethora of PDA devices, can complicate the process of choosing the right solution. You need to understand the available methods of providing a wireless connection, and you need to talk with users and determine exactly how they need to manipulate email on their PDAs. Then, keeping security in mind, you can evaluate the available implementations and decide which solution will work best for your users—and for you.

Connection Options
To connect a PDA to an Exchange mailbox, you have a choice of three methods. I refer to these methods as synchronization, connection-oriented client/server, and agent-based instant messaging.

Synchronization. Synchronization copies Exchange mailbox items to and from the PDA, which the user then can use to manipulate email offline. This process is similar to having users use Outlook and an offline store (OST) to access their mailbox content when they aren't connected to the network. Software that's sometimes called a conduit translates and copies mailbox contents to and from the PDA. Because users can access mailbox changes that occur after a synchronization session only at the next synchronization, this method gives users only a snapshot-in-time view of their email messages. Synchronization is available out of the box for almost all PDA devices that use a cable connected to a serial or USB port; you can also set synchronization to occur over a wireless (or wired) connection through a modem or NIC if the PDA supports these devices.

Out of the box, conduit software runs on the user's PC, but some solutions let you set up centralized synchronization servers on your network. (These solutions are generally specific to a particular brand of PDA.) The synchronization servers perform the same function as the PC-based synchronization conduits, but the conduit software runs on the server. Synchronization servers provide better security than individually installed PC-based conduits do. The servers give your IT group more control over email management, back up PDA-side content to a central location, and eliminate the need for users to leave their PCs logged on to support a desktop-based modem or LAN synchronization connection.

Connection-oriented client/server. The connection-oriented client/server method uses PDA-side software—sometimes in combination with a gateway server—to turn a PDA into an email client that directly manipulates an Exchange mailbox. This client can be as generic as a browser or can be a specialized solution that uses Exchange-supported Internet protocols such as POP or IMAP. This type of solution might also provide enhancements, such as compressed transmission or encryption.

I call this method "connection-oriented" because these solutions require users to initiate and maintain a connection to the network from the PDA while manipulating their mailboxes. A user can use the PDA's wireless (or wired) modem to dial into a RAS server or ISP, then use that connection as a transport to reach the corporate Exchange server. Depending on the solution, connection-oriented access can take place over a full- or part-time connection—similar to using RAS to connect a home PC or laptop as a node on the corporate LAN. Depending on the PDA's client-side capabilities, users might be able to retrieve items, then read and compose email offline. Browser-based solutions let users access mailbox, calendar, and public-folder items, but only while the PDA is connected to the server.

Agent-based instant messaging. Agent-based instant messaging necessitates a full-time wireless connection for the PDA. This solution typically involves four parts: an agent service, a PDA client, a messenger server, and the Exchange server. An agent service is software that runs on a PC or server on the corporate LAN and that acts as a proxy for the mailbox owner. The agent monitors a user's Exchange mailbox and lets the user manipulate the mailbox as if he or she were directly accessing it. A client component runs on the PDA; users employ the PDA client to read and compose email. The PDA client is always connected as a node on a wireless network (e.g., a device-specific network, a wireless ISP, a corporate wireless LAN—WLAN) but never connects directly to the Exchange server. Instead, the client communicates only with a messenger server, which also has access to the wireless network. This server accepts messages from and pushes messages to the handheld device. The agent service communicates with the messenger server over the wireless network, and the two act as intermediaries between the PDA and the Exchange server.

As the user's Exchange mailbox receives new messages, the agent service sends a copy of the messages over the wireless network to the messenger server. The messenger server transmits the messages to the PDA. When the user sends a message from the PDA, the message goes to the messenger server, which passes it to the agent service. The agent accesses the mailbox to send the message to the recipients. From a recipient's point of view, such messages look as though they originated directly from the user's mailbox. Because the PDA uses a full-time wireless connection, users don't need to manually establish a connection and receive messages from the agent service; messages are received as soon as the messenger server transmits them.

Get the Details
To determine which solution to use, you need answers to the following questions: What, which, when, and where? What PDAs are users employing, and for exactly which purposes do they plan to use the devices? When and where do users need to use their PDAs?

What and which. You probably know that most people want to use a PDA to access email, but you need to understand exactly how people want to manipulate that email. Are users going to send and receive text messages only, or do they also need to send and receive attachments? Most solutions that let users read email on a PDA don't initially pull the entire message from the user's mailbox. These solutions usually copy only the first 2000 to 8000 characters of the message. This setup can be problematic for a couple of reasons. First, what happens when users have no way to retrieve the rest of an important message that's longer than the set number of characters? Second, what if users want to forward the message to someone else? You need to be sure that the solution can incorporate the remaining content into the forwarded message.

If attachments are important, which types of attachments do users expect to encounter, and what will they need to do with them? Attachment support varies among devices. Some solutions let users view, but not edit or compose, attachments. Some solutions support attachments but discard all formatting and show only raw text. Others insert a text tag to show the user that the message has an attachment but won't let the user open or access the attachment from the handheld device. You also need to determine the level of directory support each solution provides. For some users, access to the Personal Address Book (PAB) is sufficient; for others, access to the Global Address List (GAL) is a must. (For information about some solutions that can give users enhanced address-list and attachment capabilities, see the Web sidebar "Filling in the Gaps," http://www.exchangeadmin.com, InstantDoc ID 24853.)

Although users' primary concern is probably email, most people will want to use their PDA for a variety of tasks, and some solutions limit your device and software choices. After you determine the functionality that users need on their PDAs, you can determine the types of devices you must support. For example, if opening Microsoft Word documents in color or listening to audio attachments is essential for users, a device such as Compaq's iPAQ or Hewlett-Packard's HP Jornada is a must.

When and where. Next, you need to determine when and where people plan to use their PDA. The answers to these questions will help you decide which level of connectivity you must support. For users who don't need anywhere/anytime connectivity, a simple synchronization solution using a PC-connected cradle might be sufficient. In most cases, however, providing some level of wireless access offers productivity gains and higher user satisfaction.

If users need constant access only while in a specific building or on a specific campus and the building or campus has a wireless infrastructure, you simply need to provide WLAN cards for the PDAs. If users need more far-reaching access, you need to explore a solution that works with a wireless ISP or uses a commercial wireless network. In that case, you also need to consider level-of-service issues, such as exactly where wireless services are available and what type of bandwidth users can expect. Most major metropolitan areas have good wireless coverage, whereas most rural locations don't. If your company does business internationally, you need to evaluate the wireless options in other parts of the world. Solutions that depend on access to an ISP through a cellular infrastructure will probably work internationally, but solutions that use specialized networks probably won't.

Even in metropolitan areas that have excellent wireless coverage, signal strength can be unpredictable inside buildings, and service can drop off or become spotty a short distance beyond city limits. Many wireless-service providers have coverage maps on their Web sites so that you can get some idea of the available coverage. Getting an idea of the signal strength inside a building is more difficult. If the user works in the building's core or basement computer center, for example, a signal might be nonexistent. Conduct a survey of signal strength in key areas (e.g., frequently used airports, users' homes, your 18-story office complex's conference rooms) before you deploy a wireless solution in your production environment. Consider which capabilities a particular solution can provide when wireless service is unavailable because of a weak signal, lack of coverage, or a network failure. A solution that doesn't let users read and compose messages offline definitely won't boost productivity.

Implementation Options and Security
After you answer what, which, when, and where, you have a final question: How? You need to understand how the available solutions provide access to users' Exchange mailboxes and what measures the solutions implement to secure your systems and data. You should examine three "security zones" to determine the security of data stored on the PDA, the security of the wireless data transmission, and the security of access to your Exchange server.

Figure 1 shows the boundaries of these three zones and illustrates the three general implementation models—simple client access, gateway/agent server, gateway/agent server with VPN—that various devices use. The solutions that I'm familiar with use a protocol such as Messaging API (MAPI) or IMAP in Zone 3 to access the user's Exchange mailbox; such solutions work with both Exchange 2000 Server and Exchange Server 5.5. Because Zone-3 access uses an Exchange-supported protocol, the security of Zone-3 communications depends on that protocol. For example, a solution that uses IMAP passes communications (including any authentication) in clear text, whereas a solution that uses MAPI has the same level of security as a connection to Exchange through a desktop implementation of Outlook.

Simple client access. Model A in Figure 1 shows simple client access to Exchange. An example of a solution that uses this model is a POP or IMAP client that connects directly to the Exchange server through the PDA's wireless Internet connection. The advantage of this configuration is that you can implement it with a minimal number of components. Depending on the implementation, however, this model can also have a significant disadvantage: Most PDA-based POP and IMAP clients don't implement Secure Sockets Layer (SSL) to secure transmissions between the PDA and the Exchange server, so passwords and data are passed in clear text. Even if you use an SSL-capable client, wireless connections usually have limited bandwidth—generally between 9.6Kbps and 19.2Kbps—so SSL might not be viable because of the added overhead that encryption introduces.

Gateway/agent server. Model B in Figure 1 shows a gateway or agent server that acts as an interface between the PDA and the Exchange server. Examples of solutions that use this type of model include ThinAirApps' ThinAir Server with Groupware Access and Research In Motion's (RIM's) BlackBerry.

ThinAirApps' solution is geared toward Palm OS­compatible devices and uses the connection-oriented client/server method of wireless access to Exchange. After a user establishes a wireless connection to the Internet, the PDA connects to the ThinAir Groupware Access server. This server uses MAPI to access the user's mailbox in much the same way that Exchange 5.5's Outlook Web Access (OWA) does. Users of Palm OS devices can load a ThinAir PDA client that offers enhanced functionality, such as the ability to use a PDA-based address book. However, non­Palm OS devices must use a more limited Web-browser interface.

The RIM solution, which uses the proprietary BlackBerry handheld device, implements the agent-based instant messaging access method. The BlackBerry handheld contains a wireless radio transceiver that uses cellular-packet radio networks. Because these networks were designed to support wireless data communications, devices that use these networks are always connected.

As Figure 2 shows, the BlackBerry communicates with a RIM-hosted server; a BlackBerry agent server (on which you install the BlackBerry agent service) communicates with the Exchange server. The agent server establishes one outbound connection through your firewall to the RIM server. After it's established, this connection is maintained as long as the agent service is running and supports communications in both directions for all BlackBerry devices for which the agent server is responsible. Unlike gateway servers, which work through inbound connections from handheld devices, the BlackBerry agent server only initiates outbound connections. Because the agent server doesn't accept inbound connections, securing this solution is easier. (Gateway solutions that use inbound connections can be secure, but the RIM solution is unique in that it doesn't require your firewall to accept inbound connections. You can control a connection from the inside, and you know exactly where the connection is going.)

Aside from considering how solutions that use the gateway model establish communications and which systems the messages pass through, you must consider what an intruder can see as messages move across the communications networks and systems. Both the ThinAirApps and RIM solutions offer end-to-end encrypted communication between the gateway or agent server and the handheld device.

The method that the ThinAirApps solution uses depends on the type of PDA: When a non-Palm device connects, the ThinAir gateway uses SSL to ensure secure client communications (assuming the handheld supports SSL). When a Palm OS device connects to the Groupware Access agent server through the ThinAir client, the client uses Certicom's elliptical curve cryptography (ECC) to generate a security key between the device and the agent server. This type of encryption works the same way as an SSL session but is better suited for use with less powerful computing devices (e.g., PDAs) and lower-bandwidth connections.

The RIM solution uses triple DES (3DES) encryption with a security key that's specific to each BlackBerry device. Desktop software generates a security key from random mouse movements; this software regenerates the key about once a month when the device is in its PC-connected cradle. One copy of the key resides on the Exchange server, and another resides in the BlackBerry's memory. When the agent service or the handheld sends a message, the 3DES key is used to encrypt the message. This system ensures that the BlackBerry and the agent are the only two points in the network that can decrypt the message.

Gateway/agent server with VPN. Model C in Figure 1 shows a gateway or agent server that provides access to the Exchange server similarly to Model B's method. However, this access occurs after the establishment of a wireless VPN session. When users want to access their Exchange mailbox, a connection client (PDA client software) establishes a secure communications channel from the handheld to the wireless VPN server. Users then employ an email client to connect to the gateway server. An example of this implementation is Infowave's Wireless Business Engine and add-on Exchange Connector, which implements the connection-oriented client/server wireless-access method. Wireless Business Engine provides the wireless VPN services, and the Exchange Connector is the gateway to the user's mailbox.

Two significant features of the Infowave solution are data compression and transmission optimization. Not only does Wireless Business Engine provide VPN-like services but it also analyzes the data and selects the best compression algorithm for transmission. The Exchange Connector also minimizes the amount of data that needs to be sent to the handheld: Because the MAPI session is managed on the gateway server, the Exchange Connector sends to the handheld only essential information from the gateway-to-Exchange MAPI session. These features help to compensate for the lower bandwidths available with wireless connections. Just as ThinAirApps' product supports primarily Palm OS devices, Infowave's solution supports primarily Pocket PC devices.

Get Connected
A PDA with a wireless connection can be a powerful tool that can help users accomplish a variety of business tasks. The variety of solutions on the market can bring users' PDAs and your Exchange organization together. Before you jump into an implementation, talk with users to determine their precise needs, then study the available access and connection options to find the most useful and secure solution for your environment.