Introducing System Center Mobile Device Manager

Although mobile messaging has been around in one form or another for many years, it seems that Microsoft only started taking it seriously with the release of Exchange Server 2003 SP2. SP2 featured a whole slew of new capabilities for organizations that wanted to use mobile messaging, and things got better from there. Exchange Server 2007 introduced even more improvements, and Microsoft even threw in a bunch of new mobile device security settings in Exchange Server 2007 SP1. Continuing the trend, Microsoft has recently released System Center Mobile Device Manager (MDM) 2008.

What Is Mobile Device Manager?

The best way to understand how MDM works is to compare it to Microsoft Internet Security and Acceleration Server (ISA Server). As you probably know, ISA Server is a completely separate product from Exchange. Exchange can function without ISA Server, and ISA Server can function without Exchange. Even so, ISA Server was designed specifically with Exchange in mind, and because it's Exchange aware, it can provide Exchange with better security than most other firewall products can.

MDM works similarly; it isn't an Exchange-specific add-on, but if you're using Exchange's mobile messaging capabilities, MDM can help you be more secure. It's designed to let large, enterprise-class organizations provision, manage, apply group policies to, and deploy software to Windows Mobile 6.1 devices.

Mobile Device Manager Architecture

MDM has three primary components: the Mobile Device Management Server, the Enrollment Server, and the Gateway Server. As Figure 1 shows, the MDM setup program lets you install each of these options separately. Technically, you can install each of these server roles on a common server, but I would recommend doing so only in a lab environment. In a real-world deployment, you need to host these roles on separate servers for security and performance reasons.

The Mobile Device Management Server

The Mobile Device Management Server is the heart and soul of MDM. This is the server from which all your mobile devices receive policies and software deployments. If a mobile device is on the mobile network, the device will use a cellular or Wi-Fi link to connect to an IPsec VPN, which in turn connects the device to the Mobile Device Management Server. If the device is connected to the corporate network using a Wi-Fi connection, the device doesn't bother using a VPN connection; rather, it communicates directly with the Mobile Device Management Server directly.

Policy Management

Although many of the policies that you can apply with MDM are the same types available through Exchange Server 2007 SP1 (to which Microsoft added a few dozen new mobile device policy settings), policy management is completely different. MDM actually joins Windows Mobile 6.1 devices to a domain and applies the policies through Group Policy Objects (GPOs).

One of the nice things about managing mobile devices in this way is that your mobile device security policies mirror your Active Directory (AD) structure. For example, if you have multiple organizational units (OUs) in place for various departments within your company, you can create a separate set of mobile-device-related GPOs for each OU. This ability gives you granular control over how mobile devices are used. For example, you might allow the executives in your company—and maybe even the IT staff—to have full, unrestricted access to all of the mobile device’s features. However, you might want to prevent the people in the sales department from connecting to the Internet using Wi-Fi. The ability to apply separate group policy settings to various OUs lets you accomplish this level of security fairly easily.

If you're familiar with the GPOs that are built into Windows Server by default, then you know that few (if any) are related to mobile devices. So where do all of these new group policy settings come from? Well, if you look back at Figure 1, you'll notice that the splash screen contains an option for configuring AD for MDM. It's this configuration process that makes the new group policy template settings available.

Group policies can't be applied unless a mobile device has been joined to a domain. Currently, Windows Mobile 6.1 is the only version of Windows Mobile that is capable of being joined to a domain, and is therefore the only version of Windows Mobile that you can manage through MDM.

Software Deployment

The other primary function of the Mobile Device Management Server is its ability to deploy applications to mobile devices. In case you're wondering, MDM accomplishes this by using Windows Server Update Services (WSUS) as a back-end component. In fact, Microsoft requires you to install WSUS 3.0 SP1 before you install MDM.

If you have ever installed WSUS before, you know that it's dependent on SQL Server. The Mobile Device Management Server requires a SQL Server back end for both WSUS and for the mobile-device-related data that it collects. Although you can piggyback off of an existing SQL Server instance (assuming that it has the performance capacity), Microsoft recommends using a dedicated SQL Server instance for your Mobile Device Management Server.

The Enrollment Server

The enrollment server is the server you use to initially provision a mobile device. You can use one of two different methods for provisioning mobile devices. One method involves the IT department giving you a provisioning password for the mobile device. It's also possible to let users provision their mobile devices themselves through a self-service portal (note that this self-service portal site is an optional add-on component).

When a device is enrolled, two things happen. First (as I have already discussed), the Enrollment Server creates a computer account in AD for the mobile device. Second, the enrollment process assigns a device certificate to the device being provisioned. This allows mutual authentication between the device and the gateway server.

The Gateway Server

The gateway server is essentially a VPN server that is used by mobile devices. It uses the device certificate provided by the mobile device to establish IPsec encryption prior to the user being allowed access to the corporate network.

Session Persistence

Another nice feature of the MDM VPN is Session Persistence. If a user loses his or her connection because of a weak signal, he or she can reconnect to the corporate intranet without having to reauthenticate and without losing the session history.

Putting it All Together

Now let's look at how all of these components fit together in your network's overall architecture. Figure 2 shows a simple network diagram. For the sake of simplicity, I didn’t include any redundancy or fault tolerance in the diagram, but you can use multiple MDM servers to provide scalability and high availability.

If you look on the left side of the diagram, you can see a Windows mobile device establishing connectivity with a cellular service provider, which in turn connects the mobile device to the Internet. Once an Internet connection has been established, the Windows mobile device connects to the gateway server, which resides in the demilitarized zone at the network perimeter. Both the mobile device and the gateway server each contain certificates positively identifying them. This allows for mutual authentication and allows the Windows Mobile device to establish an IPsec encrypted VPN session with the gateway server.

Once the Windows Mobile device establishes a VPN session, the gateway server puts the mobile device in touch with the Mobile Device Management Server. This server consults with AD to determine which group policies are in effect for the mobile device. It then pushes the necessary policy settings to the mobile device through the VPN connection. This same mechanism is also used for deploying software to the mobile device. This architecture is used only if the mobile device connects to the network through a cellular link. If the mobile device uses a Wi-Fi connection, it communicates directly with the Mobile Device Management Server, bypassing the gateway server.

What About Exchange Server?

As you can see, System Center Mobile Device Manager 2008 provides a lot of the same mobile device management capabilities as Exchange Server 2007 SP1 does. But which product does a better job, and is deploying MDM worth the expense and effort? This question is especially important if you have already invested in an Exchange Server 2007-based MDM infrastructure. My answer: If you're successfully using Exchange 2007 as an MDM mechanism, stick with it. MDM does offer some capabilities that you can’t get through Exchange (namely the VPN capabilities), but it isn’t worth upgrading unless your organization can directly benefit from those new capabilities.

By far the biggest advantage to deploying MDM is that it provides VPN connectivity to your network. Exchange 2007 is designed so that mobile users can access email and certain file shares and SharePoint sites, but that’s about it. MDM provides a true VPN connection to the network, giving mobile users access to anything that they have access to from their desktop or laptop. You now have the ability to connect mobile users to line of business applications residing on network servers (so long as those applications are Windows Mobile compatible).

Another advantage of using MDM is the fact that it uses group policy settings to manage the security policies for mobile devices. Since mobile devices are joined to an AD domain, you can manage them in a manner similar to the way you manage other types of network clients. System Center Configuration Manager already has some mobile device management capabilities built in, but I suspect that as time goes on, we will start seeing more comprehensive products that inventory and manage mobile devices right alongside other types of network clients.

About ten years ago, I remember hearing Bill Gates give a speech in which he said that the device that a user is using shouldn’t matter. Users should be able to connect to the network, run applications, and access their data regardless of what type of device they are using. At the time, that goal seemed really far off, but I think that System Center MDM offers a huge step toward making Microsoft’s goal a reality.