[Bug]: ADMX files installed in wrong registry location (Intune)

[sladersheppard]

The problem

This issue only occurs when the ADMX files are deployed through Intune's Device Configuration Profiles.

Winget-AutoUpdate Default Regkey Location (MSI Install from Intune as a MSI Line Of Business app, works without any issues):
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Romanitho\Winget-AutoUpdate

Where Intune is installing the Regkeys (Pushed down from the mentioned ADMX files):
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Romanitho\Winget-AutoUpdate

I had to modify a file to get the paths to work correctly, attached is the modified WAU.ADMX file.
WAUADMX-Modified.zip

What version of WAU has the issue?

2.0.0

What version of Windows are you using (ex. Windows 11 22H2)?

OS Version: 10.0.22631 N/A Build 22631

What version of winget are you using?

Windows Package Manager v1.8.1911

Log information

No real relevant logs here, the Registry Keys are being installed into the incorrect directory, and I had to modify the paths within the original WAU.admx file to get this to work through Intune (as it kept placing the Registry keys into the 32 bit registry location, instead of within the default registry path).

Additional information

No response

[sladersheppard]

This is what the configuration looks like AFTER I modified the WAU.admx file (Directly pushed from Intune Device Configuration Policies), everything is populating into the correct locations and can be deployed correctly.

[sladersheppard]

Even though the Registry Keys are now in the correct location, the "Default_Excluded_Apps.txt" is still set to the default values (As well as every other configuration > Default).
How can I force this black list of apps / other registry configurations to be the default upon deployment?

[sladersheppard]

After a reboot the configuration is now applied correctly and the app is functioning as expected.
Leaving this ticket open as there may be an opportunity to add another ADMX bundle specifically for Intune deployments, rather than having to manually modify the original ADMX file.
Also trying to install with PowerShell works about 50% of the time through Intune using the method mentioned in the readme of this project.

[AusomeOllie10]

Okay; I have just checked this on my machines and confirm a similar pattern.

Just testing the updated one above.

[Romanitho]

Hi, the configuration should not be overwritten by the Intune policy. It is supposed to be located in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Romanitho\Winget-AutoUpdate. That being said, I just observed the same issue at a client's site.

[AusomeOllie10]

Is this an issue with the ADMX? Or an issue with the policy application from WAU's side?

I've found it does the exact same issue; though the above like you said is writing directly to the path not to the policies section.

[Romanitho]

Ok, after a restart, Policies are present in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Romanitho\Winget-AutoUpdate AND HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Romanitho\Winget-AutoUpdate. So no issue on my side, just had to wait a bit.

[sladersheppard]

For myself the policies would not pull into WinGet-AutoUpdate from the following locations:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Romanitho\Winget-AutoUpdate
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Romanitho\Winget-AutoUpdate

It only seemed to work when the policies were placed in the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Romanitho\Winget-AutoUpdate > Shown in above screenshot

Upon first install (before I changed the configuration) it installed into the WOW6432Node, and was not being used by Winget-AutoUpdate. (I confirmed this by running it and checking the Updates.Log file > Can see apps like Teams being updated even though it is in the Blacklist)

Once I changed the configuration to WAUADMX-Modified.zip it was installed directly in the following directory and works without any issues:
HKEY_LOCAL_MACHINE\SOFTWARE\Romanitho\Winget-AutoUpdate
Logs after config change:
updates.log

Let me know if there is anything I missed or any additional details you would like.

[KnifMelti]

The correct path in the file should be Software\Policies\Romanitho\Winget-AutoUpdate for every key just as it is in the repo, not like @sladersheppard modified version.
The key is used by GPO Editor to write and delete the entries, and they should live under Policies.
When managed trough GPO Editor it creates the keys under both HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Romanitho\Winget-AutoUpdate and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Romanitho\Winget-AutoUpdate
That's the way Microsoft Policies work.
How Intune nowadays handle it I don't know.

[Romanitho]

Intune appears to work in exactly the same way. Both keys...

[AusomeOllie10]

Intunes broken for me at the moment; everything stuck on pending or 404 errors 🤣

So I wouldn't completely trust it's behaving at the moment.

[sladersheppard]

I switched back to the original ADMX file, but now the Black List as well as any of the configurations are not being applied to WinGet-AutoUpdate (see screenshots).
Also there is registry keys in the WOW6432Node, and I confirmed that Intune is reporting success (I even recreated the policy to confirm).

Here are some attached logs as proof that my Blacklist is not being applied:
updates (2).log > Please start at 10/24/2024, this is when the policy was refreshed and the program was manually run. It seems to be just applying the default excluded apps file located in the config directory.

Here is my Intune Configuration:

Can you please take a look?

[AusomeOllie10]

2 things.

1. Activate GPO I believe has to be sat
2. The get black list from external path needs to be set to GPO too?

Secondly how are you assigning this? Device or user?

Mines currently set to device but not applying at all. Just sat on "pending"

[sladersheppard]

@AusomeOllie10 I have just enabled "Activate WAU GPO Management", I was unaware that this was needed when deployed through Intune, once it syncs I will update here.
I also set "Get Black/White List from external Path (URL/UNC/GPO/Local)" to: GPO

Here's how I am applying this (By Device, Group contains about 10 devices for testing.)

[sladersheppard]

updates.log
Seems to be resolved based on one device's logs :)

[AusomeOllie10]

Awesome; mines failing on the GPO deployment just saying pending.

You using the import ADMX feature or writing using a custom URI?

Might roll back one version of the ADMX; as somethings not happy

[sladersheppard]

@AusomeOllie10 This is my configuration, just directly imported the ADMX file from the 2.0.0 release into the Device > Configuration > Import ADMX section in Intune

When creating a new Device Configuration Template select: Windows 10 or above > Administrative templates (imported) > Winget-Autoupdate > Select configurations.

[AusomeOllie10]

Yep; that's how I did mine. See it's the same version too.

Assuming you're deploying through in tune configuration.

Mine just say all pending 🤣 & it's been half a day lol.

Im going to strip all the ADMX off and start again; intune has not been very intune recently lol

[sladersheppard]

I fully deleted the polices and old ADMX files, then recreated them, then rescoped them to the devices. That's odd that it's been on pending for half a day.

Have you attempted to work or school sync the laptops to confirm they are checking in? Also check the registry locations in my above screenshots, if nothing is there you just confirmed it's not working.
Great article, I use the Sync all devices script using MS Graph:
https://cloudinfra.net/how-to-force-intune-sync-using-powershell/

[AusomeOllie10]

I fully deleted the polices and old ADMX files, then recreated them, then rescoped them to the devices. That's odd that it's been on pending for half a day.

Have you attempted to work or school sync the laptops to confirm they are checking in? Also check the registry locations in my above screenshots, if nothing is there you just confirmed it's not working.

Great article, I use the Sync all devices script using MS Graph:

https://cloudinfra.net/how-to-force-intune-sync-using-powershell/

Yep; done all that.

Started stripping it all off again and ADMX is stuck deleting on intune so might have found the problem lol.

We shall seek

[sladersheppard]

I had an issue a few days ago where I couldn't remove the ADMX file, kept failing for an unknown reason.
I tried the exact same thing the next day and it worked without any issues (Granted I left the Configuration Polices deleted until I got the old file deleted, might have taken time to propagate the changes).
I think Intune is freaking out with the ADMX file since it is still in "Preview", might not be fully stable :/

[AusomeOllie10]

Seems like the second attempt had fixed it; policies applying correctly now and no longer stuck on pending 😀

Suspect it was just intune being a pain as usual.

I had an issue a few days ago where I couldn't remove the ADMX file, kept failing for an unknown reason.

I tried the exact same thing the next day and it worked without any issues (Granted I left the Configuration Polices deleted until I got the old file deleted, might have taken time to propagate the changes).

I think Intune is freaking out with the ADMX file since it is still in "Preview", might not be fully stable :/

[Maarten5150]

Hi everyone,
We have a slightly different but also related issue regarding using the ADMX template.

The issue is that we need to prevent one application (Adobe Air 32.0.0.89) from updating as that exact version is needed for a legacy application to function correctly. If I add the exclusion manually to the txt file it gets overwritten daily to the standard list and the app gets updated.

We deployed everything via Intune and imported the ADMX template. Our black/whitelist is set to GPO only.
The registry path is HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Romanitho\Winget-AutoUpdate

With this setup it all seems to work for normal notebooks however I'm deploying a Azure VDI environment.
For personal VDI's (Win11) it seems to be ok as well, but for multi-session VDI's (Win11) the same setup seems to ignore the blacklist from Intune. Even that it's a Client OS, in some situations (not all) multi-session VDI's act like a server for connecting.

Any idea how to make the ADMX work?

Thanks in advance and happy to provide more info if needed.

[AndrewDemski-ad-gmail-com]

Hej Maarten Have you considered embedding the exclusion list during image build process before it lands in share image gallery? Perhaps symlinking the content of that file would be even easier? Just food for thoughts. BR AD

[Maarten5150]

Thanks for the suggestion @AndrewDemski-ad-gmail-com unfortunately that would mean that the preconfigured text file is pushed out with the change to every machine and needs to be repackage when there is an update.

We love the idea of the centralized ADMX and it works for normal clients.

[AndrewDemski-ad-gmail-com]

@Maarten5150, close, but no cigar.
Did you know that you can symlink file to network share?
Absolute Symbolic Link

the only disadvantage will be the non-zero count of active users of that file, but you can terminate those handles via MMC on the server.

TBH you can even map entire folders from a netshare.
And the content in that location could be replaced via official process.
Think of it as of poor man's MSIX AppAtach without any system integration during each update cycle (you can always register binaries once, during initial registration/setup and expect that integrations will work with updated files without problems).

Yes I unofficially sugested to put entire WAU on a netshare and keep it updated that way.

Enjoy the weekend
A