Understanding Exchange 2007 SP1 mobile policies, ECAL and MDM


Disclaimer

OK, before you get too far into this posting I just want to let you know that most of this is about why different organizations might choose to go with Exchange to manage their mobile devices and other organizations might use System Center Mobile Device Manager (MDM for short).  This particular posting is more about product direction, product offerings and the device management roadmap. If this stuff bores the hell out of you, or if you are more interested in cool scripting tips to manage your Exchange Server, you're reading the right blog; but this post is more high-level and strategy focused, you can reclaim the 5 mins it would take to read the rest of this and just read the next posting when it comes out, I promise that one will be more tech. focused.  For now I want to address some of the questions I've heard people asking.

Introduction

A couple of folks have been asking about MDM and how it fits into the idea of mobile messaging and control when most of us are used to managing such devices from within the Exchange Management Console.  Up until now devices have been managed in Exchange Server and thus some people are wondering how Exchange's mobile device management, and MDM's work together.

Ultimately our goal with these separate offerings is about choice.  Many other offerings in the device management market give people one option for device control and charge them for that.  We saw a better way to give people an option to pay for what they wanted, and allow them to migrate their way into the fast growing world of mobile devices at a pace, and cost, that's right for them.  That said; here's how we are thinking about mobile device management and the future and it starts by thinking of e-mail administrators, dealing with mobile devices, as having one of three mobile device needs: Adoption, Control or Management.

Adoption

The adoption stage is where administrators are usually running small operations or have very little mobility concerns.  These users are mostly interested in enabling the full mobile messaging experience at a very low cost and allowing access with a broad range of devices.  Exchange ActiveSync fits the need perfectly since it is included in the Exchange Standard Client Access License price (this means if you already pay for a CAL to access a mailbox via Outlook or OWA than this is included in that).  Included in this set of mobility features are things that fall into the categories of Synchronization, Authentication and Encryption.  Users get access to Direct Push e-mail, can sync all their data, remote wipe, get basic PIN policies, data encryption and the ability to access this data from any Exchange ActiveSync enabled device (See some of our Exchange ActiveSync licensees here) at no additional cost.  This is a great way for organizations to get mobility up and going quick and easy.

Control

As organizations grow, they tend to need more advanced mobile control features.  This is as true for mobile control as it is for traditional desktop control.  To provide these features to more advanced (and usually larger) organizations the ECAL was created to cover features like user-level journaling, clustering support, advanced Anti-Virus and Anti-Spam technologies (both on and offsite), etc.  Likewise, there are additional mobility features that organizations, as they get larger (and in many cases more security conscious), are interested in.  This is the control stage.  As part of the Exchange Enterprise Client Access License we have added these additional functions.  Going over all the value in the Exchange Enterprise Client Access License is probably more than you want to read in this already long posting, so I will limit my discussion to those germane features related to mobility.  In this case, the Exchange Enterprise Client Access License give users of Exchange Server 2007 SP1 access to network, application and device control policies.  This is for organizations that want more granular control of the devices and applications that are connecting to their networks (like device encryption, block/allow applications, disable the camera, etc.).  There is a good breakdown of which policies go into which Client Access License here.

Management

Finally, organizations are going to view mobile devices like any other computing device that connects to their networks.  This is what I call the management stage.  In this stage, the ability to manage your mobile devices the same way you manage your desktops is crucial.  This is usually a pretty large organization that has standardized on newer Windows Mobile devices, wants Active Directory integration, is used to using the System Center line of Microsoft applications to manage their machines and really want to treat their mobile devices as first class citizens on their networks.  These folks usually have a lot of mobile devices connecting to their network and are using mobile devices for functions beyond mobile messaging.  Typical wants/needs for these orgs are mobile VPNs/intranet access, mobile line of business apps, role-based administration, expansive/extensible mobile policies, the ability to push software out to devices or any of a host of other more unique (premium) options.  For those looking to have this full set of mobility control and access features, Microsoft System Center Mobile Device Manager (wow that's a mouthful) is a product designed to meet their needs.

Conclusion

At the end of the day, there is a lot of exciting stuff coming up in the world of mobile devices and we at Microsoft want to give our customers an easy way to utilize these new abilities.  For our customers, the path is fairly simple; if you aren't doing mobile messaging yet, Exchange Server makes this easy and low cost (indeed there is no lower cost way to get into mobile messaging if you have an Exchange Server already).  At this stage any Exchange ActiveSync enabled device will provide you a Direct Push messaging experience. If you have an Exchange Server and are realizing that you have a need additional control of the devices connecting to your server, Then the Exchange Enterprise Client Access License, along with new Windows Mobile Devices (SP1 policies require a compatible version of Windows Mobile to take advantage of those policies but older policies will still work on older devices) will provide a seamless way for you to start to implement these features and do a phased upgrade of your organization's mobile devices (or wait for your users to upgrade on their own as most folks are on an 18-24 month upgrade cycle).  Finally, once your organization has standardized on next generation Windows Mobile devices (MDM uses OMA-DM for management) and if you need additional mobile device management features (beyond what Exchange Server provides around messaging, management, monitoring and control) then your organization should look at MDM for its device management solution.

- Adam Glick


Share this post :

Comments (5)
  1. ehatem says:

    Please don’t shoot the person who is posting this

    question. However, in a mobile messaging meeting our

    Director of IT asked if Microsoft would participate in the

    Android technology being developed for mobile devices?

    Any comments?

    thanks

  2. Adam Glick says:

    To my knowledge, we’ve not been asked to participate in Android.

    If the folks running the Android project are interested in licensing EAS, we would be glad to have that conversation.

  3. Tripyre says:

    May not be the best place to ask this question, but can you modify the ActiveSync Policy message that is displayed on the mobile device when a policy is pushed to it.  The message that requests the users to either select Yes or No?

    Thanks,

  4. Adam Glick says:

    The policy message is part of the EAS implementation on the client, not the server, so there is no Exchange Server setting to change the language of this policy.  On the client side there may be a way to change this but that depends on each EAS client individually.

  5. Cheryl says:

    I noticed that in Exchange 2007 SP1 there are two encryption policies:

    1. Require encryption on the device

    2. Require encryption on the storage card

    What does the first policy do?  What does it encrypt on the device?

Comments are closed.

Skip to main content