THE Windows Phone 8.1 Configuration Baseline

This blog post will be about THE Windows Phone 8.1 configuration baseline, for usage with ConfigMgr 2012 (integrated with Microsoft Intune). This configuration baseline is created based on the information provided in the Windows Phone 8.1 MDM Protocol document. That document describes the PolicyManager configuration service provider (CSP), which is the centralized component to handle all Windows Phone supported enterprise policies. It describes in detail every currently configurable policy, by any mobile device management solution.

Configuration Items

imageI took all the settings, as described in the Windows Phone 8.1 MDM Protocol document, and created separate configuration items for each one of them. In these configuration items I included all the available information about the specific settings, including their descriptions. Based on the possible values of these settings I created a compliance rule with every configuration item, which I configured to the default values. In the compliance rules I also included the information about the possible values.

This baseline contains the following configuration items:

  • imageAllow Action Center Notifications;
  • Allow Adding Non-Microsoft Accounts Manually;
  • Allow Auto Connect To WiFi Sense Hotspots;
  • Allow Bluetooth;
  • Allow Browser;
  • Allow Camera;
  • Allow Cellular Data Roaming;
    • The configuration of this specific item is shown in the screenshots on the side. This is done to provide an example about the configuration of the different items.
  • Allow Copy-Paste;
  • Allow Cortana;
  • imageAllow Developer Unlock;
  • Allow Idle Return Without Password;
  • Allow Internet Sharing;
  • Allow Location;
  • Allow Manual MDM Unenrollment;
  • Allow Manual Root Certificate Installation;
  • Allow Manual WiFi Configuration;
  • Allow Microsoft Account Connection;
  • Allow NFC;
  • Allow Save As of Office Files;
  • Allow Screen Capture;
  • Allow Search To Use Location;
  • Allow Sharing of Office Files;
  • Allow Simple Device Password;
  • imageAllow Storage Card;
  • Allow Store;
  • Allow Storing Images From Vision Search;
  • Allow Sync My Settings;
  • Allow Telemetry;
  • Allow USB Connection;
  • Allow User To Reset Phone;
  • Allow Voice Recording;
  • Allow VPN Over Cellular;
  • Allow VPN Roaming Over Cellular;
  • Allow WiFi;
  • Allow WiFi Hotspot Reporting;
  • Alphanumeric Device Password Required;
  • imageApplication Restrictions;
  • Device Password Enabled;
  • Device Password Expiration;
  • Device Password History;
  • Maximum Device Password Failed Attempts;
  • Maximum Inactivity Time Device Lock;
  • Minimum Device Password Complex Characters;
  • Minimum Device Password Length;
  • Require Device Encryption;
  • Safe Search Permissions.

Available for download

Starting today this configuration baseline for Windows Phone 8.1 is available for download via the TechNet Galleries. Keep in mind that it contains the currently configurable enterprise policies that can be used to manage these devices. When this gets updated, I’ll try to update the configuration baseline accordingly. 

>> The complete configuration baseline is available in the TechNet Galleries! <<

To use this configuration baseline, simply download it and import it in ConfigMgr. After this the compliance rules can be adjusted, if needed, and the baseline can be deployed.

Further reading

The information about the configurable enterprise polices can be found in the Windows Phone 8.1 MDM Protocol document, starting with page 132. As mentioned before, this document is available for downloaded here: http://go.microsoft.com/fwlink/?LinkID=279003

Blog series about how to integrate Microsoft Intune and ConfigMgr with Single Sign-On

A few weeks ago I did a blog post about How to configure a relying party trust between on-premises AD FS and Microsoft Azure AD for single sign-on in Microsoft Intune. Based on that blog post I’ve got a lot of feedback of people mentioning that it was a great post, but that they would like to see the complete picture. That made me decide to create a step-by-step guide for a basic lab setup of Microsoft Intune and ConfigMgr with single sign-on. Starting today the complete series is online on windows-noob. I’ve sliced this guide in to the following four pieces:

  1. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 1: Introduction and prerequisites;
    • This first part is about what this blog series will deliver and what the prerequisites are that need to be in place.
  2. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 2: Install and configure Active Directory Federation Service;
    • This second part is about installing and configuring AD FS, WAP and single sign-on.
  3. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 3: Configure directory synchronization;
    • This third part is about configuring the synchronization of the on-premises user accounts to the Azure AD.
  4. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 4: Integrate ConfigMgr and Microsoft Intune;
    • This fourth part is about integrating Microsoft Intune with ConfigMgr to leverage the single sign-on experience.

Available for download

As a small extra for those reading my blog, I’ve also created a PDF that contains the content of this blog series. Starting now this PDF is available for download on the TechNet Galleries.

>> The complete PDF is available via download in the TechNet Galleries! <<

How to troubleshoot Windows Phone 8.1 enrollment via Microsoft Intune

In this blog post I want to put a spotlight on the troubleshooting of Windows Phone 8.1 enrollment in Microsoft Intune (with or without ConfigMgr integration). The problem with Windows Phone enrollment was that there was little to no log information about the enrollment process, but that has changed with Windows Phone 8.1. Before Windows Phone 8.1 there were only some log files (like the dmpdownloader) when the integration with ConfigMgr was used, but in most occasions they wouldn’t show helpful information.

Starting with Windows Phone 8.1 this has changed and there is the ability to get some logging of the mobile device. It’s not an easy process, and probably not an option in every situation,  but it will help to verify the health of the environment. Starting with Windows Phone 8.1 it’s possible to get logging during the device enrollment, during the certificate enrollment and during the VPN configuration. The minor detail is that the Windows Phone needs to be an emulator image, or a developer unlocked retail device.

Prerequisites

Before I will start with the steps to collect and view the logging of a Windows Phone device, it is important to have the following prerequisites in place:

Step 1: Collect the Enterprise Management logging

The first step in troubleshooting, starting with Windows Phone 8.1, is to collect the logging of the device. Since Windows Phone 8.1 and the Windows Phone Developer Power Tools 8.1 it is possible to get some logging when the mobile device is connected to the desktop, or laptop, running the tools. To collect the logging, perform the following steps:

  1. WP_DPTStart the Windows Phone Developer Power Tools 8.1;
  2. Select Device and click Connect;
  3. Select the Performance Recorder –tab, navigate to Extras and select Enterprise Management;
  4. Click Start to start the collecting of the logging;
  5. Perform the Windows Phone 8.1 enrollment;
  6. Click Stop to stop the collection of the logging and save the collected logging locally.

Step 2: View the Enterprise Management logging

The second step in troubleshooting, starting with Windows Phones 8.1, is to view the logging of the device. The captured logging is saved in an ETL format and can be opened with the Windows Performance Analyzer (WPA). To view the logging, perform the following steps:

  1. WPA_GEVEStart the Windows Performance Analyzer and open the collected logging.
  2. In the Graph Explorer, expand System Activity and double-click Generic Events.
  3. In the Analysis –tab, click Open View Editor (image).
  4. In the Generic Events View Editor, select at least Message and click Apply.
  5. Back in the Analysis –tab, the Message column will provide the detailed (error) information per provider.
  6. For device enrollment the logged information will be available in the provider named Microsoft-WindowsPhone-Enrollment-API-Provider.

Note: For troubleshooting SCEP certificate enrollment the provider will be named Microsofot-WindowsPhone-SCEP-Provider and for troubleshooting VPN configuration the provider will be named Microsoft-WindowsPhone-CmCspVpnPlus.

Result

The following picture will show an example of the logging collected of a Windows Phone 8.1 device, while enrolling the device in Microsoft Intune/ ConfigMgr. The error message 0x80090016 pointed me straight to certificate issues. The only “variable” certificates that are being used during the enrollment are used to sign the company portal. After resigning my company portal the problem was solved. This was a lot easier troubleshooting then the default message on a Windows Phone mobile device.WPA_Message

Further reading

This information an much more can be found in the Windows Phone 8.1 management bible, which can be downloaded here: http://go.microsoft.com/fwlink/?LinkID=279003

How to configure a relying party trust between on-premises AD FS and Microsoft Azure AD for single sign-on in Microsoft Intune

ADFS_SSOOne of the things that is often requested by customers is to configure single sign-on for Microsoft Intune (with or without ConfigMgr integration). The main reasons for that request are simple, it’s to make the user experience better and to prevent the user from having different accounts and passwords. In this blog post I will show how relatively easy it is to federate on-premises Active Directory Federation Services (AD FS) with the Microsoft Azure Active Directory (Micorosoft Azure AD). The best thing about this is that after this configuration is done, all Microsoft Intune authentication requests will redirect to the on-premises AD FS.

Also, in this post I will skip a few important steps (see prerequisites). I assume that those steps are more common knowledge. If that’s not the case, please let me know.

Prerequisites

A few important installations and configurations should be in place before trying to use the configuration mentioned further in this post. To be able to configure a relying party trust between the on-premises AD FS and the Microsoft Azure AD make sure that following installations and configurations are in place:

Configuration

When all the prerequisites are in place, it’s time to start with creating the federation. In a maximum of six relatively simple steps it is possible to create a relying party trust between the on-premises AD FS and the Microsoft Azure AD. This trust will make sure that the Microsoft Azure AD will trust the authentication response of the on-premises AD FS. The easiest method to create this trust is to use PowerShell. In the following six steps I will name the required cmdlets and explain the actions that it will perform.

  1. The first step is to make sure that the Microsoft Azure Active Directory PowerShell Module is installed.
  2. The second step is to load the cmdlets by either starting Microsoft Azure Active Directory Module for Windows PowerShell, or by importing the module via the following command.
    Import-Module MSOnline

  3. The third steps is to connect to the Microsoft Azure AD (used by Microsoft Intune) by using the cmdlet Connect-MsolService. An easy method to provide the required credentials, to connect to the Micosoft Azure AD, is to use an empty variable. This empty variably will make sure that the cmdlet prompts for the credentials of the Microsoft Intune subscription. Simply use the –Credentials parameter to specify the credentials (parameter) by running a command like the following.
    Connect-MsolService –Credential $cred

  4. (Optional) The fourth step is to connect to the on-premises primary AD FS server by using the cmdlet Set-MsolADFSContext. Simply use the –Computer parameter to specify the name of the on-premises primary ADFS server by running a command like the following.
    Set-MsolADFSContext -Computer cldsrv01.ptcloud.local

  5. The fifth step is to add a new single sign-on domain, also known as an identity-federated domain, to the Microsoft Azure AD by using the cmdlet New-MsolFederatedDomain. This cmdlet will perform the real action, as it will configure a relying party trust between the on-premises AD FS server and the Microsoft Azure AD. Simply use the –DomainName parameter to specify the name of the single sign-on domain by running a command like the following.
    New-MsolFederatedDomain –DomainName petervanderwoude.nl

  6. (Optional) The sixth step is to convert the domain from standard authentication to single sign-on, also known as identity-federated, by using the cmdlet Convert-MsolDomainToFederated.  This cmdlet will perform the real action, as it will convert the domain from standard authentication to single sign-on and also configures a relying party trust between the on-premises ADFS server and the Microsoft Azure AD. Simply use the –DomainName parameter to specify the name of the single sign-on domain by running a command like the following. 
    Convert-MsolDomainToFederated –DomainName petervanderwoude.nl

Note: Step 4 is only required when the cmdlets are not used locally on the AD FS server and step 6 is only required if the new single sign-on domain already exists as a standard authentication domain. In that last case a very clear message stating New-MsolFederatedDomain : The domain already exists as a standard authentication domain.  To convert the domain to identity federation, use convert-MSOLDomainToFederated. will show after performing step 5.

Result

ADFS_exampleAfter setting up the federation with Microsoft Azure AD, every logon to one of the Microsoft Online Services will redirect to the on-premises AD FS when a user name with the UPN of @petervanderwoude.nl is used. This includes Microsoft Intune. For demonstration purposes I can go to https://admin.manage.microsoft.com/ to see if it all works. As soon as I use an user account with the @petervanderwoude.nl UPN, the login page will automatically redirect to the on-premises AD FS server. This way the credentials will be verified on-premises.

Other places to see the successful configuration are in the Account Portal of Microsoft Intune, in the on-premises AD FS configuration and of course via PowerShell by using the cmdlet Get-MsolFederationProperty.

Further reading

A simplified installation guide for single sign-on for Office 365: http://technet.microsoft.com/en-us/magazine/jj631606.aspx

A checklist to use AD FS to implement and manage single sign-on: http://technet.microsoft.com/en-us/library/jj205462.aspx

A scenario about managing identities for single-forest hybrid environments using on-premises authentication: http://technet.microsoft.com/library/dn550987.aspx