Note: a web clip is a custom icon that is displayed on a user’s home screen. Users tap the icon to reach your web content in one easy step.
Problem
Due to the Apple App Store submission guidelines, line-of-business apps deployed through Windows Intune cannot be viewed from the Windows Intune Company Portal app for iOS. When these types of apps are deployed as an optional install, they are only visible from the Mobile Web Portal (MWP) on an iOS device.
Information workers need a way to discover additional apps through the Mobile Web Portal (MWP) easily.
Solution
Create and deploy a web clip to end users that links to the Mobile Web Portal which contains any optional line-of-business apps available for the user.
Scenario
You decide to start supporting in-house apps for iOS.
You want to provide a shortcut into the Mobile Web Portal for use on an iOS device.
Download a file containing the web clip properties.
Download and import an “App Package” that contains all of the localized strings for the web clip.
Instruction
Use these instructions to create and deploy a web clip for iOS devices that opens the MWP.
System Center Configuration Manager Deployment
Open the Configuration Manager Console
In the Software Library workspace, click Applications, then click Create Application
In the Type drop-down list, select Web Application
For location, enter . Click Next >
After reviewing the imported information on the next screen, click Next > again
In the Name: box, enter a name, such as Get Apps. Fill out the remaining fields accordingly
Click Next, review the results And then click Next again
Click Close to exit the wizard
Select the application and then click Deploy (right-click or in ribbon)
Windows Intune Deployment
Open the Windows Intune administrator console
Publish a web app with the URL, , through the Windows Intune Software Publishing Application
Providing users with easy access to the MWP ensures that everyone has access to the apps they need. Creating and deploying a web clip for iOS devices is a simple and effective way to accomplish this goal.
Posted on: Friday, May 30, 2014 3:06 PM Author: micham Subject: Sideloading Store Apps to Windows 8.1 DevicesView article…The term sideloading refers to the installation of Store Apps by an IT Administrator on a Windows device. Typically, the App in question is a line of business (LOB)application that is internal to the company. Therefore, the company (maybe your customer if you are and ISV) will want to make it available only to its employees rather than making it publically accessible Windows Store. This is not to say that there are no LOB Store Apps published in the Windows Store. Have a look at the SAP client Apps, for example.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:
“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.
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.
PartNumber
PartDesc
4UN-00005
WinSideloadingRights SNGL OLP NL Qlfd
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
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
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:
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.
Of course, security is always best implemented as defense in-depth, which simply means setting up multiple layers of security to protect your information. One of the first things you want to do is prevent unauthorized access by implementing strong password (PIN) compliance settings.
System Center 2012 R2 Configuration Manager supports several password compliance settings to help protect devices:
Requiring passwords
Minimum password length
Password history
Idle time before the device is locked (and requires password to unlock)
Number of failed logons before the device is wiped.
Another area in a comprehensive defense in-depth security approach is protecting the data already on the device. This level of protection is centered on encryption of either individual files or the entire device. Some devices (such as Windows and Windows Phone devices) support encryption of internal storage, while others encrypt individual files only.
Another possible source of leaked information is the secure digital (SD) card that some devices support. One approach is to disable the SD card slot entirely, but this isn’t practical for personally owned devices in Bring Your Own Device scenarios. Some devices (such as Windows Phone) create an encryption partition for any apps or data stored on the SD card. User data is still stored on an unencrypted partition on the SD card.
Again, you can configure these settings by using System Center 2012 R2 Configuration Manager configuration items (CIs) and baselines (see part three of this series: how-to configure mobile device settings).
Finally, some devices (such as Windows and Windows Phone devices) support Information Rights Management (IRM), which allows users to protect access to information used in apps. For example, you can use IRM to protect email conversations, prevent unauthorized users from opening a document, or prevent forwarding of email messages. Just as with other settings, you can configure IRM by using System Center 2012 R2 Configuration Manager CIs and baselines.
Communication protection
Another aspect of security that is often overlooked is protecting communication between the device and the information on your intranet. This protection can be broken down into strong authentication protocols and encrypting communication.
Many new device operating systems support Trusted Platform Module chips and virtual smart cards. You can use these technologies to provide stronger authentication and protection of certificates and PINs.
Also, ensure that all virtual private network (VPN) connections to your intranet use strong authentication protocols and require encryption. You can push VPN connection profiles to devices based on your organization’s security standards.
Again, you can configure all of these things by using System Center 2012 R2 Configuration Manager CIs and baselines (see my previous blog post, “Configuring mobile device settings”).
Remotely remove business apps and data
So, what happens if the device is lost or stolen? Or, what if a user is dismissed while they still have a mobile device with your information? Not to fear! System Center 2012 R2 Configuration Manager and Windows Intune allow you to remotely:
Wipe the entire device. Restore the device to factory settings and remove all apps and data (that your organization and the user installed). Built-in apps and data are restored to factory defaults, as well.
Remove only your organization’s apps, data, and configuration settings. Remove only the apps, data, and configuration settings deployed through your MDM system from the device. Any user-owned data and apps are retained.
Of course, most device vendors allows users to locate and remotely wipe their own devices by using a device-specific web app (such as Find My iPhone for Apple iOS devices or Find My Phone for Windows Phone devices). And if the user has physical access to the device, they can do a hardware reset, which restores the device to factory settings and removes all data. The ability to remotely remove business apps and data is essential for any comprehensive MDM system!
Summary
Protecting business apps and data is critical for mobile devices that are “out in the wild.” But you can sleep easier by using the protection that System Center 2012 R2 Configuration Manager and Windows Intune provide. Regardless of the device platform, you can set security baselines that can be applied across them all to help prevent information theft or disclosure.
This wraps up my series of blogs on MDM by using System Center 2012 R2 Configuration Manager and Windows Intune. I bet you can’t wait to try them both, so I have good news for you. You can download an evaluation version of System Center 2012 R2 Configuration Manager and a trial subscription of Windows Intune to experience what I’ve been talking about for yourself. Thank you for reading this series. Until next time!
Posted on: Friday, May 30, 2014 3:06 PM Author: micham Subject: Sideloading Store Apps to Windows 8.1 DevicesView article…The term sideloading refers to the installation of Store Apps by an IT Administrator on a Windows device. Typically, the App in question is a line of business (LOB)application that is internal to the company. Therefore, the company (maybe your customer if you are and ISV) will want to make it available only to its employees rather than making it publically accessible Windows Store. This is not to say that there are no LOB Store Apps published in the Windows Store. Have a look at the SAP client Apps, for example.
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:
“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.
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.
PartNumber
PartDesc
4UN-00005
WinSideloadingRights SNGL OLP NL Qlfd
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
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
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:
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:
Create a Configuration Manager application with one deployment type by completing the Create Application Wizard.
Create additional deployment types for each device that you want to support by completing the Create Deployment Type Wizard.
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!)
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.
Profile type
Description
Certificate
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.
VPN
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.
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.
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)
Posted on: Wednesday, May 28, 2014 11:00 AM Author: Enterprise Mobility Team View article…
In today’s post, I continue my discussion of mobile device management (MDM). In my last post preparing for mobile device management, I described how to prepare for MDM. Now, I talk about how to prepare for and execute device enrollment for Windows, Windows Phone, Apple iOS, and Google Android devices. Let’s start off by talking about how you prepare for device enrollment.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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:
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.
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:
In PC settings, select Network, and then select Workplace.
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.
In the Allow apps and services from IT admin page, select Turn on.
Install the Company Portal app from the Windows Store.
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:
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:
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.
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:
Install the Windows Intune Company Portal app, which is available in the Apple App Store.
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 ("!").
Tap "!" to enroll the device.
Click Install on the Management Profile screen.
Android device enrollment process
Enroll an Android device (including Samsung KNOX) by completing the following steps:
Install the Windows Intune Company Portal app, which is available on Google Play.
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.
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.
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.
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)