Controlling Windows 10 feature updates

This week is all about controlling Windows 10 feature updates. A couple of months ago a new policy type was introduced to control Windows 10 feature updates. And even more recent, support for Windows Autopilot devices was added to that policy type. That latest addition was the trigger for this blog post. In this post I’ll start with a short introduction about the different options for controlling Windows 10 feature updates, followed by more details about the Windows 10 feature updates policy. I’ll end this post by looking at the configuration options.

Introducing the control options for Windows 10 feature updates

Now let’s with an introduction about the options to control Windows 10 feature updates by using Microsoft Intune. I’m deliberately naming it controlling – and not managing – as it’s more controlling the (pace of the) installation of Windows 10 feature updates. I see managing more as being in full control of the Windows 10 (feature) updates on a device. Via Microsoft Intune it’s possible to utilize Windows Update for Business to simplify the Windows 10 update management experience in general. Utilizing Windows Update for Business is focused more on controlling the Windows 10 updates cycle, instead of approving individual updates for (specific) devices. Controlling the Windows version and controlling the installation of the quality and security updates.

It’s also good to keep in mind that Microsoft Intune only stores the policy assignments and not the updates themselves. Windows 10 devices will access Windows Update directly for the updates itself. Within Microsoft Intune the following policy types are provided to control updates:

  • Windows 10 update rings: The Windows 10 update rings policy is a collection of settings that configures setting to control when Windows 10 updates get installed. This policy type already exists for a while and enables administrators to create update rings that specify how and when Windows 10 devices should be updated with feature and quality updates. As long as the latest update is installed, the Windows 10 devices are up to date.
  • Windows 10 feature updates: (Currently public preview) The Windows 10 feature updates policy brings devices to the specified Windows version and freezes the feature set on those devices until the administrator chooses to update them to a later Windows version. While the feature version remains static, devices can continue to install quality and security updates that are available for their feature version.

As the Windows 10 feature updates policy is a new feature, the remainder of this post will focus on that feature.

Introducing the Window 10 feature updates policy

A Windows 10 feature updates policy is a pretty simplistic policy – from a configuration perspective – to control the Windows 10 feature updates on a device. When a device receives a Windows 10 feature updates policy, the device will update to the Windows version that is configured in the policy. When a device is already running a later Windows version then the Windows version that is configured in the policy, that device remains on its current Windows version. The device will not downgrade to a previous Windows version.

During the period that the Windows 10 feature updates policy is assigned to the device, the device will basically freeze on the configured Windows version (unless – as previously mentioned – the device is already running a later Windows version). That also provides the administrator more flexibility for controlling the Windows version of the device. With a Windows 10 update rings policy the administrator was limited in controlling the timeframe that a device could stay on a specific Windows version. The administrator could defer the period when the device would install a new feature update with 365 days and then pause the update assignment for another 35 days, but that was it. The Windows 10 feature updates policy actually freezes the device to the configured Windows version until the administrator modifies or removes the assigned policy.

The assigned Windows 10 feature updates policy only controls the feature updates on the device. That means that while the installed Windows version is frozen, the device can still receive and install quality and security updates for their installed Windows version. These updates will apply for the duration of support for the installed Windows version.

Limitations for the Windows 10 feature updates policy

Before looking at the current prerequisites and the configuration steps of a Windows 10 feature updates policy, it’s good to be familiar with the current limitations of this policy type.

  • When deploying a Windows 10 feature update policy to a device that also receives a Windows 10 update rings policy, the following configurations should be in place within the configured update ring:
    • The Feature update deferral period (days) setting must be set to 0.
    • The feature updates of the Windows 10 update rings policy must be running.
  • Windows 10 feature update policy cannot be applied during the Windows Autopilot process, instead the policy will apply at the first Windows Update scan after a device has finished provisioning (which is typically a day).

Also, keep in mind that this is still preview functionality. It might behave different than expected in some scenarios. At the time of writing this post I’ve seen scenarios in which this policy type might not work correctly when skipping a Windows version.

Prerequisites for the Windows 10 feature updates policy

When starting with the implementation of a Windows 10 feature updates policy, the following prerequisites must be met – at this moment – by the assigned devices to guarantee the described behavior.

  • The device must be running Windows 10 version 1703 or later
  • The device must be enrolled in Microsoft Intune and should be Azure AD joined or Azure AD registered.
  • The device must have telemetry turned on, with a minimum setting of Basic.

Configuring the Windows 10 feature updates policy

The configuration of the Windows 10 feature updates feature is actually pretty straight forward and doesn’t require a lot of configuring. The following 5 steps walk through the configuration of the Windows 10 feature updates feature and all the available configuration options.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Windows > Windows 10 feature updates to open the Windows – Windows 10 feature updates blade
  2. On the Windows – Windows 10 feature updates blade, click Create profile to open the Create feature update deployment wizard
  3. On the Deployment settings page, provide the following information and click Next
  • Name: Provide a valid name for the Windows 10 feature updates deployment
  • Description: (Optional) Provide a description for the Windows 10 feature updates deployment
  • Feature update to deploy: Select the Windows 10 version that should stick on the devices (current options are Windows 10 1803, Windows 10 1809, Windows 10 1903 and Windows 10 1909)
  1. On the Assignments page, click Select groups to include to assign the Windows 10 feature update deployment to a group of devices and click Next
  2. On the Review + create page, review the configuration of the Windows 10 feature update deployment and click Create

Administrator experience

Now let’s end this post by having a quick look at the administrator experience. Once the policy is assigned to the device, the device will check-in and install the Windows feature update according to the configured policy. The eventual result can be verified by navigating to Devices Windows > Windows 10 feature updates > [CreatedWindows10FeatureUpdatesPolicy] > End user update status. That report provides an overview of the assigned devices and their (feature) update status (as shown below).

More information

For more information about configuring updates in Microsoft Intune, refer to the documentation about Manage Windows 10 software updates in Intune.

Exclude specific groups of users or devices from an app assignment

This week another post about apps. This week it’s all about the ability to exclude a specific group of users or devices from an app assignment. That ability is not completely new, but it’s new enough to be still a little bit unfamiliar for many. It can be useful for assigning an app to a big group and still being able to exclude a small group. That can be users that should be treated a little different than the standard, like for example a test group, a demo group, or an executive group. In this post I want to have a look at those configuration options. Often I’ll also have a look at the end-user or administrative experience, but in this case there is nothing to show. It’s just an assignment configuration.

Configuration options

When working with apps the administrator has the option to assign the app to a specific group of users or devices. That can even be multiple groups. Now the administrator also has the option to exclude a specific group of users or devices. That exclusion will take precedence over an inclusion. At least for the following same group type configurations:

  • Include user groups and exclude user groups when assigning an app
  • Include device groups and exclude device group when assigning an app

An example of this would be for an administrator to assign an app to the users of the All users group and to exclude the users of the All demo users group. In that example all users except for the users of the demo users group, would get the assignment of the app. Simply because both groups are user groups. That would enable the administrator to treat the demo users differently for demo purposes.

It’s good to keep in mind that Microsoft Intune doesn’t evaluate user-to-device group relationships. When the administrator would assign apps to mixed groups, the results may not be expected. That also means that the exclusions are a service-side evaluation and not a client-side evaluation. On the service the results of the included and excluded groups are “calculated” and the result is used as the target of the assignment.

An example of this would be for an administrator to assign an app to the users of the All users group and to exclude the devices of the All demo devices group. That creates a mixed group app assignment that would result in all users (of the All users group) getting the app assignment. In other words, the exclusion does not apply. That means that it’s not recommended to mixed group app assignments.

Configuration example

Now let’s have a look at a configuration example of assigning a Win32 app in Microsoft Intune. In the following example I’ve added an assignment of the Win32 app to the users of the All users group and I want to add an exclusion for the users of the All demo users group. The following steps show how to add that exclusion by editing an existing assignment.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps Windows > Windows apps to open the Windows – Windows apps blade
  2. On the Windows – Windows apps blade, select a Win32 app (or create a new one), click Properties and navigate to the Assignment section and click Edit to open the Edit application blade
  3. On the Edit application blade, on the Assignments page, click Add group, select the All demo users group and click Select
  1. By default, the newly added group will be added with the Included MODE. To adjust this, click on Included, of the newly added group entry, switch the Mode to Excluded and click OK
  1. Now the All users group should show as Included and the All demo users group should show as Excluded. Click on Review + save to navigate to the Review + save page
  1. On the Review + save page, verify the new configuration and click Save

Note: The Review + save page will, just like the Assignments section in the Properties of the app, show both groups like both groups are a required assignment.

More information

For more information about excluding specific users or groups from an app assignment, refer to the documentation about Include and exclude app assignments in Microsoft Intune and Intune Standalone – Win32 app management.

Working with (custom) detection rules for Win32 apps

After my post of last week about Working with (custom) requirements for Win32 apps only one configuration subject of Win32 apps is left that I’ve discussed in detail, the detection rules for Win32. The format of this week is similar to that post and to previous posts about the different configuration subjects of Win32 apps. Detection rules must be used to determine the presence of a Win32 app. A Win32 app can have multiple detection rules. In that case every detection rule must be met to detect the app. That will help with making sure that the app installation will only be started when the app is not yet installed. In this post I’ll start with going through the different detection rule formats and I’ll end this post by looking at the administrator experience on a Windows device.

Detection rule

Now let’s start by having a look at the available detection rules of a Win32 app in Microsoft Intune. Let’s do that by first navigating to the location in the Microsoft Endpoint Manager admin center portal that provides the different detection rule format options for Win32 apps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps Windows > Windows apps to open the Windows – Windows apps blade
  2. On the Windows – Windows apps blade, select a Win32 app (or create a new one) and click Properties > Detection rules to open the Detection rules blade

On the Detection rules blade, the different detection rule formats of Win32 apps are shown. Those detection rule formats are categorized as mentioned below.

  1. Manually configure detection rules: This detection rule format enables the administrator to use a MSI product code, file or folder information or registry information for detecting the app.
  2. Use custom detection rules: This detection rule format enables the administrator to use a custom script for detecting the app.

The first category contains manual configurable detection rules. The manual configurable detection rules contains three different rule types that can be used to indicate the presence op the app. The first rule type in that list is MSI. That rule type enables the administrator to create a detection rule that must detect a specific MSI, or even a specific MSI version. This detection rule type can only be used once. A detection rule of this type requires the following configuration properties.

  • MSI product code – This property enables the administrator to configure the specific MSI product code that should be used to detect the installation of the app. When the installation contains an MSI, and this rule type is used, this property will be automatically populated.
  • MSI product version check – This property enables the administrator to configure also a specific version of the MSI product code that should be used to detect the installation of the app.

The second rule type in that list is File. That rule type enables the administrator to create a detection rule that must detect a specific file or folder, date, version, or size to determine the installation of the Win32 app. A detection rule of this type requires the configuration properties as mentioned below. This rule type is with its configuration properties nearly equal to the File rule type within requirement rules.

  • Path – This property enables the administrator to configure the full path of the folder that contains the file or folder that should be used to detect the installation of the app.
  • File or folder – This property enables the administrator to configure the file or folder that should be used to detect the installation of the app.
  • Detection method – This property enables the administrator to configure the method that should be used to detect the installation of the app. The following self explaining options are available.
    • File or folder exists
    • Date modified
    • Date created
    • String (version)
    • Size in MB
  • Associated with a 32-bit app on 64-bit clients – This property enables the administrator to configure that path environment variables are in 32-bit (yes) or 64-bit (no) context on 64-bit clients.

The third rule type in that list is Registry. That rule type enables the administrator to create a detection rule that must detect a specific registry setting based on value, string, integer, or version to determine the installation of the Win32 app. A detection rule of this type requires the configuration properties as mentioned below. This rule type is with its configuration properties nearly equal to the Registry rule type within requirement rules.

  • Key path – This property enables the administrator to configure the full path of the registry entry containing the value that should be used to detect the installation of the app.
  • Value name – This property enables the administrator to configure the name of the registry value that should be used to detect the installation of the app. When this property is empty, the detection will happen on the default value. The default value will also be used as detection value if the detection method is other than file or folder existence.
  • Detection method – This property enables the administrator to configure the method that should be used to detect the installation of the app. The following self explaining options are available.
    • Key exists
    • Key does not exist
    • String comparison
    • Version comparison
    • integer comparison
  • Associated with a 32-bit app on 64-bit clients – This property enables the administrator to configure that the search is in the 32-bit registry (yes) or in the 64-bit registry (no) on 64-bit clients

The second category contains custom scriptable detection rules. That is the most advanced rule format. That rule format enables the administrator to create detection rules that can check on basically anything that can be scripted, as long as the script has the correct output. A detection rule of that type requires the configuration properties as mentioned below. This rule type has some similarities with the Script rule type within the requirement rules. The main difference is with the output of this rule type as it’s more limited. In this rule type the detection of the Win32 app is based on the execution success of the script in combination with any output. It doesn’t matter what the output is.

  • Script name – This property enables the administrator to provide a name for the script.
  • Script file – This property enables the administrator to select a script that will be used to detect the installation of the app. When the script exit code is 0 and STDOUT contains any data, the app is detected (see table below for a summary).
  • Run script as 32-bit process on 64-bit clients – This property enables the administrator to configure the script to run in a 32-bit process (yes) or in a 64-bit process (no) on 64-bit clients.
  • Enforce script signature check – This property enables the administrator to configure that the script signature should be verified (yes) or that the signature verification should be skipped (no).
Exit codeData read from STDOUTDetection state
0EmptyNot detected
0Not emptyDetected
Not zeroEmptyNot detected
Not zeroNot EmptyNot detected

Administrator experience

Let’s end this post by having a look at the behavior of custom script detection rules on a Windows 10 device. The most advanced option. To do that I’ve used a really simple script that will detect the installation of Foxit Reader by looking at a specific directory. That can also be achieved by using a File rule type, but it’s an easy example for showing the functionality of custom script rule types. When the specific path is found, the script will output “Found it!“. That means that the detection rule will provide an output, when the detection was successful.

if (Test-Path "$($env:ProgramFiles)\Foxit Software\Foxit Reader\FoxitReader.exe") {
    Write-Host "Found it!"
}

When adding this script as a detection rule to a Win32 app and deploying that app as a required app to a user or a device, the installation process can be followed very good in the IntuneManagedExtension.log. That includes the process of detecting the installation of the app by going through the detection rule(s). Below is that example. It walks through the process of checking the detection rule(s) of the Win32 app. It shows the start of the script, the result of the script and following the detection state of the Win32 app (based on the result of the detection rule).

More information

For more information about the Win32 app functionality in Microsoft Intune, refer to the documentation about Intune Standalone – Win32 app management.

Working with (custom) requirements for Win32 apps

A few months ago I did a post about Working with the restart behavior of Win32 apps and a few months before that I did a post about Working with Win32 app dependencies. This week is similar to those post. This week is also about Win32 apps, but this week it’s about working with requirements for Win32 apps. Requirements can be used to make sure that the Win32 app will only install on a device that meets specific requirements. That means that requirements for Win32 apps, bring a lot of options and capabilities, which enable a lot of scenarios. Think about deploying a Win32 app to a user group and only installing on a specific device brand, type, or model. That can be achieved by using requirements. In this post I’ll quickly go through the different standard available requirement types, followed by a more detailed look at the custom script requirement type. I’ll end this post by looking at the administrator experience on a Windows device.

Requirement type

Now let’s start by having a look at the standard available requirement types within Microsoft Intune. Let’s do that by first navigating to the location in the Microsoft Endpoint Manager admin center portal that provides the different requirement options for Win32 apps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps Windows > Windows apps to open the Windows – Windows apps blade
  2. On the Windows – Windows apps blade, select a Win32 app (or create a new one) and click Properties > Requirements to open the Requirements blade

On the Requirements blade, the different standard available Win32 app requirement types are shown. Those requirement types are shown and explained below.

  1. Operating system architecture: This requirement enables the administrator to select the required architecture (32-bit | 64-bit) of the operating system that is needed for the Win32 app. This is a required configuration.
  2. Minimum operating system: This requirement enables the administrator to select the minimum operating system version that is needed to install the Win32 app. This is a required configuration.
  3. Disk space required (MB): This requirement enables the administrator to configure the free disk space that is needed on the system drive to install the Win32 app. This is an optional requirement.
  4. Physical memory required (MB): This requirement enables the administrator to configure the physical memory (RAM) that is required to install the Win32 app. This is an optional requirement.
  5. Minimum number of logical processors required: This requirement enables the administrator to configure the minimum number of logical processors that are required to install the Win32 app. This is an optional requirement.
  6. Minimum CPU speed required (MHz): This requirement enables the administrator to configure the minimum CPU speed that is required to install the Win32 app. This is an optional requirement.
  7. Configure additional requirement rules: See below.

The six requirements mentioned above are the standard available and easy to configure Win32 app requirement types. Besides those requirements, it’s also possible to add more advanced requirement types (as shown with number 7 above). The first requirement in that list of more advanced requirement types is File. That requirement type enables the administrator to create requirement rule that must detect a file or folder, date, version, or size. A requirement rule of that type requires the following configuration properties.

  • Path – This property enables the administrator to configure the full path of the folder that contains the file or folder that should be detected.
  • File or folder – This property enables the administrator to configure the file or folder that should be detected.
  • Property – This property enables the administrator to configure the type of rule that should be used to validate the presence of the Win32 app. The following self explaining options are available.
    • File or folder exists
    • File or folder does not exist
    • Date modified
    • Date created
    • String (version)
    • Size in MB
  • Associated with a 32-bit app on 64-bit clients – This property enables the administrator to configure that path environment variables are in 32-bit (yes) or 64-bit (no) context on 64-bit clients.

The second requirement in that list of more advanced requirement types is Registry. That requirement type enables the administrator to create requirement rule that must detect a registry setting based on value, string, integer, or version. A requirement rule of that type requires the following configuration properties.

  • Key path – This property enables the administrator to configure the full path of the registry entry containing the value that should be detected.
  • Value name – This property enables the administrator to configure the name of the registry value that should be detected. When this property is empty, the detection will happen on the default value. The default value will also be used as detection value if the detection method is other than file or folder existence.
  • Registry key requirement – This property enables the administrator to configure the type of registry key comparison that should be used to determine how the requirement rule is validated. The following self explaining options are available.
    • Key exists
    • Key does not exist
    • String comparison
    • Version comparison
    • integer comparison
  • Associated with a 32-bit app on 64-bit clients –This property enables the administrator to configure that the search is in the 32-bit registry (yes) or in the 64-bit registry (no) on 64-bit clients.

The third requirement in that list of more advanced requirement types is Script. That is the most advanced requirement type. That requirement type enables the administrator to create requirement rules that can check on basically anything that can be scripted, as long as the script has the correct output. A requirement rule of that type requires the following configuration properties.

  • Script name – This property enables the administrator to provide a name for the script.
  • Script file – This property enables the administrator to select a script that will be used to verify custom requirements. When the script exit code is 0, Intune will detect the STDOUT in more detail.
  • Run script as 32-bit process on 64-bit clients – This property enables the administrator to configure the script to run in a 32-bit process (yes) or in a 64-bit process (no) on 64-bit clients.
  • Run this script using the logged on credentials – This property enables the administrator to configure the script to run using the credentials of the signed in user (yes) or using the SYSTEM context (no).
  • Enforce script signature check – This property enables the administrator to configure that the script signature should be verified (yes) or that the signature verification should be skipped (no).
  • Select output data type – This property enables the administrator to configure the data type that is used to determine a requirement rule match. The following self explaining options are available.
    • String
    • Date and Time
    • Integer
    • Floating Point
    • Version
    • Boolean

This advanced requirement type enables an administrator to check on basically anything. Based on the information provided above, the script should run successful (exit code 0) and provide an output in the selected data type (string, date and time, integer, floating point, version or boolean).

Administrator experience

Let’s end this post by having a look at the behavior of requirement rules a on a Windows 10 device. To do that I’ve used a really simple script that will check the manufacturer of the device. When the manufacturer matches the specified manufacturer, the script will output “Found it!“. That means that the requirement rule should look for output data of the type String. And more specifically a String that equals “Found it!“.

if ((Get-WmiObject Win32_ComputerSystem).Manufacturer -eq "Microsoft Corporation") {
    Write-Output "Found it!" 
}

When adding this script as a requirement rule to a Win32 app and deploying that app as a required app to a user or a device, the installation process can be followed very good in the IntuneManagedExtension.log. That includes the process of verifying the requirement rules that should be checked. Below is that example. It walks through the process of checking the requirement rules for the Win32 app. It shows the start of the script, the result of the script and following the applicability of the Win32 app (based on the result of the requirement rule).

More information

For more information about the Win32 app functionality in Microsoft Intune, refer to the documentation about Intune Standalone – Win32 app management.

Microsoft Connected Cache in ConfigMgr with Win32 apps of Intune

This week is all about an awesome new feature that was introduced with the latest version of Configuration Manager, version 1910. That feature is that Microsoft Connected Cache now supports Win32 apps that are deployed via Microsoft Intune. Microsoft Connected Cache can be enabled on a Configuration Manager distribution point and serve content to Configuration Manager managed devices. That includes co-managed devices and now also Win32 apps, which enables a Configuration Manager distribution points to serve as a content location for Win32 apps deployed via Microsoft Intune. In this post I’ll start with a short introduction about Microsoft Connected Cache, followed with the required configuration of a Configuration Manager distribution point and the required configuration of the Configuration Manager clients. I’ll end this post by verifying the behavior on a client device.

Microsoft Connected Cache with Configuration Manager

Starting with Configuration Manager, version 1906, it’s possible to configure a Configuration Manager distribution point as a cache server that acts as an on-demand transparent cache for content downloaded by Delivery Optimization. In that version, the feature was known as Delivery Optimization In-Network Cache (DOINC). Starting with Configuration Manager, version 1910, this feature is now named Microsoft Connected Cache. Client settings can be used to make sure that the cache server is offered only to the members of the local Configuration Manager boundary group.

When clients are configured to use the Microsoft Connected Cache server, those clients will no longer request Microsoft cloud-managed content from the Internet. Those clients will request the content from the cache server installed on the Configuration Manager distribution point. The on-premises server caches the content using the IIS feature for Application Request Routing (ARR). Then the cache server can quickly respond to any future requests for the same content. If the Microsoft Connected Cache server is unavailable, or the content isn’t cached yet, clients download the content directly from the Internet.

Note: This cache is separate from the content on the Configuration Manager distribution point.

Enable distribution point as Microsoft Connected Cache server

The first step in configuring Microsoft Connected Cache in Configuration Manager for usage with Win32 apps from Microsoft Intune (or any other Microsoft cloud-managed content), is to enable a distribution point as a Microsoft Connected Cache server. However, before looking at that configuration, make sure that the on-premises distribution point meets the following configurations:

  • The server is running Windows Server 2012, or later
  • The default web site enabled on port 80
  • The IIS Application Request Routing (ARR) feature is not yet installed
  • The distribution point has Internet access to at least the Microsoft cloud

When the mentioned prerequisites are in-place, it’s time to have a look at the actual configuration steps. The following three steps walk through the process of enabling a distribution point as a Microsoft Connected Cache server.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration > Overview > Site Configuration Servers and Site System Roles
  2. Select {YourSiteSystemServer} select Distribution point and click Properties in the Site Role tab to open the Distribution point Properties dialog box
  3. In the Distribution point Properties dialog box, navigate to the General tab, perform the following configuration and click OK
  • Select Enable the distribution point to be used as Microsoft Connected Cache server to enable this distribution point as a Microsoft Connected Cache server and to trigger the installation
  • Select By checking this box, I acknowledge that I accept the License Terms to accept the license terms (and make sure to read them)
  • Configure with Local drive the drive that should be used to store the cache on the server
  • Configure with Disk space the maximum size of the cache on the server
  • Optionally select Retain cache when disabling the Connected Cache server to make sure that the cache will be retained on the server when the configuration is disabled

Verify the installation

After enabling the distribution point to be used as a Microsoft Connected Cache server it’s time to follow the installation process to verify a successful installation. This process can be followed in the distmgr.log, as shown below. This log keeps track of the beginning and the ending of the installation.

When looking closely on the distmgr.log, the installation is actually wrapped in a PowerShell script. That script contains all the intelligence for checking the prerequisites, making the necessary backups and starting the actual installation. That whole process of that PowerShell script is logged in DoincSetup.log. Once it completed all actions, it will be shown in the both log files.

Additional things to look at are the CacheNodeService website and the Server Farms in IIS and the DOINC folder on the selected drive. All of these created items, should be created with the same unique ID in the name. Also, in the Task Scheduler there are two tasks created for maintenance and for keeping it alive.

Enable a client to use Microsoft Connected cache

The second step in configuring Microsoft Connected Cache in Configuration Manager for usage with Win32 apps from Microsoft Intune (or any other Microsoft cloud-managed content), is to enable a client to use a Microsoft Connected Cache server as location for content download. However, before looking at that configuration, make sure that the client devices meet the following configurations:

  • The device is running Windows 10, version 1709, or later
  • The client is Configuration Manager, version 1910, or later
  • The device has 4GB, or more

When the mentioned prerequisites are in-place, it’s time to have a look at the actual configuration steps. The following three steps walk through the process of enabling a client to use a Microsoft Connected Cache server as location for content download. After creating these custom client settings, assign them to the devices like any other client settings.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration Overview Client Settings
  2. Select Create Custom Client Device Settings to open the Create Custom Client Device Settings dialog box
  3. On the General section, provide a valid name and select Delivery Optimization
  4. On the Delivery Optimization section, provide the following settings and click OK
  • Select Yes with Use Configuration Manager Boundary Groups for Delivery Optimization Group ID to make sure that the client uses this identifier to locate peers with the desired content
  • Select Yes with Enabled devices managed by Configuration Manager to use Microsoft Connected Cache servers for content download to make sure that the client can use an on-premises distribution point that is enabled as a Microsoft Connected Cache server for content download

Verify the behavior

After deploying the custom device settings to the required devices, it’s time to verify the behavior of the co-managed devices. I specifically mention co-managed devices, as I need to use Configuration Manager functionality and Microsoft Intune functionality. However, before verifying the behavior, it’s good to make sure that the following is also in-place to be able to use Win32 apps deployed by Intune on co-managed devices.

  • The co-managed device and the Microsoft Connected Cache-enabled distribution point are in the same boundary group
  • The pre-release feature Client apps for co-managed devices is enabled (often displayed as Mobile apps for co-managed devices)
  • The Client apps workload is set to Pilot Intune or Intune

When everything is available and configured, it’s time to actually look at the co-managed device. The first thing to look at is the actual configuration of Delivery Optimization on the device. Based on the custom client settings, the device will get the settings as shown below. The value DOCacheHost indicates that the distribution point is configured as Microsoft Connected Cache server, the value DODownloadMode indicates that a private group is configured and the value DOGroupId indicates the boundary group that is configured.

After verifying the settings, it’s time to look at what happens after downloading a Win32 app that’s deployed via Microsoft Intune. The easiest method to verify the required behavior is by using PowerShell. The Get-DeliveryOptimizationStatus cmdlet will provide the information to verify the behavior. The property BytesFromCacheServer indicates that the Microsoft Connected Cache server is used for the download, the property DownloadMode indicates that the correct download mode is used and the property PredefinedCallerApplication indicates that the download was an Intune app download.

More information

For more information about Microsoft Connected Cache with or without Configuration Manager, please refer to the following articles:

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:

Working with the restart behavior of Win32 apps

A long time ago, I did a post about Working with the restart behavior of Applications in ConfigMgr 2012. That post is still being read pretty well. Based on the interest of that post, and the introduction of nice new features to the Win32 apps, I thought it would be a good idea to redo that post for Microsoft Intune. Before an IT administrator had to be creative to work with, or work around, the restart behavior of Win32 apps. Either by wrapping installations and capturing the exit code, or by tuning the translation of an return code. With the latest adjustments to the Win32 apps, within Microsoft Intune, the IT administrator has more options to actually work with the return code of an Win32 app installation. These configuration options are similar to the configuration options within the app model of ConfigMgr. In this post I’ll discuss the 2 layers that together define the restart behavior after the installation of Win32 apps.

Return codes

When looking at the restart behavior after the installation of Win32 apps, the first thing that should be looked at is the return code after the installation. By default, when adding a Win32 app to Microsoft Intune, a list of standard return codes is added to indicate post-installation behavior (see figure below). These are often used return codes. When the Win32 app installation ends with a different return code, additional entries can be added. This configuration is available via [Win32 app] > Properties > Return codes.

Fore every return code a code type can be configured. The code configures the post-installation behavior of the Win32 app. The following code types are available and can be configured with the return code to apply the mentioned behavior:

  • Failed – The Failed return code indicates that the Win32 app installation failed.
  • Hard reboot – The Hard reboot return code indicates that the device is required to restart to complete the installation. Additional Win32 apps cannot be installed on the device without restart. The user will be notified about the required restart.
  • Soft reboot – The Soft reboot return code indicates that the next Win32 app is allowed to be installed without requiring a restart, but a restart is necessary to complete the installation of the installed Win32 app. The user will be notified about the restart.
  • Retry – The Retry return code indicates that the Win32 app installation is retried three times. The installation will wait for 5 minutes between each attempt.
  • Success – The Success return code indicates the Win32 app installation was successful.

Enforce device restart behavior

The second thing that should be looked at is how the device will react on the configured return code. By default, when adding a Win32 app to Microsoft Intune, the default device restart behavior is set to App install may force a device restart (see figure below). This configuration will make sure that the device will restart after the Win32 app installation, if needed, but still in an acceptable manner. The restart behavior can be configured to respond to return code differently. That configuration is available via [Win32 app] > Properties > Program.

Multiple device restart behavior configurations are available. And all these configuration options have their own effect on the return code of the Win32 app installation. The following device restart behaviors are available and can be configured to apply the mentioned behavior (including a short explanation about the expected behavior):

  • Determine behavior based on return codes: This option means that the device will restart based on the configured return code. With this configuration a Hard reboot return code will immediately trigger a restart of the device and a Soft reboot return code will notify the user that a restart is required to finish the installation.
  • No specific action: This option means that the installation will suppress device restarts during the Win32 app installation of MSI-based apps. Effectively that means that parameters are added to the installation command line of MSI-based apps to suppress device restart. With this configuration a Hard reboot return code will notify the user that a restart of the device will be triggered in 120 minutes and a Soft reboot return code will notify the user that a restart is required to finish the installation.
  • App install may force a device restart: This option means that the Win32 app installation is allowed to complete without suppressing restarts. With this configuration a Hard reboot return code will notify the user that a restart of the device will be triggered in 120 minutes and a Soft reboot return code will notify the user that a restart is required to finish the installation.
  • Intune will force a mandatory device restart: This option means that a successful Win32 app installation will always restart the device. With this configuration any successful return code will immediately trigger a restart of the device.

More information

For more information about the Win32 app functionality in Microsoft Intune, refer to the documentation about Intune Standalone – Win32 app management.

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.

Windows 10 MDM (PowerShell) scripting

A long, long time ago, I wrote about the MDM WMI Bridge provider. Nowadays I notice that the MDM WMI Bridge provider is still an unknown configuration layer for many IT admins. That’s why I’ve decided to do another post about the MDM WMI Bridge provider. A quick reminder: the MDM WMI Bridge provider is used to map the CSPs to WMI. This time my post is more focused on providing some examples and guidance. Besides that it’s also a nice addition on my latest posts about Windows 10 MDM configurations, policy refresh and troubleshooting. I’ll start this post by showing how to configure device settings and I’ll end this post by showing how to trigger device actions.

Keep in mind that this post is about configuring device settings. That means that every action requires to run in SYSTEM context. I advise to use PsExec for executing the scripts and tools mentioned in this post

Configuring device settings

The easiest starting point for everything related to WMI is Windows Management Instrumentation Tester (in short wbemtest). As an example I’ll take last weeks post to another level by also looking at the Reboot CSP for this post. The starting point for that is the MDM_Reboot_Schedule01 class.

Let’s start at the beginning. The root\cimv2\mdm\dmmap namespace, is the namespace that contains all the information regarding MDM in WMI. This is the MDM WMI Bridge provider. This namespace contains the WMI classes that map to CSP nodes. There are 3 methods available to get the available WMI classes:

  1. The docs about the MDM Bridge WMI provider
  2. Use wbemtest to connect to the namespace and click Enum Classes
  3. User PowerShell (Get-CIMClass) to enumerate the available classes

For this example I’ll use wbemtest to connect to the root\cimv2\mdm\dmmap namespace and to enumerate the available classes. This tool is an easy method for showing information via a UI. When knowing the exact class, it’s also possible to directly connect to that class by using Open Class instead of Enum Classes.

In this example, I know the class, which enables me to open the specific MDM_Reboot_Schedule01 class. Connecting to that class, provides me with the available properties (DailyRecurrent, InstanceID, ParentID, Single). These properties are well documented in the earlier mentioned article. In some scenarios, the classes and/or properties are not yet documented. In those scenarios wbemtest can be a very good starting point for getting the required information.

Now the available classes and properties are known, it’s time to have a look at the available options. As it’s basically standard WMI, at this point, there are also the standard WMI PowerShell scripting options available (Get, New, Remove and Modify). Below are some basic examples of using the CimCmdlets for WMI. Having mentioned that, I also deliberately left out some real New-CimInstance and Remove-CimInstance examples, as the example that I use for this post doesn’t support those actions. The MDM_Reboot_Schedule01 class already contains an instance and can’t contain multiple instances. Below are some generic example of using those cmdlets.

#Enumerate available instances
Get-CimInstance -Namespace $namespaceName -ClassName $className
#Create a new instance
New-CimInstance -Namespace $namespaceName -ClassName $className -Property @{}
#Get a specific instance 
$instanceObject = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'"

#Remove a specific instance
Remove-CimInstance -CimInstance $instanceObject

That basically means that it’s only possible to modify the available instance in the MDM_Reboot_Schedule01 class. That instance is Schedule. The Schedule instance can be adjusted by adding a value to the Single property and/ or the DailyRecurrent property. Those properties are used to actually create the specified schedule. Just like in the CSP configuration, the date and time value is ISO8601 and in UTC. The example below will get the Schedule instance in the root\cimv2\mdm\dmmap namespace, and will modify the Single property to configure a new single scheduled reboot.

#Declare variables
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_Reboot_Schedule01"
$parentID = "./Vendor/MSFT/Reboot"
$instanceID = "Schedule"
$singleSchedule = "2019-10-01T22:00:00Z"

#Get a specific instance
$instanceObject = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'"

#Adjust a specific property
$instanceObject.Single = $singleSchedule

#Modify an existing instance
Set-CimInstance -CimInstance $instanceObject

Triggering device actions

Besides configuring settings via the MDM WMI Bridge provider, it’s also possible to trigger actions via the provider. When still looking at the Reboot CSP, that CSP also contains a node to execute RebootNow. RebootNow will trigger a reboot within 5 minutes. That action is available within the Intune console as a Restart action for a device. The nice thing is that this action can also be triggered via the MDM WMI Bridge provider.

Let’s skip the beginning about connecting to the WMI namespace and directly navigate to the required WMI class. The MDM_Reboot class. When connecting to the MDM_Reboot class, by using wbemtest, it’s immediately clear why wbemtest is such a nice and easy tool. After connecting to the class, wbemtest immediately provides an overview of the available methods. In this case the RebootNowMethod method.

Triggering the RebootNowMethod method, via PowerShell, will provide an alternative (and very creative) method for rebooting a device. This method is well documented in the earlier mentioned documentation. In some scenarios, the methods are not yet documented. In those scenarios wbemtest can be a very good starting point for getting the required information.

The RebootNowMethod method can be triggered by getting the available instance of the MDM_Reboot class. That instance is Reboot. That instance can be used to trigger the RebootNowMethod method. The example below will get the Reboot instance in the root\cimv2\mdm\dmmap namespace, and will trigger the RebootNowMethod method to trigger a reboot within five minutes.

#Declare variables
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_Reboot"
$parentID = "./Vendor/MSFT/Reboot"
$instanceID = "Reboot"
$methodName = "RebootNowMethod"

#Get a specific instance
$instanceObject = Get-CimInstance -Namespace $namespaceName -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'"

#Trigger specific method
Invoke-CimMethod -InputObject $instanceObject -MethodName $methodName

Now let’s end this post by having a look at the effect of triggering the RebootNowMethod method. Below is an example of a simplified version (read: a one-liner) of the previous script. Just for demo purposes. After triggering that the RebootNowMethod method, the device will immediately provide a popup with a reboot notification.

More information

For more information about PowerShell and the MDM WMI Bridge provider, have a look at this article about Using PowerShell scripting with the WMI Bridge Provider.

Scheduling a reboot via Windows 10 MDM

This week is also about configuring Windows 10 devices. This week is all about scheduling a reboot on a Windows 10 device by using Microsoft Intune and Windows 10 MDM. That can be useful for scheduling reboots on for example shared devices. Simply making sure that even those type of devices get a reboot every now and then, or making sure that specific configurations or installations are getting fully applied. This can be achieved by using the Reboot CSP. In this post I’ll have a look at the available policy settings and the configuration of those policy settings. I’ll end this post by having a look at the results of the configuration.

Available policy settings

The Reboot CSP can be used to configure reboot settings. That CSP contains only a few policy settings and methods (nodes). The required policy setting for this post is available as a policy setting (node) in this CSP. The root node of the Reboot CSP is ./Vendor/MSFT/Reboot and the table below describes the nodes below.

PolicyDescription
RebootNowThis node can be used to execute a reboot of the device. It will trigger a reboot within 5 minutes to allow the user to wrap up any active work. This method is used when triggering a Restart via the Intune console.
Schedule/SingleThis node can be used to execute a reboot of the device at a scheduled date and time. Setting a null (empty) date will delete an existing schedule. The date and time value is ISO8601, and both, the date and time, are required.
Example: 2019-10-01T22:00:00Z
Schedule/DailyRecurrentThis node can be used to execute a reboot of the device, each day, at a scheduled time starting at the configured time and date. Setting a null (empty) date will delete an existing schedule. The date and time value is ISO8601, and both, the date and time, are required.
Example: 2019-10-02T21:00:00Z

Configuring the policy settings

Now let’s continue by looking at the actual configuration of the different configurable policy settings of the Reboot CSP. That means configuring a single reboot schedule and a daily recurrent reboot schedule. This can be achieved by using a custom device configuration profile. The following four steps walk through the configuration of the single reboot schedule, by using the information of above (including the example values).

The daily recurrent reboot schedule can be achieved by following the same steps and simply adjusting the OMA-URI and the Value. The screenshots below show both configurations. Also, by using two different Data type configurations. After creating the profile, it can be assigned like any other device configuration profile.

  1. Open the Azure portal and navigate to Microsoft Intune Device configuration Profiles to open the Devices configuration – Profiles blade
  2. On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade
  3. On the Create profile blade, provide the following information and click Create
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Custom
  • Settings: See step 4
  1. On 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: Single reboot schedule
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Reboot/Schedule/Single
  • Data type: Select String
  • Value: 2019-10-01T22:00:00Z

Note: The same configuration can be achieved by using the Date and time data type and selecting the date and time in the UI (as shown below). Keep in mind that it will translate the selected date and time to the UTC time, which in my case is currently a 2 hour difference. To remove the schedule, use 0000-00-00T00:00:00Z as a value.

Result on the device

After assigning the created device configuration profile(s), it’s time to have a look at the results on a device. The Reboot CSP will create a scheduled task for the configured reboot schedules (as shown below). Those scheduled tasks are available at Microsoft > Windows > EnteriseMgmt > {EnrollmentID} > Reboot.

As I’ve configured a single reboot schedule and a daily recurrent reboot schedule, the screenshot below shows a task RebootCSP daily recurrent reboot and a task RebootCSP scheduled reboot. Those tasks are used for performing the actual reboots by using deviceenroller.exe -ForcedReboot.

After successfully rebooting multiple devices, I’ve noticed the following to keep in mind:

  • The Last Run Time of the scheduled tasks never updates after a reboot, as if the scheduled task is recreated with a new Next Run Time.
  • The result of the custom device configuration profile in Microsoft Intune still shows a Remediation failed error message, while the configuration is successful.

More information

For more information about the Reboot CSP, have a look at the documentation about the Reboot CSP.