Getting Started with System Center Mobile Device Manager

Executive Summary: Microsoft's System Center Mobile Device Manager (SCMDM) is for enterprise customers who want to bring their mobile devices under the same kinds of management control that they apply to desktop and laptop PCs and servers. This article examines SCMDM's features, dives into its setup process, and shows you how it can benefit your environment.

Mobile devices are getting more and more powerful. Just a few short years ago, the idea of a smart phone running a Windows-like OS on a 500MHz CPU and 2GB of RAM would have been laughable, but now those specs would identify a low-end device! As mobile devices have gotten smarter and more robust, their value to users and companies has also increased—but so has the associated risk. Having on-the-go access to corporate documents, contacts, email, and calendar data can be a productivity and flexibility boon, but it can also be a major problem if devices with sensitive data are lost or stolen—something that happens all too often.

Microsoft first started offering mobile-device synchronization with its Microsoft Mobile Information Server, the functionality of which was integrated into Exchange Server 2003. Subsequent releases of Exchange have added improved functionality for mobile-device management, but there were still some device-management and security requirements that Exchange alone couldn’t meet. In 2008, Microsoft introduced System Center Mobile Device Manager (SCMDM) to provide enterprise functionality for mobile-device management, security, and monitoring. Let's take a look at SCMDM's features, dive into its setup process, and see how it can benefit your environment.

SCMDM Features
SCMDM promises to bring to mobile devices the kinds of management tools and behavior that we’re accustomed to on the desktop. To that end, SCMDM offers four primary capabilities: network connectivity, security, device management, and connectivity optimization.

Network connectivity. SCMDM includes its own VPN implementation that’s optimized for mobile devices. Mobile devices frequently disconnect and reconnect without the user’s knowledge, potentially changing their IP addresses (and thus confusing enterprise applications that expect a more stable connection). SCMDM handles network address translation (NAT) so that applications on the intranet don’t have to deal with the device’s connection behavior.

Security. With SCMDM, mobile devices can be joined to Active Directory (AD) domains, giving you many of the same management capabilities that typical computers have. For example, you can use users’ AD credentials to control network access, and you can apply AD Group Policies to mobile devices. SCMDM provides its own remote-wipe implementation, and it includes tools for inventorying devices and checking them for policy compliance.

Device management. Device management in SCMDM involves the concept of device enrollment. When you enroll a device, you sign it up to receive policy and management settings from SCMDM. Enrolled devices can receive Group Policy settings, and you can use SCMDM to publish software to devices in a manner similar to the existing AD publishing tools for Windows computers.

Connectivity optimization. SCMDM acts as a gateway between managed mobile devices and your internal network. As such, SCMDM can cache data (in both directions), aggregate network traffic, and better control how the device and your network talk to each other.

SCMDM and Other Microsoft Solutions
You might be wondering how SCMDM integrates with some of Microsoft’s other products. The answer is fairly simple: It can act as a replacement. For example, when you enroll a mobile device in SCMDM, the policies you define in SCMDM replace any policies you’ve defined for that device in Exchange 2010 or Exchange 2007. If you’re using System Center Configuration Manager (SCCM) for inventory and software distribution, you’ll find that SCMDM replaces its functionality, too. Likewise, the mobile VPN functionality in SCMDM takes the place of VPN connectivity through Internet and Security Acceleration (ISA) Server or Internet Application Gateway (IAG). Think of SCMDM as a complement to these products, replacing their desktop-, laptop-, and server-focused functionality with functionality that’s tailored specifically for the constraints of small, mobile, battery-powered devices.

SCMDM Components
SCMDM includes three major server roles that you’ll have to install on your network.

MDM Gateway Server. The MDM Gateway Server lives on your perimeter network. Mobile devices connect to the gateway server through its mobile VPN; the gateway provides a static IP address on the internal network for each device so that internal applications don’t have to know when the mobile device’s address changes. The gateway is also responsible for pushing Group Policy changes and software updates to the device.

MDM Device Management Server. The MDM Device Management Server is the intermediary between AD and the mobile device. It’s responsible for converting Group Policy information into a format usable by the SCMDM client on the mobile device, and it tracks and schedules software updates for transmission to enrolled devices. It’s also the central point of inventory and reporting data.

MDM Enrollment Server. The MDM enrollment server handles the work of enrolling mobile devices for use with SCMDM. In this role, it shares a database of device information with the MDM Device Management Server.

Deploying SCMDM
The process of deploying SCMDM is slightly different from that of Microsoft’s other enterprise products. Longstanding products such as Exchange automatically perform many necessary preparation steps, but SCMDM requires both more manual action on your part and a greater degree of knowledge about what the installation operations involve. The basic steps for deploying MDM are as follows:

1. Prepare your company’s AD implementation by adding the objects and templates that SCMDM uses.
2. Install and configure the MDM Enrollment Server so that devices can be enrolled.
3. Install and configure the MDM Device Management Server.
4. Install and configure the MDM Gateway Server.
5. Install the MDM Self Service Portal, an optional component that lets users perform certain device-management activities.

Preparing AD
As you might expect, the first step in an SCMDM deployment is preparing AD to support mobile-device integration. To do this, you must run the ADConfig (adconfig.exe) tool—provided as part of the SCMDM installation bits—with its /createinstance switch. You must specify the instance name that SCMDM will use. Bear in mind that you can't change the instance name later (although you can change the friendly instance name, which is what users see), so be careful to pick a name that suits your requirements. You’ll typically create a single instance in the root domain of the forest. However, every domain that will contain Windows Mobile devices has to either have its own instance or be linked to an existing instance, which you can accomplish with the ADConfig /enableinstance command.

Next, you must create and enable certificate templates, again using ADConfig, this time with the /createTemplates and /enableTemplates switches. These steps ensure that your enterprise certificate authorities (CAs) will have the templates necessary to automatically enroll mobile devices and issue certificates to them.

You must also grant users permission to manage the MDM servers themselves by adding the appropriate accounts to the four groups that the SCMDM installation process creates. The primary group that you’ll use for SCMDM administration is the MDM Server Administrators group. There are separate groups for device administrators, device-support technicians, Help desk operators, and users who can see (but not change) SCMDM configurations. The simplest way to manage these groups is to add your SCMDM administrators to the MDM Security Administrators group; members of this group can add or remove members in each of the other MDM groups. Once that’s done, the designated security administrators can set up the other group memberships as necessary. The domain’s Domain Admins group is automatically added to the MDM Security Administrators and MDM Server Administrators groups.

Because SCMDM will join enrolled mobile devices to the domain, the SCMDM installation creates a new, separate organizational unit (OU)—SCMDM Managed Devices—for mobile devices. You can create additional OUs if you want, or you can just leave this OU alone. However, if you create additional OUs, you’ll need to delegate to the SCMDMEnrollmentServers group the permission to create and delete device accounts on the new OUs so that enrollment servers can properly enroll and disenroll devices.

Installing the Enrollment and Management Servers
Once you’ve prepared your AD environment, the next step is to install the enrollment and management servers. This is a straightforward process, as long as you’ve put in place two prerequisite elements: a Microsoft SQL Server database instance that the enrollment server and device management server can use to store data about managed devices, and access to a CA that can issue certificates upon request from the enrollment server (for new devices) or for the servers themselves. If you have (or set up) a Windows Certificate Services CA on a server in your organization, the enrollment server can automatically issue certificates to new devices. If not, users might still manually request certificates for their devices, but this detracts somewhat from the inherent value of SCMDM.

You’ll also need to specify two fully qualified domain names (FQDNs): one that external users will use to attach to the enrollment server and one for internal connections. These can be the same or different. However, Microsoft’s documentation warns that you must enter the FQDN of any load-balancing device that you use, or plan to use, so that issued certificates will have the correct machine names.

Installing the Administrative Tools
Like Exchange, SCMDM has a suite of administrative tools based on the Microsoft Management Console (MMC) that you can install on any machine in your domain (although you can't use the Group Policy Management Console (GPMC) on 64-bit systems or on Windows Vista SP1). The tools installed include Group Policy Extensions, a management console for SCMDM software distribution, and the SCMDM console itself. You can also manage SCMDM through PowerShell; in fact, many of the configuration tasks you’ll need to perform on the gateway server will require you to use the MDM Shell, which is analogous to the Exchange Management Shell.

Installing the Gateway Server
The gateway server is probably the most complicated component of the entire SCMDM package. Think of it as similar in function to ISA Server, which is itself a pretty complicated product to set up. As with ISA Server computers, the MDM Gateway Server isn’t usually domain-joined, so you’ll have to manually request a certificate for it, then install the certificate (and CA chain) on the machine. You must also export a gateway configuration file, which contains information about the device-management and enrollment servers. During the actual gateway-setup process, you’ll provide this file so that the new gateway server can be configured to route traffic to the appropriate device-management and enrollment servers. Finally, you must register the gateway with the other servers by using the Add MDM Gateway wizard in the SCMDM console.

Because the overall process of installing and configuring the gateway is fairly involved, I don’t have space to include it here. For a full step-by-step guide, see the Microsoft article "Installing MDM Gateway Server".

Testing Your Deployment
Once you’ve got these components installed, you'll want to try them out! The simplest way to do this is to enroll a Windows Mobile device. To do so, you’ll need a device running Windows Mobile 6.1. (Earlier versions of Windows Mobile don’t include the SCMDM client software.)

Behind the scenes, device enrollment is fairly complicated: The new device must establish an SSL connection to the enrollment server so that it can get the correct set of certificates; then, it establishes a replacement SSL connection using the new certificates so that the enrollment server’s identity can be validated, too. At that point, the device sends a certificate request to the enrollment server, which creates a machine account for the device in AD and forwards the certificate request to the CA. The issued certificate is returned to the device, which installs it, then disconnects from the enrollment server. Fortunately, neither the administrator nor the device users have to perform all these steps manually.

Enrollment is actually a two-step process. First, the administrator must use the MDM management console to create a pre-enrollment request. This step binds an AD user with a particular device, and it also generates an enrollment ID and a one-time password that must be given to the device user. Once the pre-enrollment request is created, the user creates a new connection using the device's Domain Enroll option, entering the enrollment ID and password when prompted. Those credentials provide enough information to jump-start the enrollment process; once it’s completed, you can verify that the device has been enrolled by looking for it in the All Managed Devices container in the MDM management console.

Virtual SCMDM
SCMDM is clearly aimed at enterprise customers who want to bring their mobile devices under the same kinds of management control that they apply to desktop and laptop PCs and servers. Given the increasing capability of mobile devices, for many organizations the benefits of better mobile-device management and control will outweigh the additional cost and complexity of an MDM deployment.

If you want to experiment with MDM, Microsoft has kindly provided the "TechNet Virtual Lab: Using System Center Mobile Device Manager 2008 Features". When you visit that page and register, a clean lab environment will be automatically built, and you’ll have full access to it for 90 minutes. You can also download evaluation versions of the software to test it in your environment.