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! 

Enabling the ConfigMgr administration service through the cloud management gateway

This week is all about the administration service in Configuration Manager. More specifically, about enabling the Configuration Manager administration service via the cloud management gateway (CMG) to make it available over the Internet. The administration service provides API interoperability access to WMI over HTTPS via the SMS Provider. This REST API can be used in place of a custom web service to access information of the Configuration Manager site. Some really good information and starting points about this subject can be found at this blog post by Adam Gross. In this post I’ll skip the basics and specifically look at making the administration service available over the Internet. I want to provide in my own style what the configuration requirements are and why they are needed. I’ll start this post by showing the required configurations in Configuration Manager and in Azure AD and I’ll end this post by retrieving the most common parameters for scripting.

Before starting with the actual configurations, I want to post a little thank you message: Thank you Sandy for answering my (dumb) questions while I should simply read better.

Configuring the SMS Provider properties

The administration service is available with the installation of the SMS Provider. Every site system with an SMS Provider has the administration service. Before being able to enable the SMS Provider over the CMG, the following prerequisites should be in-place:

  • The server that hosts the SMS Provider role requires .NET 4.5.2 or later
  • Enable the SMS Provider to use a certificate, by either using Enhanced HTTP or by manually binding a PKI-based certificate on the server that hosts the SMS Provider role
  • A running CMG (as I’m not going through that installation)

When those prerequisites are in-place, the SMS Provider can be configured to allow CMG traffic for the administration service by following the next three steps.

  1. Open the Configuration Manager administration console and navigate to Administration > Overview > Site Configuration > Servers and Site System Roles
  2. Select the server that hosts the SMS Provider role, select the SMS Provider role and click Properties in the Site Role tab to open the Provider role properties dialog box
  3. On the Provider role properties dialog box, select Allow Configuration Manage cloud management gateway traffic for administration service and click OK

Register a new app with Azure AD

For accessing the administration service via the CMG, two apps must be created within Azure AD, 1) a Web app (also known as a Server app within Configuration Manager) that is used for making the administration service available and 2) a Native app (also known as a Client app within Configuration Manager) that is used for obtaining an access token for the user. That access token can be sent in a request to the Web app, which authorises the user and returns the administration service.

During the creation of the cloud services within Configuration Manager a Web app and a Native are already created. I need to (and can) access the administration service via that created Web app, but I don’t want to reuse the existing Native app as I need to make some adjustments and I don’t want to interfere with existing functionalities. The following steps walk through the registration and configuration of a new Native app with the required configurations to obtain and access token for the user and be able to sent that token in a request to the Web app.

  1. Open the Azure portal and navigate to Azure Active Directory  > App registrations to open the App registrations blade
  2. On the App registrations blade, click New registration to open the Register an application blade
  3. On the Register an application blade, provide the following information (as also shown below) and click Register
  • Name: Provide a valid name for the Web app (in this post: ConfigMgrAdminService)
  • Supported account types: Select Accounts in this organisational directory only ({yourTenant} only – Single tenant)
  • Redirect URI (optional): Select Public client/native (mobile & desktop) and provide https://login.microsoftonline.com/common/oauth2/nativeclient as Redirect URI

Note: The mentioned redirect URI, is the latest recommended value for desktop applications running on Windows (see also: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-app-registration).

  1. After the registration of the app, navigate to Authentication to open the Authentication blade
  2. On the Authentication blade, navigate to the Default client type section and select Yes with Required for the use of the following flows where a redirect URI is not used (as shown below) and click Save
  1. Navigate to API permissions to open the API permissions blade
  2. On the API permissions blade, click Add a permission to open the Request API permissions blade
  3. On the Request API permissions blade, select APIs my organisation uses and select the Web app – the standard name of that app is ConfigMgrService (as shown below) – that was initially created during the setup of the cloud services to open the specific API permissions blade
  1. On the specific API permissions blade, select Delegated permissions, select user_impersonation and click Add permissions (as shown below) to return to the API permissions blade
  1. On the API permissions blade, select Grant admin consent for {yourTenant} (as shown below

Retrieve the parameters to start with PowerShell

After configuring the SMS Provider properties, registering and configuring the Native app, the administration service is available via the CMG. The next step is to actually externally connect with the administration service. However, this might be an open door, but before doing that it’s good to understand that the user that is authentication and connecting with the administration service must have sufficient permissions within Configuration Manager.

At this moment I won’t provide an example, that might be something for a future post, but for now I’ll refer to this great post by Zeng Yinghua (also known as Sandy) and this repository about the Microsoft Graph (as the idea for retrieving a token is the same). The main challenge in any of those scripts is getting the token. To successfully achieve that, the following information is often required.

  1. Application (client) ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 1).
  2. Tenant ID of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 2).
  3. Redirect URI of the Native app that is named ConfigMgrAdminService in this post. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrAdminService > Overview (shown in the figure below with number 3) or copying the information that was provided in step 3 during the registration of Native app in Azure AD.
  1. Application ID URI of the Web app that is named by default ConfigMgrService. That information can be found in the Azure portal at Azure Active Directory  > App registrations > ConfigMgrService > Overview (shown in the figure below with number 4)
  1. External URL of the administration service. That information can be the easiest retrieved in SQL by using the query below on the ConfigMgr database
select ExternalEndpointName, ExternalUrl from vProxy_Routings
where ExternalEndpointName = 'AdminService'

More information

For more information about Configuration Manager administration service, please refer to the documentation about the SMS Provider.

Device compliance based on custom configuration baselines

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

Introduction

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

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

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

Configure device compliance policy

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

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

Configure configuration baseline policy

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

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

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

(Optional) Configure Configuration Manager Compliance

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

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

Experience

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

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

More information

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

The different ways of (re)naming Windows 10 devices

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

Configuration options

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

Custom device configuration profile

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

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

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

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

Domain join device configuration profile

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

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

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

Windows Autopilot deployment profile

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

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

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

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

Windows Autopilot device property

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

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

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

This can also be automated via the WindowsAutopilotIntune module.

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

More information

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

Report-only mode for conditional access

This week is, like last week, about a awareness for new feature that is introduced with conditional access. Last week was all about the recently introduced Conditional Access Insights workbook. In that post I already mentioned the Report-only mode for conditional access policies. In this post I want to focus on that Report-only mode. Report-only mode is a new state of a conditional access policy state that allows IT administrators to evaluate the impact of conditional access policies before enabling them in their environment. That enables the IT administrators to anticipate on the number and names of users impacted by common deployment initiatives such as blocking legacy authentication, requiring multi-factor authentication, or implementing sign-in risk policies. A great step forward.

In this post I’ll walk through the steps of configuring Report-only mode for conditional access policies, followed by looking at the end-user experience. I’ll end this post by looking at the administrator experience.

Configure report-only mode

Let’s start by having a look at the steps to configure the Report-only mode for a conditional access policy. These steps will walk through the creation of a new conditional access policy, with a focus on configuring the Report-only mode. The exact configuration of the conditional access policy assignments and conditions are not part of that focus. The following three steps walk through that configuration.

  1. Open the Azure portal and navigate to Azure Active Directory  > Security > Conditional access (or open the Microsoft 365 Device Management portal and navigate to Endpoint security Conditional access) to open the Conditional access – Policies blade
  2. On the Conditional access – Policies blade, click New policy to open the New blade
  3. On the New blade, configure the assignment and conditions to filter the users and cloud apps that should be targeted by the conditional access policy. After configuring the conditions it’s time to look at the access controls. The access controls are the configuration that eventually might impact the end-user. In the access controls, the grant control determines that behavior. In the grant control the IT administrator can configure the requirements that should be met for accessing the cloud app for the end-user. Depending on the configured requirements, there might be a minimal impact for the end-user (see Figure 1 and and Figure 2 about the messages that are shown about the impact of the conditional access policy based on the configured requirements). After configuring the grant control, select Report-only with Enable policy (also shown in Figure 1) and click Create.

End-user experience

Depending on the configuration that is used in the grant control, of the conditional access policy, the end-user might have a slight impact when using the Report-only mode. The table below is a summary of the available requirements in combination with the potential impact. This table is based on the information as shown during the configuration of the conditional access (see Figure 2), as I haven’t been able to get the mentioned experience on my test devices. I’ve tested with a Samsung Galaxy 10, iPad 2018 and iPhone X.

RequirementPotential user impact
Require multi-factor authentication No impact
Require device to be marked as compliantMay prompt users on macOS, iOS and Android devices to select a device certificate
Require Hybrid Azure AD joined device No impact
Require approved client appMay prompt users on macOS, iOS and Android devices to select a device certificate
Require app protection policyMay prompt users on macOS, iOS and Android devices to select a device certificate

Administrator experience

An interesting part to look at is the experience of the IT administrator. That can be achieved by looking at the Conditional Access Insights workbook (as shown last week). The Conditional Access Insights workbook can be used to get the insights of the different Report-only mode conditional access policies. The data in the workbook can be filtered to only show information about Report-only mode conditional access policies, or even only data of a specific conditional access policy.

Besides that workbook, the Sign-ins monitoring of Azure AD also provides a new tab in the details of a sign-in. That tab is the Report-only (Preview) tab. As shown below that tab provides information about the different Report-only mode conditional access policies that were applicable to the sign-in. Per conditional access policy, the result is shown of the sign-in. That result will show what the effect would be of that conditional access policy and that information will help with determining the impact of enabling that conditional access policy.

Below is an overview of the different result states of a Report-only conditional access policy. Almost all of these results are shown in Figure 3 above (with the exception of the user action required result).

ResultExplanation
Report only: FailureThe configured conditional access policy conditions were satisfied, but not all the required (non-interactive) controls were satisfied.
Report only: SuccessThe configured conditional access policy conditions and required (non-interactive) controls were satisfied. 
Report only: Not appliedNot all configured conditional access policy conditions were satisfied.
Report only: User action requiredThe configured conditional policy conditions were satisfied, but a user action would be required to satisfy the required controls.

More information

For more information regarding report-only, please refer to the following documents:

Conditional Access Insights

This week is all about creating awareness for the Conditional Access Insights workbook. This workbook is currently still in preview and is using Azure Monitor workbook functionality. The Conditional Access Insights workbook contains sign-in log queries that can help IT administrators with getting insights on the impact of conditional access policies. That is useful for troubleshooting, for following trends and for testing the latest introduction to conditional access of Report-only policies. Especially the latest category can be easily verified by using the Conditional Access Insights workbook. In this post I’ll walk trough the steps of creating a Log Analytics workspace (to store Azure Monitor log data), followed by the steps to send Azure AD sign-in information to Azure Monitor logs.I’ll end this post by actually looking at the Conditional Access Insights workbook.

Create a Log Analytics workspace

The first step to prepare for using the Conditional Access Insights workbook, is to create a Log Analytics workspace. A Log Analytics workspace is a unique environment for Azure Monitor log data. Each Log Analytics workspace has its own data repository and configuration, and data sources and solutions are configured to store their data in a particular workspace. To create a Log Analytics workspace simply follow the 2 steps below.

  1. Open the Azure portal and navigate to  All services  > Log Analytics workspaces to open the Log Analytics workspaces blade
  2. On the Log Analytics workspaces blade, provide the following information and click OK
  • Select Create New
  • Log Analytics Workspace: Provide a unique name for the Log Analytics workspace
  • Subscription: Select a valid subscription for the Log Analytics workspace
  • Resources group: Select an existing resource group for the Log Analytics workspace, or click Create new to create a new resource group for the Log Analytics workspace
  • Location: Select a location for the Log Analytics workspace
  • Pricing tier: Select a pricing tier for the Log Analytics workspace

Note: Alternatively the Log Analytics workspace can be created during the process of configuring the diagnostic settings of Azure AD.

Send logs to Azure Monitor logs

The second step to prepare for using the Conditional Access Insights workbook, is to send the Azure AD sign-in logs to Azure Monitor logs (previously known as Log Analytics). Azure Monitor logs allows the administrator to query data to find particular events, analyze trends, and perform correlation across various data sources. To send the Azure AD sign-in logs to Azure Monitor logs simply follow the 3 steps below.  

  1. Open the Azure portal and navigate to  Azure Active Directory  > Diagnostic settings to open the [Azure AD] > Diagnostic settings blade
  2. On the [Azure AD] > Diagnostic settings blade, click Add diagnostic settings to open the Diagnostic settings blade
  3. On the Diagnostic settings blade, provide the following information and click Save
  • Name: Provide a unique name for the diagnostic settings configuration
  • Select Send to Log Analytics
  • Subscription: Select a valid subscription for the Azure Monitor logs
  • Log Analytics Workspace: Select the previously created Log Analytics workspace as a location to store the Azure Monitor logs
  • Log: Select SignInLog

Conditional Access Insights workbook

After making sure that the Azure AD sign-in information is send to Azure Monitor logs, the Conditional Access Insights workbook can be used to get insights in the log data. This workbook contains sign-in log queries that can help IT administrators monitor the impact of conditional access policies. This provides the IT administrators with the ability to report on how many users would have been granted or denied access. This workbook contains details per condition so that the impact of a policy can be contextualized per condition. The following steps walk through navigating to and through the Conditional Access Insights workbook.

  1. Open the Azure portal and navigate to  Azure Active Directory  > Workbooks to open the [Azure AD] > Workbooks blade

Tip: Also make sure to take a look at the other available workbooks, as those workbooks provide a lot of insights about the different sign-ins. Really useful for insights.

  1. On the [Azure AD] > Workbooks blade, click Conditional Access Insights (Preview) to open the Conditional Access Insights (Preview) workbook

The Conditional Access Insights workbook provides the IT administrator with a lot of insights based on the Azure AD sign-in information. The figures above show the following information:

  • Figure 4 shows the parameter selection and the Impact summary section of the workbook. The parameter selection section provides five parameters to filter the insights of the workbook: Conditional Access Policy, Time Range, User, Apps and Data View. The first filter can also be used to easily verify the impact of the recently Report-only conditional access policies, as the insights can be filtered to a specific conditional access policy. The Impact summary section, shows a quick overview of the results for the selected conditional access policy in the specified time range. Clicking on the different tiles will further filter the breakdown sections.
  • Figure 5 and 6 show the Breakdown per condition and sign-in status section of the workbook. The Breakdown per condition and sign-in status section shows the impact of the selected conditional access policies broken down by each of six conditions: Device state, Device platform, Client apps, Sign-in risk, Location and Applications. Clicking on the logs sign with a breakdown, will open the used query in the logs viewer. That will provide the kql-query that is used to filter the right information.
  • Figure 7 shows the Sign-in details section of the workbook. The Sign-in details section enables the IT administrator to investigate individual sign-ins, filtered by the parameters selected in the workbook. Search for individual users, sorted by sign-in frequency, and view their corresponding sign-in events.

More information

For more information regarding conditional access insights, refer to the following documents: