Mobile Device Management (Part 1)

by [Published on 20 Dec. 2011 / Last Updated on 20 Dec. 2011]

In this article the author will explore the new Mobile Device Management capabilities of Exchange 2010 and the possibility of creating allow, block and quarantine lists to control which mobile devices are allowed to connect to Exchange.

If you would like to read the next part in this article series please go to Mobile Device Management (Part 2).

Introduction

Microsoft Exchange ActiveSync [EAS] is a synchronization protocol based on HTTP and XML that lets mobile devices access information on an Exchange Server such as e-mail, calendar, contacts, tasks and Global Address List [GAL].

EAS has come a long way since its version 1.0 back in 2002 when it was known as AirSync. Not to be confused with ActiveSync, first released in 1996 under the name of Handheld PC Explorer, which allows handheld devices to synchronize data and information with a desktop computer, EAS keeps improving year after year, constantly adding more and more features.

The latest version, 14.1 released with Exchange 2010 SP1, adds a few new features such as GAL photos or Information Rights Management over EAS. The one we will be focusing on in this article adds device and user information to the provision command of mobile devices, allowing administrators to create Allow, Block and Quarantine lists (known as ABQ lists) in order to control which mobile devices are allowed to access Exchange mailboxes.

Although this functionality was present in the RTM version of Exchange 2010 with version 14 of EAS, SP1 adds a user interface in Exchange Control Panel [ECP] for easier management of ABQ lists.

Managing Mobile Devices

Henrik Walther explained how to manage mobile devices with Exchange 2007 in his article entitled Mobile Messaging with Exchange Server 2007 – Part 2: Managing Mobile Devices. Exchange 2010 has since improved these capabilities by introducing new management capabilities for mobile devices.

The biggest improvement is the fact that administrators now have the option to choose whether certain mobile devices are allowed to connect to Exchange, if they should be blocked, or quarantined until an administrator decides to either allow or block them. This is known as the mobile device Access State and can be defined for every user and every device globally at the organization level, through an access rule specific to a device type, or through an exemption that only applies to a single user. We will explore all 3 different methods in the second part of this article, but for now let’s have a look at all possible access states:

Allow

This state allows the mobile device to connect to Exchange and synchronize e-mails and handle calendar information, contacts, tasks and notes. The device remains in this state as long it complies with the EAS mailbox policy configured by the administrator.

Quarantine

Contrary to what administrators might think, when a device is in the quarantine state it is allowed to connect to Exchange. Users can add content to their own Calendar, Contacts, Tasks and Notes folders but will not be able to retrieve any content from their mailbox. The mailbox will contain a single e-mail (Figure 1) that is made available on the device, informing the user that the mobile device is quarantined (Figure 2).


Figure 1.1:
Mailbox in the Quarantine state


Figure 1.2:
E-mail informing the user the device is currently quarantined

This e-mail can have customized text with instructions, for example, so that users know what to do. Although superfluous and not very useful for the recipients, you can see the text I added in Figure 2 where it says “Your mobile device is temporarily blocked from synchronizing with the server while permissions are verified”. We will later see how to configure this text.

It is also possible to configure the EAS organizational settings with one or more administrators who will receive an e-mail message (Figure 3) the first time a mobile device tries to connect to Exchange and gets quarantined. Administrators can then release or block the device by either creating a personal exemption just for that user and that device, or a rule for all users with identical devices. We will see all three different methods in the second part of this article.


Figure 1.3:
E-mail informing the administrator a device has been quarantined

Block

When in the block state due to an access rule or a personal exemption, a mobile device will not be allowed to connect to Exchange and will receive a HTTP 403 Forbidden error (Figure 4). The user will also receive the e-mail message in Figure 5 notifying that the mobile device was blocked from accessing their mailbox. However, in the case of blocked devices, the user will not be able to see the e-mail on the mobile device, only using a client such as Outlook for example. This might cause some confusion for users that are not aware of what might be happening...

The user will be able to see e-mails that were synchronized before the rule was in place, if there were any (the device will not be cleared of any e-mails such as when it is quarantined), but will not be able to download or send any new e-mails.


Figure 1.4:
Permission denied message when a device is blocked


Figure 1.5:
E-mail informing the user the device is currently blocked

If, on the other hand, the mobile device was blocked for not complying with the EAS mailbox policy, the user will not be able to download any data. There will be no notification e-mail delivered to the user but some devices will inform that it does not comply with the security settings, although this varies from device to device. The iPod, for example, displays the following message if EAS requires a passcode and one is not set:


Figure 1.6:
Passcode required to comply with EAS policy

Discovery

When a user first connects a mobile device to Exchange through EAS, the device is in the discovery access state, where it is quarantined until recognized by the server. This state can last from 1 to 14 minutes and no e-mails are sent to the administrators or the user while the device is in this state.

Upgrade

This final state is the same as the Allow state in the sense that the device has full access to the user’s mailbox. It exists to permit the device to upgrade its information and communication protocols to the latest EAS version and be recognized by Exchange when the user’s mailbox is moved from an earlier version of Exchange. When the device is recognized, Exchange applies the appropriate access level based on the EAS configuration. This state only lasts up to 7 days from the first time the device connects to Exchange 2010 after the mailbox move.

Determining Access States

Each time Exchange receives an EAS request from a mobile device, it has to determine which level of access the device should be given. To determine this, Exchange follows a pre-determined sequence of challenges:

  1. Is the mobile device authenticated? If not, prompt the user for credentials. If yes, go to step 2;
  2. Is EAS enabled for the current user? If not, return an "access restricted" error. If yes, go to step 3;
  3. Is the EAS mailbox policy criteria met by the mobile device? If not, block access. If yes, go to step 4;
  4. Is the mobile device blocked by a personal exemption for the user? If yes, block access. If not, go to step 5;
  5. Is this mobile device allowed by a personal exemption for the user? If yes, grant access. If not, go to step 6;
  6. Is this mobile device blocked by a device access rule? If yes, block access. If not, go to step 7;
  7. Is this mobile device quarantined by a device access rule? If yes, quarantine the device. If not, go to step 8;
  8. Is this mobile device allowed by a device access rule? If yes, grant access. If not, go to step 9;
  9. Apply the default access state according to the EAS organizational settings, which will allow, block or quarantine the device.

Conclusion

In this first part of the article, we explored the basics of the new Mobile Device Management capabilities of Exchange 2010. We saw all the possible access states and how Exchange determines the state each device should be assigned. The second part will be hands-on, as we will see how to configure and manage all aspects of Mobile Device Management.

If you would like to read the next part in this article series please go to Mobile Device Management (Part 2).

Featured Links