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:

Expired Cloud Management Gateway server authentication certificate

Let’s start this new year with a short blog post about the Cloud Management Gateway (CMG). More specifically, about replacing an (expired) server authentication certificate on the CMG. The server authentication certificate is a required certificate for the CMG. That certificate is used to build the secure channel that is used with the created HTTPS service. The HTTPS service is were the internet-based clients connect. This certificate should come from a public provider, or from a public key infrastructure (PKI). In this post I’ll have a quick look at how to prevent the expiration of the server authentication certificate and how to replace the server authentication certificate.

Certificate expiration

The most important thing to note is – like with everything else – that prevention is better than cure. In this case: make sure that the certificate is replaced before it expires. Of course it still happens that – for whatever reason – the certificate is forgotten. In that case the Configuration Manager site will keep on working, but the clients that are managed over the Internet via the CMG, will loose their connection with the Configuration Manager site. The clients will show behavior in the CcmMessaging log that includes the messages shown below.

It includes the messages WINHTTP_CALLBACK_STATUS_SECURE_FAILURE and WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID, which both imply that something is wrong with the server certificate (see also the docs for some more details).

As mentioned, prevention is better than cure. At this moment Configuration Manager will not provide any alerts about the expiration of the CMG server authentication certificate. That doesn’t mean that there are no methods available for verifying the expiration of the certificate. When working with a solid third-party certificate provider, warnings will arrive months, weeks and days ahead of the expiration date. Ignoring those messages is nearly impossible (unless managed by a different team). When not willing to rely on a third-party, looking in the Azure portal is a very good alternative. Navigate to the cloud service of the CMG and select Certificates. That section will provide an overview of the certificates that belong to the cloud service. An example is shown below.

Of course this can also be automated by looking at PowerShell and/or the Azure Management API. That API contains the certificate URI for a resource group, which can be used for automation purposes.

Replace the certificate

The actual replacement of the (expired) CMG server authentication certificate should be pretty straight forward and can be achieved by following the next three steps.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration > Overview > Cloud Services Cloud Management Gateway
  2. Select {YourCMG} and click Properties in the Home tab to open the {YourCMG} Properties dialog box
  3. In the {YourCMG} Properties dialog box, navigate to the Settings tab, browse to (and select) the new certificate and click OK

Note: In my case I noticed that it wasn’t as straight forward as I thought. The deployment in Azure would fail with the message that the certificate with the new thumbprint was not found. I could address this challenge by manually uploading the certificate with the cloud service in Azure and again performing the mentioned steps. Performing those steps again will make sure that the correct actions are performed with the new certificate.

After a successful deployment of the cloud service the, earlier mentioned, Certificates section of the cloud services will show the new certificate and, in my case, show the old and expired certificate.

Also, it’s good to know that when the CMG server authentication certificate was actually expired, the clients will automatically start communicating again once the certificate is replaced.

More information

For more information about the certificates for the CMG, please refer to the documentation Certificates for the cloud management gateway.

Windows Insider MVP 2020!

Another year, another awesome start! Earlier today I received that great email stating that I’m re-awarded as a Windows Insider MVP! What an awesome start of the new year!

I feel really honored and privileged to be awarded with my second Windows Insider MVP award and to already been holding the Microsoft MVP (Enterprise Mobility) award for five years! Just awesome! An awesome start, of another community driven year!

Of course none of this would be possible without the support of my great family I love them and couldn’t do this without their support! Just awesome! I’m ready for another awesome year!