There a three aspects that you may have to deal with when considering LOB sideloading: licensing requirements, technical requirements and management of sideloaded apps. You will want to understand all of them to understand if there is additional cost, how plan for the best way to enable your devices for sideloading or what are your options for handling new App version updates. Let´s have a look then.

1. Sideloading Licensing Requirements

Sideloading functionality is available “out of the box” for Windows 8.1 Professional and Windows 8.1 Enterprise but only if they are domain-joined. The addition of the Professional edition is new and has been announced as recently as April 2014:

[1] Building the Mobile Workplace with Windows and Windows Phone

“Easier Deployment – Delivering Windows 8.1 Update via Windows Update allows businesses to deploy updates with increased predictability. And, to help businesses develop and deploy modern apps for their workforce, we are enabling sideloading for any domain-joined Windows Pro PC or tablet”

The Windows 8.1 Professional, Windows 8.1 Enterprise that are not domain-joined and the Windows 8.1 RT edition (that cannot be domain-joined) still can be enabled for sideloading but will require a sideloading key that has to be installed and activated on the device. It is a multiple activation key (MAK) and you can obtain it from the reseller.

[2] Volume Licensing reference guide Windows 8.1 and Windows RT 8.1

page 12 and further has a full detail in section “Windows 8.1 Enterprise Sideloading”.

Typically, the sideloading activation key will have to be acquired by to owner of the operating system license. So how much it is going to cost? Well, the thing to check is if you have existing volume licensing Enterprise Agreement with Microsoft. The licensing guide mentioned above lists all of the programs that include them free of charge as of 1 May. If you are in a qualifying licensing program, just contact your reseller who will make the keys available to you.

If you do not have a qualifying volume licensing program then you can purchase from a reseller unlimited number of sideloading activation keys for approx. $100 through the Open contract as also mentioned by [1]. The best thing is to contact the reseller that you normally work with to check out all these options for your particular case.

So in summary, if you are dealing with devices that will not be in domain and you want to install LOB Store App you will need the sideloading activation key. Before you attempt the installation, however, the devices will have to be prepared by your IT pro, so read on.

2. Technical Requirements for Sideloading

There are three technical requirements that have to be met by the device before you attempt to install Store App on it regardless if you are doing it manually, via Powershell scripts or via Mobile Device Management system such as Windows Intune. You will find them explained in

[3] Configure PCs for Sideloading Requirements

but here they are summarized and I illustrate them with screenshots taken on Windows 8.1 Professional with Update 1 that is not domain joined and therefore requires all the steps.

1. Enable the Windows Registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1.

If you are dealing with domain joined device you get this key set via group policy Allow all trusted applications to install. If you are preparing a device that will not domain joined you will most likely find out that the Appx in not present in HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows. In that case: a) create a New Key named Appx b) right click the Appx node you just created and select New-> DWORD (32-Bit) Value, assign it a Name AllowAllTrustedApps c)right click the DWORD you just created and select Modify and type 1 in the Value Data. You should have an entry as per figure below:

.

Figure 1. AllowAllTrustedApps Windows Registry Key2. Ensure that the

2. Ensure that the code signing certificate has been issued by a trusted certification authority.

All Store App packages are signed with a code signing certificate. If the developer uses an Authenticode code signing certificate that has been purchased from common certificate authority (e.g.: Symantec, VeriSign) then you do not need to take an action because the root certificates for these authorities are already present in the Local Machine\Trusted Root Certification Authority certificate store. However, if the application package has been signed with the certificate emitted by customers own Certification Authority or the developer used the self-signed certificate generated by Visual Studio then you will have to make sure the root certificate is present in the Trusted Root Certification Authority store.

You can locate the code signing certificate in Visual Studio solution by looking up the application manifest as shown in the figure below

Figure 2. Application Manifest with code signing certificate

Configure Certificate button allows developer to pick existing code signing certificate from the certificate store a file or get Visual Studio to generate a self signed certificate. If you click the View Full Certificate button you can get the full certification path, copy the certificate to a file, etc. When the Store App is packaged (using the Store->Create App Packages option) the code signing certificate will also be available in the AppPackages solution subfolder. So if you are using self-signed certificate you could just pick it up together with the .appxbundle that contains the application package and take both to your target machine.

On the device that you want to configure simply double click the self signed certificate (.cer) file, select Install Certificate and then in the Certificate import Wizard select Local Machine as the Store Location instead of Current User that will be selected. In the next step select Place all certificates in the following store and browse for the Trusted Root Certification Authorities store to get it installed.

Should you install incorrectly then on Windows 8.1 with Update 1 you will get explicit error message (on Windows 8 you may get more cryptic error HRESULT: 0x80073CFF) as per figure below:

Figure 3. Lack of root certificate error

If all is well the command will complete silently and you should be able to locate the application installed. For domain joined machines you would be able to run the app at this stage, however, for cases that require sideloading key you will see the message App can´t open as in the figure below

Figure 4. App can´t open message

This is because we are missing the step 3 described below.

3. Install and Activate the sideloading key on the devices that require it (as described it in previous section).

There are two commands that we have to execute exactly as described in the “To activate a sideloading product key” section of the sideloading requirements: one to install the key and the second to activate it. You need Administrator privilege to execute these commands as per figures below:

Figure 5. Installation of the sideloading key

Note that the key you type here is the sideloading key that you have purchased from your reseller.

Figure 6. Activation of the key.

In this second step the string supplied (ec67814b….) is always the same because it is a guid that identifies the sideloading feature that we are enabling. If you are unsure if the device has already the sideloading key activated you can check it with command slmgr / dlv that will display the license information. Then scan it for the section with Name: APPXLOB-Client add-on and ensure that the line License Status is showing Licensed.

With all these steps concluded you can install and launch the Store Application successfully.

I should mention for completeness that in development environment you do not require sideloading key. The store apps can run thanks to the Developer License. This license is temporal and periodically will expire. If you are putting in production the machine that was perhaps previously a test machine you can check if it has developer license installed (Get-WindowsDeveloperLicense) and remove it (Unregister-WindowsDeveloperLicense) before configuring production sideloading key using the powershell commands documented in

[4] Windows Developer License Cmdlets in Windows PowerShell

3. Application Management

The licensing requirements and the technical requirements mentioned in the two previous sections have to always be met regardless of the actual method you choose for installing the applications. You have already seen that you can install the application using the Add-AppxPackage command. The command will take an application package (.appx) or the newer application bundle (.appxbundle) as an argument. You can use the Remove-AppxPackage to remove the application.

However, most customers will require more sophisticated solution to manage the application. They will want to assign specific LOB Apps to users in certain groups (Finance, HR) and will want to have a mechanism to install the new versions of the applications even for users with no access to domain.

Windows Intune offers a complete Mobile Device Management solution. It can help not only manage the applications but also (in case of Windows RT) activate the sideloading keys and install root certificates on devices that user enroll for management. Also Windows Intune integrates with System Center Configuration Manager that many customers already have deployed.

The end user has access to the Company Portal application that lists the applications that the Administrator made available in Windows Intune. The Company Portal is essentially a Store App that communicates with the Windows Intune tenant.

You can view two videos that show Windows Intune capabilities with respect to App sideloading:

[5] [youtube http://youtube.com/w/?v=KFpaUSWAv9U]

[6] [youtube http://youtube.com/w/?v=TUrEPNLUkio]

Also you can see the commercial information in

[7] Windows Intune Purchasing and Support Guide

The alternative to Windows Intune is to build this capability yourself. This could be as basic as the network share containing the scripts or a more complex application equivalent to the Company Store communicating with your package repository of choice (Azure Storage / SharePoint, etc.) but you would need to decide if the development effort would be worth it.

System Center 2012 R2 Configuration Manager application model

The System Center 2012 R2 Configuration Manager application model is the only method for deploying apps to mobile devices. Although System Center 2012 R2 Configuration Manager still supports the Configuration Manager package and program model, it’s not designed to deploy apps.

A Configuration Manager application can have one or more deployment types. A deployment type is used to define different ways of deploying the same application. For example, you could define a Configuration Manager application for Microsoft Skype, and create a separate deployment type for the Windows desktop version, Windows Store version, Windows Phone version, Apple iOS version, and Andrord verion (for a total of five deployment types).

This powerful model allows you to define an application once, and then add or remove deployment types as necessary. The Configuration Manager application model also supports automatic updates to an application, supersedence (replacing one application with another), and application retirement (removal), so you can manage your apps throughout their entire life cycle!

Sideloading and deeplinking

There are two ways to deploy apps to mobile devices: sideloading and deeplinking. Sideloading is when you have the actual installation files (such as an .appx, .xap, .iap, or .apk file) and you want to install your app by using the installation files on the appropriate device type. Some devices may require special certificates or sideloading keys for this (see my second blog post on performing device enrollment). When you create a deployment type for a sideloaded app, you provide a Universal Naming Convention path to where the installation files are located.

Deeplinking is when the app is located in the device store and you provide a link to that app. The app is not actually installed; rather, the user is provided with a link to the app that appears in the Company Portal app. When the user installs the app from the Company Portal app (, the app page is automatically displayed in the device store. When you create a deployment type for a sideloaded app, you provide a URL to where the app is located in the device app store.

Now, let’s look at the types of apps that you can deploy to mobile devices.

Application deployment types

The following is a list of the deployment types that System Center 2012 R2 Configuration Manager supports for mobile devices:

• Windows Installer (*.msi file). Used to deploy Windows desktop apps to Windows devices
• Windows app package (*.appx, *.appxbundle). Used to sideload Windows Store apps to Windows devices
• Windows app package (in the Windows Store). Used to deeplink Windows Store apps to Windows devices
• Windows Phone app package (*.xap file). Used to sideload Windows Phone apps to Windows Phone devices
• Windows Phone app package (in the Windows Phone Store). Used to deeplink Windows Phone Store apps to Windows Phone devices
• App Package for iOS (*.ipa file). Used to sideload App Store apps to iOS devices
• App Package for iOS from App Store. Used to deeplink App Store apps to iOS devices
• App Package for Android (*.apk file). Used to sideload Android apps to Google Android devices.
• App Package for Android on Google Play. Used to deeplink Android apps to Android devices systems
• Web Application. Used to create a shortcut to the URL for a web app (such as https://webapp.contoso.com)

As you can see, these deployment types tend to fall into the two categories I mentioned earlier: sideloading and deeplinking. You select the particular deployment type based on the targeted device and whether you are sideloading or deeplinking the app.

However, there is one exception: Web Application. This deployment type allows you to add links (think tiles in Windows and Windows Phone) to a web app. For this deployment type, you specify the URL for the web app.

So, for example, if I wanted to deploy Skype to Windows, Windows Phone, iOS, and Android devices, I would create a Skype application, and then create a deployment type for each targeted device. The one twist is that for Windows, I would probably deploy both the desktop version by using a Windows Installer deployment type and the Windows Store version by using a deeplink to the Skype app in the Windows Store. The other deployment types would also be deeplinks to the Skype app in the respective device stores.

Application creation and deployment

Now, with all the background information, how do you actually create and deploy apps to your mobile devices? That’s the easy part! Just follow these simple steps:

1. Create a Configuration Manager application with one deployment type by completing the Create Application Wizard.
2. Create additional deployment types for each device that you want to support by completing the Create Deployment Type Wizard.
3. Deploy the Configuration Manager application to the user collections that contain your mobile users by completing the Deploy Software Wizard.

After you have deployed the Configuration Manager application, the app shows up in the Company Portal app on each device. Users can install the app and immediately start using it.

Summary

Now you seen how easy it is to deploy apps to mobile devices. System Center 2012 R2 Configuration Manager and Windows Intune can help you manage your apps throughout their life cycle. In my next, and final post in this series, I’ll talk about how to protect business data stored on mobile devices.

NEXT BLOG POST IN THIS SERIES: How-to protect business apps and data on mobile devices (Coming later today!)

Can’t be all things to all devices

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.

Compliance settings

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?

Company resource access settings

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.

Summary

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)

Device enrollment preparation

You can think of device enrollment preparation as the next logical step after preparing for MDM. But device enrollment preparation is specific to the types of devices you want to support. So, you only need to prepare for those devices that you need to support. In the next few paragraphs, I’ll walk you through each device type and how you can prepare for its enrollment.

Prepare for Windows device enrollment

To prepare your Windows Intune subscription for Windows devices, complete the following steps:

1. Enable Windows device enrollment. Enable Windows device enrollment by selecting the Enable Windows enrollment check box on the Windows tab of the Windows Intune Subscription Properties dialog box.
2. Add the code-signing certificate. You use this code-signing certificate to sign your line-of-business apps. You add the code-signing certificate on the Windows tab of the Windows Intune Subscription Properties dialog box.
3. Add sideloading keys. You add sideloading keys in the Windows Sideloading Keys node of the Software Library workspace in the Configuration Manager console.

   Sideloading keys are necessary for:

   • All Windows RT 8.1 and Windows RT devices.
   • Windows 8.1 and Windows 8 Enterprise and Pro devices that are not domain joined.

Sideloading keys are not required for the Windows 8.1 Enterprise, Windows 8.1 Pro, and Windows 8 Enterprise devices that are domain joined.

Prepare for Windows Phone device enrollment

Preparing your Windows Intune subscription for Windows Phone devices is almost as easy as for Windows devices. Complete the following steps for Windows Phone devices:

1. Register as a company developer in the Windows Phone Dev center. To be able to deploy your own apps (and specifically, the Company Portal app), you must register as a Windows Phone company developer here. You must register so that you can obtain a certificate, which is required to sign your apps (such as the Company Portal app, which you can customize and sign for your use). You must have your customized and signed Company Portal app to deploy apps to Windows Phone devices.
2. Customize, sign, and upload your Company Portal app. To sign your Company Portal app, you must obtain a code-signing certificate from the Symantec Enterprise Mobile Code Signing Certificate website. You use the code-signing certificate to sign your Company Portal app and configure your Windows Intune subscription to use the certificate.
3. Create and deploy a Microsoft System Center 2012 R2 Configuration Manager application for your Company Portal app. You create a System Center 2012 R2 Configuration Manager application based on the Company Portal app’s .xap file. Then, you deploy the app to all users in the Configuration Manager user collection for users who will be enrolling devices.
4. Enable Windows Phone device enrollment. You enable Windows Phone device enrollment by selecting the Enable Windows Phone enrollment check box on the Windows Phone tab of the Windows Intune Subscription Properties dialog box.
5. Add the application enrollment token. You obtain the application enrollment token from the Symantec Enterprise Mobile Code Signing Certificate website that you used to sign your Company Portal app. Add the application enrollment token on the Windows Phone tab of the Windows Intune Subscription Properties dialog box.
6. Select the Configuration Manager application package based on the signed Company Portal .xap file. You select the Configuration Manager application package in Application package containing signed company portal .xap on the Windows Phone tab of the Windows Intune Subscription Properties dialog box.

But what if you want to evaluate Windows Phone management? Do you have to go through all these steps? Not to fear! You can download the Support Tool for Windows Intune Trial Management of Windows Phone. This tool helps simplify the configuration process; but remember that it’s for evaluation purposes only. For production environments, use the process above.

Preparation for iOS device enrollment

Preparing for iOS device enrollment is similar to the process for Windows Phone. Here are the steps you must complete:

1. Enable iOS device enrollment. Enable iOS device enrollment by selecting the Enable iOS enrollment check box on the iOS tab of the Windows Intune Subscription Properties dialog box.
2. Specify the Apple Push Notification (APN) certificate. Obtain the APN certificate by downloading a certificate request from Windows Intune. Submit the certificate request to the Apple Push Certificate Portal, and then upload the APN certificate to Windows Intune.

Prepare for Android device enrollment (including Samsung KNOX)

To prepare for Android device enrollment (including Samsung KNOX), simply select the Enable Android enrollment check box on the Android tab of the Windows Intune Subscription Properties dialog box.

Device enrollment process

Just as with preparation for device enrollment, the device enrollment process is different for each device type. Let’s look at how you would enroll each type of device.

Windows device enrollment process

The Windows device enrollment process is the same for Windows 8.1 and Window RT 8.1 devices. Complete the following steps:

1. In PC settings, select Network, and then select Workplace.
2. In Enter your user ID to get workplace access or turn on device management, type the user’s email address, and then select Turn on.
3. In the Allow apps and services from IT admin page, select Turn on.
4. Install the Company Portal app from the Windows Store.
5. Start the Company Portal app, and sign in to Windows Intune.

It can take 5 to 10 minutes after enrollment begins before the Company Portal can be accessed.

Note If your Windows account does not have a public domain and you are using a *.onmicrosoft.com account, you will need to create a new REG_SZ registry key called DiscoveryService with the value manage.microsoft.com in the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM

Windows Phone device enrollment process

Just as with the Windows device enrollment process, Windows Phone device enrollment is slightly different for Windows Phone 8 and Windows Phone 8.1. Here are the steps you must complete:

1. Sign in to Windows Intune by performing one of the following tasks:

• For Windows Phone 8, on the Start screen, swipe in from the right, and then select settings. Select company apps, and then sign in by with the user’s email address.
• For Windows Phone 8.1, on the Start screen, swipe in from the right, and then select settings. Select Workplace, and then sign in with the user’s email address.

Note If your Windows Intune account does not have a public domain and you’re using a *.onmicrosoft.com account, you must manually enter the Windows Intune server address as manage.microsoft.com.

1. Ensure that the Install company app check box is selected after you have signed in.

iOS device enrollment process

To enroll an iOS device, complete the following steps:

1. Install the Windows Intune Company Portal app, which is available in the Apple App Store.
2. Sign in to Windows Intune by using the Windows Intune Company Portal app and your credentials.

After you have signed in to Windows Intune, you will see an exclamation point ("!").

1. Tap "!" to enroll the device.
2. Click Install on the Management Profile screen.

Android device enrollment process

Enroll an Android device (including Samsung KNOX) by completing the following steps:

1. Install the Windows Intune Company Portal app, which is available on Google Play.
2. Sign in to Windows Intune by using the Windows Intune Company Portal app and your credentials.

Summary

Well, now you know how easy it is to prepare for device enrollment and enroll devices. You can find more about device enrollment preparation and the device enrollment process for each type of device at Mobile Device Enrollment. In my next installment, I’ll discuss how to configure compliance settings for mobile devices by using System Center 2012 R2 Configuration Manager and Windows Intune.

NEXT BLOG POST IN THIS SERIES: How-to configure mobile device settings (Coming May 29)

Over the next few days, I’ll be writing a series of blog posts about mobile device management (MDM). Microsoft’s focus is on providing best-in-class mobile and cloud services.Today, everyone has a mobile device, whether it’s a tablet, convertible, laptop, or smartphone. Users are never out of touch with one another and their information. But how can we manage devices that are never in one place for long? Well, because mobile devices mostly use cloud services, the best way to manage these devices is through a cloud service.Enter Microsoft System Center 2012 R2 Configuration Manager and Windows Intune. These products provide user-centric management for devices that are mobile or at your offices. Over the next few posts, I’ll be focusing on how to use System Center 2012 R2 Configuration Manager and Windows Intune to manage your mobile devices and reduce the level of effort (and worry) you spend doing so.Watch this video to see Microsoft mobile device management in action.

Now that we’ve seen how Microsoft mobile device management works, let’s talk more about the products that are used and how they work together.

Microsoft mobile device management products

I’ll start off by talking about the products in a Microsoft MDM solution: Microsoft System Center 2012 R2 Configuration Manager and Windows Intune. Why do you need both products? The short answer is that you don’t. For example, many organizations are using System Center 2012 R2 Configuration Manager and Microsoft Exchange Server to manage their mobile devices through Microsoft Exchange ActiveSync. Other organizations use only Windows Intune to manage their on-premises and mobile devices.

So, why use both System Center 2012 R2 Configuration Manager and Windows Intune? To be able to manage all of your devices and users in one place. When you integrate these two products, you can manage users and devices regardless of whether they are in your office or out in the field, and you can do so from one management console: the Configuration Manager console. This integration allows you to manage all phases of the device life cycle, too, from device enrollment through device retirement and all phases in between.

In fact, when you enable System Center 2012 R2 Configuration Manager and Windows Intune integration, Windows Intune becomes transparent for the most part. You manage devices through System Center 2012 R2 Configuration Manager, which communicates with Windows Intune through the Windows Intune Connector in System Center 2012 R2 Configuration Manger. Windows Intune communicates with your mobile devices. Conceptually, after you set up the System Center 2012 R2 Configuration Manager–Windows Intune integration, Windows Intune appears as a logical extension of System Center 2012 R2 Configuration Manager.

So, let’s look at how to prepare for MDM by examining the prerequisites.

Mobile device management prerequisites

How do you go about creating an enterprise-class MDM solution? You need:

• System Center 2012 R2 Configuration Manager. This version of System Center Configuration Manager has all the features to manage Windows, Windows Phone, Apple iOS, and Google Android devices. System Center 2012 R2 Configuration Manager also supports the latest version of Windows Intune, which provides support for the Windows 8.1 operating system, Windows Phone 8.1, iOS 7, Android, and the Samsung KNOX Standard platform.
• Windows Intune subscription. Windows Intune subscriptions are based on the number of users you’re managing. You can manage up to five devices for each user, which means that you will need a subscription license for each user who has a mobile device. Users who don’t have a mobile device don’t require a Windows Intune subscription license.
• Public Domain Name System (DNS) domain. You must have a public-facing DNS domain that Windows Intune can verify. The Windows Intune verification process includes adding DNS records to this domain.
• Public user principle name (UPN) for users. Ensure that your users have a public UPN (such as dan). The domain portion of the UPN should match the public DNS domain that Windows Intune verified.
• Create a DNS alias for automatic enrollment. In your public-facing DNS zone, add a DNS alias (CNAME) record for EnterpriseEnrollment that points to manage.microsoft.com. For example, if the user UPN is dan, you would create a DNS record of EnterpriseEnrollment.contoso.com.
• Device certificates or keys. Each device platform (such as Windows, Windows RT, Windows Phone, or iOS) may require certificates that are specific to the platform. You will also need sideloading keys for Windows devices.
• System Center 2012 R2 Configuration Manager user collection. This user collection contains all of the users you’ll be managing through Windows Intune. You must create this collection prior to configuring your Windows Intune subscription.

For more information about these prerequisites, see Prerequisites in How to Manage Mobile Devices by Using Configuration Manager and Windows Intune.

That’s all you need as far as prerequisites. When these elements are in place, you’re ready to configure integration between System Center 2012 R2 Configuration Manager and Windows Intune.

Synchronize on-premises Active Directory with Microsoft Azure Active Directory

In most cases, you’ll have an on-premises Active Directory Domain Services (AD DS) infrastructure, which is where your user accounts are managed. Ideally, you want to provide a single sign-on experience for your users so that they can use the same credentials to access on-premises and Windows Intune services.

To do this, install and configure the Microsoft Azure Active Directory Sync Tool. This tool synchronizes the user and group accounts in your on-premises AD DS forest with Azure Active Directory (which Windows Intune uses). You install the tool on an on-premises server (virtual or physical). The installation process is wizard-driven and simple.

Configure the Azure Active Directory Sync Tool by providing:

• Administrative credentials for your Windows Intune subscription.
• Administrative credentials for your on-premises AD DS forest.
• Verification if you want to synchronize passwords for the accounts.

After you have configured the Azure Active Directory Sync Tool, it automatically starts the synchronization process. Depending on the number of users in your AD DS forest, synchronization can take a few minutes or a couple of hours. The tool continues to run and keeps both directory services in sync with each other, which helps ensure that users need to remember only one set of credentials.

You can also use Active Directory Federation Services (AD FS) with Windows Intune to enable single sign-on. Implementing single sign-on with AD FS means that password hashes do not have to be synchronized between your on-premises AD DS cloud and Azure Active Directory.

For more information about how to install and configure the Azure Active Directory Sync Tool, see Set up your directory sync computer and Directory integration. For more information about implementing Windows Intune sign-on with AD FS, see Checklist: Use AD FS to implement and manage single sign-on.

Configure the Windows Intune subscription

With the user accounts synchronized, you’re ready to configure the Windows Intune subscription in System Center 2012 R2 Configuration Manager. Windows Intune subscriptions that are:

• Integrated with System Center 2012 R2 Configuration Manager can be administered only in the Configuration Manager console.
• Not integrated with System Center 2012 R2 Configuration Manager can be administered only in the Windows Intune Administration portal.

Note You configure a Windows Intune subscription for integration with System Center 2012 R2 Configuration Manager only once. The process cannot be reversed for that subscription.

You configure the Windows Intune subscription by completing the Add Windows Intune Subscription Wizard. In that wizard, you provide the following information:

• User collection that contains users who will enroll their mobile devices
• Administrative credentials for your Windows Intune subscription
• Company name that you want to appear in the Company Portal app
• Any company logos that you want displayed in the Company Portal app
• System Center 2012 R2 Configuration Manager site code
• IT support contact information (which is displayed in the Company Portal app)
• The mobile device platforms (Windows, Windows Phone, iOS, or Android) that you want to support
• Any platform-specific configuration information

You can also configure some of these settings after you have added the Windows Intune subscription in the Configuration Manager console.

Add the Windows Intune Connector site system role

Adding the Windows Intune Connector site system role in System Center 2012 R2 Configuration Manager is like adding any other System Center 2012 R2 Configuration Manager site system role: you use the Add Site System Roles Wizard in the Configuration Manager console. You don’t have to provide configuration settings; just ensure that you select the Windows Intune Connector site system role on the System Role Selection wizard page. For more information about adding the Windows Intune Connector site system role in System Center 2012 R2 Configuration Manager, see The Windows Intune Connector Site System Role.

Enable Windows Intune extensions

Windows Intune has Configuration Manager console extensions that allow the Configuration Manager console to be aware of new capabilities. You can find these extensions in the Extensions for Windows Intune node in the Administration workspace.

For example, the iOS 7 Security Settings extension adds support for the new iOS 7 security configuration settings; the Windows Phone 8.1 Extension adds support for Windows Phone 8.1 features and management. Depending on the devices you’re managing, you may need to enable some or all of the extensions.

After you enable the Windows Intune extensions for the Configuration Manager console, close the console, and then reopen it to complete the process. When you restart the Configuration Manager console, the new features and configuration options appear.

For more information about Windows Intune extensions in System Center 2012 R2 Configuration Manager, see Planning to Use Extensions in Configuration Manager.

Summary

Now you’ve seen how easy it is to prepare for MDM by using System Center 2012 R2 Configuration Manager and Windows Intune. You can try out these steps by downloading the evaluation copy of System Center 2012 R2 Configuration Manager and signing up for a trial version of Windows Intune. In my next blog post, I’ll walk through the process of enrolling different types of devices.

NEXT BLOG POST IN THIS SERIES: Performing device enrollment (Coming May 28th)