Manage company policies on Windows Phone 8.1 via OMA-URI settings in Microsoft Intune

A bit more than a month ago, I created THE Windows Phone 8.1 Configuration Baseline for usage with ConfigMgr 2012 (integrated with Microsoft Intune). That Configuration Baseline contains all the currently configurable company policies via OMA-URI settings. At that time the management of OMA-URI settings on Windows Phone 8.1 wasn’t possible via Microsoft Intune standalone, but this has changed with the latest update to Microsoft Intune. That’s why I thought it would be good to dedicate this blog post to creating OMA-URI settings in Microsoft Intune standalone.

As it’s not possible, yet, to export a Configuration Policy in Microsoft Intune, like a Configuration Baseline in ConfigMgr, I will simply show how to create an OMA-URI setting in Microsoft Intune. Also good to know, OMA-URI settings can be used for a lot more then “just” company policies. For example, it can also be used to manage WiFi profiles. Like I mentioned in previous blog posts, and like I will keep on mentioning, all the OMA-URI settings can be found in the Windows Phone 8.1 MDM Protocol document.

Configuration

In this example configuration, I’m going to show how to create a Windows Phone OMA-URI Policy to disable cellular data roaming. The same steps are applicable to all the different OMA-URI settings that are currently available for managing company policies on Windows Phone 8.1. To disable cellular data roaming via an OMA-URI setting, simply perform the following steps:

  • MicrosoftIntune_OMAURI_AddEditLogon on to the Microsoft Intune administration console;
  • Navigate to Policy > Configuration Policies;
  • Click Add… and the Create a New Policy dialog box will show;
  • Navigate to Windows > Windows Phone OMA-URI Policy;
  • Select Create and Deploy a Custom Policy, click Create Policy and the Create Policy page will show;
  • Provide a <Name> and click Add… with OMA-URI Settings and the Add or Edit OMA-URI Setting dialog box will show.
  • Provide the following information and click OK:
    • Setting name: Allow Cellular Data Roaming;
    • Setting description: Allow or disallow cellular data roaming;
    • Data type: Integer;
    • OMA-URI (case sensitive): ./Vendor/MSFT/PolicyManager/My/Connectivity/AllowCellularDataRoaming;
    • Value: 0;
  • Click Save Policy and the Deploy Policy: <Name> dialog box will show;
  • Click Yes and the Manage Deployment: <Name> dialog box will show;
  • Select (a) group(s), click Add and click OK.

Note: It’s not necessary to create a new Windows Phone OMA-URI Policy for every OMA-URI setting. To add more OMA-URI settings to an existing policy, simply select the Configuration Policy and click Edit….

Result

In this case I really like to show the results, but not by showing a screenshot of the device. I want to do this by showing something way cooler in the Microsoft Intune administration console, I want to show the Policy tab, of the Mobile Device Properties, of a device. This tab shows an overview of the deployed policies and more importantly the status of the policies. In this case it shows that my Windows Phone 8.1 device now Conforms with the OMA-URI setting.

MicrosoftIntune_OMAURI

Further reading

More information about using OMA-URI settings with ConfigMgr (integrated with Microsoft Intune) can be found in this post about THE Windows Phone 8.1 Configuration Baseline. Additional to that post is this post about Extending the hardware inventory for PolicyManager settings on the Windows Phone 8.1. That post describes the same OMA-URI settings, but then how to add them to the hardware inventory.

More information about the configurable company polices can be found in the Windows Phone 8.1 MDM Protocol document, starting with page 140. This is a living document that gets updated by Microsoft when required. That also means that the mentioned page number might change in the (near) future.

Manage Microsoft Intune users via PowerShell

This week my blog post will contain some PowerShell again! After almost a month finally some PowerShell on my blog again. Even though Microsoft Intune has no PowerShell support, yet, there are parts that can be managed via PowerShell already. In my blog series about how to integrate Microsoft Intune and ConfigMgr with single sign-on I already showed some related PowerShell cmdlets for adding and verifying a domain name and for enabling Active Directory synchronization.

In this post I will show how to manage the Microsoft Intune users. As in the most scenario’s the users and groups will be synchronized from the on-premises Active Directory, I won’t show how to create users and groups. Instead I will show how to get information about the users, how to license the users and how to work with role memberships for users.

Prerequisites

Before I can start, with showing some PowerShell cmdlets for managing the users, it’s required to connect with the Microsoft Online Services and to get the licensing information.

Connect

The first prerequisite is that I have a Microsoft Intune subscription and that I’m connected to the Microsoft Online Services, via PowerShell. To connect to the Microsoft Online Services I can use the Connect-MsolService cmdlet, as shown below, and provide the Microsoft Intune subscription information in the  dialog box that will show directly after.

Connect-MsolService –Credential $cred

Licenses

The second prerequisite is that I have my license information available. The reason for this is simple, a part of managing users is assigning licenses and the only way to assign licenses is by knowing what’s available.  To get an overview of my licenses I can use the Get-MsolAccountSku cmdlet as shown below.

Get-MsolAccountSku

GetMsolAccountSku

Manage users

During this blog post, I’m assuming that the users are synchronized from the on-premises Active Directory, via Microsoft Azure Active Directory Sync Services, to the Azure Active Directory. When this is not the case the users can be created via the New-MsolUser cmdlet, groups can be created via the New-MsolGroup cmdlet and users can be added to a group via the Add-MsolGroupMember cmdlet.

Information

The first thing I would like to do is to check my users to see if they’re licensed and, if required, even more details about that user. To get the basic information about the user, I can use the Get-MsolUser cmdlet as shown below. In case it’s required to get more details about the user pipe the output through a Format-List.

Get-MsolUser -UserPrincipalName tvanderwoude@petervanderwoude.nl

GetMsolUser

Licensing

I can now see that this user is not licensed. There are two methods to provide this user with a license. The first method is via the Microsoft Intune Account Portal and the second method is via PowerShell. Of course I will do this via PowerShell. To add a license to this user I need the AccountSkuId and with that information I can use the Set-MsolUserLicense cmdlet as shown below.

Set-MsolUserLicense -UserPrincipalName ` tvanderwoude@petervanderwoude.nl -AddLicenses "myintunecloud:INTUNE_A"

When I would now run the Get-MsolUser cmdlet again, the isLicensed value will be set to True. Also, running the Get-MsolAccountSku cmdlet again would show that the ConsumedUnits value is set to 25. To remove the license again, I can simply use the Set-MsolUserLicense cmdlet again and replace the AddLicenses parameter with the RemoveLicenses parameter.

Roles

Another thing I would like to do is assign roles to my users. Roles are used to provide a user with specific administrative permissions within the Microsoft Intune subscription. One thing to keep in mind, with working with the different roles, is that the role names used within PowerShell are slightly different from how they are displayed in the Microsoft Intune Account Portal. The following table shows the minor differences between the role names.

MsolRole Account Portal
User Account Administrator User management administrator
Service Support Administrator Service Support Administrator
Helpdesk Administrator Password Administrator
Company Administrator Global Administrator
Billing Administrator Billing Administrator

Now I want to add this user to the Password Administrator role. To add the user to this role I can use the Add-MsolRoleMember cmdlet as shown below.

Add-MsolRoleMember -RoleName "Helpdesk Administrator" ` -RoleMemberEmailAddress "tvanderwoude@petervanderwoude.nl"

After this I would like to verify if the user is indeed a member of the Password Administrator role. To check the members of a role I can use the Get-MsolRoleMember cmdlet as shown below. One thing to keep in mind here is that this specific cmdlet requires the ObjectId of a role to be used as input parameter.

Get-MsolRoleMember -RoleObjectId ` (Get-MsolRole -RoleName "Helpdesk Administrator").ObjectId

GetMsolRoleMember

To remove an user from a role, I can do the same as with adding a user to a role. The only difference would be that the Remove-MsolRoleMember cmdlet needs to be used. The parameters are the same.

Further reading

A while ago my colleague Ronny de Jong did a blog post about a closer look at the user provisioning of Microsoft Intune. This is a very good read that describes the flow of the the user provisioning when using Microsoft Intune integrated with ConfigMgr. That post also shows how users are licensed in that scenario.

How to configure multi-factor authentication in Microsoft Intune – Part 2: The single sign-on method

MicrosoftIntune_MFA_Part2_01Last week I started this series with a blog post on How to configure multi-factor authentication in Microsoft Intune – Part 1: The easiest method, this week I’m going to take it up one level and also include single sign-on in the configuration. I will describe the multi-factor authentication configuration, for Microsoft Intune, when using single sign-on. The nice thing is that the multi-factor authentication page, in Microsoft Intune, already describes the configuration. In this post I will walk through that configuration and also show the results of that configuration, as that was a little bit surprising to me.

Scenario

Like last week it’s important to mention a couple of lines about the scenario before I’ll start with this configuration for multi-factor authentication. This specific multi-factor authentication configuration is only possible when the following situations are applicable:

  • The Mobile Device Management Authority is set to Microsoft Intune;
  • The devices to enroll are all Windows 8.1 (and newer) or Windows Phone 8.1;
  • Multi-factor authentication is only required during the device enrollment;
  • Single sign-on is used. For a basic single sign-on configuration have a look at the first three parts of this blog series. Keep in mind that Microsoft Intune should not be integrated with ConfigMgr 2012.

Configuration

Now let’s start with the configuration. The configuration is pretty straight forward and divided in two steps. The first step will describe the configuration of an additional authentication method in the on-premises Active Directory Federation Services (AD FS) and the second step will describe, like last week, the configuration in Microsoft Intune. After going through the following two steps multi-factor authentication will be enabled, in a single sign-on configuration, for device enrollment of Windows 8.1 (and newer) and Windows Phone 8.1.

Step 1

MicrosoftIntune_MFA_Part2_02The first step is to select an additional authentication method in the on-premises AD FS. I will do this by using the default certificate authentication option. To configure certificate authentication as an additional authentication method follow the next steps:

  1. Logon to the on-premises federation server and open the AD FS management console;
  2. Right-click Authentication Policies and select Edit Global Multi-factor Authentication;
  3. In the Edit Global Authentication Policy window, select Certificate Authentication with Select additional authentication methods and click OK.

Note: It’s important to not configure any additional multi-factor authentication settings. Not in the global authentication policy and not in the Microsoft Office 365 Identity Platform authentication policy. Configuring these settings will cause multi-factor authentication to be triggered for more then just the device enrollment in Microsoft Intune.

Step 2

The second step is to enable multi-factor authentication in Microsoft Intune. To configure multi-factor authentication in Microsoft Intune follow the next steps:

  1. MicrosoftIntune_MFA_Config_01Logon on to the Microsoft Intune administration console;
  2. Navigate to Administration > Mobile Device Management > Multi-factor Authentication;
  3. MicrosoftIntune_MFA_ConfigSelect Configure Multi-factor Authentication;
  4. In the Configure Multi-factor Authentication dialog box select Enable Multi-factor Authentication and click OK.

Result

The result of this configuration is as expected, in a way that multi-factor authentication is only required with the enrollment of Windows 8.1 (and newer) and Windows Phone 8.1. The one thing I noticed, and I didn’t really expect, is that multi-factor authentication will be triggered in the on-premises AD FS and in Microsoft Intune. To the end-user the behavior will be as shown in the screenshots below. During the first enrollment the end-user has to select a certificate, for the on-premises multi-factor authentication, and configure multi-factor authentication, for the Microsoft Intune service. During the next enrollments the end-user has to select a certificate, for the on-premises multi-factor authentication, and the configured multi-factor authentication method, for the Microsoft Intune service, will be used automatically.

First enrollment Next enrollments
MicrosoftIntune_MFA_Part2_03 MicrosoftIntune_MFA_Part2_03
MicrosoftIntune_MFA_01 MicrosoftIntune_MFA_07

Further reading

The first three parts of this blog series about how to integrate Microsoft Intune and ConfigMgr with single sign-on can be useful for a initial set up of AD FS. Also, this walkthrough guide about managing risks with additional multi-factor authentication for sensitive applications can be useful for configuring multi-factor authentication. That guide describes, step-by-step, the configuration of the additional authentication methods of certificate authentication and Windows Azure multi-factor authentication.

How to configure multi-factor authentication in Microsoft Intune – Part 1: The easiest method

By now I think it’s save to assume that everybody knows about the new capabilities of Microsoft Intune that where added last week. Also, next to those adjustments there were the “long” hoped for improvements to the Windows Phone 8.1 enrollment process. These new capabilities and improvements triggered me to do a new small blog series and this time about multi-factor authentication. In this blog series I will describe a few different multi-factor authentication configurations for, initially, Microsoft Intune standalone. This first part will be the easiest configuration, without anything fancy like single sign-on.

Scenario

Before I’ll start with this configuration for multi-factor authentication it’s important to mention a couple of lines about the scenario. This specific multi-factor authentication configuration is only possible when the following situations are applicable:

  • The Mobile Device Management Authority is set to Microsoft Intune;
  • The devices to enroll are all Windows 8.1 (and newer) or Windows Phone 8.1;
  • Multi-factor authentication is only required during the device enrollment;
  • Single sign-on is not used.

Configuration

Now let’s start with the configuration. The configuration is really, as mentioned in the title, easy. After the following four steps multi-factor authentication will be enabled for device enrollment of Windows 8.1 (and newer) and Windows Phone 8.1:

  1. MicrosoftIntune_MFA_Config_01Logon on to the Microsoft Intune administration console;
  2. Navigate to Administration > Mobile Device Management > Multi-factor Authentication;
  3. MicrosoftIntune_MFA_ConfigSelect Configure Multi-factor Authentication;
  4. In the Configure Multi-factor Authentication dialog box select Enable Multi-factor Authentication and click OK.

Result

The result of this configuration is actually exactly as expected, multi-factor authentication is only required with the enrollment of Windows 8.1 (and newer) and Windows Phone 8.1. To the end-user the behavior will be as shown in the screenshots below. During the first enrollment the end-user has to configure multi-factor authentication (either via phone or via an app) and during the next enrollments the configured multi-factor authentication method will be used automatically.

First enrollment Next enrollments
MicrosoftIntune_MFA_01 MicrosoftIntune_MFA_07

Further reading

Around the time that I came-up with this blog series Peter Daalmans also posted a blog post about multi-factor authentication with Microsoft Intune. Luckily (for me) he describes a different scenario then the ones I’ll cover in this series, but it’s a good and related read.

Extend the Hardware Inventory for PolicyManager settings on Windows Phone 8.1

This blog post will be a follow-up on last weeks blog post about THE Windows Phone 8.1 configuration baseline, as I will show this week how those settings can be added to the hardware inventory. Especially with using multiple configuration baselines and Company Resource Access policies, it’s easy to loose track of the current configuration of, in this case, Windows Phone 8.1. That’s why I  took the information about the PolicyManager configuration service provider (CSP),  again, as provided in the Windows Phone 8.1 MDM Protocol document, but this time to create a MOF file.

Hardware Inventory settings

By default ConfigMgr (and Microsoft Intune) will inventory a lot of great information, but not about the settings managed via the PolicyManager. That is why I created a MOF file for all the settings in the PolicyManager and that MOF file can be used to extend the current hardware inventory. A good thing to note here is that only settings that are currently configured via the PolicyManager will be available for the hardware inventory. This MOF file will contain all reporting string like the following example about the Allow Cellular Data Roaming setting.

[SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/PolicyManager/My/Connectivity/AllowCellularDataRoaming”)] String Allow_Cellular_Data_Roaming;

HardwareInventoryMOFThis MOF file adds the inventory information for the following settings:

  • Allow 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;
  • Allow Copy-Paste;
  • Allow Cortana;
  • Allow 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;
  • Allow 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;
  • Application 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 MOF file, for extending the hardware inventory on 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 MOF file accordingly. 

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

To use this MOF file, simply download it and import it in ConfigMgr. After this the different settings can be added to the hardware inventory.

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

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