Configuring the OneDrive sync app basics for Windows devices

This week is all about configuring the OneDrive sync app basics for Windows devices. The main component for accessing OneDrive for Business content on Windows devices, is the OneDrive sync app. By default the OneDrive sync app is available on Windows devices and installed per user. In this post I’ll have a look at the installation of the OneDrive sync app and the basic configuration that I think that should be applied to get the best user experience. All by using Microsoft Intune for managing the Windows devices. I’ll end this post by having a quick look at the configuration on the Windows device.

OneDrive sync app installation

The first thing that should be addressed is the installation of the OneDrive sync app. By default, the OneDrive sync app is available on Windows devices and installs per user. That means that the OneDrive sync app will be installed in the %localappdata% directory, for each user that signs in on the Windows device. That’s not always the most optimal method for addressing the OneDrive sync app installation, as it also often means that during the initial sign in of the user, an update of the OneDrive sync app will be downloaded and installed. To address that, especially on shared and multi-user devices, I like to install the OneDrive sync app with the per-machine installation option. That effectively means that the OneDrive sync app will be installed in the %Program Files% directory (keep in mind that it’s a 32-bit app) and that will make sure that all profiles on the Windows device will use the same OneDrive binaries. Besides the installation location, the behavior of OneDrive is similar.

To make sure that the OneDrive sync app is up-to-date during the initial sign in of to user – to make sure that the different available policies will apply immediately an that conditional access will work – the OneDrive sync app should be up-to-date after provisioning the device. Ideally during the Out-of-the-Box experience (OOBE), with or without using Windows Autopilot. That can be achieved by using a simple PowerShell script, of which an example is shown below.

#Download OneDrive per-machine installer
$downloadLocation = "https://go.microsoft.com/fwlink/?linkid=844652"
$downloadDestination = "$($env:TEMP)\OneDriveSetup.exe"
$webClient = New-Object System.Net.WebClient
$webClient.DownloadFile($downloadLocation, $downloadDestination)

#Run OneDrive per-machine installer
$installProcess = Start-Process $downloadDestination -ArgumentList "/allusers" -WindowStyle Hidden -PassThru
$installProcess.WaitForExit()

That script will download the latest version of OneDriveSetup.exe and will install it with the per-machine installation option. To make sure that it will be installed during the OOBE, wrap it as a Win32 app. As a detection method simply use the installation directory (as the directory will change) of the OneDrive sync app. The reason to go for a Win32 app is simple: a Win32 app will be installed and tracked during the Enrollment Status Page (ESP) and that will make sure that the OneDrive sync app is up-to-date before the user signs in to the Windows device.

Note: For further tuning the initial sign in of the user, have a look at this section of a post by Ben Whitmore.

OneDrive sync app basic configurations

The second thing that should be addressed is the configuration of the OneDrive sync app. The idea of configuring the OneDrive sync app on the Windows device, is to make sure that the user can be productive as fast as possible without any user interaction. The following settings are my preferred configurations that should be performed to achieve that goal. The list also contains some settings to limit potential data loss, which might not apply to all organizations. All of these settings are now available as a part of the Administrative Templates that are available in Microsoft Intune. As these settings are configured via Administrative Templates, the configurations are eventually done by using registry key values (device settings at HKLM\SOFTWARE\Policies\Microsoft\OneDrive and user settings at HCU\SOFTWARE\Policies\Microsoft\OneDrive). To configure Administrative Templates, simply open the Microsoft Endpoint Manager admin center portal, navigate to Device > Configuration profiles and create a new profile.

Silently sign in users to the OneDrive sync client with their Windows credentials – This setting is a must for every organization, as it’s used, on (hybrid) Azure AD joined devices, to set up the OneDrive sync app for the user that signs in on the Windows device.

When using the following configuration, the OneDrive sync app will be automatically (and silently) set up for the user that signs in on the Windows device, without the need for the user to provide credentials. That configuration will set the registry key value SilentAccountConfig to 1.

  • Setting type: Device
  • Setting value: Enabled

Silently move Windows known folders to OneDrive – This setting is strongly advised for every organization, as it’s used to set up the redirection of the known folders (Documents, Pictures, and Desktop) of the user to OneDrive.

When using the following configuration, the known folders will automatically (and silently) redirected to OneDrive without user interaction. Besides that, the user receives a notification after the folders have been successfully redirected. That configuration will set the registry key value KFMSilentOptIn to {{yourTenantId}} and KFMSilentOptInWithNotification to 1.

  • Setting type: Device
  • Setting value: Enabled
  • Tenant ID: {{yourTenantId}}
  • Show notification to users after folders have been redirected: Yes

Prevent users from redirecting their Windows known folders to their PC – This setting is strongly advised for every organization (especially in combination with the previous setting), as it’s used to prevent the user from redirecting the known folders (Documents, Pictures, and Desktop) back to the Windows device.

When using the following configuration, the user is prevented from redirecting the known folders back to the Windows device. It forces users to keep their known folders redirected to OneDrive. That configuration will set the registry key value KFMBlockOptOut to 1.

  • Setting type: Device
  • Setting value: Enabled

Use OneDrive Files On-Demand – This setting is strongly advised for every organization, as it’s used to configure OneDrive Files On-Demand. Files On-Demand will help organizations with saving storage space on the Windows device and minimizes the network impact of the OneDrive sync.

When using the following configuration, Files On-Demand is automatically configured for the user. The user will see online-only files in File Explorer, by default, and de file contents don’t download until a file is opened. That configuration will set the registry key value FilesOnDemandEnabled to 1.

  • Setting type: Device
  • Setting value: Enabled

Set the sync client update ring – This setting is strongly advised for every organization, as it’s used to configure the update ring for the OneDrive sync app. It enables the administrator to choose one of the following update rings.

  • Enterprise: In this ring the user gets new features, bug fixes, and performance improvements last.
  • Production: In this ring the user gets the latest features as they become available. This is the default.
  • Insider: In this ring the user receives builds that let them preview new features coming to OneDrive.

When using the following configuration, the update ring will be configured to the production ring and the OneDrive sync app will get the latest features as they come available. That configuration will set the registry key value GPOSetUpdateRing to 5 (Insider=4, Enterprise=0)

  • Setting type: Device
  • Setting value: Enabled
  • Update ring: Production

Allow syncing OneDrive accounts for only specific organizations – This setting is advised for organizations in specific scenarios, as it’s used to prevent the user from uploading files to other organizations by whitelisting allowed organizations.

When using the following configuration, the user will be prevented from adding an account of a different organization. The user receives an error if they attempt to add an account from an organization that is not whitelisted. When a user is already syncing files from another organization, the files stop syncing. That configuration will set the registry key AllowTenantList with a value of {{yourTenantId}} to {{yourTenantId}}.

  • Setting type: Device
  • Setting value: Enabled
  • Tenant ID: {{yourTenantId}}

Prevent users from syncing personal OneDrive accounts – This setting is advised for organizations in specific scenarios, as it’s used to prevent the user from uploading files to their personal OneDrive account.

When using the following configuration, the user will be prevented from adding a personal OneDrive account. When the user is already syncing files from a personal OneDrive, the files stop syncing. That configuration will set the registry key value of DisablePersonalSync to 1.

  • Setting type: User
  • Setting value: Enabled

End-user experience

Now let’s end this post by having a quick look at the end-user experience after applying these configurations. Let’s start by having a look a the last two settings that can be used to prevent easily “losing” data to personal and other organizational accounts. When the user will try to add a personal account, the user will be provided with a message as shown in Figure 8 (below on the left). When the user will try to add another work account, the user will be provided with a message as shown in Figure 9 (below on the right).

The experience of the other more common OneDrive sync app configurations is shown below in Figure 10. OneDrive is automatically configured (see number 1), the known folders are automatically moved to OneDrive (see number 2), the files are on-demand available (see also number 2) and the user is notified about the successful configurations (see number 3).

From an administrator perspective there are also some interesting registry and file locations to look at. To see that the per-machine installation worked as expected, a OneDrive folder should exist in the %ProgramFiles% directory (keep in mind that it’s a 32-bit app). And to see that the device configurations are applied, the corresponding registry keys should be available in HKLM\SOFTWARE\Policies\Microsoft\OneDrive. The user configurations should be available in HCU\SOFTWARE\Policies\Microsoft\OneDrive.

More information

For more information about configuring OneDrive for Business for Windows devices, refer to the following docs:

Simplifying the migration of Android device administrator to Android Enterprise work profile management

This week is all about a recently introduced feature that will help organizations with their move away from Android device administrator managed devices to Android Enterprise work profile management. That is a very welcome feature as Google is decreasing device administrator support in new Android releases, which makes difficult for Microsoft Intune (and any other MDM-solution) to adequately manage Android device administrator managed devices starting with Android 10. The feature in Microsoft Intune that will help with moving away from Android device administrator managed devices is a compliance setting that will enable organizations to block devices in a structured manner and to provide a direct migration path to Android Enterprise work profile management.

In this post I’ll show how to create and configure a device compliancy policy that will slowly trigger end-users to start the migration to Android Enterprise work profile management, followed by the steps to block the enrollment of Android device administrator managed devices. Together that should help organizations to fully move away from Android device administrator managed devices. I’ll end this post by having a look at the end-user experience.

Configuring the device compliance policy

The first step is preparing a good migration experience, from Android device administrator managed devices to Android Enterprise work profile management, for the end-users. That can be achieved by creating a device compliance policy that eventually will block Android device administrator managed devices. To make sure that the end-user is not immediately being blocked from accessing company resources, I advise to use at least two levels of noncompliance. The first level would be that the end-user receives an email message with the advise to start the migration and the second level would be to actually block access to company resources. That can be after a longer period of noncompliance. The following seven steps walk through the steps for configuring a device compliance policy and provide some guidance for the different configurations. After the creation of the device compliance policy, assign the policy like any other policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Android > Compliance policies to open the Android | Compliance policies blade
  2. On the Android | 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 device compliance policy
  • Description: (Optional) Provide a description for the device compliance policy
  • Platform: Select Android device administrator
  • Settings: See step 4 and 5
  • Locations: Leave default (for this post)
  • Actions for noncompliance: See step 6
  • Scope (Tags): Leave default (for this post)
  1. On the Android compliance policy blade, select Device Health to open the Device Health blade
  2. On the Device Health blade, select Block with Devices managed with device administrator and click OK to return to the Android compliance policy blade and click OK to return to the Create Policy blade
  3. On the Create Policy blade, select Actions for noncompliance to open the Actions blade
  4. On the Actions blade, add an action to first notify the user via email and make sure to adjust the default action to not mark a device as noncompliant immediately. That will provide the end-user with time to perform the migration before completely being blocked.

Note: The url https://portal.manage.microsoft.com/UpdateSettings.aspx can be used in the email message to launch the Company Portal app directly in the Update device settings page.

For automation purposes, automating the device compliance policy configuration can be achieved by using the deviceCompliancePolicies object in the Graph API.

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

Configuring the device enrollment restrictions

The second step is making sure that new Android device administrator managed devices can no longer be enrolled into Microsoft Intune. That can be achieved by using device enrollment restrictions. The device enrollment restrictions can be used for blocking the enrollment of Android device administrator devices. The following five steps walk through the adjustment of the default enrollment restrictions. Something similar, and often more flexible, can be achieved by using custom enrollment restrictions.

  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, select Block with Android device administrator (see example below) and click Review + save to continue to the Review + save page
  5. On the Review + save page, click Save

For automation purposes, automating the device type restriction configuration can be achieved by using the deviceEnrollmentConfigurations object in the Graph API.

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

End-user experience

Now let’s end this post by having a look at the end-user experience, which is the most important part of everything in this post. The end-user experience determines whether this migration process will be adopted by the end-user and whether this migration process is intuitive enough to walk the end-user through this migration process. My personal experience, after performing multiple of these migrations, is very positive. It catches problems and brings the end-user back to the progress in the Company Portal app. Even on an older device, which wasn’t encrypted, I eventually ended up in the Company Portal app.

Figure 4 to Figure 14 below, walk through the migration steps for the end-user when starting with an Android device administrator managed device and moving to Android Enterprise work profile management. Figure 5 is also the starting point when the end-user would click on the provided link in an email and Figure 15 provides an overview of the end result.

Note: In Figure 4 it already shows that the device status is “Not in Compliance“, while in fact the device can still be “In grace period“. Also, in Figure 5 the end-user will receive the message “Unable to resolve” when the enrollment of Android Enterprise (work profile) devices is restricted for the specific end-user.

More information

For more information about moving to Android Enterprise work profile management and enrollment restrictions, refer to the following docs:

Changing the primary user of Windows devices

This week is all about the primary user of a Windows device. More specifically about the recently introduced functionality to change or remove the primary user of a Windows device. The primary user is used within Microsoft Intune to map a licensed user to a device. Changing the primary user enables the administrator to switch the primary user of a device from one user to another user, or to switch a device without an assigned primary user (shared device) to a specific user. Besides that, removing the primary user enables the administrator to switch a device from a specific user to a shared device. In this post I’ll start with a short introduction about the primary user (and shared devices), followed by actually changing the primary user. The steps for changing the primary user manually and the places to look at in the Microsoft Graph API for automating the steps.

Introduction to the primary user

Before looking at the possibilities of changing or removing a primary user, it’s good to understand the usage and default configuration of the primary user of a Windows device. That’s why it’s good to start with a short introduction. The primary user is used within Microsoft Intune to map a licensed user to a device. That enables the user to see the device in the Company Portal app and the Company Portal website, and also enables the user to perform self-service actions on that device. Besides that, it helps the administrator when troubleshooting and supporting users.

When a device has no primary user assigned, the Company Portal app detects it as a shared device. Shared devices can be identified with a “shared” label appearing on the device tile in the Company Portal app. On a shared device, the Company Portal app can still be used to request and install available apps. However, self-service actions aren’t available. By removing the primary user of a device, the device is configured to operate in shared mode.

Microsoft Intune automatically adds the primary user to the Windows device during, or soon after, the enrollment of the device. The table below, based on the table in my post about Windows 10 enrollment methods, provides an overview of the user that is added as primary user to the device. When the user performs the enrollment, the primary user is added during enrollment, and when the device is automatically enrolled, the primary user is added during sign in.

Enrollment methodOwnershipPrimary user
Bring Your Own DevicePersonalUser that performs enrollment
Azure AD joinCorporateUser that performs enrollment
Windows AutopilotCorporateUser that performs enrollment
Device Enrollment ManagerCorporateNone
Provisioning packageCorporateNone
Co-managementCorporateFirst user that signs in
Group PolicyCorporateFirst user that signs in

Note: Keep in mind that Windows Autopilot contains multiple scenarios, including a scenario without user interaction. In that case no primary user is assigned.

Changing the primary user

Just before looking at the actual steps of changing the primary user of a Windows device, it’s good to go through a few notes about changing the primary user.

  1. Changing the primary user can take up to 10 minutes to be reflected.
  2. Changing the primary user is currently not possible on co-managed devices.
  3. Changing the primary user does not make any changes on the local device (the local group membership are not adjusted).
  4. Changing the primary user doesn’t change the “Enrolled by” user.
  5. Changing the primary user doesn’t affect the assigned user in Windows Autopilot.

Now let’s have a look at the steps for changing the primary user of a Windows device in the Microsoft Endpoint Manager admin center portal. After looking at the manual steps, I’ll also have a quick look at the Graph API for automating these steps. The steps for removing the primary user are similar and just one click away. When following the four steps below for changing the primary user of the Windows device, the steps for removing the primary user will also become clear (during step 2).

Note: To change the primary user of a Windows device, the administrators should be at least Intune Administrator, Help Desk Operator, School Administrator, or Endpoint Security Manager.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Windows devices > {DeviceName} > Properties to open the {DeviceName}|Properties blade
  2. On the {DeviceName}|Properties blade, select Change primary user to open the Select primary user blade
  1. On the Select primary user blade, select a user and click Select to return to the {DeviceName}|Properties blade
  2. On the {DeviceName}|Properties blade, click Save

For automation purposes, it might be better to know how to automate the primary user configuration. That can be achieved by using the managedDevices object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices('{managedDeviceId}')/users/$ref

Below is an example of a JSON that should be used for adding a primary user. To create the relationship between the mangedDeviceId and the userId, the JSON contains OData data.

@odata.id: "https://graph.microsoft.com/beta/users/{userId}"

Keep in mind that at the moment of writing this article the required properties are only available in the BETA version of the API and production use is not supported.

More information

For more information about primary users of Windows devices, 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:

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.

Windows 10 MDM (PowerShell) scripting

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

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

Configuring device settings

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

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

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

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

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

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

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

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

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

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

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

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

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

Triggering device actions

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

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

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

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

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

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

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

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

More information

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

Simple method for adding notifications to scripted installations

This week is focused on the end-user experience. More specifically, the end-user experience for scripted actions. Especially when deploying apps, or performing other scripted actions, by using the PowerShell functionality, there could be actions of interest for the end-user.In that case I would like to notify the end-user. The app deployment functionality already provides the option to display notifications to the end-user and in this post I’ll show a simple, but effective method, to also display notifications to scripted installations. That can be a nice addition to this post about combining the powers of the Intune Management Extension and Chocolatey. In this post I’ll provide an updated script, followed by the required configuration steps. I’ll end this post with the end-user experience.

Script

The first step is to create a PowerShell script that can be used to install Chocolaty packages and to show notifications to the end-user after a successful installation. The following script provides the exact mentioned functionality, nothing more, nothing less, and the script is documented to provide some more details about the exact actions. The script uses the BurntToast module, which is available in the PowerShell Gallery, to display notifications.

Note: The BurntToast module, which is used, will only work for the logged-on user. For functionality in SYSTEM context, additional adjustments are required.

Configuration

The next step is to configure the PowerShell script in Microsoft Intune. The script must run in SYSTEM context to easily install new Windows Features. To upload the script, follow the five steps below. After uploading the script, simply assign the script to the required devices. I deliberately mentioned devices, as I’m using a security group that filters on the version of Windows 10. The good thing is that nowadays these scripts can be assigned to devices and that users are not required to be logged on first.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts to open the Device configuration – PowerShell scripts blade;
2 On the Device configuration – PowerShell scripts blade, click Add to open the Script Settings blade;
3a Notification-AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Create;

  • Name: Provide a valid name for the PowerShell script;
  • Description: (Optional) Provide a description for the PowerShell script;
  • Script location: Browse to the created PowerShell script;
  • Settings: See step 3b;

Note: The script must be less than 200 KB.

3b Notification-ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK;

  • Run the script using the logged on credentials: Yes;
  • Enforce script signature check: No;
  • Run script in 64 bit PowerShell: Yes;

Explanation: This configuration will make sure that the script will run by using the user credentials on 32-bit and 64-bit devices.

Note: Keep in mind that the script will be running by using the user credentials, which will require the user to be local administrator for installing the different apps.

End-user experience

Let’s end this post by having a look at the end-user experience. This time I choose to go for an animated gif, as that will provide the best example of the end-user experience. Below is an example of the script installing 7-Zip and Notepad++.

Notification-Experience

More information

For more information about the BurtToast module, please refer to the PowerShell Gallery.

Simply enabling Windows Sandbox

This blog post uses Containers-DisposableClientVM, to enable the Windows Sandbox feature on Windows 10 devices. This is available in Windows 10 Insider build 18305 or later.

This week is all about enabling a recently introduced Windows Feature. That Windows Feature is Windows Sandbox. Windows Sandbox is a lightweight desktop environment that is specifically created for safely running applications in isolation. It provides an isolated, temporary, desktop environment where users can run untrusted software without the fear of lasting impact to their device. Any software installed in Windows Sandbox stays in the sandbox and cannot affect the host. The installed software is permanently deleted, once Windows Sandbox is closed. Windows Sandbox is part of Windows 10 (Pro and Enterprise) Insider build 18305 or later. In this post I’ll show how to use Microsoft Intune to enable Windows Sandbox, followed by the end result.

Script

Let’s start  by looking at the PowerShell script that can be used to enable the Windows Sandbox feature. The following PowerShell script can be used to basically enable any Windows Feature, but will be used in this post to specifically install the Windows Sandbox feature.

Note: When using a virtual machine, nested virtualization must be enabled for that virtual machine. That can be achieved by using the following PowerShell cmdlet on the host machine: Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true.

Configuration

The next step is to configure the PowerShell script in Microsoft Intune. The script must run in SYSTEM context to easily install new Windows Features. To upload the script, follow the five steps below. After uploading the script, simply assign the script to the required devices. I deliberately mentioned devices, as I’m using a security group that filters on the version of Windows 10. The good thing is that nowadays these scripts can be assigned to devices and that users are not required to be logged on first.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts;
2 On the Device configuration – PowerShell scripts blade, click Add script to open the Script Settings blade;
3a EWS-AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Settings to open the Script Settings blade;

  • Name: Provide a valid name for the PowerShell script;
  • Description: (Optional) Provide a description for the PowerShell script;
  • Script location: Browse to the created PowerShell script;
  • Settings: See step 3b;

Note: The script must be less than 200 KB (ASCII) or 100 KB (Unicode).

3b EWS-ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK to return to the PowerShell script blade;

  • Run the script using the logged on credentials: No;
  • Enforce script signature check: No;
4 Back on the Add PowerShell script blade, click Create.

End result

Now let’s end this post by looking at the results. To verify a success, simply start Windows Sandbox. That Windows Feature should be available now. To verify a success from a Microsoft Intune perspective, either check the status of the PowerShell script in the Azure portal , or look at the AgentExecutor.log and IntuneManagementExtension.log on the device.

EWS-Example

Note: By using PowerShell, at this moment, Windows Sandbox can also be enabled on not supported devices (devices without virtualization capabilities), .

More information

For more information regarding Windows Sandbox and PowerShell scripts in Microsoft Intune, please refer to the following articles:

Simply installing the Windows 10 Accounts extension for Google Chrome by using PowerShell

This week is all about simply automatically installing the Windows 10 Accounts extension for Google Chrome. About a year ago I showed that the extension is required when using conditional access and I also showed earlier that it’s possible to use ADMX ingestion to configure Google Chrome. However, the latter is always the easiest method. It actually might be a bit complicated for a simple configuration. That’s why I’m going a different road this time. This time I’m going for a small PowerShell script that will create a registry key and value. In this post I’ll show how to create the PowerShell script, how to assign it by using Microsoft Intune and the end result in Google Chrome.

Create PowerShell script

As I’ve decided to use a PowerShell script to install the Windows 10 Accounts extension for Google Chrome, together with Google Chrome, this section will explain the variables and actions used in the script. For installing Google Chrome, I’ll reuse a PowerShell script that I explained in this post about Combining the powers of the Intune Management Extension and Chocolatey.

Script variables

The PowerShell script contains a few variables that are used to make sure that the Windows 10 Accounts extension will be installed. Those variables together are actually a registry key and value. That means that the variables block on top of the script (see script snippet section) at least contains the values as shown below. The registry key and value will trigger the installation of the Windows 10 Accounts extension and is the same registry key and value that would otherwise be created by the ADMX configuration.

Path HKLM\Software\Policies\Google\Chrome\ExtensionInstallForcelist
Name 1
Type REG_SZ (String)
Data ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

Script actions

The PowerShell script contains a few actions that it should perform to complete the required activities of installing Google Chrome and the required Windows 10 Accounts extension. It contains the following actions that can be found in the different try-catch blocks (see script snippet section).

  1. Install Chocolatey if it’s not installed;
  2. Install Google Chrome by using Chocolatey (it will automatically check if it’s already installed);
  3. Create the required registry path if it doesn’t exist;
  4. Create the required registry key if it doesn’t exist.

Script snippet

The PowerShell script is shown below and should pretty much explain itself.

Configure PowerShell script

The next step is to configure the PowerShell script in Microsoft Intune. To upload the script, follow the next five steps. After uploading the script, simply assign the script to the required users and/or devices.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts;
2 On the Device configuration – PowerShell scripts blade, click Add script to open the Script Settings blade;
3 ChromeExtension-PowerShell-IntuneOn the Add PowerShell script blade, provide the following information and click Settings to open the Script Settings blade;

  • Name: Provide a valid name for the PowerShell script policy;
  • Description: (Optional) Provide a description for the PowerShell script policy;
  • Script location: Browse to the PowerShell script.

Note: The script must be less than 10 KB (ASCII) or 5 KB (Unicode).

4 ChromeExtension-ScriptSettings-IntuneOn the Script Settings blade, provide the following configuration and click OK to return to the PowerShell script blade;

  • Run the script using the logged on credentials: No;
  • Enforce script signature check: No;

Note: Configure Run the script using the logged on credentials to No means that the PowerShell script will run in SYSTEM context;

5 Back on the Add PowerShell script blade, click Create.

End result

Now let’s end this post by looking at the end result. I’ll do that by showing a screenshot of Google Chrome. Below is a screenshot of Google Chrome showing the policy page, which shows the configured policy, and it also shows the installed Windows 10 Accounts extension (blue Windows icon on the top right).

ChromeExtension

More information

Fore more information related to conditional access and the requirements for Google Chrome, please refer to this article about Conditional Access Technical Reference | Client apps condition.