Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Winget Reference within %AppData% does not get created after Winget Installation #4378

Open
RyanEruditional opened this issue Apr 14, 2024 · 1 comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.

Comments

@RyanEruditional
Copy link

Brief description of your issue

I am using Winget within Intune to deploy System and User Behaviour applications.

In previous versions of Winget, a reference is placed within: \AppData\Local\Microsoft\WindowsApps

\AppData\Local\Microsoft\WindowsApps\Winget.exe
\AppData\Local\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe

With the most recent version of Winget, these folders do not get created successfully after installation.

Below is the result of my Transcript log when deploying Winget (App Installer) through Intune. As you can see, this has installed successfully.

**********************
Transcript started, output file is C:\Eruditional-IT\Intune\Winget-AppInstaller\Winget-WindowsPackageManager_Install.log
Starting Transcript for Winget-WindowsPackageManager Installation
Attempting to download required files
Invoking Download
Downloading https://aka.ms/getwinget TO (->) C:\Eruditional-IT\Intune\Winget-AppInstaller\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Invoking Download
Downloading https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx TO (->) C:\Eruditional-IT\Intune\Winget-AppInstaller\Microsoft.VCLibs.x64.14.00.Desktop.appx
Invoking Download
Downloading http://www.nuget.org/api/v2/package/Microsoft.UI.Xaml/2.7.3 TO (->) C:\Eruditional-IT\Intune\Winget-AppInstaller\microsoft.ui.xaml.2.7.3.zip
Running Function: Install-WingetWindowsPackageManager
XmalPath is: C:\Eruditional-IT\Intune\Winget-AppInstaller\MicrosoftUIXaml\tools\AppX\x64\Release\Microsoft.UI.Xaml.2.7.appx
VClibs64DownloadPath is: C:\Eruditional-IT\Intune\Winget-AppInstaller\Microsoft.VCLibs.x64.14.00.Desktop.appx
WingetDownloadPath is: C:\Eruditional-IT\Intune\Winget-AppInstaller\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Attempting to Install Winget-WindowsPackageManager


Path          :
Online        : True
RestartNeeded : False

Running Function: Test-Winget
Winget Path is C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.22.10861.0_x64__8wekyb3d8bbwe\winget.exe
Winget Version is: v1.7.10861
Attempting to get Winget Version
Current Winget Version is: 1.7.10861
Current Winget Version is: 1.7.10861
Attempting to get Winget Path
Winget Path is C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.22.10861.0_x64__8wekyb3d8bbwe\winget.exe
Checking Condition
Winget Version has been obtained
Winget Version is 1.7.10861
Reinstall value is: 0
Winget (App Installer) has been successfully installed.

I am able to successfully resolve Winget's path when deploying applications as system. System applications are installed without problems.
SYSTEM PATH: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.22.10861.0_x64__8wekyb3d8bbwe\winget.exe

USER Behaviour applications deployed via Intune cannot access the above System Path. As mentioned previously, these applications rely on the below:

\AppData\Local\Microsoft\WindowsApps\Winget.exe
\AppData\Local\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe

Without this path, I am unable to install USER Behaviour applications.

If I amend permissions for C:\Program Files\WindowsApps\ and give myself access. I can run winget.exe within:
C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.22.10861.0_x64__8wekyb3d8bbwe\winget.exe

This then generates the necessary folders within AppData for the user.

However in context of Microsoft Autopilot/Intune, deploying a script via system to run winget.exe within Windows Apps will only create the appdata folders within the appdata of System itself and not for other users.

Users cannot access this location and I cannot risk giving users access to these folder location. It is naturally prohibited to access by default within Windows.

Has anyone come across this before? This wasn't a issue in previous versions of Winget. Anyone know of any valid work arounds?

Many thanks.

Steps to reproduce

Install Winget via:

Add-AppxProvisionedPackage -Online -PackagePath $WingetDownloadPath -DependencyPackagePath $VClibs64DownloadPath,$XmalPath -SkipLicense

Expected behavior

Winget to install itself within AppData

Actual behavior

Winget only installs itself within:
C:\Program Files\WindowsApps\

It does not appear within AppData

Environment

Windows 11 23H2 Build 22631.286
Winget Version: v1.7.10861
Intune Deployment.
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage Issue need to be triaged label Apr 14, 2024
@RyanEruditional
Copy link
Author

I have found a work around.

Deploy Winget via System behaviour with dependencies:
Add-AppxProvisionedPackage -Online -PackagePath $WingetDownloadPath -DependencyPackagePath $VClibs64DownloadPath,$XmalPath -SkipLicense

Then deploy Winget via User behaviour with dependencies:
Add-AppxPackage -Path $WingetDownloadPath -DependencyPath $VClibs64DownloadPath,$XmalPath

(Install script is a bit more complicated then the above but it sums up the overall point)

System Intune installation of Winget cannot access the User folders therefore winget.exe in AppData does not get created.
User Intune installation of Winget cannot access WindowsApps therefore Winget.exe does not get created here.

Deploy Winget both via System and User ensures that both files are created.

@denelon denelon added Issue-Bug It either shouldn't be doing this or needs an investigation. and removed Needs-Triage Issue need to be triaged labels Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests

2 participants