This is the third blog post in my five-part series on mobile device management (MDM). If you missed the first two parts: preparing for mobile device management and how-to perform device enrollment for mobile device management, I invite you to check them out. Today, I’m going to talk about configuring mobile device settings by using Microsoft System Center 2012 R2 Configuration Manager and Windows Intune.
I’d like to point out before we get started that not all configuration settings are supported on all devices. For example, one configuration setting may be available on a Windows RT 8.1 device, but not on an Apple iOS device. Of course, the same could be said about a setting that is available for a Google Android device that is not available in the Windows 8.1 operating system. That said, many of the settings available in System Center 2012 R2 Configuration Manager are applicable to most of the devices.
To help you, System Center 2012 R2 Configuration Manager tells you if a configuration setting that you have set is supported on a specific device platform. I’ll talk about this more later as we walk through the process for creating configuration settings.
The question is, how does System Center 2012 R2 Configuration Manager know so much about these different mobile devices? And how does Microsoft add support for new devices that are released (such as Windows Phone 8.1)? The answer is extensions for Windows Intune.
System Center 2012 R2 Configuration Manager lists the Windows Intune extensions as they are released. You need to enable Windows Intune extensions to use them. Once you enable an extension, Configuration Manager automatically downloads the extension through the Windows Intune Connector. The Configuration Manager console installs the extension and add new user interface items to make System Center 2012 R2 Configuration Manager aware of the new or different capabilities and features of a device. After the extension is installed, you will need to restart the Configuration Manager console to use the new extension. For more information about extensions for Windows Intune and the Windows Intune Connector, see my first blog in this series.
For those of you who are familiar with Desired Configuration Management in System Center 2012 R2 Configuration Manager, you already know how to create compliance settings. Creating compliance settings is a three-part process. First, you create configuration items (CIs); next, you create configuration baselines; finally, you deploy the configuration baselines to System Center 2012 R2 Configuration Manager user or device collections. A configuration item can contain one or more configuration settings. For example, you could create a CI to manage mobile password settings, but that one CI could have different individual settings, such as minimum password length, password expiration, and password complexity.
A configuration baseline contains one or more CIs, and you deploy the baseline to System Center 2012 R2 Configuration Manager user or device collections. For example, you could create one configuration baseline that contains all the CIs for a sales force, and then create yet another baseline that contains less restrictive CIs for your IT pros. Then, you would deploy the configuration baselines to the respective user collections.
Configuration Manager configuration items and baselines work the same for Windows Intune mobile device management as they do for devices directly managed by Configuration Manager. This allows you to create configuration items and baselines that you can apply to both sets of devices.
You can include however many settings you want in a CI, but typically you want a CI to be somewhat granular. This allows you to reuse the same CI across multiple configuration baselines. For example, if your organization has a policy about app store access, you could create a CI that contains the app store settings. Then, you could include that one CI in all of your baselines.
When you deploy the configuration baselines to the devices, MDM does its magic! The configuration settings are pushed to the devices (as applicable), and the devices are configured to match your published configuration baselines. And if a user resets their device and enrolls the device again, then the device will be brought back into compliance. What happens if the user purchase a new device? If you deploy the configuration baseline to the user, when the user enrolls their new device, that device will be brought into compliance! Who says MDM isn’t easy?
Invariably, users will want to access your organization’s resources from their mobile devices, whether they are in your office, at a Wi‑Fi hotpot, at the airport, or at home. But you need to control how these users access your resources. System Center 2012 R2 Configuration Manager has just the answer in the Company Resource Access features, which you configure by using profiles. The following table lists the profile types that you can create and provides a brief description of each.
These profiles allow you to “push” root and intermediate certificates to mobile devices. Windows Intune configures devices to request user and device (personal) certificates from the enterprise certification authority via the Simple Certificate Enrollment Protocol. Only user and device certificates use the Simple Certificate Enrollment Protocol. Root and intermediate certificates are pushed directly by Windows Intune.
In this way, you can be certain that users have the certificates they need to access your resources remotely. You can define where the certificates are stored on the devices (such as in the computer certificate store or the user certificate store).
You can create certificate profiles by using the Create Certificate Profile Wizard in the Configuration Manager console. You can deploy certificate profiles to System Center 2012 R2 Configuration Manager user or device collections by using the Deploy Certificate Profile Wizard in the Configuration Manager console.
As you might guess, these profiles allow you to define virtual private network (VPN) connection profiles and push those profiles to mobile devices. Just as with certificate profiles, you ensure that users connect remotely using the level of security you establish. Users are also unable to remove profiles that you deploy to them, which also helps in instance where they might inadvertently delete traditional VPN connections.
VPN profiles contain the same information you use to configure a VPN connection, including the VPN type (such as IPsec, Secure Sockets Tunnel Protocol, Cisco AnyConnect, F5 BIG‑IP Edge Client, or Juniper Networks Junos Pulse), authentication method, VPN server information, and proxy settings. However, in addition to the “normal” VPN settings, you must configure which device platforms you support.
You create VPN profiles by completing the Create VPN Profile Wizard, and then deploy them by completing the Deploy VPN Profile Wizard, both of which are in the Configuration Manager console.
Wi‑Fi profiles allow you to . . . yes, you guessed it! These profiles allow you to “push” Wi‑Fi connection profiles to devices. Just as with certificate and VPN profiles, the primary benefit is that you can help ensure that users use the security settings that your organization requires.
Just as with VPN profiles, Wi‑Fi profiles contain the same type of information you’d configure when establishing a Wi‑Fi connection, including secure set identifier, security type (such as Wi‑Fi Protected Access [WPA] or WPA2), the encryption to use, and proxy settings. Just like the other profile types, you also need to specify which device platforms are supported.
You create VPN profiles by completing the Create Wi-Fi Profile Wizard, and then deploy them by using the Deploy Wi-Fi Profile Wizard, both of which are in the Configuration Manager console.
So, now you’ve seen how to configure mobile device settings by using System Center 2012 R2 Configuration Manager and Windows Intune. Pretty easy, wasn’t it? And centrally managing device configuration helps ensure that all your mobile devices are configured the same way and are compliant with your organization’s standards. You can help protect your organization’s resources by ensuring that users use secure settings when remotely connecting. In my next post, we’ll look at how to deploy apps to mobile devices.
NEXT BLOG POST IN THIS SERIES: Deploying apps to mobile devices (Coming May 30)
Comments in this blog are open and monitored for each post for a period of one week after the posting date. If you have a specific question about a blog post that is older than one week, please submit your question via our Twitter handle @MSFTMobility