Manage Windows Package Manager settings with Microsoft Intune

2023-02-23: The below described issue will be fixed in Windows Package Manager version 1.5, see GitHub for more info.

2022-12-06: The below described settings to block Winget from using the Microsoft Store seem to cause an issue for certain users when the settings is applied during the enrollment. So currently this doesn’t seem a stable solution: DesktopAppInstaller | Microsoft Store App Failed installing (call4cloud.nl)

Last week I wrote a blog post regarding the new Microsoft store integration in Intune, which made me realize that we might not only want to push some settings regarding the Microsoft Store but also regarding Windows Package Manager/ WinGet.

IT Admins might have limited the Microsoft Store to only the private store (which completely blocks the store in Windows 11), to only allow installing store apps made available by the IT department. But that doesn’t mean end-users are not able to install applications from the store (at least not on Windows 11 22H2 which I’m running). You might interpret the below text from this Microsoft documentation to completely block installing apps from the store….

But it does not. Because in recent versions of Windows, we have WinGet available by default. And WinGet allows an end user to install applications from the sources which are available. By default the Microsoft Store is available (and the WinGet source). This allows the standard user to install applications, that don’t require admin permissions, from both sources, even if we blocked access to the (public) Microsoft store.

As you can see below, the Microsoft store is blocked on my Windows 11 device (by setting the Store\Only display the private store within the Microsoft Store to Enabled), but with WinGet I’m able to install the store version of Whatsapp.

We have some MDM policy CSPs available, which we can deploy with Microsoft Intune to our devices, to have some control over WinGet. The Desktop App Installer CSP are described on the Microsoft Docs. With a combination of these settings, we can control the sources available via WinGet. By removing the default sources, the user is not able anymore to use WinGet to install store applications.

I have also tried to disabled App Installer, but the result from this was also installing store apps via the Company Portal failed to install.

Unfortunately, these settings are not available in the Microsoft Intune portal, and we also can’t import the ADMX file in an Administrative Templates policy in Intune (well importing might work), but the location on the Windows device to which the settings are ingested, is blocked. So, the only thing left for Intune managed devices, is using a custom Intune profile.

The documentation describes the CSPs are supported on Windows 10 and 11, I only tested this on Windows 11 22H2.

If you’re not using Intune to manage your devices, you should have a look at this article which describes the good old GPOs.

Configure the custom Intune profile

If we have a look at the settings that we have available, we might consider using these three settings to prohibit end users installing applications using WinGet:
EnableMicrosoftStoreSource
EnableDefaultSource
EnableAdditionalSources

By default, the Microsoft store is available as source on WinGet, by using EnableMicrosoftStoreSource we can disable this.
By default, we also have the WinGet source available as default source, which we can disable this by setting the policy setting EnableDefaultSource.
And we have EnableAdditionalSources available, to block the user from adding additional sources.

Although we currently can only use a custom Intune profile and we need to use the OMA-URI, configuring these three settings is pretty straightforward. These settings can be enabled or disabled; no additional information needs to be added to the string in the profile.

Let’s sign into the Intune portal and I’ll show you an example.

• Browse to Devices, Windows, Configuration profile
• Click Create profile

• Select Windows 10 and later as Platform
• Select Templates as Profile type
• Select Custom and click Create

• Enter a Name for the profile
• Enter a Description (optional)
• Click Next

• Click Add to add a new OMA-URI row
• Fill in this information:

Name: Desktop App Installer – EnableMicrosoftStoreSource (enter what fits your needs)
OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DesktopAppInstaller/EnableMicrosoftStoreSource
Data Type: String
Value:

<disabled/>

Repeat this step, by adding new rows for every setting. These are the other OMA-URIs;
./Device/Vendor/MSFT/Policy/Config/DesktopAppInstaller/EnableAdditionalSources
./Device/Vendor/MSFT/Policy/Config/DesktopAppInstaller/EnableDefaultSource

Change the Name and set the settings to disabled.

Finish the creation of the profile by assigning the profile to a security group.

The end result

Let’s have a look at the end-user device.

If we would set EnableAdditionalSources to disabled, we can still access the Microsoft Store source. When we also set EnableMicrosoftStoreSource to disabled, the default sources are removed:
No sources defined.

But we can still install UWP apps from the new Microsoft Store.

And we can install WIN32 apps.

That’s it for this post. Thanks for reading!