![]() A consistent standard for installers would be a huge step forward.Windows 11 Taskbar Styler is an advanced Windhawk mod to override style attributes of the taskbar control elements. Maybe one day Microsoft will lock us into MSIX and lock out all these proprietary installers. I doubt that I will ever glance at WinGet, it's never going to match what PMP offers. Literally saved me an entire full time employee. ![]() It's not actually that expensive and those guys are crunching installers all day long every single day to keep that metadata up-to-date. Go look at the Patch My PC addon to MECM/Intune. Even MECM does not offer a catalog to handle this, you have to buy a third party catalog to really tackle this. "hmm, is the switch quiet, silent or unattended, hell if I know" There are a myriad of hodgepodge standards for installing software on a Windows OS. It's huge and complex because the core problem is huge and complex because Microsoft never locked us down to a single Windows Installer, setup.exe bullshit is still allowed to run rampant. MS already has an enterprise level software deployment tool, MECM. If I get the chance to tomorrow, I’ll update this comment with a full example. The Azure VM RunCommand extension executes under the system account, so I wanted to find some way to get it to work through that. I just recently went through writing the logic out in some PowerShell scripts. ![]() ![]() $wingetCliPath install -id Google.Chrome -exact -source winget under the system context. I then run $app = Get-AppXPackage -AllUsers -Name "Microsoft.DesktopAppInstaller" and then $wingetCliPath = Join-Path -Path $app.InstallLocation -ChildPath "AppInstallerCLI.exe" to create a path to run winget. I have the latest Microsoft.DesktopAppInstaller download and added as a provisioned app with the Add-AppXProvisionedPackage cmdlet. There is a way to get around this though and I’ve been implementing it into my Azure Virtual Desktop image building process. The other benefit comes from how locked down the app’s files are to users, so in theory the files can’t be tampered with in any way.Īs deployments use the Windows’ NTAUTH\System account, and the “App Installer” package only auto-installs the moment a user signs in (which System never does), this tool then becomes worthless for our environment and we’re stuck with manual msiexec installs and updates. There’s a far lesser chance a user will unintentionally install something that compromises the system if it’s installed inside the user’s context. To have apps be installed under the user context instead of the system context. We used to deploy Slack through the Windows Store, but now the Store has updated to this fancy new one, and now it's forcing our users to sign into a Microsoft Account, which doesn't seem plug into Azure AD in any way.Īnd why the fuck would MS make something to 'eventually replace MSI' with such a huge oversight? is there any reason at all for winget to exist? And why the fuck would MS make something to 'eventually replace MSI' with such a huge oversight? Submitting this on the winget GitHub I got told that this is an MSIX limitation and not a winget limitation, and that there's currently an issue raised but it's "in their backlog", which is most unhelpful. When MS announced the winget package manager, I did initially think finally, as I could then simply have a script linking to MS Store apps and never have to worry about updates to those applications.įast forward to its release in Windows 10, and I find that winget is being placed in %localappdata%\Microsoft\WindowsAppsĪs deployments use the Windows' NTAUTH\System account, and the "App Installer" package only auto-installs the moment a user signs in (which System never does), this tool then becomes worthless for our environment and we're stuck with manual msiexec installs and updates.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |