This week a quick extra blog post, just before the start of my vacation, about an easy method for construction settings of ingested ADMX-files. A few years ago I did a post about a deep dive for ingesting third-party ADMX-files and until today I still receive questions on that post that are related to constructing settings of ingested ADMX-files. Even though the described method is still available, there is an easier method for constructing the settings of ingested ADMX-files. A method that is less sensitive to errors. The following four steps walk through that easy method by again using chrome.admx as an example.
The first step is ingesting the ADMX-file. That can be achieved by following the same steps as provided in my earlier post. After creating the required configuration that contains the content of the ADMX-file, assign the profile to a group with a test device and let Microsoft Intune do its magic.
While Microsoft Intune is performing its magic on the test device, it’s time to start with the second step. The second step is looking up the setting and the available values in the ADMX-file. Just like my earlier post – to keep it simple – I’m looking at the SitePerProcess setting (see Figure 1). Now instead of going through the ADMX-file to construct a difficult OMA-URI, it’s time to have a look at the test device once Microsoft Intune performed its magic.
After Microsoft Intune performed its magic, it’s time to start with the third step. The third step is looking up the setting of the ingested ADMX-file in the registry of the test device. Simply navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\ADMXDefault and locate the just ingested ADMX-file. To make life a little bit easier, knowing to parent category can help. Otherwise, just find and locate the SitePerProcess setting. Once the setting is located, the required part of the OMA-URI is available without doing any really difficult steps (see Figure 2).
The fourth and last step is putting the information together. The OMA-URI of a device-based ingested ADMX-file always starts with ./Device/Vendor/MSFT/Policy/Config. That combined with the information found in the registry of the test device makes ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess.
I know I should have posted these steps earlier, but I still hope that it will still help administrators around the globe with constructing their OMA-URIs for settings of ingested ADMX-files. For as long as it’s still required.
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.
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/.
This 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.
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.
On the Scope tags page, configure the applicable scopes and click Next
On the Assignments page, configure the assignment and click Next
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
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.
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.
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.
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.
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/.
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.
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.
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.
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.
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.
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.
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.
Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Devices configuration – Profiles blade;
On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
On 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.
On 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.
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.
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.
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.
For more information about the available storage sense settings in the Policy CSP, please refer to the documentation about Policy CSP – Storage.
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.
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.
Monthly Channel (Targeted)
Semi-Annual Channel (Targeted)
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.
Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
On the Device configuration – Profiles blade, select Create profile to open the Create profile blade;
On 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;
On the <Name> blade, select Settings to open the <Name> – Settings blade;
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.
On 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.
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.
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.