winget-cli: Winget Defaultstate folders under user profiles does not have admin or system permission. cannot be deleted with user profile deletion
Brief description of your issue
user profiles aren’t being deleted properly from sysdm.cpl or when trying to manually delete the user profiles within the C:\Users directory when the machine has Winget installed and enrolled via Intune to install software. The following folder path remains following profile deletion due to permissions which prevents the top level user profile folder from being removed:
C:\Users%username%\appdata\local\microsoft\winget\state\defaultstate the permissions on the winget defaultstate folder are meant to be set without the local administrators group or system access rights ssue happens only when winget is installed and used to install apps via intune (when the machine is enrolled into intune and has some software to be installed via new store in intune ) then we have these folders which has admin and system permission on top of it
but if we go one level deeper in the folders we can see that only the current user has permission (no system or admin permission ) so that those folders remain when user tried to delete profile and causing new folder for profile when the user logs in again ending up filling the c:\users folders with a lot of repeated names and numbers because the winget folder cannot be deleted by admin as he do not have permission on it
Parent folder has a system and administrator full control but it is not reflected to the inside folder.
Steps to reproduce
-
Enroll a Windows 10 21H2 device into Intune.
-
Assign an application from the New Store to a test user, this will force WinGet to install to allow the app you’ve assigned to be downloaded and installed once you’ve logged in with the test user.
-
Logon with the test user that has the app assigned to them and ensure the app has been downloaded and installed.
-
these folders and files will be created C:\Users%username%\AppData\Local\Microsoft\WinGet\Settings\defaultState\sources_metadata C:\Users%username%AppData\Local\Microsoft\WinGet\State\defaultState\StoreEdgeFD\installed.db if we check the permissions on Default state folders , we will find only the current user has permission , no system or administrator permissions files are attached below
-
Logon with another account and attempt to delete the profile of the test account from system properties. The test account profile folder (C\Users\testuser) should remain with the WinGet folder within.
Expected behavior
these folders named Defaultstate under winget folder should have a system and administrator permission so it can be deleted if we need to delete the profiles and clean up the C:\users folder
Actual behavior
the profile gets deleted from the system however the the user profile folder under c:\users still exist and cannot be deleted because wingt defaultstate folders still resides on it and cannot be deleted because of admin and system permissions missing , to delete them we need to set the permission manually to take ownership then delete profile
Environment
windows 10 21H2
Version of App Installer is 1.19.10173.0
Installed version of Winget v1.4.10173
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 66 (14 by maintainers)
Can confirm I’m on 1.5.1572 and the ACLs were still incorrect. Simple to remediate with a script.
https://gist.github.com/7ep3s/94c8f0e98769e0af5dca75ac53262158
Hello @yao-msft , I could confirm the issue is resolved, the last operations on my last comment was related to UAC and it is working when you click on Continue and it is not related to the permission issue we had thanks for your co-opration
@yao-msft can we have someone from Intune team to help in the validation of Intune fix status - and if that will help in the pre-existing users
This is not fixed by just updating to latest winget v1.6 package. Intune takes a copy of winget code and distribute with Intune client update. It’s only fixed after Intune releases a new client update. @IntuneAdmin mentioned the Intune support team says it’s released with Intune 2311 last week. Please let us know if the issue still exists after updating to Intune 2311 client.
@RDMacLachlan do you by chance have any idea when this might roll out?
Intune team has taken the winget 1.6 library update. It should be in next Intune client update.
We will release a new winget library after our winget 1.6 stable release is out (probably in 1-2 weeks). After that I’ll ask intune to take in the new library (not sure how long that’ll take to end customer delivery). But I’ll report back when I have rough dates. Thanks.
Yes, this was user error, manually running the script did not go well. Everything works fine via your detect and remediation script.
What we are still encountering is that TEMP profiles have sometimes been created. I also detect and remove this with a detect and remediation script (I can share this tomorrow)
The only problem I still have because of these issues is that the Intune policy that throws away the user profiles does this after 30 days from the “Win32_UserProfile” but the old user profile folder remains. (before the ACL rights are set correctly So)
I can delete this by running a detect and remediation script which deletes the C:\user folder older than 30 days, but here there is a good chance that I will also delete folders where the Win32_UserProfile still exists if the remediation script is earlier than the shared profile delete. from Intune. Unfortunately I don’t have a good solution for this yet.
any good idea for this?
Should this script work if you haven’t explicitly installed WINGET but are using it with an Intune deploy from the Windows Store (new)? App deployment.
We ran your script but it doesn’t work for us in this situation.
intune remediation package scripts for those who are still looking for a way to address this in their env while the bug is fixed https://github.com/7ep3s/IntuneRemediationScripts/tree/main/WingetACLRemediation
This is fixed from winget side, the fix is scheduled to be released with winget v1.6. But Intune uses a copy of winget binaries, intune teams needs to update their copy and push out a new client release to truly fix the issue. The issue is closed automatically by github when linked pr is merged, I’ll reopen the issue for tracking purpose.
Thanks for confirming this is still a bug.