It's a complex setup, but you'll get tight control over mobile devices when you follow these steps
The use of mobile devices, or smartphones, for business isn't new; however, the patterns of use and the features these devices offer have changed radically in recent years. Today, it's possible to browse the web, send and receive email, and run countless applications—from customer relationship management (CRM) apps to word processing to social networking software—all while talking with someone on a call. The increased processing power, memory, and storage make these devices powerful business tools, and your users probably have corporate documents, customer lists, and sensitive pricing information on their devices. Responding to the loss of a device might involve sending breach notifications to customers and partners, and potentially paying fines and other penalties.
However, losing devices isn't the only risk a company faces. Employees who quit or are terminated could potentially walk out with your company's intellectual property, and it's possible that data could be accidentally leaked to social networking sites, as well as leaked through web browsing and personal email use. Previously, the response to these risks might have been to ban the use of mobile devices altogether, but their popularity and usefulness means that more and more organizations are seeking ways to integrate them into the enterprise while applying corporate policies to them.
There are solutions available today that can be used to integrate mobile devices with corporate networks and apply policies to them. In this article, I'll describe Microsoft System Center Mobile Device Manager (MDM) 2008 SP1, focusing on installation and configuration.
MDM isn't the only solution Microsoft has that supports mobile devices. Organizations with Microsoft Exchange Server 2010 can use Exchange to manage mobile devices so that devices can send and receive email using the Exchange infrastructure with Exchange ActiveSync (EAS). In addition, EAS can be used to push basic policies to mobile devices.
Basic policies for mobile devices can be used to enforce password policies, such as a policy that requires the use of a complex password. They can also be used to enforce what users can do with their devices, including disallowing removable storage such as memory cards; preventing use of the camera and Wi-Fi; restricting what Bluetooth features are available; and controlling which applications can run, including the browser and non-Exchange email apps. A broad EAS setting lets you enable or disable nonprovisionable devices, which are devices that won't or can't enforce policies pushed by Exchange.
Exchange 2010 ties basic policies to mailboxes, not devices, and doesn't offer true end-to-end management of security and devices. Nor does it offer a remote-access solution, which permits mobile devices to consume resources on the corporate network. MDM offers these features, and it has much richer policy and enforcement features. However, MDM supports only Windows Mobile–based devices running Windows Mobile 6.1 or later, whereas Exchange 2010 can support any EAS-enabled device. MDM and Exchange 2010 can coexist, and can be used simultaneously for device management.
MDM is a reasonably complex product to deploy, consisting of several components. First, MDM requires Microsoft SQL Server 2005 or later to store policy and configuration information. MDM itself requires a Gateway Server, Device Management Server, and Enrollment Server. You can deploy the Device Management Server and Enrollment Server roles on the same server, which is a typical scenario for smaller environments. The Gateway Server is deployed in your demilitarized zone (DMZ), and it requires one network interface for internal communications and one for external communications. The Gateway Server's external interface must have a public IP address, must have a default route configured, and can't be published behind Microsoft ISA Server or Forefront Threat Management Gateway (TMG). The Device Management Server and Enrollment Server roles are deployed on your intranet.
The three server roles form an instance of MDM, and an instance can support as many as 30,000 mobile devices. You can deploy multiple instances to support more than 30,000 users, or to accommodate users in different regions so that users can connect to a local MDM instance for best connection speeds, and you can manage groups with disparate policy requirements. Note that MDM doesn't require Exchange (or its mobility features) but can be used to offer Exchange services to mobile devices.
MDM is a 64-bit–only product, so it requires 64-bit–capable hardware and a 64-bit OS: Windows Server 2003 R2 64-bit. Installation on Windows Server 2008 isn't supported—some tools and utilities simply fail to install, although there are some workarounds. Before you can deploy MDM, you need a Certification Authority (CA), which should be an enterprise CA integrated with Active Directory (AD). The enterprise CA can run on Server 2008, and the Windows Server 2003 R2 servers that you install MDM on can be member servers in a Server 2008–based forest with the functional level raised to Server 2008 Forest Functional mode.
Before you install MDM, you need to configure AD. This configuration doesn't extend your AD schema; it simply involves creating objects to support MDM. Log on to the server on your network on which you intend to install either the Device Management Server role or the Enrollment Server role, run MDM Setup.exe, and select the Configure Active Directory for MDM option under the Prepare section of the setup splash screen. You need to be logged on as a member of the Enterprise Administrators group. When you select this option, a command prompt window opens, and the command ADConfig.exe /help runs before giving you a command prompt. If you scroll back through the Help text, you'll find that the ADConfig command has many command-line options.
Despite looking very confusing, using ADConfig is relatively simple. Run the command
ADConfig.exe /createinstance: /domain:
where instance is the name you want to give to your MDM instance, and domain is the domain in your forest in which it will run. The instance name can be no longer than 30 characters and can contain only alphanumeric characters, the dash (-), and the underscore (_). The domain name must be specified as a Fully Qualified Domain Name (FQDN)—for example, corp.infosecresearch.com. When you enter the command, you'll be asked to confirm the action before configuring AD. Take particular note of the settings you specified because the instance name can't be changed after the command completes. As the command runs, it tells you what it's doing and shows the success or failure of each configuration change. You'll be asked to confirm whether you want to enable your instance as the final step of the command.
If you have multiple domains in your forest and you want the mobile devices associated with each domain to be managed by this instance of MDM, you need to run the command
ADConfig.exe /enableinstance: /domain:
where instance is the name of your instance and domain is the FQDN for each domain. You should run ADConfig with the /enableinstance flag only after you're sure that the initial configuration has replicated throughout the forest.
Next, you create the certificate templates used by MDM. Certificate templates are used to control how keys in issued certificates can be used, what the certificate policy is, and how long it's valid for. Run the command
ADConfig.exe /createtemplates:
where instance is the name of your instance. ADConfig again asks you to confirm the operation before proceeding, and it displays status information as it runs. After you create the templates, you need to enable them so that your CA can issue them. Run the command
ADConfig.exe /enableTemplates:
/ca:\
where instance is the name of your MDM instance, CA server FQDN is the FQDN of the CA that will issue the certificates, and CA instance is the CA's instance name. You can find the CA's instance name by running certutil.exe from the command line; the instance is the Name value. As with other ADConfig commands, you'll be asked to confirm the operation before it runs.
The next step in preparing to install MDM is to add a domain account to the SCMDMSecurityAdmins (instance) and SCMDMServerAdmins (instance) groups, where instance is the name of the MDM instance you've used in the previous steps. An account in the first group can add users to other MDM groups for the instance, and an account in the second group can install and manage MDM servers for the instance. Although you can use two accounts, I recommend that you use a single account, which will become the MDM administrator account. If you're logged on with an account that was added to the MDM groups, you'll need to log off and log back on for the additional group memberships to take effect.
The next step is to install the MDM Enrollment Server. Every MDM instance requires an Enrollment Server, and you can install more than one of this role for fault tolerance and load balancing. Mobile devices must be enrolled through the Enrollment Server so that MDM can manage them. This role needs to be published so mobile devices can access it from both the intranet (internal) and the Internet (external). Before you install the Enrollment Server, you need to know the internal and external FQDNs that will identify the server.
To install the server, select Enrollment Server from the setup splash screen. The Enrollment Server requires Microsoft IIS 6.0 and the full suite of IIS 6.0 management tools. Without this prerequisite, the server won't install.
The server installation process is wizard-based. After you accept the license agreement, the wizard asks you to select the MDM instance you're installing the Enrollment Server for. Next, it asks you to confirm the installation location on the file system, and then to specify the SQL Server instance the Enrollment Server will use. You can use an existing instance of SQL Server if desired. You need systems administrator access on the SQL Server instance to configure the MDM database.
At this point, you specify the external and internal Enrollment Server FQDNs. The external Enrollment Server FQDN is used by mobile devices to enroll. You need to add the external FQDN to your public DNS and ensure that the server can be reached from the Internet. The wizard then asks you to specify the port that the Enrollment Server Administration web site will listen on. You can't use port 443 because the Enrollment Server itself uses that port. Setup provides a random port number, which you can usually use unless it conflicts with another service or you have a policy that dictates which ports to use. Make sure you record the port number so you can reuse it if you install multiple Enrollment Servers.
Next, you need to specify the CA server and instance name you specified when preparing AD for MDM. The CA issues certificates to mobile devices. You also need to specify a CA to issue SSL certificates for MDM during the remainder of the setup. This CA can be any issuing CA in your enterprise, including the CA used during device enrollment. After you specify the necessary information, the wizard presents you with your choices, which you confirm by clicking Install.
You need to install at least one Device Management Server for your MDM instance. If you install multiple Device Management Servers for scalability and fault tolerance, you have to use a load balancer to spread the mobile devices across them. Like the Enrollment Server, the Device Management Server is web-based, so you also need to install IIS 6.0 along with its full suite of management tools.
Before you install the Device Management Server, you need to install Windows Server Update Services (WSUS) 3.0 SP1 on each server that will be a Device Management Server. Note that WSUS 3.0 SP2 isn't recognized by MDM, so you must use SP1. MDM uses WSUS to deploy software packages to mobile devices, but WSUS can also be used to manage software updates in your enterprise. If you're using WSUS only to deploy software packages to mobile devices, you can configure it to download updates only for Microsoft Report Viewer because you must select at least one product to update. WSUS itself requires you to install the Report Viewer 2005 Redistributable or later. You can get both WSUS and Report Viewer from the Microsoft Download Center.
To install the Device Management Server, select Mobile Device Management Server on the setup splash screen. You'll be asked to accept the license terms, select the MDM instance that the Device Management Server will be added to, the location to install the software to, and the database server to use. Note that if you install the Device Management Server on the same server as your Enrollment Server, setup uses the same installation location and database server, so these options will be grayed out.
Next, the installation wizard asks for the FQDN for the Device Management Server, which is an intranet FQDN. If you're installing multiple Device Management Servers, enter the FQDN of the load balancer that will front them. Setup validates that the FQDN exists in DNS. The wizard then asks you for the Device Management and Administration web site ports. If this is your first server, take note of the ports chosen and ensure that they're used when configuring subsequent Device Management Servers. The next step asks you for a CA that can issue SSL certificates during setup of the Device Management Server. If you're installing the Device Management Server on the same server as the Enrollment Server, the CA is automatically populated. At the end of the setup, you'll be shown the selections you made. Click Install to begin the installation process.
The next step in getting MDM up and running is to install the MDM Administrator Tools. You can install the tools on 32-bit or 64-bit systems. Prerequisites for the tools are to install Windows PowerShell 1.0, Group Policy Management Console (GPMC), and the WSUS administration console. Note that Windows 7 ships with PowerShell 2.0, which the tools installer doesn't recognize. You can't install PowerShell 1.0 alongside PowerShell 2.0, meaning you can't install the MDM Administrator Tools on Windows 7 systems. If you don't have PowerShell 1.0 or GPMC, you can get them from the Microsoft Download Center. GPMC for Windows Vista SP1 and later is included in the Remote Server Administration Tools (RSAT), which you can also download from Microsoft.
You install the MDM Administrator Tools by selecting the item on the MDM setup splash screen. You're asked to accept the license and whether to install all tools (the default) or a custom installation. After you've made you selection, you're presented with a summary of what will be installed. Click the Install button to begin installation. The installed tools can be found on the Start menu under a program group called Microsoft System Center Mobile Device Manager.
The next-to-last step is to get the Gateway Server up and running. The Gateway Server lets your mobile devices access resources such as SharePoint sites or file servers inside your corporate network, without the need to publish each one or duplicate them in your DMZ. The Gateway Server needs IIS 6.0 and the Microsoft .NET Framework 2.0 SP1.
Before you install the Gateway Server, you need to configure the server OS with a certificate that MDM will use to authenticate it in SSL sessions. The steps to install the certificate are a little complex. Start by creating a document with Notepad called GatewayCertReq.inf, and enter the following text in it:
\\[NewRequest\\]
Subject="CN="
MachineKeySet=True
KeySpec=1
Replace MDMGatewayServerFQDN with the internal FQDN of the server, not the external FQDN (although it's possible they're the same). Next, run the command
certreq -new GatewayCertReq.inf GatewayCertReq.txt
Copy the output file, GatewayCertReq.txt, to a member server in your domain and run the command
replacing instance with the name of your MDM instance. If you have more than one issuing CA in your forest, you'll be prompted to select the CA you want to use. It must be the same CA you installed the templates on earlier. Copy the output file, GatewayCert.cer, back to your MDM Gateway Server and enter the command
certreq -accept GatewayCert.cer
Next, you need to install the certificate of your root CA, any intermediate CAs, and the issuing CA. If you're using Certificate Services, simply browse to the root CA's virtual directory (\certsrv) from a domain-joined machine, click the Download a CA certificate, certificate chain, or CRL link, then click Download CA certificate and save the file. By default, the file is named certnew.cer. If your root CA isn't the CA that issued your Gateway Server's certificate, browse to the issuing CA's virtual directory and download the certificate chain; save the file, then copy it to your Gateway Server. This file is named certnew.p7b by default.
You install the certificates on the Gateway Server by launching Microsoft Management Console (MMC) with the Certificates snap-in, making sure that you specify you want the Computer Account option. With the snap-in loaded, expand the Trusted Root Certification Authorities node, right-click Certificates, select All Tasks, then Import. In the Certificate Import Wizard, select the file certnew.cer. Repeat this process for the intermediate CAs by importing certnew.p7b to the Intermediate Certification Authorities node.
Next, you need to create the Gateway Server's configuration file, which is a short piece of XML used when you install the Gateway Server. Go to the workstation or server on which you installed the Administrator Tools, launch the Mobile Device Manager Shell, change into a temporary working directory, and enter
Export-MDMGatewayConfig
A file called GatewayConfig.xml is generated and written to the working directory. Copy the file to the Gateway Server.
Now that you've prepared the Gateway Server, you can run Gateway Server setup by selecting that option from the Install section of the setup screen. In the Gateway Server Setup wizard, after the license screen, you're prompted for the internal IP address that the server will listen on for connections from the Device Management Server and the TCP port to listen on. The default is port 443. Next, you're prompted to browse for and select the GatewayConfig.xml file you copied over. You then select the Gateway Server authentication and root CA certificates that you've imported. Finally, you're prompted to confirm your choices before installing the software.
After installation, you'll be prompted to run the Add MDM Gateway Wizard. Before you do that, however, you need to go back to a system that has the MDM Administrator Tools installed, launch the Mobile Device Manager Shell, and enter the command
Set-EnrollmentConfig -GatewayURI
where ExternalFQDN is the FQDN of the Gateway Server as mobile devices outside your network see it. When the command completes, you'll see some configuration information displayed. Now you can launch the Add MDM Gateway Wizard, which you do from the MDM Console. In the console, expand your instance, then select Gateway Management. In the Actions pane, select Add MDM Gateway Wizard.
The first step in the wizard is to enter a name for the Gateway Server. I recommend you use its FQDN to avoid name conflicts. The next step is to configure access points. The first access point is the external IP address that mobile devices will use to establish a VPN connection through the Gateway Server. This address must be a public, routable IP address. The next access point is the internal FQDN of the Gateway Server, which the Device Management Server uses to connect to, and the SSL port, which defaults to 443.
Next, you specify the address pool from which IP addresses are allocated to mobile devices that connect through a VPN. You can add one or more address pools, as Figure 1 shows, and each can have as many as 65,535 addresses (using a subnet mask of 255.255.0.0). Note that the address pools must be consistent with the internal IP address of the Gateway Server, meaning that the subnets and subnet masks must be complementary, with no conflict or overlaps. If required, you can also specify a default gateway for clients to access intranet resources, which might be necessary if the address pools aren't on the same subnet as the Gateway Server itself.
After the address pool is configured, you're asked for the IP addresses of your DNS and WINS servers. You must specify at least one DNS server. The IP addresses you provide should be for DNS servers either in your DMZ or reachable from it. You should also enter any routing information that mobile devices connecting through a VPN will need to reach resources on your intranet, including the Device Management Server. When you've entered all the necessary information in the wizard, click the Add button. You can add more gateways if necessary, or you can click Finish to exit the wizard.
To verify that the Gateway Server is configured, launch the MDM Console and select Gateway Management under your MDM instance. As Figure 2 shows, the Service Configuration State should be "Running" and the Sync State should be "Up to date." If the service isn't running, or the state is "Error," check the MDM logs in the Windows Event Viewer on the Gateway Server. (MDM extends the Windows logs to add its own.) Chances are that you can't access the Gateway Server in the DMZ because of a firewall issue. Alternatively, you might have a conflict between the address pools you configured and the networking setup of the Gateway Server itself.
Most of the communication between the MDM servers and mobile devices uses SSL-based connections. However, some other protocols are also used. Depending on how you deploy MDM, you might need to configure ISA Server or TMG servers, as well as network and built-in Windows firewalls.
To begin, you need to ensure that the Device Management Server can communicate with the Gateway Server. The default port is 443/TCP (HTTPS), unless you specified another port during Gateway Server installation. Mobile devices need to be able to talk to the Enrollment Server over port 443/TCP, and you'll need to publish the Enrollment Server so that it can be seen from the Internet. Mobile devices also need to be able to communicate with the Device Management Server via the IPsec VPN in the DMZ over port 8443/TCP (unless you specified another port during installation) and with the Gateway Server to establish IPsec tunnels, which require IP protocol 50, 500/UDP and 4500/UDP to be opened.
You also need to open access to DNS and to specific servers, such as email servers, using the ports they conventionally use for VPN access. For clients terminating in the DMZ, use addresses allocated from the address pools configured on the Gateway Server.
With MDM successfully installed, you can begin enrolling mobile devices by creating enrollment requests. In limited deployments and in smaller organizations, it's possible to manage enrollment requests manually, but in larger deployments and organizations, you'll want to install and configure the Self Service Portal so users can manage their own enrollment and device configuration. For information about installing the Self Service Portal, see the Microsoft article "Install MDM Self Service Portal."
To manually enroll a mobile device, launch the MDM Console, expand the MDM instance you want to manage, expand the Device Management node, then select All Managed Devices. In the Actions pane, click Create Pre-Enrollment to launch the Pre-Enrollment Wizard. After the introductory step, the wizard prompts you for a name for the mobile device that will be enrolled; this name must be unique and a maximum of 15 characters in length. You can override the organizational unit (OU) that a mobile device object is placed into in AD. For large environments or environments in which you use OUs to set different policies for mobile devices, you might want to create new OUs and place mobile device objects in those OUs. If you use alternative OUs, you must run the PowerShell cmdlet Set-EnrollmentPermissions and specify each OU to prepare it.
Next, you're prompted to specify the device's user, for which you have three options: Active Directory User, Other user identifier, and Anonymous User. If you select Active Directory User, you can use Group Policy to manage the mobile device, and you can email the selected user with enrollment information, which makes setup easy for users who already get email on their mobile devices. I recommend that you avoid the other options because their usefulness is limited. An example of when you might use these options is if multiple people share a mobile device. When adding AD users, you select them from a list by using the Browse button in the wizard, or you can manually enter their distinguished name (DN).
Next, you need to confirm the choices you've made and create the pre-enrollment. When the pre-enrollment operation completes, the wizard provides you with information to pass along to the owner of the device to complete enrollment, as Figure 3 shows. The device owner needs only the E-mail address/User name and Enrollment password. A pre-enrollment is valid for only eight hours by default.
To use the pre-enrollment, the device owner needs to go into the phone's Settings menu, select Connections, then select Domain Enroll to launch the device Domain Enrollment. When launched, the owner selects the Enroll option and enters the E-mail address/User name and Enrollment password provided. If the mobile device isn't able to automatically find an Enrollment Server, the device owner is alerted and can manually enter the public FQDN. The phone contacts the enrollment server, downloads necessary enrollment information, completes enrollment, then prompts the user to connect to the Device Management Server to finish the configuration. The mobile device needs to reboot during enrollment and configuration. When the device has completed enrollment and configuration, the Domain Enroll function on the device is disabled and enrollment information is displayed, as Figure 4 shows.
The enrolled mobile device is also visible in the MDM Console, as Figure 5 shows.
Enrolled and configured devices establish VPN connections to the Gateway Server, then on to the Device Management Server as well as to other resources on your corporate network. Keeping a constant VPN connection can drain batteries on mobile devices; therefore, you might wish to advise your users to disconnect the mobile VPN on the device when not in use. However, you might need to configure an option through Group Policy to let users disconnect the VPN.
You can use the Update Device Details option in the MDM Console to refresh device information at any time. It's from the MDM Console that you can wipe a lost or stolen device, or block it from connecting to the corporate network via the Gateway Server.
Mobile devices can be managed in a fashion similar to desktops or laptops through the use of Group Policy Objects (GPOs). However, you first need to load an administrative template containing mobile settings. To do so, launch GPMC from Administrative Tools on the machine where you installed the MDM Administrator Tools. Next, right-click Group Policy Objects, select New, and give the GPO a name to create it. Next, edit the GPO and expand the Policies node under Computer Configuration. Right-click Administrative Templates and select Add/Remove Templates. In the dialog box that appears, click the Add button, then scroll down the list of folders and templates displayed in the Policy Templates picker until you find one called mobile.adm, and double-click it.
After the mobile device policy template is loaded, you'll find that additional policies have been added to the Group Policy Management Editor under both Computer Configuration and User Configuration. In each one, you'll find Windows Mobile Settings under Administrative Templates in the Policies node. On Vista systems, they're under Classic Administrative Templates (ADM). Device policies let you control things such as passwords, device features (e.g., cameras, Bluetooth), applications, encryption, VPN connections, and software distribution. User policies are limited to EAS settings and the use of Secure MIME (S/MIME) for secure email.
To apply a policy to mobile devices, simply link the GPO to an OU containing objects representing mobile devices. Note that the Group Policy modeling tools don't work well with mobile device settings, but you can use the Windows Mobile Group Policy Results Wizard to generate a report of settings that apply to a device or user. This wizard is available from GPMC on the system on which you installed the MDM Administrator Tools.
You can create and distribute software packages to mobile devices by launching the MDM Software Distribution Console, which is available in the MDM Administrator Tools collection. Before you create a package, you need to point the console to a WSUS server running on a Device Management Server. You then launch the Create Package Wizard from the console by expanding the Software Distribution node, the node representing the WSUS server, and the Packages node. In the Packages node, right-click Software Packages to launch the wizard.
In the wizard, you specify the location of the .cab file containing the software to be distributed, along with information to sign the .cab file if desired. You can restrict software on mobile devices to only that which is distributed with MDM or Group Policy. Other information required when creating packages for distribution to mobile devices includes which devices, mobile OS versions, and languages the package is intended for, as well as dependencies and uninstall options. After a package has been created for distribution, you can track its installation by running reports with the Software Distribution Console.
You should now have a good grasp of how to deploy MDM 2008 SP1, as well as some of its capabilities for mobile device management. Although it's a reasonably complex product to get up and running, MDM offers an excellent platform to manage security of mobile devices, especially to enterprises with sophisticated mobile device management needs. However, MDM can be used to manage just a small number of mobile devices as well—for instance, those belonging to key personnel or other employees who have business-critical data on their devices.