Quick tip: Easy method for constructing settings of ingested ADMX-files

This week a quick extra blog post, just before the start of my vacation, about an easy method for construction settings of ingested ADMX-files. A few years ago I did a post about a deep dive for ingesting third-party ADMX-files and until today I still receive questions on that post that are related to constructing settings of ingested ADMX-files. Even though the described method is still available, there is an easier method for constructing the settings of ingested ADMX-files. A method that is less sensitive to errors. The following four steps walk through that easy method by again using chrome.admx as an example.

  1. The first step is ingesting the ADMX-file. That can be achieved by following the same steps as provided in my earlier post. After creating the required configuration that contains the content of the ADMX-file, assign the profile to a group with a test device and let Microsoft Intune do its magic.
  1. While Microsoft Intune is performing its magic on the test device, it’s time to start with the second step. The second step is looking up the setting and the available values in the ADMX-file. Just like my earlier post – to keep it simple – I’m looking at the SitePerProcess setting (see Figure 1). Now instead of going through the ADMX-file to construct a difficult OMA-URI, it’s time to have a look at the test device once Microsoft Intune performed its magic.
  1. After Microsoft Intune performed its magic, it’s time to start with the third step. The third step is looking up the setting of the ingested ADMX-file in the registry of the test device. Simply navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\ADMXDefault and locate the just ingested ADMX-file. To make life a little bit easier, knowing to parent category can help. Otherwise, just find and locate the SitePerProcess setting. Once the setting is located, the required part of the OMA-URI is available without doing any really difficult steps (see Figure 2).
  1. The fourth and last step is putting the information together. The OMA-URI of a device-based ingested ADMX-file always starts with ./Device/Vendor/MSFT/Policy/Config. That combined with the information found in the registry of the test device makes ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess.

I know I should have posted these steps earlier, but I still hope that it will still help administrators around the globe with constructing their OMA-URIs for settings of ingested ADMX-files. For as long as it’s still required.

Device compliance based on custom configuration baselines

This week is all about the new feature to include a custom configuration baselines as part of a compliance policy assessment. That’s a new feature that is introduced in Configuration Manager, version 1910. That will also make this a followup on the post I did earlier this year about using the power of ConfigMgr together with Microsoft Intune to determine device compliance. This will be added functionality, as it’s now possible to make custom configuration baselines part of the device compliancy check. For both, Configuration Manager managed devices and co-managed devices. Even when the workload is switched to Microsoft Intune.

Introduction

This option that makes it possible to use a custom device configuration baseline part of a compliancy policy, opens up a whole new world of possibilities. Especially when knowing that this can also be used when co-managing devices. This enables organisations to create a custom device configuration baseline for specific business requirements that cannot be captured by using the default functionalities that are available for Configuration Manager and Microsoft Intune.

This provides a lot of flexibility for devices that are either managed by Configuration Manager, or that are co-managed by using a combination Configuration Manager and Microsoft Intune. In the latter scenario, that even still provides that flexibility when the compliance policies workload is switched to Microsoft Intune. In that case Microsoft Intune can be configured to take the ConfigMgr compliance assessment result as part of the overall compliance status. The info gets sent to Azure AD and can be used for conditional access. In this post I’ll show how to correctly configure the device compliance policy, the configuration baseline and (optionally) the Configuration Manager compliance.

Before starting with the different configurations it’s good to keep in mind that if the compliance policy evaluates a new baseline that has never been evaluated on the client before, it may report non-compliance at first. This occurs if the baseline evaluation is still running when the compliance is evaluated.

Configure device compliance policy

The first configuration that should be in place is the device compliance policy. The device compliance policy is used to determine the compliance status of the device. Within the device compliance policy, a new rule is available that will enable the evaluation of configuration baselines as part of the compliance of the device. The following steps walk through the creation of a new device compliance policy including the required rule. The device compliance policy can be deployed like any other device compliance policy.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies
  2. Click Create Compliance Policy to open the Create Compliance Policy Wizard
  3. On the General page, provide the following information and click Next
  • Name: Provide a valid name for the compliance baseline
  • Description: (Optional) Provide a description for the compliance baseline
  • Select Compliance rules for devices managed with Configuration Manager client
  1. On the Supported Platforms page, select Windows 10 and click Next
  1. On the Rules page, perform the following actions and click Next
  • Click New to open the Add Rule dialog box
  • On the Add Rule dialog box, select Include configured baselines in compliance policy assessment and click OK
  1. On the Summary page, click Next
  2. On the Completion page, click Close

Configure configuration baseline policy

The second configuration that should be in place is the configuration baseline policy. The configuration baseline policy is used to configure, or verify, specific configuration on a device. Within a configuration a new settings is available that will make the evaluation of the configuration baseline a part of the compliance evaluation. The following steps will walk through the process of creating a new configuration baseline including the new setting. In my example I’m adding a configuration item that will verify if the local administrators comply the the organisation defaults. The configuration baseline can be deployed like any other configuration baseline.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines
  2. Click Create Configuration Baseline to open the Create Configuration Baseline dialog box
  1. On the Create Configuration Baseline dialog box, provide the following and click OK
  • Name: Provide a valid name for the configuration baseline
  • Description: (Optional) Provide a description for the configuration baseline
  • Configuration data: Select the required configuration items that should be part of this configuration baseline
  • Select Always apply the baseline even for co-managed devices
  • Select Evaluate the baseline as part of compliance policy assessment

The combination of these settings will make sure that the configuration baseline is applied to co-managed devices and that the configuration baseline will be evaluated as part of the compliance. Keep in mind that any baseline with the second option selected, that is deployed to the user, or to the user’s device, is evaluated for compliance.

(Optional) Configure Configuration Manager Compliance

An optional configuration is to configure Microsoft Intune to also look at information of Configuration Manager for determining the compliance. In my scenario that is a required configuration as I’m using it in combination with co-managed devices. Within a compliance policy a setting is available that will require compliance from Configuration Manager. The following steps walk through the configuration of that setting in a device compliance policy. Nothing more, nothing less. The device compliance policy can be assigned like any other device compliance policy.

  1. Open the Microsoft 365 Device Management portal and navigate to Devices Windows > Compliance policies to open the Windows – Compliance policies blade
  2. On the Windows – Compliance policies blade, click Create Policy to open the Create Policy blade
  3. On the Create Policy blade, provide the following information and click Create
  • Name: Provide a valid name for the compliance policy
  • Description: (Optional) Provide a description for the compliance policy
  • Platform: Select Windows 10 and later
  • Settings: See step 4 and 5
  • Actions for noncompliance: Leave default (for this post)
  • Scope (Tags): Leave default (for this post)
  1. On the Windows 10 compliance policy blade, select Configuration Manager Compliance to open the Configuration Manager Compliance blade
  2. On the Configuration Manager Compliance blade, select Require with Require device compliance from System Center Configuration Manager and click OK to return to the Windows 10 compliance policy blade and click OK

Experience

Now let’s end this post by having a look at the end-user experience. In my scenario I’ve created a custom configuration baseline that will verify the number of local administrators on the device. When it’s above a specific number of local administrators, the device is considered not compliant as the device might be compromised. In that case the end-user will receive a message in the Company Portal app as shown below. It explains the end-user that the security settings should be updated and to look for more information in Software Center.

When looking at Software Center it actually provides exactly the same message to the end-user. It provides the end-user with the message that the security settings should be updated. For more information the end-user should contact the support department. So make sure that the requirements are clear to the end-user.

More information

For more information see the Include custom configuration baselines as part of compliance policy assessment section of the Create configuration baselines doc.

The different ways of (re)naming Windows 10 devices

This week is all about Windows 10 devices. More specifically about (re)naming Windows 10 devices. And all that by using standard available functionality without custom scripting. This post will bring different posts together that I did over the last couple of years and will introduce one new configuration option that was recently introduced within Windows Autopilot. In this post I’ll go through the different (configuration) options for (re)naming Windows 10 devices.

Configuration options

Now let’s dive into the different configuration options. All of these configuration options are from a MDM-Intune-Autopilot perspective. Scripting a device rename action could also be scripted by using PowerShell, but for this post I want to rely on built-in functionality.

Custom device configuration profile

The first configuration option that I want to mention is the configuration that is available on every Windows 10 device, as it relies on Windows 10 MDM. This configuration relies on a custom device configuration profile, as shortly explained below. The actual behavior is similar to what will happen when selecting a device and clicking Restart.

When creating a custom device configuration profile, provide at least the following information on the Custom OMA-URI Settings blade.

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description
  • OMA-URI: ./Device/Vendor/MSFT/Accounts/Domain/ComputerName
  • Data type: Select String
  • Value: CLDCLN%SERIAL% (or use the other example of CLDCLN%RAND:6%)

For more information about the custom device configuration option, please have a look at my blog post specifically about this subject.

Domain join device configuration profile

The second configuration option that I want to mention is the configuration that is only available for Windows Autopilot deployments that require a hybrid Azure AD join. In that case a domain join device configuration profile should be used to configure the name of the Windows 10 device. Below is a short explanation.

When creating a custom device configuration profile, provide at least the following information on the Domain Join (Preview) blade.
  • Computer name prefix: Provide a computer name prefix. The remaining characters of the 15 characters of a computer name will be random
  • Domain name: Provide the domain name that the device will join
  • Organizational unit: (Optional) Provide the OU that the computer account is created in

For more information about the domain join device configuration option, please have a look at my blog post specifically about this subject.

Windows Autopilot deployment profile

The third configuration option that I want to mention is the configuration that is only available for Windows Autopilot deployments that require Azure AD join. In that case the Windows Autopilot deployment profile should be used to configure the name of the Windows 10 device. Below is a short explanation.

When creating a Windows Autopilot deployment, provide at least the following information on the Create profile blade, on the Out-of-box experience (OOBE) section.

  • Deployment mode: Select User-Driven, or Self-Deploying, as both option can be used in combination with applying a computer name template
  • Join to Azure AD as: Select Azure AD joined to join the device to Azure AD during the Windows Autopilot user-driven experience
  • (When applicable) End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot user-driven experience
  • (When applicable) Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot user-driven experience
  • (When applicable) Hide change account options: Select Hide to hide the change account options during the Windows Autopilot user-driven experience
  • User account type: Select Administrator to only make any user on the device an administrative user
  • (When applicable) Language (Region): Select the applicable language and configure the keyboard
  • (When applicable) Allow White Glove OOBE: Select Yes, when using in combination with White Glove
  • Apply computer name template: Create a computer name, according to the configured template, for devices at initial startup

For more information about the Windows Autopilot deployment profile option, please have a look at my blog post specifically about this subject. This is just one example about Windows Autopilot on my blog that contains this configuration option.

Windows Autopilot device property

The fourth configuration option that I want to mention is the configuration that is only available for Windows Autopilot deployments that require Azure AD join. In this case it’s a property of the Windows Autopilot device that can be used for configuring the configuring the device. The device name will only be configured during the Windows Autopilot deployment. Below are the steps for configuring the device name for Windows Autopilot devices.

After adding a device to Windows Autopilot the following steps help with adjusting the device name.

  • Open the Microsoft 365 Device Management portal and navigate to Devices Windows > Windows enrollment > Devices to open the Windows Autopilot devices blade
  • On the Windows Autopilot devices blade, select the applicable device to open the Properties blade
  • On the Properties blade, provide a custom name with Device Name and click Save.

This can also be automated via the WindowsAutopilotIntune module.

Note: It’s possible to configure the device name for all devices, but are ignored with Hybrid Azure AD joined deployment.

More information

For more information about the different device (re)name options, please refer to the following articles:

Applicability rules for device configuration profiles

This week a new blog post about a little nice, but quite unknown, feature. Applicability rules for device configuration profiles. The nice thing about applicability rules is that those rules can be used to target devices in a group that meet specific criteria. That enables an administrator to assign a device configuration profile to all users, or all Windows 10 devices, but only actually apply to Windows 10 devices of a specific version or edition. In this post I’ll go through the configuration of applicability rules (including a few important details) and the administrator experience.

Configure applicability rule

Let’s start by looking at applicability rules. Applicability rules can be configured for every device configuration profile type with Windows 10 and later as Platform, with the exception of Administrative Templates as Profile Type. It enables the administrator to only assign the device configuration profile to a specific version or edition of Windows 10.

Before looking at the configuration of applicability rules, it’s good to be familiar with a few important notes about assigning a device configuration profile including applicability rules. When assigning such a device configuration profile, keep the following in mind:

  • When two device configuration profiles are assigned with the exact same settings, and only one of those profiles has an applicability rule configured, then the profile without an applicability rule is applied.
  • When assigning device configuration profiles to groups, the applicability rules act as a filter, and only target the devices that meet the specified criteria.

Now let’s have a look at the actual configuration of applicability rules. The following steps walk through the configuration of applicability rules in device configuration profiles for Windows 10 devices.

  1. Open the Microsoft 365 Device Management portal and navigate to Devices > Windows Configuration profiles to open the Windows – Configuration profiles blade
  2. Select an existing device configuration profile, or create a new device configuration profile and navigate to Applicability Rules to open the Applicability Rules blade
  3. On the Applicability Rules blade, configure a rule click Add to add the rule and click Save
  • The Rule selection enables the administrator to either use Assign profile if – that will include users or groups that meet the specified criteria – or use Don’t assign profile if – that will exclude users or groups that meet the specified criteria –.
  • The Property selection enables the administrator to either use OS edition – that will enable a list to check the Windows 10 editions that must be included – or use OS version – that will enable fields to enter the min and max Windows 10 version numbers that must be included –. Both values (min and max) are required.

Administrator experience

Let’s end this post by shortly mentioning the administrator experience. The experience is not that exiting actually. When an applicability rule is applicable to a device, the device is targeted with the configuration profile. The device will try to assign the configuration profile and simply show the normal Succeeded, Error or Failed status. When an applicability rule is not applicable to a device, the device wil not be targeted with the configuration profile and the configuration profile will get the status of Not applicable.

More information

For more information regarding applicability rules for device configuration profiles, refer to the Applicability rules section of the Create a device profile in Microsoft Intune doc.

Android Enterprise fully managed devices and the Google Play store

This week another post about an Android Enterprise configuration. Last week was related to company owned single-use (COSU) devices (also known as dedicated devices), while this week is related to company owned business only (COBO) devices (also known as fully managed devices). More specifically, about adding a personal touch to fully managed devices. Microsoft Intune doesn’t know the company owned personally enabled (COPE) devices, yet, but there is a feature within the fully managed devices configuration that can at least enable some more personal options to the user. That can be achieved with a simple configuration to allow access to all apps in the Google Play store. I’ll start this post with the configuration steps (and a little introduction) and I’ll end this post by having a look at the end-user experience.

Configuration

Let’s start with a quick introduction about the setting that should be configured and the impact of that setting. The setting Allow access to all apps in Google Play store must be set to Allow. Once it’s set to Allow, users get access to all apps in Google Play store. Apps can be sort of blocked by the administrator by assigning an uninstall of the apps to the user (or device). That will simply remove the app (over-and-over) again. When it’s set to Not configured, users are forced to only access the apps the administrator makes available (or required) via the Google Play store.

The following 3 steps walk through the process of creating a device restrictions policy that enables access to the Google Play store for users.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

AEFMD-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner > Device restrictions
  • Settings: See step 3b
3b On the Device restrictions blade, select Applications to open the Applications blade; and click OK to return to the Add configuration policy blade;
3c On the Applications blade, select Allow with Allow access to all apps in Google Play store and click OK and OK to return to the Create profile blade;
AEFMD-Applications

Note: This profile can be assigned to user and device groups.

End-user experience

Now let’s end this post by having a look at the end-user experience. Depending on the exact configuration the end-user can end up with one of the three scenarios as shown below.

  1. Below on the left is showing the Google Play store for the work account only, without access to all apps in the Google Play store.
  2. Below in the middle is showing the Google Play store for the work account only, with access to all apps in the Google Play store. Even though my store is in Dutch, the number of items in the menu, and the apps shown in the background, show the difference.
  3. Below on the right is showing the Google Play store for the work account when also a personal account is added (see the purple circle with a “P”). It provides the same options as shown in the middle, but also enables the user to switch between accounts.
Screenshot_20190729-172606_Google Play Store Screenshot_20190729-181300_Google Play Store Screenshot_20190724-210437_Google Play Store

The combination for the user to add a personal account to the device and being able to install apps via the Google Play store, will at least give the user some options to personalize the device.

More information

For more information about the device configuration options for Android Enterprise fully managed devices, please refer to the Device owner section in the documentation about Android Enterprise device settings to allow or restrict features using Intune.

Create a custom multi-app kiosk mode

This week is all about creating a custom multi-app kiosk mode for Android Enterprise dedicated devices. The Android Enterprise dedicated device settings also contains multi-app kiosk settings, but in some scenarios those settings can still be a little bit limiting. To create a multi-app kiosk mode, Microsoft Intune relies on the Managed Home Screen app. The fun part is that the Managed Home Screen app already contains a few more settings that are currently only available via app configuration policies. In this post I’ll start with a quick overview of the app configuration options that exist nowadays, followed by showing an app configuration example for the Managed Home Screen app to add a non-Managed Google Play Store app. Technically speaking I’ll add a single app, using the multi-app configuration option. Really adding multiple apps is more of the same. I’ll end this post by showing the end-user experience.

It’s important to keep in mind that the preferred and advised method to configure multi-app kiosk mode settings is still by using the dedicated device settings.

App configuration options

Let’s start this post by having a look at the app configuration options that are available nowadays. In the early days it was still required to manually configure configuration keys and values. These days Intune can prepopulate configuration keys that are available within the Android apps. Below is a quick overview of the 2 app configuration options that are available :

Configuration designer: The Configuration designer can be used to configure simple settings via the UI. It will automatically populate the available configuration keys within the app and allows the administrator to configure the simple configuration values. As long as the value type is not BundleArray
MSH-ConfigurationDesigner
JSON data: The JSON data can be used to configure all settings via a JSON template. The template will automatically populate the available configuration keys within the app and allows the administrator to configure all the configuration values.

MHS-JSONEditor

Configure the Managed Home Screen app

Now the app configuration options are clear. Let’s have a look at the app configuration of the Managed Home Screen app. As an example I want to use a setting that is only configurable via JSON data, as the value type is a BundleArray. That setting is to add (custom non-Managed Google Play Store) apps to the Managed Home Screen app. The following 3 steps walk through the process of creating an app configuration policy that enables the built-in Settings app to the multi-app kiosk mode.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > App configuration policies to open the Client apps – App configuration policies blade;
2 On the Client apps – App configuration policies blade, click Add to open the Add configuration policy blade;
3a

MHS-AddConfigPolicyOn the Add configuration policy blade, provide the following information and click Add;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Device enrollment type: Select Managed devices
  • Platform: Select Android
  • Associated app: See step 3b
  • Configuration settings: See step 3c
  • Permissions: See step 3d

Note: The main focus of this post is the configuration around the configuration settings (step 3c). That doesn’t mean that the permission configuration (step 3d) can’t be really useful when the app needs specific permissions. As it’s not the key part of this post, I won’t go into to much details for now.

3b

On the Associated app blade, select Managed Home Screen and click OK to return to the Add configuration policy blade;

Note: When the Managed Home Screen app is not available make sure that that the app is approved and synchronized with Intune.

3c

On the Configuration settings blade, select Enter JSON data with Configuration settings format. Now either click Download JSON template, for offline editing, or use the JSON editor to directly configured the required configuration keys. Before clicking on OK to return to the Add configuration policy blade, go through the following 3 steps (see also the screenshot below):

  1. Navigate to the applications configuration key to add the required apps for the custom multi-app kiosk mode. In my example, I add the Settings app (com.android.settings) to my multi-app kiosk mode. The valueString should be the app package name. To add another app simply copy the complete managedProperty and adjust the valueString.
  2. To be able to save the configuration, make sure to change all the values that need to be configured and still state something like STRING_VALUE. When a setting is not needed it can also be removed.
  3. The red areas on the scrollbar show the locations of values that must be adjusted or removed before the configuration can be saved.

Note: Make sure that the settings in the app configuration policy don’t overlap with settings in the dedicated device configuration.

MHS-JSONEditor-Config
3d On the Permissions blade, click Add to open the Add permissions blade. The Add permissions blade can be used select permissions that should be overridden. Select the required permissions and click OK to return to the Permissions blade and click OK to return to the Add configuration policy blade.

Note: At some point in time these configuration options will probably become available in the multi-app kiosk mode settings for dedicated devices.

End-user experience

Let’s end this post by having a look at the end-user experience. When the device is enrolled and the assigned apps are installed, the device will ask to select a home screen app (the message will actually show after the installation of the Managed Home Screen app). After selecting the Managed Home Screen app, the home screen will show as configured in the app configuration policy.

As shown on the right, I only get the Settings app (Instellingen is the Dutch version of Settings) as app on my home screen. That’s exactly what I wanted. Also, I configured a blue theme and I removed nearly all the other options from the end-user.

Note: The experience might be different from the configuration via the dedicated device settings. The main difference might be that in some cases the end-user might receive a message to configure a home screen app. So make sure to carefully test the end-user experience, to see if it matches the expectations.

Screenshot_20190721-195426

More information

For more information about configuring the Managed Home Screen app, please refer to the documentation about Configure the Microsoft Managed Home Screen app for Android Enterprise .

Configuring shared multi-user devices

This week is all about a recently introduced profile in Microsoft Intune to configure shared PC mode on a Windows 10 device. That profile is named Shared multi-user device profile. Something similar has been available already for a while via Intune for Education. The main use case for this profile are school devices that are shared between multiple students. In this post I’ll provide a brief introduction regarding shared PC mode, followed by the configuration (and the configuration options) of the Shared multi-user device profile. I’ll end this post by looking at the end-user experience.

Introduction

Let’s start with a short introduction about shared PC mode and immediately address the main use case. Shared PC mode s designed to be management- and maintenance-free with high reliability. A good example of devices that benefit from shared PC mode are school devices. These devices are typically shared between many students. By using the Shared multi-user device profile, the Intune administrator can turn on the shared PC mode feature to allow one user at a time. In that case, students can’t switch between different signed-in accounts on the shared device. When the student signs out, the administrator can also choose to remove all user-specific settings.

End-users can sign in to these shared devices with a guest account. After users sign-in, the credentials are cached. As they use the shared device, end-users only get access to features that are allowed by the administrator. For example, the administrator can choose when the shared device goes in to sleep mode, the administrator can choose if users can see and save files locally, the administrator can enable or disable power management settings, and much more. Administrators also control if the guest account is deleted when the user signs-off, or if inactive accounts are deleted when a threshold is reached.

Configuration

Now that it’s known what the main use case is of the the Shared multi-user device profile, let’s have a look at the configuration of the Shared multi-user device profile. The following four steps walk through the creation of the Shared multi-user device profile, including a short explanation with the different configuration options. After the creation of the profile, it can be assigned to a user and/or device group (just like any other profile).

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, click Create profile to open the Create profile blade;
3a SMUD-CreateProfileOn the Create profile blade, provide the following information and click Settings to open the Shared multi-user blade;

  • Name: Provide a valid name for the profile;
  • Description: (Optional) Provide a description for the profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Shared multi-user device;
  • Settings: See step 3b;
3b On the Shared multi-user device blade, provide the following configuration and click OK to return to the Create profile blade (see screenshot below);

  • Share PC mode: Select Enable to turn on shared PC mode. In shared PC mode, only one user can sign in to the device at a time. Another user can’t sign in until the first user signs out;
  • Guest account: Select Guest to create a guest account locally on the device that will be shown on the sign-in screen. These guest accounts don’t require any user credentials or authentication. Each time this account is used, a new local account is created;
  • Account management: Select Enable to turn on automatic deletion of accounts created by guests. These accounts will be deleted based on the account deletion configuration;
  • Account deletion: Select Immediately after log-out to make sure that created guests accounts are deleted immediately after log-out;
  • Local Storage: Select Disabled to prevent users from saving and viewing files on the hard drive of the device;
  • Power Policies: Select Enabled to prevent users from turning off hibernation, overriding all sleep actions, and changing the power settings;
  • Sleep time out (in seconds): Enter 60 (or any other value between 0 and 100) as the number of inactive seconds before the device goes into sleep mode;
  • Sign-in when PC wakes: Select Disabled to make sure that users don’t have to enter their username and password (they can use the guest account);
  • Maintenance start time (in minutes from midnight): Can be used to enter the time in minutes (0-1440) when automatic maintenance tasks, such as Windows Update, run.
  • Education policies: Select Enabled to use the recommended settings for devices used in schools, which are more restrictive. These settings are documented here;
SMUD-ShareMultiUserDevice.
4 Back on the Create profile blade, click Create.

Note: Besides configuring Windows Update, it is not recommended to set additional policies on devices configured with shared PC mode. The shared PC mode is optimized to be fast and reliable over time with minimal to no manual maintenance required.

End-user experience

Let’s end this post by looking at the end-user experience after assigning the Shared multi-user device profile. The first thing the end-user will notice is that it can click on the guest user account icon and simply click sign-in. No password will be required.

SMUD-Example01

Once logged on to the device, there are many places to look for a limited experience and specific configurations. I choose to show an important configuration related to the guest account and and few configurations related to available options to the end-user. Below on the right is an example of the guest accounts that are created. Every time the user logs off, the account will be disabled and a new account will be created. Below on the left and on the bottom are two examples related to permissions. It shows that the guest user can’t access the local C-drive and the Control Panel. It also confirms a statement at the beginning of this post; the main use case is schools. It clearly shows in the messages.

SMUD-Example02

More information

For more information regarding Windows 10 shared multi-user devices and configuring those devices in Microsoft Intune, please refer to the following articles:

Require an Internet connection during device setup

This week I’m going to look at a well hidden configuration option that is recently introduced and can be really useful in specific scenarios. That configuration option is to require an Internet connection during the device setup. Requiring an Internet connection during device setup can be useful when trying to prevent users from resetting the device (either accidently or on purpose) and configuring it without an Internet connection, as configuring a device without Internet connectivity would enable a user to configure the device with a local user and without enrollment. In this blog post, I’ll start with a short introduction about why this configuration option would be useful and what the options are with this configuration option. Followed by the configuration steps and the end-user experience.

Introduction

Configuring a device without Internet connectivity would enable a user to configure the device with a local user and without an enrollment to Microsoft Intune (and Azure AD). That’s often what organizations want to prevent, as it disconnects a device from the organization. Minor detail, this configuration option must be configured once. Of course it would be great if this configuration option could be a Windows default, or available via the Windows Autopilot configuration. However, to my understanding this is currently not possible due to legal requirements. At this moment it’s simply legally not allowed to require an Internet connection on a device during the initial setup. Having said that, as this setting is configured via the TenantLockdown CSP, I can imagine that, in a Windows Autopilot for existing devices scenario, this can be configured as a Windows default, via PowerShell, by using the WMI Bridge Provider.

Configuration

Before looking at the configuration, let’s start with a few important requirements and limitations:

  • The device must run Windows 10, version 1809 or later;
  • The device must be configured once before the setting is applicable;

Now let’s continue by looking at the required configuration. The following four steps walk through the steps to get create a new device configuration profile and the specific configuration option. That device configuration profile can be assigned to an Azure AD group.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, select Create profile to open the Create profile blade;
3a On the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the device configuration profile;
  • Description: (Optional) Provide a description for the device configuration profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Device restrictions;
  • Settings: See 3b;
3b On the Device restrictions blade, select General to open the General blade. On the General blade, select Require with Require users to connect to network during device setup and click OK to return to the Device restrictions blade. On the Device restrictions blade, click OK;
OOBE-Configure-Network

Note: This setting must be configured before it’s applicable. In other words, it’s not applicable during the initial out-of-box experience.

End-user experience

Let’s end this post by looking at the end-user experience. Once the configuration is in place and a reset is performed on the device, there will be an additional check during the device setup. When the device is not connected to the Internet, the end-user will receive a message as shown below. It requires the user to connect to the Internet. The user will not be able to continue without that connection. Once the user is connected to the Internet, the page below will show a Next button that can be used to continue with the device setup.

OOBE-Connect-Network

More information

For more information regarding the device configuration options and the TenantLockdown CSP, please refer to the following articles:

Enable password reset from the login screen

This week is about something similar as last week. This week is all about the password reset option on the login screen. In other words, the Reset password option. Starting with Windows 10, version 1709, it’s possible to enable the Reset password option from the login screen for Azure AD joined devices. I know that a lot has been written already about this subject, but I have the feeling that this subject needs a place on my blog. My style and more details. In this post I’ll provide a short introduction about Azure AD self-service password reset (SSPR), followed by walking through the required configurations for SSPR and the Reset password option. I’ll end this post by looking at the end-user experience.

Introduction

Now let’s start this post with an introduction about Azure AD SSPR. With SSPR users can reset their passwords on their own when and where they need to. At the same time, administrators can control how a user’s password gets reset. That means that the user no longer needs to call a help desk just to reset their password. SSPR includes (the focus of this post is number 2):

  1. Self-service password change: The user knows their password but wants to change it to something new;
  2. Self-service password reset: The user is unable to sign in and wants to reset their password by using one or more of the following validated authentication methods:
    • Send a text message to a validated mobile phone;
    • Make a phone call to a validated mobile or office phone;
    • Send an email to a validated secondary email account;
    • Answer their security questions.
  3. Self-service account unlock: The user is unable to sign in with their password and has been locked out. The user wants to unlock their account without administrator intervention by using their authentication methods.

Configuration

Let’s continue by having a look at the required configuration, to enable the Reset password option from the login screen. As the configuration of the actual settings requires SSPR to be enabled, I divided the configuration into two steps. The first step is to enable SSPR and the second step is to configure the Reset password option.

Step 1a: Enable SSPR

The first step is to enable SSPR, as it’s the starting point for enabling the Reset password option from the login screen. Without SSPR enabled, and still configuring the Reset password option, the user will receive a message that SSPR is not enabled for the user and that the user should contact the administrator. The following seven steps walk through the relatively simple configuration to enable SSPR.

1 Open the Azure portal and navigate to Azure Active Directory > Password reset;
2

AAD_PR_PropertiesOn the Password reset – Properties blade, select All and click Save;

3

AAD_PR_AuthOn the Password reset – Authentication methods blade, select the number of required methods to reset and the available methods to user and click Save;

Note: Make sure that you have at least as many methods available to users as you have required to reset.

4

AAD_PR_RegistrationOn the Password reset – Registration blade, configure whether or not to require users to register when signing in and click Save;

5

AAD_PR_NotificationsOn the Password reset – Notifications blade, configure the notification settings and click Save;

6

AAD_PR_CustomizationsOn the Password reset – Customization blade, configure the customization settings and click Save;

7

AAD_PR_OnPremOn the Password reset – On-premises integration blade, and configure the password write back configuration and click Save;

Note: This is required when using an on-premises directory and also requires the configuration of step 1b.

Step 1b: (Optional) Configure password writeback

Another part of the first step is the optional configuration of password writeback. This should be configured to write the passwords from Azure AD back to the on-premises directory. To achieve this, use the following seven steps to reconfigure Azure AD Connect.

1 On the Azure AD Connect server, start Azure AD Connect to open the Microsoft Azure Active Directory Connect wizard;
2 On the Welcome page, click Configure;
3 On the Additional tasks page, select Customize synchronization options and click Next;
4 On the Connect to Azure AD page, provide the required credentials and click Next;
5 On the Connect Directories page, click Next;
6 On the Domain/OU Filtering page, click Next;
7

MAADC_OptionalFeaturesOn the Optional Features page, select Password writeback and click Next;

Note: I’ve also got Device writeback configured, which causes the next page to appear.

8 (Optional) On the Writeback page, click Next;
9 On the Configure page, click Configure and once completed click Exit;

Step 2: Enable Reset password option

The second step is to configure the required setting to enable the Reset password option from the login screen. In other words, the second step is to configure a device configuration profile with at least a custom OMA-URI setting. The required setting is part of the Authentication node of the Policy CSP. It’s the AllowAadPasswordReset policy. That policy allows administrators to enable the self-service password reset feature on the windows logon screen. An integer value of 0 means not enabled and an integer value of 1 means enabled.

The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSI_AllowPasswordResetOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name; 
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset;
  • Data type: Select Integer;
  • Value: 1.

Note: For testing purposes it’s also possible to configure the Reset password option by using the HKLM\SOFTWARE\Policies\Microsoft\AzureADAccount registry key with the value, type and data of AllowPasswordReset, REG_DWORD and 1.

End-user experience

Now let’s end this post by walking through the end-user experience. On the login screen a new option is available when selecting password as the sign-in option, the Reset password option.

RP_01

When the user selects Reset password, the user will be redirected to the Azure AD self-service password reset service.

RP_02

The User ID is already prepopulated and when the user clicks on Next, the user should choose a verification method. In my case a text to my mobile phone.

RP_03

When the user provides the correct mobile phone number and clicks on Next, the user must provide the actual verification code of the text message.

RP_04

When the user provides the correct verification code and clicks on Next, the user must provide a new password.

RP_05

When the user provides a new password and clicks Next, the user will be provided with the message that the password has been reset. When the user than clicks on Finish, the user will be redirected to the login screen.

RP_06

More information

For more information about SSPR, Windows 10 and the Reset password option, please refer to the following articles:

Enable PIN reset from the login screen

This week I’m going for an end-user experience focused blog post. This week is all about the PIN reset option on the login screen. In other words, the I forgot my PIN option. Starting with Windows 10, version 1709, it’s now possible to enable the I forgot my PIN option from the login screen. When using Windows Hello for Business, which can be configured during the Windows enrollment, by using Microsoft Intune, the PIN is the fallback mechanism when it’s not possible to authenticate with biometrics. In other words, the PIN is really important.

In this post I’ll provide the required configuration to provide the user with the I forgot my PIN option from the login screen. I’ll do that by assuming that the user can use the Windows Hello for Business PIN recovery service to reset their PIN. I’ll end this post by looking at the end-user experience.

Configuration

Now let’s start by having a look at the required configuration to enable the I forgot my PIN option from the login screen. As the configuration of the actual settings requires the tenant ID, I divided the configuration into three steps. The first step is to find and introduce the required setting, the second step is to get the tenant ID and the third step is to use the tenant ID in the actual configuration.

Step 1: Get the required setting

The first step is to get and introduce the required setting. The PIN-related settings are part of the Windows Hello for Business settings, which can be configured by using the PassportForWork CSP. Starting with Windows 10, version 1703, that CSP contains the EnablePinRecovery node. With Windows 10, version 1703, this setting can be used to enable the I forgot my PIN option from the Settings panel and starting with Windows 10, version 1709, this setting can also be used to enable the I forgot my PIN option from the login screen.

This settings has a boolean value that enables a user to change their PIN by using the Windows Hello for Business PIN recovery service. This cloud service encrypts a recovery secret, which is stored locally on the client, and can be decrypted only by the cloud service. The default value of this setting is false. Once the administrator enables this setting, the PIN recovery secret will be stored on the device and the user can change their PIN if needed.

Step 2: Get the tenant ID

The second step is to get the tenant ID. This is super simple these days, but, as I’ve never provided the actual steps, I thought it would be smart to publish them once. To get the tenant ID, simply follow the two steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Properties;
2

tenantIDOn the Properties blade, click Copy next to Directory ID to copy the tenant ID;

Note: Just to be clear, this should be used in the OMA-URI instead of {tenantID}.

Step 3: Configure the required setting

The third step is to configure the required setting to enable the I forgot my PIN option from the login screen. In other words, the third step is to configure a device configuration profile with at least a custom OMA-URI setting. The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MIS_PINResetOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{tenantID}/Policies/EnablePinRecovery;
  • Data type: Select Boolean;
  • Value: Select True.

End-user experience

Now let’s walk through the end-user experience. On the login screen a new option is available when selecting PIN as the sign-in option, the I forgot my PIN option.

IfmP_01

When the user selects I forgot my PIN, the user will be redirected to the login experience of the identity provider. In my case ADFS.

IfmP_02

When the user provides a password and clicks on Sign-in, the user needs to provide an additional verification option, on an Azure AD branded page. In my case a text message.

IfmP_03

When the user provides the additional verification and clicks on Next, the user will be provided with an additional notification to make sure that the user is aware of the impact.

IfmP_04

When the user accept the impact of resetting the PIN and clicks Continue, the user will be provided with a dialog box to create a new PIN. Also, the user can click on PIN requirements to view the requirements for the new PIN. In my case it will show the Windows Hello for Business settings as configured in the Windows enrollment section of Microsoft Intune.

IfmP_05

When the user provided a new PIN and clicks OK, the user will be provided with the message that it’s all set. When the user than clicks on OK, the user will be redirected to the login screen.

IfmP_06

More information

For more information about Windows 10 and the (remote) PIN reset functionality, please refer to the following articles: