Post-install winget not working

Hammer of the Gods

Hammer of the Gods

New Member
Having trouble getting some PowerShell scripts used for installing programs to execute during post-install. If I run them on the desktop manually after setup they work fine, but they appear to not work properly when I put the .ps1 files in post install.


Set execution policy for LocalMachine to unrestricted via a registry edit:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"Path"="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
"ExecutionPolicy"="Unrestricted"


Post-install order:

WinGet_Chocolatey.ps1
Install_Programs.ps1
DirectX.ps1


WinGet_Chocolatey.ps1
Script to install WinGet and Chocolatey:

#Install WinGet
Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
#Install Chocolatey
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))


Install_Programs.ps1
Script to install starting programs:

#Install VCRedist 2013 + 2015-2022
winget install --id=Microsoft.VCRedist.2013.x86 -e --accept-package-agreements --accept-source-agreements ; winget install --id=Microsoft.VCRedist.2013.x64 -e ; winget install --id=Microsoft.VCRedist.2015+.x86 -e ; winget install --id=Microsoft.VCRedist.2015+.x64 -e
#Install Shell
winget install nilesoft.shell
#Install Google Chrome
winget install --id Google.Chrome -e
#Install PowerToys
winget install Microsoft.PowerToys --source winget
#Install Notepad++
winget install --id Notepad++.Notepad++ -e
#Install 7-Zip
winget install --id 7zip.7zip -e
#Install VLC
winget install --id=VideoLAN.VLC -e
#Install EarTrumpet
winget install --id=File-New-Project.EarTrumpet -e


DirectX.ps1
Script to install DirectX (separated to troubleshoot the elevated rights separately):

#Elevate Script
if (-Not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) {
if ([int](Get-CimInstance -Class Win32_OperatingSystem | Select-Object -ExpandProperty BuildNumber) -ge 6000) {
$CommandLine = "-File `"" + $MyInvocation.MyCommand.Path + "`" " + $MyInvocation.UnboundArguments
Start-Process -FilePath PowerShell.exe -Verb Runas -ArgumentList $CommandLine
Exit
}
}
#Instal DirectX
winget install --id=Microsoft.DirectX -e
 
garlin said:
Nope. Can't run winget this way, it's UWP and requires an user context.

You missed these helpful threads:

When you run "powershell -NoProfile -ExecutionPolicy Bypass", Windows doesn't need the ExecutionPolicy reg key for the command.
NTLite will silently run every Post-Setup *.ps1 script with those arguments.
Click to expand...
garlin Thank you.

Is there any chance you would mind simplifying, compresssing, and dumbing it down for me? After your response I read both of those threads in their entirety plus some of your PowerShell GUI for MS apps. Before two days ago I had never created a windows image, rarely used powershell, and never created a powershell script. I'm sure it's relatively simple, but to be honest not only am I learning a lot of this for the first time, but my brain is fried from cram learning it all. I'm so close to being satisfied with my build, but getting this working is the last thing I need, and will make me comfortable enough to remove the Microsoft Store entirely.

My current goal is simply to get winget and Chocolatey to install during post-install.
 
winget is great for the interactive user. But it's a nightmare for Post-Setup scripting because MS made the decision to deliver an UWP app, presumably to work beside App Installer. App Installer is the feature where you click on any MSIX or APPX package in Explorer, and it will auto-install everything (including missing pre-requisite packages).

UWP apps must be provisioned against a logon user. Local SYSTEM or any service account cannot execute winget, even though there's plainly a winget.exe in the WindowsApps folder. Any normal user can call winget, but they need to run it with admin rights. Unless you disable UAC (which is never a good thing), this requires agreeing to the UAC prompt.

In short, what needs to happen:
1. Local SYSTEM runs Add-AppxProvisionedPackage on the App Installer package.
2. Wait until an user account is normally provisioned (right after first logon).
3. Run winget under that user's session, but with elevated rights to skip the UAC prompt.

Chocolatey on the other hand, is a normal Win32 app. After you run their PS command to download/self-install, it's ready to run. Other than adding the correct path so your script knows where to find things, it works for everyone including SYSTEM.

In respect to scripting, Chocolatey is far simpler to manage. There are differences between winget & Chocolatey's package selection (winget can do Store packages). The default version of winget requires a Microsoft Account identity to download from Store, but the GitHub version doesn't.

Understandably, this is a lot of detail. If you want to proceed with winget, there are two versions of the script.
- Runs on PC's without a Windows license in BIOS (post #9)
OR​
- Runs on PC's with a Windows license in BIOS (Dell, HP, Lenovo) (post #15)
 
garlin
Gotcha. I think I understand... mostly... or at least enough to get the picture.

So, my reason for wanting this to all be done under SYSEM during post install is so that any programs installed to the system instead of the user. Having it done behind the scenes and everything ready to go when I log in is a very nice bonus, but not necessary.

My reason for wanting to use a scripted package installer instead of individual installers on the image is to avoid adding as much as possible to the image, keep it as clean and small as possible, as well as to make my preset/image essentially "immune to time", avoiding as many post-install updates as possible. For example, I would like to make it so use an image I create today in 2 years and it would install updated versions of the programs it's scripted to install.

My reasons for wanting to use winget instead of Chocolatey are that it's packages seem to be generally more up-to-date than Chocolatey's, and it can install from the Microsoft Store.

My questions are:
  1. Does installing winget under USER, either manually after initial login or automatically via post-setup, install programs to all users/system?
  2. I gather that the version from GitHub is the better option. It's newer and does not require my Microsoft account. Considering my end goal of removing the Microsoft Store entirely without loosing the ability to get MS Apps, do you recommend the GitHub version over the one pulled in my script? Is there a way to install that one via command line as well? Should I build it myself or just download the release?
 
Hammer of the Gods said:
1. Does installing winget under USER, either manually after initial login or automatically via post-setup, install programs to all users/system?
Click to expand...
winget is running as SYSTEM, therefore it installs for all users.

2. I gather that the version from GitHub is the better option. It's newer and does not require my Microsoft account. Considering my end goal of removing the Microsoft Store entirely without loosing the ability to get MS Apps, do you recommend the GitHub version over the one pulled in my script? Is there a way to install that one via command line as well? Should I build it myself or just download the release?
Click to expand...
GitHub is where all the interesting features are being added. I believe some of them will get rolled into a future Windows (12?), but right now there's a split where the Store build only has the basic features. Now you don't really have to keep upgrading GitHub builds, unless they've fixed a major bug (like Chrome not installing) or added exciting features.

Pick one of the stable builds, do the download and leave it alone for about a year. winget is one of those slow and steady code projects.
 
garlin
Thank you, and I appologize for being a noob at this, as well as asking so much. I greatly appreciate your help.

So the first question was asking was if the other applications in my scripts being installed by winget, not winget itself, would be installed to the system. I can't think of an example, but some applications installers ask if you want them installed for all users or just the current one. I want them installed for all users. I assume it will do this since it's running as SYSTEM.

I have moved my script to the user portion of post-setup and it runs like a charm there.

As for which version, I was easily able to get into the insider program for the Package Installer. This insider version appears to be the "best of both worlds", including the latest GitHub version of winget (1.4.10173) and allowing automatic updates, if I choose to keep the MSStore.

Speaking of the MSStore, I haven't committed myself to removing it yet. I'd like to and if I do I'll happily use the GitHub winget, but unless I'm doing something wrong, it seems none of the versions of winget I've tested are able to upgrade my already installed MSStore apps, and others it can't seem to install at all, no matter what package name/ID I try. The game bar for example. Windows comes with a super old version that needs updating after setup, but it refused to do so with the upgrade command. I had to uninstall it first then reinstall it to get the updated version. The Game Bar Plugin on the other hand, I was unable to update/reinstall at all using either the name in the winget list or any other name/ID.

Another weird issue is that if I use the script I made which starts with installing winget (Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe), it installs 1.2.xxxx instead of at least the relase version (1.3.xxxx). This doesn't really matter whether I go with removing the MSStore and using the Git version, or keep the MSStore and just update it there after it installs everything, but it's weird.

On a side note, all versions of winget I've been trying, the MSStore release version, the insider build, the GitHub version, and the GitHub version I build with Visual Studio (1.5), all installed chrome without issue. No special commands or versions of Chrome, just "winget install -e --id Google.Chrome".

Included my WIP script if you're interested. You may want to edit out my list of programs to install.
 

Attachments

  • Combined.7z
    1.1 KB
Hammer of the Gods said:
Thank you, and I appologize for being a noob at this, as well as asking so much. I greatly appreciate your help.

So the first question was asking was if the other applications in my scripts being installed by winget, not winget itself, would be installed to the system. I can't think of an example, but some applications installers ask if you want them installed for all users or just the current one. I want them installed for all users. I assume it will do this since it's running as SYSTEM.

I have moved my script to the user portion of post-setup and it runs like a charm there.

As for which version, I was easily able to get into the insider program for the Package Installer. This insider version appears to be the "best of both worlds", including the latest GitHub version of winget (1.4.10173) and allowing automatic updates, if I choose to keep the MSStore.

Speaking of the MSStore, I haven't committed myself to removing it yet. I'd like to and if I do I'll happily use the GitHub winget, but unless I'm doing something wrong, it seems none of the versions of winget I've tested are able to upgrade my already installed MSStore apps, and others it can't seem to install at all, no matter what package name/ID I try. The game bar for example. Windows comes with a super old version that needs updating after setup, but it refused to do so with the upgrade command. I had to uninstall it first then reinstall it to get the updated version. The Game Bar Plugin on the other hand, I was unable to update/reinstall at all using either the name in the winget list or any other name/ID.

Another weird issue is that if I use the script I made which starts with installing winget (Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe), it installs 1.2.xxxx instead of at least the relase version (1.3.xxxx). This doesn't really matter whether I go with removing the MSStore and using the Git version, or keep the MSStore and just update it there after it installs everything, but it's weird.

On a side note, all versions of winget I've been trying, the MSStore release version, the insider build, the GitHub version, and the GitHub version I build with Visual Studio (1.5), all installed chrome without issue. No special commands or versions of Chrome, just "winget install -e --id Google.Chrome".

Included my WIP script if you're interested. You may want to edit out my list of programs to install.
Click to expand...
Sorry to revive this months old thread but I had to come here and praise this solution.
It worked like a charm.
I have been cracking my head for more than a week now and for some reason decided to check the forums for an answer before I gave up.
I had already made a script to download the latest version of apps I use from their websites, but it's a pain.
This solves it.

Thank you!
 
You must log in or register to reply here.
Back
Top