Managing local administrators via Windows 10 MDM

This week is all about managing local administrators via Windows 10 MDM by using restricted groups. There has been many requests for a post like this after I wrote this post about creating local user accounts. And I have to admit that this post has been on my backlog for a long time. Better late than never, I think. Also, I’m definitely not the first to write about this subject, but I do think that I have some new insights that can be really helpfull. In this post I’ll start with an overview of the options for configuring local administrators on Azure AD joined (and Microsoft Inune managed) devices and reasons for using restricted groups, followed by the steps for configuring restricted groups. I’ll end this post by looking at the end-user experience.

Overview

When discussing the local administrators on Azure AD joined devices, it’s often about the Global administrator role and the Device administrator role. These roles are by default local administrator on Azure AD joined devices. Users can be added to the Global administrator role like any other administrator role. Adding users to the Device administrator role, however, is a different configuration. Users can be added by configuring additional local administrators on Azure AD joined devices. These two roles have one thing in common and that is that those roles apply to all Azure AD joined devices. No exceptions. However, there might be scenarios in which it’s required to limit the local administrators on a device, or scenarios in which it’s required to differentiate the additional local administrators for different groups of devices.

Another option to manage local administrator on Microsoft Intune managed devices – which are often also Azure AD joined – is by using restricted groups. For this it’s possible to use the RestrictedGroups section in the Policy CSP. That contains a single node that can be used for adding local administrators (or for adjusting any other existing local group). When specifically looking at managing local administrators, make sure to keep the following in mind:

  • By using restricted groups, the provided local administrators will replace the existing local administrators.
  • By using restricted groups, which is a configuration node of the Policy CSP, the provided local administrators will be reapplied, within 8 hours, when changed by the user (behavior starting with Windows 10, version 1903).
  • The default local Administrator account must be part of the custom configuration, as it’s required for applying a custom configuration.
  • Every Azure AD joined device contains two SIDs (one representing the Global administrator role and one representing the Device administrator role) that are by default part of the local administrators.

Note: By default, on Azure AD joined devices, the user joining the device to Azure AD is also local administrator on the device.

Configuration

By knowing the available configuration options and the different configurations it’s time to look at the configuration steps. The five steps below walk through the configuration. Throughout those configuration steps, I’ll provide the required information regarding the OMA-URI and the XML-value that should be configured.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices > Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile blade
  3. On the Create a profile blade, provide the following information and click Create to open the Create profile blade
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Create profile blade, select Settings to open the Custom OMA-URI Settings blade
  2. On the Custom OMA-URI Settings blade, click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
  • Data type: Select String
  • Value: The value should be an XML. That XML should contain a groupmembership-element and that groupmembership-element should contain an accessgroup-element. That accessgroup-element contains the local group that should be adjusted and that accessgroup-element contains member-elements that contain the users that should be added to the local group. For an example see the XML below.

Note: The RestricedGroups section can be used to add members to any local group on a device.

<groupmembership>
	<accessgroup desc = "Administrators">
		<member name = "Administrator" />
		<member name = "AzureAD\pvanderwoude@petervanderwoude.nl" />
		<member name = "AzureAD\tvanderwoude@petervanderwoude.nl" />
		<member name = "S-1-12-1-2091167666-1329275207-1706997396-915002206" />
		<member name = "S-1-12-1-2447031348-1225114094-1633491097-1064162478" />
	</accessgroup>
</groupmembership>

End-user experience

Now let’s end by having a look at the end-user experience. The best place to look is in the Properties of the Administrators group. That group should reflect the provided configuration, as shown in Figure 4.

This configuration is the most common to be used when the primary user of the device is not a local administrator. A method to provide additional support to the end-user, without the requirement of adding that specific account as a local administrator on all devices.

It’s also good to keep in mind that starting with Windows 10, version 1903, the settings of the Policy CSP actually refresh. When, for whatever reason, the configuration of the local administrators was adjusted, the configuration will refresh within 8 hours. The next device check-in will take care of that.

Another place for verifying the configuration, would be to look at MDM Diagnostic Report. That report will show an overview of the RestrictedGroups setting configuration.

More information

For more information about managing local administrators, refer to the following articles:

.

Using bulk actions for renaming Windows devices

A few months ago, I did a blog post about the different ways of renaming Windows 10 devices. This week is a follow-up on that post, as it will also be about renaming Windows devices. This time it’s about using the recently introduced functionality to perform Bulk actions on devices. Those Bulk actions include the action to rename Windows 10 devices in bulk. That Bulk action is also available as a single action on a device and is currently not available for hybrid Azure Active Directory joined devices, nor available for co-managed devices. In this post I’ll show how to perform this action by using the Microsoft Endpoint Manager admin center, followed by using the Microsoft Graph Explorer. I’ll end this post by showing an example using PowerShell and the Microsoft Graph API.

Rename Windows devices using the Microsoft Endpoint Manager admin center

Now let’s start by having a look at using a Bulk action for renaming a Windows 10 device by using the Microsoft Endpoint Manager admin center. This method is – in my opinion – always the first step towards automating an action. The following 9 steps walk through the Bulk action for renaming Windows 10 devices. While performing these steps make sure to use Microsoft Edge and to turn on the Developer tools (Ctrl + Shift + I), as that will help with identifying the Graph request that should be used for automation purposes.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devices > Bulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, provide the following information (see Figure 1) and click Next
  • OS: Select Windows
  • Device action: Select Rename
  • Enter new name: Provide a new naming conform the provided guidelines
  1. On the Devices page, click Select devices to include to select the devices to rename and click Next
  2. On the Review + create page, review the provided information and click Create

Verify request information using the Microsoft Graph Explorer

When following the Bulk action via the Network trace in the Developer tools, it shows the executeAction action that will perform the actual action. The most relevant parts of that action are shown below, as Figure 2 shows the request URL and Figure 3 shows the request payload. That combination is needed for automation purposes.

A closer look shows that the executeAction action is used as the request location to post the request.

https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction

That request requires a request body to supply a JSON representation of the different properties. A closer look at that JSON payload shows the properties action, actionName, deviceIds, deviceName, platform, realAction and restartNow. The good thing is that these properties are pretty self explanatory, especially in combination with the action that was performed to retrieve this information. It’s good to specifically point out that the deviceIds property is an array that can currently contain up to a 100 devices and that the deviceName property should contain the naming format for the different applicable devices.

{
	action: "setDeviceName",
	actionName: "setDeviceName",
	deviceIds: ["d8cd02c1-9443-4ad0-8681-937c2e6d7607"],
	deviceName: "CLDCLN%RAND:2%",
	platform: "windows",
	realAction: "setDeviceName",
	restartNow: false
}

The next step toward automating this Bulk action is by trying the correct request URL and request payload via the Microsoft Graph Explorer, as that’s an easy method to try Graph API requests. Simply sign-in, change the action to POST, add the request URL, add the request payload (as shown in Figure 4) and click Run Query.

Note: The application requires the scope DeviceManagementManagedDevices.PrivilegedOperations.All.

Running the query will return a bulkManagedDeviceActionResult result type. That result type provides a JSON representation of the status properties. Those status properties include successfulDeviceIds, failedDeviceIds, notFoundDeviceIds and notSupportedDeviceIds. The good thing is that these properties are also pretty self explanatory. A simple method to verify this behavior is by throwing in some random deviceIds. Those deviceIds should end up as part of the notFoundDeviceIds.

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#microsoft.graph.bulkManagedDeviceActionResult",
    "successfulDeviceIds": [
        "d8cd02c1-9443-4ad0-8681-937c2e6d7607"
    ],
    "failedDeviceIds": [],
    "notFoundDeviceIds": [],
    "notSupportedDeviceIds": []
}

Rename Windows devices using PowerShell and the Microsoft Graph API

After verifying the request URL and the request payload, the last step toward automating this Bulk action is putting it all together in a PowerShell script. I’m going to provide a really simple example that would still require administrator interaction, but does show how it can be achieved. That example is shown below and basically performs the following actions:

  • Install the PowerShell SDK for Microsoft Intune Graph API (if it’s not installed).
  • Connect with the Graph API, which will prompt the administrator for credentials.
  • Set the required variables for the request URL and the request payload.
  • Invoke the Graph API request with the configured variables.
#Install PowerShell SDK for Microsoft Intune Graph API
If ((Get-Module Microsoft.Graph.Intune) -eq $null) {
    Install-Module -Name Microsoft.Graph.Intune
}

#Connect to Microsoft Graph
$ConnectGraph = Connect-MSGraph

#Set the request URL
$URL = "https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction"

#Set the JSON payload
$JSONPayload = @"
{
	action: "setDeviceName",
	actionName: "setDeviceName",
	deviceIds: ["d8cd02c1-9443-4ad0-8681-937c2e6d7607"],
	deviceName: "CLDCLN%RAND:2%",
	platform: "windows",
	realAction: "setDeviceName",
	restartNow: false
}
"@

#Invoke the Microsoft Graph request
Try {        
    Invoke-MSGraphRequest -HttpMethod POST -Url $URL -Content $JSONPayload -Verbose -ErrorAction Stop
}
Catch {
    Write-Output "Failed to rename the Windows devices"
} 

When the PowerShell script was successfully executed it will also return the bulkManagedDeviceActionResult result type, as shown in Figure 5. Simple improvements to this PowerShell script would be to remove the administrator interaction, add the deviceIds to a variable and query for the required devices.

More information

For more information about renaming Windows devices and , refer to the following articles:

Using policy sets to group objects

This week is all about Policy sets in Microsoft Intune. Policy sets are introduced a few months ago and enable administrators to group management objects that need to be identified and assigned as a single object. That can help with simplifying the administration of the environment. A Policy sets can be a group of almost all different object that are available within Microsoft Intune. That includes objects for different platforms within the same Policy sets. This enables an administrator to use Policy sets for a lot of different use case, from creating a standard for a specific user type to creating a standard set of apps for all users. In this post I’ll walk through the configuration steps and through the different steps I’ll describe the available options and challenges. I’ll end this post with some notes about the assignment of a Policy set.

Creating policy sets

Now let’s have a closer looking at Policy sets by walking through the configuration. The following 9 steps walk through the creation of a Policy set and the different options.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Policy sets to open the Policy sets blade
  2. On the Policy sets blade, select Policy sets and click Create to open the Create a policy set wizard
  3. On the Basics page, provide the following information (see Figure 1) and click Next: Application management
  • Policy set name: Provide a valid name for the Policy set
  • Description: (Optional) Provide a description of the Policy set
  1. On the Application management page, provide the following information (see Figure 2) and click Next: Device management
  • Apps: Click Select apps to add apps to the Policy set. That can be an iOS/iPadOS store app, an iOS/iPadOS line-of-business app, a Managed iOS/iPadOS line-of-business app, an Android store app, an Android line-of-business app, a Managed Android line-of-business app, an Office 365 ProPlus Suite (Windows 10), a Web link, a Built-in iOS/iPadOS app, or a Built-in Android app. That also means that a Windows app (Win32) is currently not supported. After adding an app to the Policy set, the assignment type can also be configured.
  • App configuration policies: Click Select app configuration policies to add app configuration policies to the Policy set.
  • App protection policies: Click Select app protection policies to add app protection policies to the Policy set. That can be an APP targeted at managed Windows devices, an APP targeted at managed iOS/iPadOSOS devices, an APP targeted at managed Android devices, an APP targeted at unmanaged iOS/iPadOSOS devices, or an APP targeted at unmanaged Android devices. That also means that APP targeted at unmanaged Windows devices are not supported.
  1. On the Device management page, provide the following information (see Figure 3) and click Next: Device enrollment
  • Device configuration policies: Click Select device configuration policies to add device configuration policies to the Policy set.
  • Device compliance policies: Click Select device compliance policies to add device compliance policies to the Policy set. Only the Android Enterprise device owner type policies are not available.
  1. On the Device enrollment page, provide the following information (see Figure 4) and click Next: Scope tags
  • Device type restrictions: Click Select device type restrictions to add custom device type restrictions to the Policy set.
  • Windows autopilot deployment profiles: Click Select Windows autopilot deployment profiles to add Windows autopilot deployment profiles to the Policy set.
  • Enrollment status pages: Click Select enrollment status page profiles to add custom enrollment status page profiles to the Policy set.
  1. On the Scope tags page, provide the following information (see Figure 5) and click Next: Assignments
  • Scope tags: Click Select scope tags to add custom scope tags to the Policy set.
  1. On the Assignments page, provide the following information (see Figure 6) and click Next: Review + create
  • Included groups: Click Select groups to include to include groups to the assignment of the Policy set.
  • Excluded groups: Click Select groups to exclude to exclude groups from the assignment of the Policy set
  1. On the Review + create page, verify the following information and click Create

After going through the configuration of a Policy set it’s good to note that security baselines are not part of a Policy set configuration. The guided scenario Try out a cloud-managed PC also creates a policy set to group the different objects that are created during the guided scenario and that are supported as being a part of the guided scenario. That scenario also creates a security baseline assignment that is not part of the created Policy set. Guided scenarios are available on the Home page of the Microsoft Endpoint Manager admin center.

For automation purposes, it might be better to know how to automate the device type restriction configuration. That can be achieved by using the policySet object in the Graph API.

https://graph.microsoft.com/beta/deviceAppManagement/policySets

Assignment notes

Let’s end this post with some notes about the assignment of a Policy set. The following should be kept in mind when creating the assignment for the Policy set.

  • The different non-Windows app protection policies (APP) do not support an assignment via a Policy set. In that case the group will be added as a direct assignment. Those assignments will not be deleted when the assignment of the Policy set is removed.
  • The different APPs do not support an assignment to All users or All devices
  • A Windows autopilot deployment profile does not support an assignment to All users
  • An Enrollment status page profile does not support the assignment of virtual groups (All users, All devices or All user & All devices)
  • An Device type restriction profile does not support the assignment of virtual groups (All users, All devices or All user & All devices)

When the assignment of the Policy set is created it will show as a specific assignment with the different objects that are part of the Policy set (as shown in Figure 8).

More information

For more information about using policy sets for managing groups of objects in Microsoft Intune, refer to the documentation about Use policy sets to group collections of management objects.

Configure FIDO2 security key restrictions

This week is all about FIDO2 security keys. More specifically about configuring FIDO2 security key restrictions to make sure that users can only use specific FIDO2 security keys, or to prevent users from using specific FIDO2 security keys. That makes this blog post a follow up on this post about enabling password-less sign-in with security keys. In this post I’ll provide a short introduction about the FIDO2 security key AAGUID (and how to find it), followed by the steps to configure the FIDO2 security key restrictions. I’ll end this post by looking at the end-user experience.

FIDO2 security key AAGUID

According to the FIDO2 specification each authenticator should provide an Authenticator Attestation GUID (AAGUID) during attestation. An AAGUID is a 128-bit identifier that indicates the type (for example make and model) of the authenticator. The AAGUID should be identical across identical authenticators that are created by the same manufacturer, and should be different from the AAGUID of authenticators of different types and different manufacturers. To ensure this, the AAGUID is randomly generated.

The AAGUID of a FIDO2 security can be used to configure restrictions for the end-users, by either only allowing specific FIDO2 security keys based on their AAGUID or by only blocking specific FIDO2 security keys based on their AAGUID. To help with that some manufactures (like Yubico) provide a complete list of the AAGUIDs of their FIDO2 security keys.

When this information is not easily available, it’s possible to find the AAGUID by using the get_info.py script that’s available in the Python-FIDO2 library provided by Yubico. That script can make the device WINK, which will provide the information about the FIDO2 security that includes the AAGUID. Below (in Figure 1) is an example of FIDO2 security key that is sending a WINK. The information provided when sending the WINK includes the AAGUID and on some devices also the FIDO2 security key name and model.

Another method to retrieve the AAGUID of a FIDO2 security key is to register the security key as a sign-in method. That can be achieved via the Security method section of My account. After registering the security key, the AAGUID can be found with the security key as shown below in Figure 2.

Below is an overview of the FIDO2 security keys that I’ve had available during testing, including their AAGUID.

FIDO2 security keyFIDO2 AAGUID
Yubikey 5 NFC (Firmware version: 5.1.x)fa2b99dc9e3942578f924a30d23c4118
Yubikey 5C (Firmware version: 5.1.x)cb69481e8ff7403993ec0a2729a154a8
Feitian ePass FIDO-NFC Security Key K9ee041bce25e54cdb8f86897fd6418464
Feitian BioPass FIDO2 Security Key K2677010bd7212a4fc9b236d2ca5e9d4084
Feitian BioPass FIDO2 Security Key K2777010bd7212a4fc9b236d2ca5e9d4084
Feitian BioPass FIDO2 Security Key K3312ded7454bed47d4abaae713f51d6393
eWBM Goldengate Security Key G31095442b2ef15e4defb270efb106facb4e
eWBM Goldengate Security Key G32087dbc5a14c944dc88a4797d800fd1f3c

Configuring FIDO2 security key restriction

The configuration steps are pretty straightforward and can be achieved by adjusting the FIDO2 Security Keys authentication method. That can be achieved by performing the 3 steps mentioned below. Those steps are fully focussed on configuring the KEY RESTRICTION POLICY. When the FIDO2 Security Keys authentication method is not yet enabled, make sure to also perform the required actions for that. In other words, make sure to enable the authentication method and configure the target of the authentication method.

  1. Open the Azure portal and navigate to Azure Active Directory Security > Authentication methods Authentication method policy (preview) to open the Authentication methods – Authentication method policy (preview) blade
  2. On the Authentication methods – Authentication method policy (preview) blade, select FIDO2 Security Key to open the FIDO2 Security Key settings section
  3. On the FIDO2 Security Key settings section, provide at least the following information (see also Figure 3 for an overview of the available options) and click Save
  • Enforce key restrictions: Select Yes
  • Restrict specific keys: Select Block to create a key restriction policy that will blacklist the specified AAGUIDs and select Allow to create a key restriction policy that will whitelist the specified AAGUIDs
  • Click Add AAGUID and specify the specific AAGUIDs that should be blocked (blacklisted) or allowed (whitelisted)

End-user experience

Let’s end this post by having a look at the end-user experience. When the end-user wants to register a security key (either not on whitelist, or on the blacklist), via the Security info section in My Profile, the end-user can walk through the complete process of adding another sign-in method. At the end of the process, the end-user will receive an error with the message that the particular key type has been blocked by the organization. The message doesn’t provide a list of supported security keys.

More information

For more information about password-less authentication deployment and password-less FIDO2 security keys, refer to the following articles:

Windows 10 enrollment methods

This week is all about Windows 10 enrollment methods. The different methods to enroll Windows 10 devices into Microsoft Intune. There are many different methods to enroll Windows 10 devices, which makes it easy to get lost. In this post I’ll provide an overview of these different enrollment methods, including the use case of the enrollment method and how to perform the enrollment. This post is definitely not a complete guide through the different enrollment methods. Its main purpose is to create awareness for the different enrollment methods and to describe the main characteristics of the enrollment methods.

The different enrollment methods

Now let’s discuss the different enrollment methods and their use cases. Before starting, it’s good to mention that I’m aware of the existence of the MDM only enrollment method. However, I don’t consider that as a valid option to enroll a device into Microsoft Intune, as that method doesn’t register the device in Azure AD. And that provides many challenges, for example with conditional access. When discussing the different enrollment methods, I’ll try to group those methods were possible and I’ll try to mention the differences.

Bring Your Own Device (BYOD)

Description: The Bring Your Own Device (BYOD) method enables the user to enroll a personal device into Microsoft Intune by using the Settings panel and adding a Work and School account. That action will trigger the flow to register the device in Azure AD and that will also automatically enroll the device into Microsoft Intune.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Keep in mind that within the auto-enrollment configuration, the administrator can also configure MAM enrollment. When the MDM and MAM enrollment is configured for a user, the MAM enrollment takes precedence for personal devices.

Example scenario: This can be useful for Bring Your Own Device (BYOD) scenarios. The device will be enrolled as a personal device.

Azure AD join (with auto enrollment)

Description: The Azure AD join method enables the user to enroll a corporate-owned device into Microsoft Intune, similar to enrolling a personal device – by using the Settings panel and adding a Work and School account – the user can also choose to join the device to Azure AD. That option will become available during the same configuration flow. The user has to specifically choose to join Azure AD during that flow (as shown in Figure 2). This same behavior can also be triggered during the Out-Of-the-Box-Experience (OOBE). That can be achieved by setting the device up for an organization. That will trigger the flow to Azure AD join the device.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1).

Example scenario: This can be useful for Choose Your Own Device (CYOD) scenarios. The device will be enrolled as a corporate-owned device.

Windows Autopilot

Description: The Windows Autopilot method enables users to easily enroll corporate-owned devices. Windows Autopilot can be used to automate the Azure AD Join and directly enroll corporate-owned devices into Microsoft Intune. This method simplifies the OOBE – as mentioned with the Azure AD join method – as it will automatically add the device to AD or Azure AD and directly enroll the device into Microsoft Intune.

Important requirements: This requires that the device should be added in Microsoft Intune as Windows Autopilot devices (as shown in Figure 5) and specific Windows Autopilot profiles should be created to control the behavior and the OOBE.

Example scenario: This is useful in scenarios when handing out devices to users without the need to build, maintain, and apply custom operating system images to the devices. The device will be enrolled as a corporate-owned device.

Device Enrollment Manager (DEM)

Description: The Device Enrollment Manager (DEM) method enables the administrator to enroll multiple corporate-owned devices. The DEM account is a special account with permissions to enroll and manage multiple (up to 1000) corporate-owned devices. That enables a bulk enrollment method for non-personal corporate-owned devices. The enrollment can be achieved by following any of the flows to configure an Azure AD join.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Besides that the Device Enrollment Manager (DEM) should be configured (as shown in Figure 3) and make sure to keep the maximum number of devices that the user account can add to Azure AD matches.

Example scenario: This can be useful in scenarios where the device is enrolled and prepared before handing it out to the user of the device. The device will be enrolled as a corporate-owned device.

Provisioning package

Description: The provisioning package method enables the administrator to bulk enroll corporate-owned devices. A provision package can be used to add devices in bulk to Azure AD and automatically enroll those devices into Microsoft Intune. That provisioning package can be created by using the Windows Configuration Designer (as shown in Figure 4) and can be applied to corporate-owned devices. Once the package is applied, it’s ready for Azure AD users to sign in.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Besides that make sure to keep the maximum number of devices that a user can add to Azure AD matches with the usage of the package.

Example scenario: This can be useful in scenarios where an authorized user joins large numbers of corporate-owned devices. The device will be enrolled as a corporate-owned device.

Co-management

Description: The co-management method enables administrators to automatically enroll corporate-owned devices. Co-management enables organizations to automatically enroll devices into Microsoft Intune. This requires the device to be managed with Configuration Manager and the enablement of co-management. Within the co-management configuration, the automatic enrollment in Microsoft Intune can be configured (as shown in Figure 6).

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1) and that the device is registered or joined to Azure AD (can be achieved via Client Settings).

Example scenario: This is useful in scenarios when the flexibility is still required to use the technology solution that works best for the organization. The device will be enrolled as a corporate-owned device.

Group Policy

Description: The Group Policy method enables administrators to automatically enroll corporate-owned devices. Group Policy enables organizations to automatically enroll devices into Microsoft Intune. The automatic enrollment is triggered by the Group Policy (as shown in Figure 7). That means that the device is always hybrid Azure AD joined.

Important requirements: This requires the device to registered in Azure AD.

Example scenario: This is useful in scenarios when mass-enrolling domain-joined devices.The device will be enrolled as a corporate-owned device.

An overview of the enrollment methods

Let’s end this post by providing short overview of the different enrollment methods and their most important characteristics that are mentioned in throughout this post. Those characteristics are the ownership registration of the device, the user affinity with the device and the user interaction with the device during the enrollment.

Enrollment methodOwnershipUser affinityUser interaction
Bring Your Own DevicePersonalYesYes
Azure AD joinCorporateYesYes
Windows AutopilotCorporateYesYes
Device Enrollment ManagerCorporateNoNo
Provisioning packageCorporateNoNo
Co-managementCorporateYesNo
Group PolicyCorporateYesNo

A couple of remarks with this table are that 1) Windows Autopilot contains multiple scenarios, including scenarios without user interaction and that 2) methods without user affinity provide challenges with conditional access.

More information

For more information about configuring Windows 10 enrollment methods, refer to the following docs:

Controlling Windows 10 feature updates

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

Introducing the control options for Windows 10 feature updates

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

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

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

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

Introducing the Window 10 feature updates policy

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

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

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

Limitations for the Windows 10 feature updates policy

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

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

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

Prerequisites for the Windows 10 feature updates policy

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

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

Configuring the Windows 10 feature updates policy

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

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

Administrator experience

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

More information

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

Block Android device enrollment for specific device manufacturer

This week is all about restricting the enrollment of Android devices. More specifically, about a very recently introduced feature which is the ability to block Android device enrollment based on the manufacturer of the device. That enables the organization to prevent Android devices of specific manufacturers from enrolling in Microsoft Intune. That can be useful when the organization has a specific policy for allowed device manufacturers. In this post I’ll walk through the configuration steps, followed with the end-user experience.

Starting with this post, I’ll provide both the configuration steps via the Microsoft Endpoint Manager admin center portal and the configuration location in the Graph API (including the related JSON-snippet) as part of the configuration steps.

Configuration steps

Now let’s start by having a look at the configuration steps. These configurations can be achieved by either creating custom device type restrictions or by editting the existing default device type restriction. In the following example I’ll walk through these steps by adjusting the default device type restrictions. The following steps show how to add a device manufacturer to a list of blocked manufacturers.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Enroll devices > Enrollment restrictions to open the Enroll devices – Enrollment restrictions blade
  2. On the Enroll devices – Enrollment restrictions blade, select the Default device type restriction and navigate to Properties to open the All Users – Properties blade
  3. On the All Users – Properties blade, navigate to the Platform settings section and click Edit to open the Platform settings page on the Edit restriction blade
  4. On the Platform settings page, provide the manufacturers to block in the Device manufacturer field (see example below) and click Review + save to continue to the Review + save page

Note: Use a comma-separated list when adding multiple manufacturers.

  1. On the Review + save page, click Save

For automation purposes, it might be better to know how to automate the device type restriction configuration. That can be achieved by using the deviceEnrollmentConfigurations object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations

However, keep in mind that the required properties are currently only available in the BETA version of the API. Below is an example snippet of a JSON that contains the Android Enterprise configuration with the blocked manufactures configuration, similar to the configuration via the UI.

"androidForWorkRestriction": {
    "platformBlocked": false,
    "personalDeviceEnrollmentBlocked": false,
    "osMinimumVersion": null,
    "osMaximumVersion": null,
    "blockedManufacturers": [
        "Samsung"
    ]
}

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll do that by showing the behavior on a personally-owned Android device that should enroll by using Android Enterprise work profiles to manage corporate data and apps. By default, enrollment of this type of personally-owned devices is enabled. That can be limited by using the enrollment restrictions, as shown in this post, or by simply blocking personally-owned devices.

In this scenario, I’m allowing the enrollment of personally-owned and company-owned Android devices, but I’m blocking any enrollment of Android devices from a specific device manufacturer.

When the end-user downloaded and installed the Company Portal app and started the enrollment process, at some point during the enrollment process the end-user will be blocked. While being blocked, the end-user will receive the message “Couldn’t add your device“. That message, of which an example is shown on the right, includes a clear explanation of why the device couldn’t be added. In my example the end-user is being told that the company needs the end-user to use an Android device manufacturer other then samsung.

Note: Keep in mind that the only reason that I’m using Samsung as an example in this post, is that I’ve got test Android devices of that device manufacturer. I don’t have any reasons that would actually require me to block the enrollment of Android devices from that device manufacturer.

More information

For more information about blocking Android device enrollment for specific device manufacturers, refer to the following docs:

Exclude specific groups of users or devices from an app assignment

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

Configuration options

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

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

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

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

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

Configuration example

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

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

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

More information

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

Working with (custom) detection rules for Win32 apps

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

Detection rule

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

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

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

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

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

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

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

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

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

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

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

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

Administrator experience

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

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

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

More information

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

Working with (custom) requirements for Win32 apps

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

Requirement type

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

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

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

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

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

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

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

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

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

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

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

Administrator experience

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

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

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

More information

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