Custom terms and conditions for using the Company Portal of Microsoft Intune

Updated September 8, 2015: Since the August 2015 update of Microsoft Intune the creation and deployment of custom Terms and Conditions has changed. An update blog post can be found here: https://www.petervanderwoude.nl/post/multiple-custom-terms-and-conditions-for-device-enrollment-and-company-access/

And we’re back in the cloud, back in Microsoft Intune. One of the things customers like to do is customize, as the standards are often to generic. The nice thing with the Company Portal is that it’s already possible to customize things like the text, logo and colors via both Microsoft Intune standalone and Microsoft Intune hybrid (integrated with ConfigMgr). To add-on to that, it’s now also possible to create custom Terms and Conditions, via Microsoft Intune standalone, and in this blog post I’ll show how easy this can be done.

The nice thing is that I can publish custom Terms and Conditions that the users will see when they first use the Company Portal. It doesn’t matter from which device and it doesn’t matter if that device is already enrolled or not. The users will have to accept the custom Terms and Conditions before they can access the Company Portal. What makes it even better is that when I update the custom Terms and Conditions, I can choose if I want the users to accept the new Terms and Conditions again. In that case the user would have to go through the same process again when logging on to the Company Portal.

The last positive note, for now, about custom Terms and Conditions, that I would like to point out, is that they apply to users and not to devices. That means that the users only has to accept each version once.

Configuration

Now let’s go on with the configuration, which, to be quite hones, is not very difficult, but good to know. I’ll go through the different settings and I’ll also try to show the behavior of the different settings. First let’s go through the different available settings, by going through the following three steps.

  1. Logon on to the Microsoft Intune administration console;
  2. Navigate to Admin > Company Portal > Terms and Conditions;
  3. Select Require users to accept company terms and conditions before using the Company Portal, provide the following information and click Save:
    • Title: <Provide a title for the custom terms and conditions>
    • Text for terms: <Provide a text for the custom terms and conditions>;
    • Text to explain what it means if the user accepts: <Provide a text describing what it means when the user accepts the custom terms and conditions>;
    • With Decide whether to require users to re-accept updated terms select one of the following options:
      • Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal;
      • Keep the current version number, and require only new users to accept the updated terms;

In my opinion the most important setting is the last setting of the third step. With that specific setting I can decide what happens when I update the custom Terms and Conditions. Let me show that setting in a bit more detail by showing an example. When I create initial custom Terms and Conditions, it will look like the following screenshots that include an example of what it looks like on Windows Phone 8.1.

Configuration Windows Phone 8.1 Example
CompPortTC_v1 TC_v1

Now let’s have a look at what will happen when I update the custom Terms and Conditions. When I update the custom Terms and Conditions and select Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal the version number will increase and it will directly impact the users as shown in the following screenshots.

Configuration Windows Phone 8.1 Example
CompPortTC_v2 TC_v2

When I update the custom Terms and Conditions and select Keep the current version number, and require only new users to accept the updated terms nothing will change for the end user. Simple conclusion is that a major change should always require an increase of the version number.

Besides accepting the custom Terms and Conditions the user can, off course, also decline them. In that case the user will be given an additional question of Are you sure you want to decline the terms and conditions?, including an explanation of what it would mean for the user.

Report

Now the last thing I would like to know is which users accepted the custom Terms and Conditions. The good thing is that Microsoft Intune standalone has a canned report that shows which users accepted the custom Terms and Conditions. This includes the information about the most recent version number that the user accepted and the date and time it was accepted. For example, below are two examples about a user that accepted the initial custom Terms and Conditions and later also accepted the renewed custom Terms and Conditions.

Initial version Increased version
TC_Report_v1 TC_Report_v2

Windows Phone 8.1 Kiosk mode: Inside AssignedAccessXml

Let’s start my first blog post of this new year with a nice story about a XML that can be used to configure a Windows Phone 8.1 device in a kiosk mode. This XML can be applied on a Windows Phone 8.1 device via OMA-URI settings. As it’s now possible to configure OMA-URI via Microsoft Intune and via Microsoft Intune integrated with ConfigMgr 2012, the information in the post is applicable to both scenario’s. I have to admit that it’s not as simple to configure as kiosk mode for an iOS device, or an Andriod device (via Microsoft Intune), but it does provide a lot more options to configure. In this blog post I will go through the different required elements of the XML and the different configuration options.

<Apps>

The first required element is <Apps>. The list of applications listed in this element is an allowed list of applications. That means that only the listed applications are visible to the end-user. To add applications to this list the productId of an application is required.  The following table shows the productId of the default applications, also known as first party applications.

Application ProductId
Alarms  {5B04B775-356B-4AA0-AAF8-6491FFEA560A}
Battery Saver {C551F76F-3368-42BB-92DF-7BFBB9265636}
Bing Finance  {1E0440F1-7ABF-4B9A-863D-177970EEFB5E}
Bing Food  {CC512389-0456-430F-876B-704B17317DE2}
Bing Health  {CBB8C3BD-99E8-4176-AD8C-95EC6A3641C2}
Bing News {9C3E8CAD-6702-4842-8F61-B8B33CC9CAF1}
Bing Sports {0F4C8C7E-7114-4E1E-A84C-50664DB13B17}
Bing Travel {19CD0687-980B-4838-8880-5F68ABA1671E}
Bing Weather {63C2A117-8604-44E7-8CEF-DF10BE3A57C8}
Calculator  {5B04B775-356B-4AA0-AAF8-6491FFEA5603}
Calendar  {36F9FA1C-FDAD-4CF0-99EC-C03771ED741A}
Camera (built-in) {5B04B775-356B-4AA0-AAF8-6491FFEA5631}
Cortana  {5B04B775-356B-4AA0-AAF8-6491FFEA568C}
Data Sense  {5B04B775-356B-4AA0-AAF8-6491FFEA5646}
Email {5B04B775-356B-4AA0-AAF8-6491FFEA5614}
Facebook {0C340A67-3288-4C76-9375-0F2FEFBA0412}
Games {50A6AEF0-4F35-434B-9308-CB3251303AE4}
Internet Explorer {5B04B775-356B-4AA0-AAF8-6491FFEA5660}
Maps {5B04B775-356B-4AA0-AAF8-6491FFEA5686}
Messaging  {5B04B775-356B-4AA0-AAF8-6491FFEA5610}
Music {D2B6A184-DA39-4C9A-9E0A-8B589B03DEC0}
Office Hub {5B04B775-356B-4AA0-AAF8-6491FFEA561E}
OneDrive {AD543082-80EC-45BB-AA02-FFE7F4182BA8}
OneNote {5B04B775-356B-4AA0-AAF8-6491FFEA561B}
People {5B04B775-356B-4AA0-AAF8-6491FFEA5615}
Phone  {5B04B775-356B-4AA0-AAF8-6491FFEA5611}
Photes {5B04B775-356B-4AA0-AAF8-6491FFEA5632}
Podcasts  {C3215724-B279-4206-8C3E-61D1A9D63ED3}
Settings  {5B04B775-356B-4AA0-AAF8-6491FFEA5601}
Storage Sense {5B04B775-356B-4AA0-AAF8-6491FFEA564D}
Store  {5B04B775-356B-4AA0-AAF8-6491FFEA5633}
Video {6AFFE59E-0467-4701-851F-7AC026E21665}
Wallet {5B04B775-356B-4AA0-AAF8-6491FFEA5683}

The productId of the all the other applications, also known as third party applications, can be found in the Windows Phone Store. Simply navigate to the store and select the required application. This will display an URL that includes the productId. For example see the screenshot below that shows a productId of 3a509cd-61d6-df11-a844-00237de2db9e for the Netflix application.

NetflixUrl

The nice thing is that this isn’t everything that can be configured for the applications. It’s also possible to pin the applications to start by using the <PinToStart> element. When this element is used it’s also required to specify the size and location of the application by using the <Size> and the <Location> elements. The size can be small, medium and large. The location can be provided by using the <LocationX> and the <LocationY> elements. Good to know with those elements is that they start the first line with 0. This all together can make the <Apps> element look like this:

<Apps> <Application productId="{3a509cd-61d6-df11-a844-00237de2db9e}"> <PinToStart> <Size>Medium</Size> <Location> <LocationX>0</LocationX> <LocationY>2</LocationY> </Location> </PinToStart> </Application> </Apps>

<Buttons>

The next required element is <Buttons>.  The buttons in this element can be part of two groups. One group is to lock down the button, which prevents the button from being used and the other group is to remap the button to start an application. To add buttons to this element the XMLname of the button is required.  The following table shows the XMLname of the different buttons an the supported actions.

Button XML name  Block and Override Remap
Camera  Camera  Supported No
Back Back Not supported No
Start (Windows Key) Start Supported No
Search Search Supported Yes (App launch)
Volume Up Not supported No
Volume Down Not supported No
Power Not supported No

Like I mentioned the buttons can be configured  to be locked and to be remapped. This can be configured by using the <ButtonLockdownList> and <ButtonRemapList> elements. Within both elements the <ButtonEvent> element can be used to specify which button event should be locked or be remapped. This event can be Press and/ or PressAndHold. Within the remap event it’s possible to specify an application by using the earlier mentioned productId. This all together can make the <Buttons> element look like this:

<Buttons> <ButtonLockdownList> <Button name="Start"> <ButtonEvent name="PressAndHold" /> </Button> <ButtonRemapList> <Button name="Search"> <ButtonEvent name="Press"> <Application productId= "{3a509cd-61d6-df11-a844-00237de2db9e}" /> </ButtonEvent> </Button> </ButtonRemapList> </ButtonLockdownList> </Buttons>

<Settings>

The next required element is <Settings>. This element is an allowed list for the system and application items from the settings menu. That means that only the listed system and application items are visible to the end-user. To add a system or application item to this list the <System> or the <Application> element can be used with the XMLname of the required system or application item.  The following table shows the XMLname of the default system and applications items.

Element Settings name XML name
System about Microsoft.About
System ease of access Microsoft.Accessibility
System email+accounts Microsoft.Accounts
System advertising id Microsoft.AdvertisingId
System airplane mode Microsoft.AirplaneMode
System battery saver Microsoft.BatterySaver
System Bluetooth Microsoft.Bluetooth
System brightness Microsoft.Brightness
System Cellular+SIM Microsoft.CellularConn
System backup Microsoft.CloudStorageCpl
System workplace Microsoft.CompanyAccount
System date+time Microsoft.DateTime
System quiet hours Microsoft.DoNotDisturb
System driving mode Microsoft.DrivingMode
System feedback Microsoft.Feedback
System find my phone Microsoft.FindMyPhone
System kids corner Microsoft.KidZone
System language Microsoft.Language
System location Microsoft.Location
System project my screen Microsoft.MirrorUX
System notifications+actions Microsoft.NocenterSettings
System lock screen Microsoft.PhoneLock
System region Microsoft.Regional
System sync my settings Microsoft.RoamingCpl
System screen rotation Microsoft.RotationLock
System internet sharing Microsoft.SoftAP
System ringtones+sounds Microsoft.Sounds
System speech Microsoft.Speech
System storage sense Microsoft.StorageSettings
System start+theme Microsoft.Themes
System keyboard Microsoft.TouchKeyboard
System phone update Microsoft.Updates
System VPN Microsoft.VPN
System Wi-Fi Microsoft.WiFi
System NFC Microsoft.NFC
System USB Microsoft.USB
System data sense Microsoft.DataSmart
Application internet explorer Microsoft.IE
Application maps Microsoft.Maps
Application messaging Microsoft.Messaging 
Application Office Microsoft.OfficeMobile 
Application people Microsoft.Contacts 
Application phone Microsoft.Phone 
Application photos+camera Microsoft.Photos 
Application search Microsoft.Search 
Application store Microsoft.Marketplace 
Application wallet Microsoft.Wallet 
Application cortana Microsoft.AssistUX

This all together can make the <Settings> element look like this:

<Settings> <System name="Microsoft.CompanyAccount" /> <Application name="Microsoft.AssistUX" /> </Settings>

<ActionCenter>

The next required element is <ActionCenter>. This element can be used to enable or disable access to the quick settings and notifications, by specifying a value of true or false. This can make the <ActionCenter> element look like this:

<ActionCenter enabled="false" />

<MenuItems>

The next required element is <MenuItems>. This element can be used to prevent menu items from being resized, moved or pinned to start. That will give the end-user the complete locked down experience, as nothing can be adjusted anymore. Within this element the <DisableMenuItems> element can be used to prevent the menu items from be changed. This can make the <MenuItems> element look like this:

<MenuItems> <DisableMenuItems /> </MenuItems>

<StartScreenSize>

The last required element is <StartScreenSize>. This element can be used to configure the size of the start screen. The supported sizes are small, medium and large. Medium and large represent 3-column start views, while small represents a 2-column start view . Besides that, small and medium are for 720-pixel or lower resolution displays, while large is for 1080-pixel or higher resolution displays. This can make the <StartScreenSize> element look like this:

<StartScreenSize>Large</StartScreenSize>

<HandheldLockdown>

The previous six elements come together in the <Default> element, which is located in the top level element named <HandheldLockdown>. Those six elements must always be part of the XML. This makes the complete example of this post look like this:

<?xml version="1.0" encoding="utf-8"?> <HandheldLockdown version="1.0" > <Default> <Apps> <Application productId= "{3a509cd-61d6-df11-a844-00237de2db9e}"> <PinToStart> <Size>Medium</Size> <Location> <LocationX>0</LocationX> <LocationY>2</LocationY> </Location> </PinToStart> </Application> </Apps> <Buttons> <ButtonLockdownList> <Button name="Start"> <ButtonEvent name="PressAndHold" /> </Button> <ButtonRemapList> <Button name="Search"> <ButtonEvent name="Press"> <Application productId= "{3a509cd-61d6-df11- a844-00237de2db9e}" /> </ButtonEvent> </Button> </ButtonRemapList> </ButtonLockdownList> </Buttons> <Settings> <System name="Microsoft.CompanyAccount" /> <Application name="Microsoft.AssistUX" /> </Settings> <ActionCenter enabled="false" /> <MenuItems> <DisableMenuItems /> </MenuItems> <StartScreenSize>Large</StartScreenSize> </Default> </HandheldLockdown>

Further reading

More information about the possible configurations on a Windows Phone 8.1 device can be found in the Windows Phone 8.1 MDM Protocol document. This is a living document that gets updated by Microsoft when required.

What is DirectorySyncClientCmd.exe?

AADSync_DirectorySyncClientCmdLet’s end this year, on my blog, with a short blog post about DirectorySyncClientCmd.exe. This executable is part of the Microsoft Azure Active Directory Sync Services (AAD Sync), which is the predecessor of the Microsoft Azure Active Directory Sync tool (DirSync). AAD Sync is the (new) way to connect Azure AD with the on-premises AD. In combination with Microsoft Intune (and ConfigMgr) the most common use case, for AAD Sync, is the synchronization of the on-premises users (and their properties) to the Azure AD.

To trigger the synchronization there is the executable named DirectorySyncClientCmd.exe. That means that, unlike in DirSync, there is no need for PowerShell to trigger a synchronization.

Usage

AADSync_ScheduledTask_thumb[2]This executable is actually only used in one way by AAD Sync. During the installation of AAD Sync a new scheduled task, named Azure AD Sync Scheduler, is created. This scheduled task will run DirectorySyncClientCmd.exe once every three hours. This same scheduled task can be adjusted when there is a need to run the synchronization more often, or less.

Also good to know is that DirectorySyncClientCmd.exe can be started manually, by simple double-clicking it. Even better to know is that this executable has more options. Simply run this executable with the “?” parameter to reveal them. It will show the delta and the initial parameters. The delta parameter is simply the default behavior when the executable is started and the initial parameter can be used when the initial synchronization was skipped.

Result

SynchronizationServiceManagerTo follow the results of triggering DirectorySyncClientCmd.exe, simply use the Synchronization Service Manager. This will show an overview of the actions that were performed during the triggered synchronization (and all the previous synchronizations).

Also good to know is that when DirectorySyncClientCmd.exe is triggered directly, is that it will display the progress on-screen in a Command Prompt.

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! <<