SolutionBase: Making data available to mobile users

Mobile users present a special challenge to network administrators. Microsoft used to ship Mobile Information Server to help ease the problem, but it has now integrated many of this product's features into Exchange Server 2003. Here's how to make these features work.

Previously, if you wanted to make Exchange Server resources available to mobile users, the product of choice was Mobile Information Server. However, Microsoft included all of Mobile Information Server's functionality into Exchange Server 2003 and discontinued Mobile Information Server. This is great news for those who may have considered experimenting with Mobile Information Server but lacked the budget for the necessary software licenses. In this article, I will explore the various mobility features that are built in to Exchange Server 2003, and I'll also explain how you can configure Exchange Server so that mobile users may access their e-mail via cell phone.

What has changed?

Since Microsoft did away with Mobile Information Server and integrated its mobility features into Exchange Server 2003, you might be wondering what else changed. For the most part, everything works similarly to the way it did under Mobile Information Server. The only feature that Microsoft cut is the short message service e-mail notification to supported cell phones feature.

Microsoft added a few features, though. Mobile users can take advantage of Office Outlook RPC over HTTP and up-to-date notifications to Windows mobile-based devices. Management over mobility has also been simplified since managing mobile configurations is now done directly through the Exchange System Manager.

Outlook Mobile Access

The primary Exchange mobility component is Outlook Mobile Access (OMA). If you have worked with Exchange for a while, you are probably already familiar with Outlook Web Access (OWA) and may wonder how OWA differs from OMA.

OWA is basically a Web interface to Exchange Server. It allows any of your Exchange users to access their Exchange mailbox remotely by using a Web browser and an Internet connection. To access OWA, a user would enter An OWA session is designed to look very similar to what the user would see if they were using Microsoft Outlook to access Exchange Server directly. Since OWA is very graphic intensive and is jam packed with features, it requires a moderate amount of bandwidth and a suitable screen resolution. Although many cell phones have built-in Web browsers, they really aren't suitable for running OWA. The main reason is that cell phones are extremely slow compared to a normal dial-up connection. I can't speak for anyone else, but my cell phone's Internet access is about the equivalent to using a 14.4 modem. The other big problem with running OWA on a cell phone is screen resolution. Most cell phones lack the necessary screen resolution to be able to display an OWA screen without having to scroll beyond the screen's boundaries. This makes using OWA very difficult. Even if the entire OWA screen did fit, it would be very difficult to read on a two-inch display. Because of these limitations, Microsoft has designed OMA as a sort of generic OWA. OMA offers a text-only interface with a minimal set of features. You can see the default OMA screen shown in Figure A.

Figure A

OMA offers a text-only interface to Exchange.

Configuring OMA

OMA is either enabled or disabled at the global level. While you can't enable or disable OMA at the server level or at the information store level, you can control which users are or are not allowed to use OMA. I'll show you how to do that a bit later on.

For right now, open the Exchange System Manager and navigate to Global Settings | Mobile Services. Right-click on the Mobile Services container and select the Properties command from the resulting shortcut menu. When you do, you will see the Mobile Services Properties sheet, shown in Figure B.

Figure B

The Mobile Access Properties Sheet allows you to enable or disable OMA.

As you can see in the figure, there are several options available to you on this properties sheet. The first three options have to do with ActiveSync. I will come back to those options later. The bottom two check boxes allow you to configure OMA. The Enable Outlook Mobile Access check box is pretty self explanatory. If this check box is selected, OMA is enabled for the entire Exchange organization. If the check box is deselected, OMA is disabled for the Exchange organization as a whole. The Enable Unsupported Devices check box needs a bit more explaining. As you probably know, Microsoft maintains a hardware compatibility list for Windows Server. The idea behind the hardware compatibility list is that if a system is listed on it, then Microsoft guarantees that Windows will run on that system. If a system is not listed on the hardware compatibility list, Windows might indeed run on the hardware but Microsoft isn't going to support it. The Enable Unsupported Devices option in Exchange is kind of like the hardware compatibility list for mobile devices. Microsoft maintains a list of mobile devices that are guaranteed to work with OMA. If a device isn't listed on this list, it may not work with OMA. If you select the Enable Unsupported Devices check box, Exchange will give you the freedom to try to connect to OMA from any device you like. Just remember that, if you try to connect to OMA with an unsupported device and it doesn't work, you can't turn to Microsoft for help. You can access the list of compatible mobile devices at Microsoft's Web Site. The unsupported device option can be thought of as a security feature too. If your organization has only supported mobile devices, there is no reason to enable unsupported devices. Disabling unsupported devices limits the types of devices that people can use to connect to your Exchange organization. This means that if someone wanted to break in to your network by using some OMA exploit, they would first have to get a compatible device. Once you have enabled OMA, you can access OMA by opening a Web browser and entering If you are testing OMA for your organization, it is usually considered a best practice to test OMA on a mobile device or on a mobile device emulator. However, if you enable unsupported devices, you can access OMA through Internet Explorer on a regular PC. For the purposes of this article, I have been using HTTP in my OMA URL, but in the real world you'd be better off using HTTPS because of the encryption that it provides.

Testing Outlook Mobile Access

If you happen to have an OMA-compatible cell phone or PDA, the easiest way to test OMA is probably to try to access it directly through your mobile device. In a lot of companies, though, budget restrictions prevent such toys from being issued to the IT department. If you need to roll out Outlook Mobile Access but don't have a device to test it on, you can use an emulator. An emulator allows you to simulate a Microsoft Smart Phone within Windows 2000 or Windows XP, as shown in Figure C.

Figure C

You can use an emulator to simulate a Microsoft Smart Phone.

The process for installing and configuring the emulator is fairly intricate. I don't want to get in to all of the gory detail because I need to save space to talk about configuring Exchange for mobile users. What I can tell you is that, prior to installing the emulator, you must install the following components in this order:
  1. eMbedded Visual C++ 4.0
  2. eMbedded Visual C++ 4.0 Service Pack 3
  3. SmartPhone 2003 SDK
You can find links to download these components and the emulator at Microsoft's Download Web site. Be sure to set plenty of time aside for the download, because the files tend to be big. The eMbedded Visual C++ 4.0 component alone is a 229 MB download.

Exchange ActiveSync

The other mobile feature built in to Exchange Server 2003 is ActiveSync. If you frequently use a laptop or a PDA, you are probably used to working offline and then re-synchronizing everything the next time you connect to the network. ActiveSync is a technology that allows mobile devices to stay in sync with the Exchange organization without having to be cradled (physically attached to the network).

The way ActiveSync works is that the Exchange server sends out an up-to-date notification (UTD) in the form of an SMTP message. The message is sent to the mobile operator's front-end server, where it is converted into an SMS message and forwarded to the wireless device. The mobile device receives the SMS message and processes it at the TCP/IP level, which means that the device's owner will never have to see the inbound message. The SMS message contains a GUID that was sent by the Exchange Server. When the device receives the SMS message, it compares the GUID to the most recently received GUID. This tells the device whether it is currently in sync or if it needs to be synchronized. If the device determines that it does need to be synchronized, it will enter a three-minute waiting period and then initiate synchronization. The three-minute hold occurs because there is a chance that the user has been working offline and has composed messages that have yet to be transmitted. If such messages exist, they will be transmitted during the three-minute hold prior to the synchronization. ActiveSync ensures that mobile users always have an up-to-date view of their Exchange mailbox. Every time a new message is delivered to a mobile user's mailbox, an event sync is called, which launches the process that I just described, ensuring that the mobile user's mailbox is always up-to-date. The good news is that, as an administrator, you don't really have to get involved in this process. Earlier, I showed you the Mobile Services Properties Sheet and told you to ignore the first three check boxes. These are related to the ActiveSync process. The first check box is Enable User Initiated Synchronization. Selecting this check box allows mobile users to keep their mobile devices in sync with the Exchange Server. If you deselect this check box, the entire ActiveSync process will fail. The second check box is Enable Up-To-Date Notifications. As I explained earlier, up-to-date notifications are messages sent by Exchange to mobile devices containing a GUID number. If you want to use ActiveSync, this check box should be selected. Otherwise, automatic synchronization won't work correctly. The last option is Notification To User Specified SMTP Addresses. This option allows users to use their own wireless service provider to receive SMTP notifications. If you select this option, you will have to specify a mobile carrier for each wireless service provider. You can accomplish this by right-clicking on the Mobile Services container in the Exchange System Manager and selecting the New Mobile Carrier command from the resulting shortcut menu.

Granting access

You can control access to the mobile services through the Active Directory Users And Computers console. To do so, right-click on the user or users that you want to regulate and select the Properties command from the resulting shortcut menu. When you do, you will see the user's properties sheet. Now, select the Exchange Features tab. As you can see in Figure D, the Exchange Features tab allows you to enable or disable Outlook Mobile Access, user-initiated synchronization, and up-to-date notifications on a per-user basis.

Figure D

The Exchange Features tab allows you to enable or disable Outlook Mobile Access, user-initiated synchronization, and up-to-date notifications on a per-user basis.

Ready to go

Configuring Exchange Mobile Services is extremely easy to do. The entire configuration process is done by selecting or deselecting a handful of check boxes. In fact, configuring the mobile information services might be just a little too easy.

Normally, this is where I would end the article, but I want to take just a moment and discuss mobile security. It is so easy to configure Mobile Services that you may not take the time to think about the consequences of your actions. Anytime you enable Mobile Services, you are providing users with another way of getting into your network. Your job as an Administrator is to make data as easily accessible to those who need it as possible, while still keeping the bad guys out. You therefore need to consider whether enabling the convenience of having users check mail on their cell phones is worth the security risk. I personally think Mobile Services is more of a benefit than a risk, but you need to make that decision for yourself based on your own organization's needs. If you do decide to implement Mobile Services, just don't forget the tricks that I have shown you for it more secure.

Editor's Picks