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.

Configure storage sense via Windows 10 MDM

This blog post uses the Storage node of the Policy CSP, to configure Storage Sense on Windows 10 devices. Most of the policies in that area are added in Windows 10, version 1903, which is currently still in preview.

This week a short blog post about a few newly introduced policy settings in Windows 10, version 1903, which is currently still in preview. Those settings are related to Storage Sense and those settings are made available via a newly introduced ADMX-file. That ADMX-file is StorageSense.admx. Storage Sense can automatically clean some of the user’s files to free up disk space. In this post I’ll briefly go through the available settings, followed by the configuration and the end-user experience.

Settings

Let’s start by having a look at the available settings. The Storage area is not a new node within the Policy CSP, but starting with Windows 10, version 1903, it does contain multiple new policy settings. These policy settings are ADMX-backed policy settings, which are part of the new StorageSense.admx. Below is an overview of the available policy settings. Keep in mind that the complete node of these policy settings, starts with ./Device/Vendor/MSFT/Policy/Config/Storage/.

Policy Description

AllowStorageSenseGlobal

Values: 0 (Disabled) or 1 (Enabled)

This setting can be used to enable or disable Storage Sense and to make sure that the user cannot override that.

AllowStorageSenseTemporaryFilesCleanup

Values: 0 (Disabled) or 1 (Enabled)

This setting can be used to configure that when Storage Sense runs, it can delete the temporary files that are not in use.

ConfigStorageSenseCloudContentDehydrationThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can dehydrate cloud-backed content that hasn’t been opened in a certain amount of days.

ConfigStorageSenseDownloadsCleanupThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can delete files in the Downloads folder if they have been there for over a certain amount of days.

ConfigStorageSenseGlobalCadence

Values: 1 (Daily), 7 (Weekly), 30 (Monthly) or 0 (During low free disk space)

This setting can be used to configure Storage Sense to automatically clean some of the files to free up disk space.

ConfigStorageSenseRecycleBinCleanupThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can delete files in the Recycle Bin if they have been there for over a certain amount of days.

Note: Even though these policy settings are ADMX-backed policy settings, I noticed that it wasn’t required to use specific configuration values. I could use simple integer values.

Configuration

Now let’s continue by having a look at the configuration options for Storage Sense. In other words, create a device configuration profile with the previously mentioned custom policy settings. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a user or device group.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Devices configuration – Profiles blade;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

MSIntune-DC-SS-01On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSIntune-DC-SS-02On the Custom OMA-URI Settings blade, provide the following information and 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 description;
  • OMA-URI: Specify a the required policy setting;
  • Data type: Select Integer;
  • Value: Specify the required value.

Note: Simply repeat this step for every policy setting that should be configured.

MSIntune-DC-SS-03

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

End-user experience

Let’s end this post by looking at the end-user experience. Below is an example of a Windows 10 device running the latest available Windows Insider Preview build. In that example it’s clearly shown that Storage Sense is enabled and managed by the organization.

StorageSenseEnabled01

More details about the Storage Sense configuration can be found when clicking on Configure Storage Sens or run it now. These configuration options are shown below, including the configuration that I’ve applied, which can’t be adjusted.

StorageSenseEnabled02

More information

For more information about the available storage sense settings in the Policy CSP, please refer to the documentation about Policy CSP – Storage.

Easily controlling the Office update channel by using administrative templates

Let’s start this new year about a specific use case for the recently introduced feature to configure administrative template settings via Microsoft Intune. That specific use case is to easily control and configure the Office update channel by using the Administrative Templates profile type within Microsoft Intune. Before, this configuration would require ingesting a custom ADMX and creating custom OMA-URI settings, for configuring the Office channel, based on the information in the ingested custom ADMX. That’s not necessary anymore, as Microsoft Intune now provides a built-in list of available administrative template policy settings. In this post I’ll show the configuration steps, followed by the configuration results on a Windows 10 device.

Configuration

Before looking at the actual configuration steps, it might be good to first refresh memories by looking at the naming of the update channels in the different locations. The following table shows the naming of the different channels in Microsoft Intune (and the Office apps) and in the actual ADMX. Good news! This is actually the last time that it’s really required to look at this information. As this post will show, it wasn’t even necessary for the configuration in this post. It will be useful for verifying the results. Microsoft Intune will now provide an easy method for configuring many ADMX-backed settings, without going through the actual ADMX anymore.

Azure portal ADMX setting
Monthly Channel FirstReleaseCurrent
Monthly Channel (Targeted) Current
Semi-Annual Channel Deferred
Semi-Annual Channel (Targeted) FirstReleaseDeferred
Insider Fast InsiderFast

When this would be a configuration of an ADMX-backed settings, the information in the table above would be really relevant during the configuration. Since recently Microsoft Intune contains a new profile type, named Administrative Templates. These profiles take care of the heavy work. In case of Office settings, which will be used in this post, these profiles even take care of ingesting the correct ADMX-files. The following six steps walk through the creation of an Administrative Templates profile type that will be used to configure the Office update channel. After the creation of the policies it can be assigned to a user and/or device group.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, select Create profile to open the Create profile blade;
3

OfficeUpdates-CreateProfileOn the Create profile blade, provide the following information and click Create to open the <Name> blade;

  • Name: Provide a unique name for the device configuration profile;
  • Description: (Optional) Provide a description for the device configuration profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Administrative Templates (Preview);
4 On the <Name> blade, select Settings to open the <Name> – Settings blade;
5 On the <Name> – Settings blade, type Updates in the Search to filter items… field to filter the available settings to only update related settings and select Update Channel (as shown below) to open the Update Channel blade.
OfficeUpdates-Settings
6

OfficeUpdates-UpdateChannelOn the Update Channel blade, select Enabled to enable the setting, select the required update channel with Channel Name and click OK.

Note: Keep in mind that enabling a setting and clicking OK will directly save the change to the created device configuration profile. This is a similar experience to how changes are managed when working with normal group policies.

Note: In my device configuration profile I’ve also configured Enable Automatic Updates and Hide option to enable or disable updates to make sure that Office automatically checks for updates without an option for the user to disable Office updates.

Result

Now it’s really interesting to look at the result of the created configuration. For that, let’s first have a look at the registry. Below on the left is an overview of the registry key of the policy manager that contains the created Office configuration. It clearly shows the settings that should be configured, including the update branch. The update branch contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is an overview of the registry key of the policy manager that contains the ingested Office ADMX.

OfficeUpdates-Registry01 OfficeUpdates-Registry02

Another interesting location is the standard location in the registry that contains policy settings. Below on the left is an overview of the configured update branch. The update branch also contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is the actual configuration of an Office app shown. That clearly shows the Monthly Channel configuration.

OfficeUpdates-Registry03 OfficeUpdates-Outlook01