Prevent non-administrator users from installing Windows app packages via Windows 10 MDM

This week a short new blog post about a new introduced Windows 10 MDM policy setting, in Windows 10, version 2004, to address new default behavior. That policy setting is related to the installation of Windows app packages. More specifically, that policy setting can be used to prevent non-administrator users from initiating the installation of (signed) Windows app packages. Starting with Windows 10, version 2004, every user – administrator and non-administrator – can initiate the installation of (signed) Windows app packages. On previous versions of Windows 10 that would require the administrator to at least enable the ability to sideload apps (part of the developer settings), for users to be able to initiate the installation of (signed) Windows app packages. This policy setting can be used to return to a situation similar to before, as it enables the administrator to prevent users from initiating the installation of (signed) Windows app packages. That can be the preferred situation for specific groups of users. In this post I’ll quickly go through the setting and requirements, followed by the configuration steps. I’ll end this post by having a look at the end-user experience.

Overview

Let’s start with a quick overview of this specific policy setting. This is an ADMX-backed setting that is available via the AppxPackageManager.admx and this policy setting is used to manage the ability of users to initiate the installation of (signed) Windows app packages. The friendly name of this policy setting is Prevent non-admin users from installing packaged Windows apps and this policy setting is only available in the Windows 10 Business, Enterprise and Education editions.

The policy setting is available in the ApplicationManagement area in the Policy CSP. That’s not a new area, but starting with Windows 10, version 2004, it contains this specific new policy setting. In the table below is an overview of the policy setting and keep in mind that the complete node of this policy setting starts with ./Vendor/MSFT/Policy/Config/ApplicationManagement/.

PolicyDescription
BlockNonAdminUserInstallThis policy setting manages the ability of non-administrator users to install (signed) Windows app packages. When enabled (value: 1), non-administrator users will be unable to initiate the installation of (signed) Windows app packages. Administrator users will still be able to initiate the installation of (signed) Windows app packages in Administrator-context. When disabled (value: 0), or not configured, all users will be able to initiate the installation of (signed) Windows app packages.

Note: This policy does not configure the ability of users to install Windows app packages via the Microsoft Store.

Configuration

When knowing the available policy setting and the possible values, it’s time to take a look at the steps for configuring that specific policy. The nine steps below walk through the configuration of a new custom configuration profile that includes the required OMA-URI and its value. The wizard style of configuring makes sure that the configuration profile will be assigned to the selected users and/or devices.

  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 page
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Basics page, provide the following information (the Platform and Profile type are greyed out and configured based on the provided information on the previous page) and click Next
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Configuration settings page, click Add to open the Add Row page. On the Add Row page, provide the following information and click Add (and click Next back on the Configuration settings page)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Policy/Config/ApplicationManagement/BlockNonAdminUserInstall
  • Data type: Select Integer
  • Value: 1
  1. On the Scope tags page, configure the applicable scopes and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. On the Applicability rules page, configure the applicability rules (think about the existence of this setting for only the Business, Enterprise and Education edition and the existence of this setting for only the 2004 version and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

Note: At some point in time this configuration will probably become available in the Microsoft Endpoint Manager admin center portal without the requirement of creating a custom device configuration profile with a custom OMA-URI.

End-user experience

Let’s end this post by having a look at the end-user experience. The basic end-user experience when using this policy setting, is the same for every user. When initiating the installation of a (signed) Windows app package by simply double-clicking the file, every user – non-administrator and administrator – will receive the same experience. For an administrator to still be able to install a (signed) Windows app package, the installation should be initiated in an administrator-context (for example: using PowerShell that was started by using Run as Administrator).

To show the end-user experience, I’ve used two different Windows app packages. Below on the left is an example of a trusted app in MSIX-format and below on the right is an example of an offline trusted Microsoft Store app in APPX-format. Both examples simply used to show the behavior of the policy setting. MSIX Hero is actually a really nice and simple tool for managing and troubleshooting MSIX packages and Word Mobile is just a simple APPX package.

Reminder: This policy does not configure the ability of users to install Windows app packages via the Microsoft Store.

More information

For more information about the policy setting to prevent non-administrator from initiating the installation of Windows app packages, refer to the ApplicationManagement policies in the Policy CSP documentation.

Pushing notifications to users on iOS and Android devices

This week is all about the different options in Microsoft Intune to send push notifications to users on iOS (and iPadOS) and Android devices. The trigger of this post is the option to send push notifications as an action for noncompliance, which was introduced with the 2005 service release of Microsoft Intune. Besides that, it was already possible to send custom notifications to a single device, to the devices of a group of users, or as a bulk action to multiple devices. In this post I want to go through the different options for sending push notifications, followed by showing the end-user experience.

Send custom notifications

Custom notifications can be used to push a notification to the users of managed iOS (including iPadOS) and Android devices. These notifications appear as push notifications from the Company Portal app (or Microsoft Intune app) on the device of the user, just as notifications from other apps. A custom notification message includes a title of 50 characters or fewer and a message body of 500 characters or fewer. Besides those message limitations, the following configurations should be in place for a device to be able to receive push notifications.

  • The device must be MDM enrolled.
  • The device must have the Company Portal app (or Microsoft Intune app).
  • The Company Portal app (or Microsoft Intune app) must be allowed to send push notifications.
  • An Android device depends on the Google Play Services.

Send custom notification to a single device

The method for sending a custom notification to a single device is by using device actions. To use device actions for sending a custom notification to a single device, simply follow the three steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > All devices {{select Android or iOS device} to open the Overview page of the specific device
  2. On the Overview page, select the Send Custom Notification device action (when the option is not available, select the  option first from the upper right side of the page) to open the Send Custom Notification pane
  3. On the Send Custom Notification page, specify the following message details and select Send to send the notification to the device
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to a single device can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices('{IntuneDeviceId}')/sendCustomNotificationToCompanyPortal

Send custom notification to a group of devices

There are actual two methods for sending a custom notification to a group of devices. The first method for sending a custom notification to a group of devices is by using the tenant administration. That can be achieved by using the four steps below. The twist is that those steps will enable the administrator to send a notification to a group, which will only target the users of that group. The notification will then only go to all the iOS (and iPadOS) and Android devices that are enrolled by that user.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Teant administration Custom notifications to open the Tenant admin | Custom notifications blade
  2. On the Basics page, specify the following message details and select Next
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the group that should be used to send this notification to and click Next
  2. On the Review + Create page, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to the devices of a group of users can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

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

The second method for sending a custom notification to a group of devices is by using bulk actions. That can be achieved by using the four steps below. Those steps will enable the administrator to send a notification to multiple selected iOS (and iPadOS) and Android devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devicesBulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, specify the following details and select Next
  • OS – Select the platform of the devices that should receive this notification (Android (device administrator), Android (Work Profile), or iOS/iPadOS)
  • Action – Send custom notification
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the devices to send this custom notification to and click Next
  2. On the Review + Create tab, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to multiple selected devices can be achieved by using the executeAction object in the Graph API.

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

Send noncompliance notification

Noncompliance notifications can be used to push a notification to a device about the noncompliance state of the device. These notifications appear as push notifications from the Company Portal app on the device of the user, just as notifications from any other app. The notification is pushed to the device, the first time after the device is noncompliant and checks in with Microsoft Intune (depending on the configured schedule of the push notification). The message of the notification contains the details about the noncompliance and can’t be customized. Also, the notification is only pushed a single time. To push multiple notifications, simply add multiple actions. The four steps below show how to add a noncompliance action that will send a push notification to a compliance policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Endpoint security Device compliancePolicies to open the Compliance policies | Policies blade
  2. On the Compliance policies | Policies page, either create a new policy, or edit an existing policy (this example is of editing an existing policy)
  3. On the Actions for noncompliance page, select Send push notification as an additional action
  1. On the Review + save page, click Save

For automation purposes, automating updating a device compliance policy can be achieved by patching the specific deviceCompliancePolicies object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies/{policyId}

End-user experience

Let’s end this post by having a look at the end-user experience. The push notifications will show on the lock screen just as notifications from any other app. Below on the left (Figure 5) is showing an example of the lock screen that contains a custom notification and a noncompliance notification. Below in the middle (Figure 6) is showing an example of a custom notification when the Company Portal app was open. The user will go to the same page in the Company Portal app, when clicking on the custom notification on the lock screen. Below on the right (Figure 7) is showing an example of the page in the Company Portal app, when clicking the noncompliance notification. That will enable the user to immediately take action.

Note: The experience on Android devices is similar. However, keep in mind that on Android devices, other apps might have access to the data in push notifications.

More information

For more information about the different options to send push notifications to users on iOS and Android devices, refer to the following docs:

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:

Accessing SharePoint and OneDrive content on unmanaged devices

This week is all about accessing SharePoint sites and OneDrive accounts on unmanaged devices. More specifically, limiting access to SharePoint and OneDrive content on unmanaged devices. Configuring (limited) access to SharePoint sites and OneDrive accounts starts by using conditional access. For applying conditional access to SharePoint sites and OneDrive accounts, the Office 365 SharePoint Online cloud app, or the recently introduced Office 365 (preview) cloud app can be used. The first cloud app is applicable to all services that depend on SharePoint Online (including OneDrive and Teams). The second cloud app is applicable to all productivity and collaboration services of Office 365. An all-in-one app. However, both of these cloud apps don’t provide really granularity to only apply specific behavior for accessing specific SharePoint sites, or OneDrive accounts. In this post I’ll focus on the Use app enforced restrictions session control and the options that it provides for differentiating between SharePoint sites and OneDrive accounts. About three years ago, I did a post on the basic configurations options of that sessions control.

The Use app enforced restrictions session control can be used to require Azure AD to pass device information to the SharePoint Online. That enables SharePoint Online to know whether the connection was initiated from a managed device. In this case a managed device is an Intune managed and compliant device, or a hybrid Azure AD joined device. SharePoint Online can use that information to provide a limited experience to unmanaged devices. Adjusting the experience can be achieved by using the Unmanaged devices access control in SharePoint Online. In this post I’ll have a look at the standard and advanced configuration options of that access control (including a brief look at the future). I’ll end by having a look at the end-user experience.

SharePoint unmanaged devices standard configuration

The Unmanaged devices access control in SharePoint Online can be used to provide full or limited access on unmanaged devices. It’s even possible to completely block access on unmanaged devices. Limiting the access on unmanaged devices allows the end-user to remain productive while minimizing the risk of accidental data loss. With limited access, users, on unmanaged devices, will have browser-only access with no ability to download, print, or sync files. It won’t be possible to access content through apps, including the Microsoft Office desktop apps. This does require the use of modern authentication. An additional reason to block legacy authentication.

The Unmanaged devices access control standard configuration is available via the SharePoint admin center. This access control can be configured for the complete organization by following the next two steps.

  1. Open the SharePoint admin center and navigate to Policies > Access control > Unmanaged devices
  2. On the Unmanaged devices blade, select the experience for the end-user on unmanaged device by choosing between full access, limited access and block access.

When configuring the Unmanaged devices access control with a limited or blocked experience, by following the mentioned steps, the Apps that don’t use modern authentication access control will automatically change to blocked. The main reason for that is that those apps can’t enforce a limited or blocked experience. Also, these configuration will automatically create corresponding conditional access policies.

SharePoint unmanaged devices advanced configuration

The advanced configuration options of the Unmanaged devices access control in SharePoint Online are only available via PowerShell. The standard configuration via the SharePoint admin center can only configure the access control organization-wide, while PowerShell enables the administrator to configure the access control on site-level. That includes OneDrive accounts. That enables the administrator to configure a limited or blocked experience for specific SharePoint sites and OneDrive accounts. That can be achieved by using the Set-SPOTenant cmdlet for organization-wide configurations, or by using Set-SPOSite cmdlet for site-level configurations. Those cmdlets contain the ConditionalAccessPolicy parameter that can be used to configure the Unmanaged devices access control. That parameter can be used with one of the following values:

  • AllowFullAccess – This value will make sure that the configuration of Allow full access from desktop apps, mobile apps, and the web is applied to the tenant or site. This is the default configuration and allows full access for unmanaged devices.
  • AllowLimitedAccess – This value will make sure that the configuration of Allow limited, web-only access is applied to the tenant or site. This is the limiting configuration that will only allow web access and doesn’t allow the user to print, download or synchronize for unmanaged devices.
  • BlockAccess – This value will make sure that the configuration of Block access is applied to the tenant or site. This will completely block access for unmanaged devices.
  • ProtectionLevel – This value is a preview feature that can be used for configuring authentication tags.

For configuring the Unmanaged devices access control for specific SharePoint sites or OneDrive accounts, the Set-SPOSite cmdlet can be used in combination with the ConditionalAccessPolicy parameter and the Identity parameter. The latter parameter is used for specifying the specific SharePoint site or OneDrive account. An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess

When using the ConditionalAccessPolicy parameter, it enables the administrator to apply even more restrictions. It enables the administrator to combine the limited access with also removing the ability to edit files and the ability to copy and paste from files. That can be achieved by using the AllowEditing parameter with the value $false (default is $true). An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess -AllowEditing $false

Besides limiting the editing abilities for the user, it’s also possible to further limit the preview functionality. That can be achieved by using the LimitedAccessFileType parameter. That parameter can be used with one of the following values:

  • OfficeOnlineFilesOnly – This value will make sure that users can only preview Office files in the browser. This limiting configuration increases security on unmanaged devices, but may decrease user productivity.
  • WebPreviewableFiles – This value value will make sure that users can preview Office files and other file types (such as PDF files and images) in the browser. This is the default configuration and is optimized for user productivity on unmanaged devices, but offers less security for files that aren’t Office files. 
  • OtherFiles – This value will make sure that users can download files that can’t be previewed (such as .zip and .exe) in the browser. This option offers less security on unmanaged devices.

The LimitedAccessFileType parameter enables the administrator to limit the preview functionality, by using one of the three mentioned values. An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess -AllowEditing $false -LimitedAccessFileType WebPreviewableFiles

Note: Keep in mind that the site-level configuration will only work as expected when it’s more restrictive than the organization-wide configuration.

Conditional access configuration

The conditional access configuration is required to make sure that Azure AD will pass the device information to the SharePoint Online. That can be achieved by using the Use app enforced restrictions session control. This configuration can be used next to other conditional access policy that use grant controls to make sure that for example MFA is also always required for access to SharePoint Online or OneDrive for Business on unmanaged devices. That in combination with the limited configuration can provide the organization with the required level of access control on unmanaged devices. For this post the focus is on the Use app enforced restrictions session control. That session control can be configured by following the next seven steps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Security > Conditional access Policies to open the Conditional Access | Policies blade
  2. On the Conditional Access | Policies blade, click New policy to open the New blade
  3. On the New blade and provide a unique name
  4. Select Users and groups to configure the assigned users of this conditional access policy
  5. Select Cloud apps or user actions and select Office 365 SharePoint Online as the assigned app of this conditional access policy
  6. Select Conditions > Client apps and select Browser as the applicable client app of this conditional access policy
  7. Select Session and select Use app enforced restrictions to make sure that the configured limited experience will be applicable to this session

What the future brings

Before having a look at the end-user experience, it might be good to briefly mention that the near future will bring some more possibilities. While writing this post new MFA and other granular policies for SharePoint sites and OneDrive are introduced by using a new user action in conditional access. The Accessing secured app data user action. That user action is already configurable in conditional access by using this url for configuring the conditional access policy. It enables the administrator to configure a few protection levels for data. Those protection levels can be added to SharePoint sites and OneDrive accounts and can be assigned with different conditional access policies. That eventually might provide the administrator with a more granular control over the access to the data in the different locations. Jan Bakker already wrote some more details about that functionality at his blog. More about that subject in the future.

End-user experience

The mentioned configurations enable the administrator to provide different limited experiences to different SharePoint sites and OneDrive accounts. Let’s bring these configurations together to provide a limited experience for accessing OneDrive on unmanaged devices and by blocking access to specific SharePoint sites on unmanaged devices. Below in Figure 3 is an example of the end-user experience when opening a Word document in OneDrive on an unmanaged device, when limited access is configured with web previewable files and no editing options. That will enable the user to only preview the document in the browser. Below in Figure 4 is an example of the end-user experience when opening a TXT-file in OneDrive on an unmanaged device and when the same limited configurations apply. That will block the user from accessing the file.

Below in Figure 5 is an example of the end-user experience when accessing a SharePoint site when that specific site is blocked on unmanaged devices. That will provide the user with the message that the access is denied for untrusted devices, due to organizational policies.

More information

For more information about conditional access, SharePoint Online and OneDrive for Business, refer to the following docs:

Android Enterprise and Microsoft Intune

This week is all about the device management jungle of Android Enterprise. I should have discussed this subject a long time ago, but better late than never. Especially when I’m still seeing many question marks when discussing Android Enterprise. With the release of Android 10.0 coming to the different existing Android devices now, the purpose of this post is to create an overview of the different enterprise deployment scenarios of Android Enterprise, including the Microsoft Intune specific additions, and the different related enrollment methods. Everything focussed on providing a good starting point for managing Android devices. The main trigger is the nearing end of Android device administrator with the release of Android 10.0. Earlier I provided the steps for simplifying the migration of Android device administrator to Android Enterprise work profile management with Microsoft Intune, but that was a specific scenario for migrating away of Android device administrator. That doesn’t answer the question if Android Enterprise work profile management is the best deployment solution for your organization.

With this post I hope to provide a better overview of the different deployment scenarios, the requirements and the enrollment methods. All to make a good start with Android Enterprise. Before I’ll dive into Android Enterprise, I’ll start with a little bit of history about Android device administrator. After going through the Android Enterprise deployment scenarios and enrollment methods, I’ll end with a short note about the (crazy) future. I won’t compare or discuss the different configuration options for the different deployment scenarios, as I think that a deployment scenario should be chosen based on the use case first and not directly based on the available configuration options.

A little bit of history

Let’s start with a little trip down memory lane. A long time ago, with Android 2.2, Google introduced the Device Administration API. That API provided device administration features at a device level and allowed organizations to create security-aware apps with elevated administrative permissions on the device. It would enable organizations to perform some basic actions on the device to manage basic components, like email configurations (including remote wipe) and password policies. However, it also introduced many big challenges. One of those challenges was the limited number of configuration options, without a third-party solution like Samsung Knox, and another one of those challenges was the inconsistent level of control across different manufacturers. The more Android device administrator was used, the bigger the scream became for something new.

And something new came. Starting with Android 5.0 and later, Google started with the introduction of Android Enterprise by introducing the managed device (device owner) and work profile (profile owner) modes to provide enhanced privacy, security, and management capabilities. These modes support the different Android Enterprise deployment scenarios (more about those scenarios later) and can be managed by using the Android Management API. That API can be used to configure different enhanced policy settings for the managed devices and the companion app (Android Device Policy) automatically enforces those policy settings on the device. Microsoft Intune has chosen to rely on the API for managing most of the deployment scenarios.

Now only turning off the old management method is left. Starting with Android 9.0, Google has started with decreasing device administrator support in new Android releases, by starting with deprecating specific settings. These settings are mainly related to the camera and password configurations, and these settings are completely removed starting with Android 10.0. That will prevent organizations from being able to adequately manage Android devices by using Android device administrator. A big trigger to move away from Android device administrator. The advise – when using only Microsoft Intune – is to move to Android Enterprise modes and deployment scenarios with the introduction of Android 10.0. Even better, don’t wait until the introduction of Android 10.0 (but that advise might be a bit late now).

Android Enterprise deployment scenarios

The biggest challenge of the Android Enterprise device management jungle is the number of deployment scenarios. When looking specifically at the combination with Microsoft Intune, there is even an additional deployment scenario on top of the standard Android Enterprise deployment scenarios. Below in Figure 1 is an overview of the currently available Android Enterprise deployment scenarios with Microsoft Intune (picture is taken from the slide deck of session BRK3082 at Microsoft Ignite 2019).

Now let’s have a closer look at these different deployment scenarios and the supportability of Microsoft Intune. I’ll do that by zooming in on the different deployment scenarios as shown in Figure 1.

Android APP managed – Android app protection policies (APP) managed app is the least intrusive method for allowing access to company data on personal devices and still making sure that the data remains safe. Also, this method is not Android Enterprise specific. In this scenario, the app is managed with protection policies that will make sure that the company data remains within the app and these protection policies are only applied once the user signs in with a work account. Also, the protection policies are only applied to the work account and the user is still able to use the same app with a personal account. If needed, the IT administrator can remove company data from within the managed app.

AE Work Profile – Android Enterprise work profile is supported with Android 5.0 and later in Microsoft Intune and is focused on providing access to company data on personal devices by using a profile owner mode. In this scenario, the user enrolls the device and after enrollment a separate work profile is created on the device. This separate profile creates the separation between company data and personal data and can be easily identified by the user. The apps that are part of the work profile are marked with a briefcase icon and the company data is protected and contained within the work profile. If needed, the IT administrator can remove the work profile from the device.

AE Dedicated – Android Enterprise dedicated devices – previously known as corporate-owned, single-use (COSU) devices – are supported with Android 6.0 and later in Microsoft Intune and is focused on providing single purpose company-owned devices by using a device owner mode. This is often used for kiosk-style devices (example: devices used for inventory management in a supermarket). In this scenario, these devices are enrolled and locked down to a limited set of apps and web links, all related to the single purpose of the device. These devices are not associated with any specific user and are also not intended for user specific applications (example: email app). If needed, the IT administrator can remove any (company) data of the device.

AE Fully managed – Android Enterprise fully managed devices – previously known as corporate-owned, business-only devices (COBO) devices – are supported with Android 6.0 and later in Microsoft Intune and is focussed on providing company-owned devices, used by a single user exclusively for work, by using a device owner mode. In this scenario, these devices are enrolled and fully managed by the IT organization. To give the user a personal touch, the IT administrator can allow the user to add a personal account for the installation of apps from the Google Play store. However, the device will remain fully managed and there will be no differentiation between company data and personal data. If needed, the IT administrator can remove all (company) data of the device.

AE Fully managed with work profile – Android Enterprise fully managed devices with work profile – previously known as corporate-owned, personally-enabled (COPE) devices – are not yet available with Microsoft Intune, but are eventually focussed on providing company-owned devices used for work and personal purposes, by using a combination of device owner mode and profile owner mode. In this scenario, the IT organization still manages the entire device, but can differentiate between the strength of the configuration depending on the type of profile (example: a stronger configuration set to the work profile and a lightweight configuration set to the personal profile). That should provide the user with a personal space on the device and that should provide the IT administrator with enough capabilities to protect the company data.

For the management of the company-owned devices, Microsoft Intune relies on the Android Management API and Android Device Policy. That enables Microsoft to be able to quickly introduce new features, when introduced in the API. However, that also creates a dependency on Google to introduce new features via the API. A negative example of that dependency is the time it took before the Android Enterprise fully managed devices with work profile deployment scenario became available via the API. At this moment the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune.

Android Enterprise enrollment methods

Once familiar with the Android Enterprise deployment scenarios, it’s good to get familiar with the Android Enterprise enrollment methods. That will enable the IT administrator to get an Android device in the correct mode (device owner, or profile owner) and the correct deployment scenario. The table below provides and overview of the available enrollment methods for the different deployment scenarios. It also provides some details about a few important properties of the deployment scenarios (based on the information about the deployment scenarios). Those properties are: is a reset required to get started with a deployment scenario and is a user affinity applicable with a deployment scenario.

As the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune, the information regarding that deployment scenario is an educated guess, based on the other deployment scenarios. That’s why the information is in grey, as it’s still work in progress. The only thing that I’m sure of is that it would require a new enrollment. There will be no migration path from an Android Enterprise fully managed device to an Android Enterprise fully managed device with work profile. That will require a new enrollment. Keep that in mind with determining an eventual deployment and management strategy.

Deployment scenarioEnrollment methodsReset requiredUser affinity
Android app protection policies managed appManaged appNoNot applicable
Android Enterprise work profile deviceCompany Portal appNoYes
Android Enterprise dedicated deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesNo
Android Enterprise fully managed deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes
Android Enterprise fully managed device with work profileNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes

Now let’s have a closer look at the different enrollment methods and the supportability within Microsoft Intune. I’ll do that by zooming in on the different enrollment methods as mentioned in the table above.

Managed app – Managed app enrollment is not specific to Android Enterprise and is supported with any platform version that is supported by the specific managed app. With this enrollment method, the user downloads and installs an app that is protected with app protection policies – when using a work account – and adds a work account to that app. After signing in it triggers the app protection policies for the work account. Also, keep in mind that the user would need to have the Company Portal app installed as a broker app.

Company Portal app – Company Portal app enrollment is supported with Android 5.0 and later in Microsoft Intune for Android Enterprise deployment scenarios. With this enrollment method, the user downloads and installs the Company Portal app and signs in with a work account. After signing in the user triggers the enrollment process in the Company Portal app.

Near Field Communication – Near Field Communication (NFC) enrollment is supported with Android 6.0 and later in Microsoft Intune and can make the enrollment of a device as simple as tapping the device on a specially formatted NFC tag. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can simply tap the device on the NFC tag. That tap will automatically start the enrollment process.

Token entry – Token entry enrollment is supported with Android 6.0 and later In Microsoft Intune and enables the enrollment of a device by specifying a specific (enrollment) token. With this enrollment method, once the device is reset, or just out-of-the-box, the administrator, or user, walks through the standard setup wizard and once arrived at the Google sign-in screen provides the afw#setup code to trigger the Android Device Policy. That will enable the token entry to actually start the enrollment process.

QR code scanning – QR code scanning enrollment is supported with Android 7.0 and later in Microsoft Intune and enables the enrollment of a device by simply scanning a QR code. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can multi-tap the screen to enable scanning of a QR code (on Android 7 and 8 that will first prompt for the installation of a QR code reader app). That QR code will automatically start the enrollment process.

Zero touch – Zero touch enrollment is supported with Android 8.0 and later In Microsoft Intune – only with participating manufacturers – and enables the enrollment of a device automatically. Similar to Apple Business Manager and Windows Autopilot. With this enrollment method, on first boot of the device, it will automatically check to see if an enterprise configuration is assigned. If so, the device initiates the provisioning method and downloads Android Device Policy. That download and installation will automatically start the enrollment process.

Note: Besides these standard Android Enterprise enrollment methods, there are also third-party additions (like Samsung Knox enrollment) that can benefit the enrollment process.

What the future brings

Let’s end with a look at the future and some advise. By now it should be obvious that platforms change. However, when looking at the first early signs of Android 11.0 – and specifically at what Android 11.0 brings to the Android Enterprise fully managed devices with work profile deployment scenario – organizations might wonder if change is always for the better. Just when the deployment scenarios of Android Enterprise get more and more traction, new changes are coming. Google recently announced that it will no longer support a work profile on fully managed devices with Android 11.0. Instead enhancements are made to the work profile, to provide a new enhanced work profile deployment scenario. And Android 11.0 will be a hard cut. Existing work profiles on fully managed devices will need to be migrated (to either a fully managed devices or to this new enhanced work profile) when upgrading to Android 11.0. The main driver for Google is the privacy of the user. Jayson Bayton wrote a great article around this subject. Also, when interested in anything around Android and Android Enterprise, I strongly advise to read more of his articles. It’s a great resource!

This change with Android 11.0 makes the future around the Android Enterprise fully managed devices with work profile deployment scenario, especially from a Microsoft Intune perspective, even more challenging. Even before that deployment scenario is available is available within Microsoft Intune. However, this shouldn’t be a reason for waiting even longer with the migration to Android Enterprise. Make sure to be familiar with the Android management requirements within your organization and built the solution and roadmap around those requirements. Often the lifecycle of the device is a good moment to look at a new method for managing the devices. Especially when looking at the supportability of new Android releases on existing devices. Don’t wait until the last moment and make a plan.

I would like to end by mentioning one last time that my advise is not to manage Android 10.0 with Android device administrator and only Microsoft Intune, as those devices will no longer be able to receive password requirements. To add-on to that, and to make my advise even stronger, make sure to be familiar with the upcoming restrictions to the Company Portal app on Android 10.0 devices managed via Android device administrator (see: Decreasing support for Android device administrator). Determine your own migration while you still can!

More information

For more information regarding Android device administrator and Android Enterprise, refer to the following articles:

Simplifying management of the Google Chrome browser

This week is all about simplifying the management of the Google Chrome browser. I’ve done my fair share of posts about different methods for managing settings for the Google Chrome browser, by using Microsoft Intune, like for example by using ADMX-files or by using PowerShell, but it can be easier. It can also be achieved by using Chrome Browser Cloud Management. Chrome Browser Cloud Management is a cloud-based solution that enables the management of the Google Chrome browser across Windows, Mac and Linux devices. In this post I’ll start with a short introduction about Chrome Browser Cloud Management, followed by the steps to enrol Windows devices by using Microsoft Intune. I’ll end this post by looking at the end-user experience.

Note: Keep in mind that this post is only intended to provide a simple management solution for the Google Chrome browser. Please make your own consideration if this would be added value for your organization.

Introduction to Chrome Browser Cloud Management

Let’s start with a short introduction to Chrome Browser Cloud Management. Chrome Browser Cloud Management provides the IT administrator with a unified managed experience across Windows, Mac and Linux devices via a single cloud-based console. That removes the need to use different management tools for different platforms when managing Google Chrome across the organisation. Besides that, it can even provide benefits when managing a single platform. Even in combination with Microsoft Intune. At this moment, Microsoft Intune can provide some challenges with managing Google Chrome, as it would require the use of either PowerShell scripting or ADMX-files. Both, at this moment, time intensive activities. In that case, using Chrome Browser Cloud Management would add an additional management tool, but would save time in configurations.

Chrome Browser Cloud Management provides a method to enroll Google Chrome browsers by providing an enrollment token to the browser. On Windows devices that can be achieved by applying a simple registry key. Once the Google Chrome browsers are enrolled, the Chrome Browser Cloud Management enables the management over user settings and apps and extensions. Both contain some often used configurations. Below are a couple of examples of often used configurations. Figure 1 shows how to easily configure the Homepage and Page to load on startup setting and Figure 2 shows how to easily add the Windows 10 Accounts extension.

Enroll cloud-managed Google Chrome browsers

Now let’s continue by looking at enrolling Google Chrome browsers. Basically that requires two actions. The first actions is to generate the enrollment token and the second action is to enroll Google Chrome browsers by using the enrollment token.

Action 1: Generate enrollment token

The first action is to generate and enrollment token. That token will be used for enrolling the Google Chrome browsers. The following four steps walk through the process of generating that token.

  1. Open the Google Admin console and navigate to Devices > Chrome management > Managed browsers to open the Managed browsers page
  2. On Managed browsers page, on the right bottom of the screen click on the + button to open the Chrome Browser Cloud Management License Agreement dialog box
  3. On the Chrome Browser Cloud Management License Agreement dialog box, click I ACCEPT to generate an enrollment token and to open the Enrollment token dialog box
  4. On the Enrollment token dialog box, click the copy sign to copy the enrollment token and click DONE.

Note: I’m not downloading the registry file, as I think that it’s easier to deploy the enrollment token by using a PowerShell script.

Action 2: Enroll Google Chrome browsers on Windows devices

The second action is to enroll Google Chrome browsers on Windows devices by using the generated enrollment token. For that purpose I’ve created a small PowerShell script that will be deployed via Microsoft Intune. That means two steps. The first step is to create the PowerShell script and second step is distribute the PowerShell script via Microsoft Intune.

Let’s start with the first step. The following PowerShell script provides a simple example that will create the registry path and key if needed. Simply add the copied enrollment token as the value of the $KeyValue variable.

The second step is to distribute the PowerShell script by using Microsoft Intune. That will make sure that the enrollment token applied to the Windows devices, which will trigger the Google Chrome browser to enroll. The next seven steps walk through the deployment of the PowerShell script.

  1. Open Microsoft Endpoint Manager admin center portal and navigate to Devices > Windows > PowerShell scripts to open the Windows | PowerShell scripts blade
  2. On the Windows | PowerShell scripts blade, click Add to open the Add PowerShell script wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the PowerShell script
  • Description: (Optional) Provide a description for the PowerShell script
  1. On the Script settings page, provide the following configuration and click Next
  • Script location: Select the PowerShell script
  • Run the script using the logged on credentials: Select No to run the script in SYSTEM context
  • Enforce script signature check: Select No
  • Run script in 64-bit PowerShell Host: Select Yes
  1. On the Scope tags page, configure any additional scope tags for this PowerShell script and click Next
  2. On the Assignments page, configure the assignment of this PowerShell script and click Next
  3. On the Review + add page, review the settings and click Add

End-user experience

Let’s end this post by having a look at the end-user experience. Below I’ve provided a few examples of the experience for the end-user. Figure 5 provides an overview of the applied registry key and its value and Figure 6 provides an overview of the Google Chrome browser and the applied policies. The latter shows the managed state of the Google Chrome browser and the applied Chrome policies. With those Chrome policies it provides the source of the policy, which is Platform for the cloud management enrollment token configured via Microsoft Intune and Cloud for all policies configured via Chrome Browser Cloud Management, and the policy name and value. The shown Chrome policies – and their results – are the examples provided in the introduction.

Note: An administrator can also look at the enrolled browsers in the Google Admin console by navigating to Devices > Chrome management > Managed browsers.

More information

For more information about cloud-management of the Google Chrome browser, refer to the documentation about Cloud-managed Chrome Browser.

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:

Enable device upload when already using co-management

This week is all about the recently introduced functionality of Microsoft Endpoint Manager tenant attach. More specifically, the device sync and the device action functionalities that become available via the Microsoft Endpoint Manager admin center for Configuration Manager managed devices. This is the first big step into creating an integrated solution for managing all devices. This brings Configuration Manager and Microsoft Intune together into a single console. In this post I’ll start with an introduction to the different cloud integration options, followed by the step for enabling the device upload. I’ll end this post by having a look at what this integration brings from an administrator perspective.

Introduction to cloud integration

Let’s start with a quick introduction to all the different cloud integration terminologies that are currently used in combination with Configuration Manager. The main reason for that is that I often hear a lot of confusion about the terminologies in regards to what it is and what it is used for and a new term – tenant attach – will not make that a lot easier.

  • Co-management – Co-management (sometimes even referred to as client attach) is about enrolling Configuration Manager managed devices into Microsoft Intune for additional cloud value. In other words, managing Windows 10 devices by using both Configuration Manager and Microsoft Intune. That enables the administrator to configure specific workloads for Configuration Manager or Microsoft Intune, to enable a smooth transition to the cloud. These products balance the workloads to make sure that there are no conflicts. For a complete overview of the benefits and these workloads, please refer to this doc about what co-management is.
  • Coexistence – Coexistence is about enrolling Configuration Manager managed devices into a third-party MDM solution. In other words, managing Windows 10 devices by using both Configuration Manager and a third-party MDM. That creates two management authorities on a device that don’t integrate with each other, which might create conflicts. To prevent these conflicts the Configuration Manager client detects when a third-party MDM service is also managing the device. When detected, it automatically deactivates certain workloads in Configuration Manager. For a complete list of these workloads, please refer to this doc about third-party MDM coexistence with Configuration Manager.
  • Tenant attach – Tenant attach (the new kid) is about attaching a Configuration Manager environment to the Microsoft Intune tenant for instant cloud value. That will bring all devices to single console and that console is Microsoft Endpoint Manager admin center. Bringing all the devices to that single console will enable the administrator (at first mainly focussed on the helpdesk) to perform basic actions on all devices, either managed by Configuration Manager or managed by Microsoft Intune.
  • Cloud hosted – Cloud hosted is about hosting Configuration Manager components in Microsoft Azure. That will bring the reliability and flexibility of Microsoft Azure to Configuration Manager for managing for example Internet clients by using a Cloud Management Gateway (CMG).
  • Cloud attach – Cloud attach is about attaching different cloud components to a Configuration Manager environment. That is a more generic term that is often used when attaching any cloud functionality to a Configuration Manager environment. That can be about co-management (client attach), tenant attach, and cloud hosted. Basically any cloud service that is attached to the on-premises environment for providing more and better functionalities for managing devices by using cloud functionality.
  • Hybrid MDM – Previously there was even hybrid MDM (or Microsoft Intune hybrid) that would integrate Microsoft Intune with Configuration Manager to provide cloud MDM-capabilities to Configuration Manager. That would enable customers to use Configuration Manager as a single pane of glass for managing all devices within the environment. That feature is retired as of September 1, 2019.

Note: For a nice overview see also this session about Supercharging PC and mobile device management: Attach Configuration Manager to Microsoft Intune and the Microsoft 365 cloud (starting at about 6:38) of Microsoft Ignite 2019.

Enable device upload

After processing the terminology for all the different cloud (and management) integration options for a Configuration Manager environment, it’s time to look at the new tenant attach functionality. When assuming that co-management is already being used within the environment, the following five steps will walk through also configuring the device upload functionality.

  1. Open the Microsoft Endpoint Configuration Manager administration console and navigate to Administration > Overview > Cloud Services Co-management
  2. Select the CoMgmtSettingsProd policy and click Properties in the Home tab to open the Properties dialog box
  3. In the Properties dialog box, navigate to the Configure upload tab, perform the following configuration and click OK
  • Select Upload to Microsoft Endpoint Manager admin center to enable this site to upload devices to Microsoft Endpoint Manager admin center
  • Select All my devices managed by Microsoft Endpoint Configuration Manager (recommended) to enable this site to upload all devices to Microsoft Endpoint Manager admin center, or select A collection I select to enable this site to only upload specific devices to Microsoft Endpoint Manager admin center
  1. In the authentication prompt, provide credentials of a global administrator
  2. In the Create AAD Application dialog box, click Yes to register an application in AAD

Administrator experience

The most interesting part of this post – in my opinion – is the administrator experience. New objects that are created and the relation between the different new objects and activities that an administrator can see. Below is an overview of a those objects and activities from a Configuration Manager perspective. Figure 2 and Figure 3 provide an overview of the new objects in the Configuration Manager administration console. The Cloud Attach Azure service and the application registration with the Azure Active Directory Tenants. Both of these objects are created when enabling device upload. The latter is a reference to the created app registration in Azure Active Directory.

Figure 4 and Figure 5 provide an overview of the objects that are being synchronized to Microsoft Endpoint Manager admin center. As I’ve selected that all device are synchronized, those figures show that my All Systems collections (9 members) relates to the number (6) found in CMGatewaySyncUploadWorker.log. That’s 9 objects minus the default objects of the unknown computer objects (2) and the provisioning device object.

Figure 6 provides an overview of the devices that are synchronized in the Microsoft Endpoint Manager admin center. In green it shows the ConfigMgr only devices (4) and in red it shows the co-managed devices (2). That brings the total the the 6 device objects that were synchronized.

Figure 7 and Figure 8 provide an overview of the device actions that become available for the synchronized devices. It shows the different locations of these actions for co-managed devices as well as for ConfigMgr only devices. At this moment the device actions of Sync machine policy, Sync user policy and App evaluation cycle are available.

Note: The user performing the actions via the Microsoft Endpoint Manager admin console need to have the appropriate permissions within Configuration Manager.

More information

For more information about enabling device upload in Configuration Manager, please refer to the documentation about Microsoft Endpoint Manager tenant attach: Device sync and device actions.

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:

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:

.