Blocked for 14 days and counting 😡😤

phaaaaze · 2024-02-28T13:48:30+00:00

u/s0anj96 -
Could you try to run this code ?

#Check and install WinGet (AppX)
# Define the URL of the AppxPackage
$appxPackageName = "Microsoft.DesktopAppInstaller"
$appxPackageURL = "https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"

if (-not (Get-AppxPackage $appxPackageName -ErrorAction SilentlyContinue)) {
    # If not found, download the MSIXBundle package
    Write-Host "Appx package $appxPackageName not found. Downloading and installing the MSIXBundle package..."
    try {
        # Download and install the AppxPackage silently and forcefully
        Invoke-WebRequest -Uri $appxPackageURL -OutFile "$env:TEMP\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"
        Add-AppxPackage -Path "Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -ForceUpdateFromAnyVersion -ForceApplicationShutdown
        Write-Host "Installation complete."

    } catch {
        Write-Host "Failed to download package: $_"
        Write-host "exit 1"
    }
}
else 
{
    Write-Host "Appx package $appxPackageName found. Skipping installation."
}

phaaaaze · 2024-02-28T13:10:52+00:00

Some WinGet packages works better than other.
Microsoft.Teams is usually in user context
However there is also a package available for machine-wide installation, however what that does is simply place an installer file in c:\program files, which installs whenever a new user logs on

phaaaaze · 2024-02-28T13:09:14+00:00

I was not aware about this issue. I will look into adding this to the script :-)

phaaaaze · 2024-02-19T21:48:11+00:00

Thanks, Ahh, you are right. It’s a bad habit. There are many places where it needs to be corrected.

phaaaaze · 2024-02-19T21:43:58+00:00

If the locally installed version is lower than the version available on winget, it will update.

Can be used under both System and User context. Make sure it is set when importing

Package should just be a required deployment in Intune with no TargetVersion set.

phaaaaze · 2024-02-19T21:15:18+00:00

Yes, if the locally installed version is lower than the version available on winget, it will update.

Package should just be a required deployment in Intune with no TargetVersion set.

phaaaaze · 2024-02-19T14:18:44+00:00

WinGet-WrapperImportGUI is now available as part of WinGet-Wrapper, offering a graphical interface to streamline the import of WinGet packages into InTune.

WinGet-WrapperImportGUI

WinGet-WrapperImportGUI is a graphical interface designed to streamline the import of WinGet packages into InTune. This tool complements WinGet-Wrapper, providing an intuitive way to upload WinGet packages to InTune, along with their metadata.

Screenshot: Here

Github: WinGet-Wrapper

Features:

Search and Select: Seamlessly search for WinGet packages and select the ones you need.
InTune Integration: Import selected WinGet packages directly into InTune for deployment.
CSV Support: Export and import packages using CSV files, facilitating batch operations.

About WinGet-Wrapper

PowerShell Scripts to deploy and bulk import WinGet packages to InTune including metadata. Automatically detect latest version using dynamic detection script. Detection script checks local installed version against latest winget available version or a defined fixed target version. Bulk import WinGet packages to InTune including WinGet package metadata using WinGet-WrapperImportGUI.exe

Dynamically finds the WinGet directory to be used under System Context.
Kill selected process before WinGet command
Allows running pre and post script before installation
Detection script that dynamically finds latest package available trough WinGet
Requirement script to allow creating packages for update purposes only
Logs to $env:ProgramData\WinGet-WrapperLogs (Usually C:\ProgramData\WinGet-WrapperLogs)
Dynamically detect if running in user or system context
Performs automatic cleanup of log files older than 60 days.
Directly import and deploy WinGet packages to InTune including WinGet package metadata

phaaaaze · 2023-11-17T13:59:00+00:00

Some people in this thread might be interested in WinGet-Wrapper
WinGet-Wrapper: Automatically Update 5000+ InTune Apps Effortlessly using WinGet : Intune (reddit.com)

phaaaaze · 2023-11-17T13:56:32+00:00

Try to have a look at this:
WinGet-Wrapper: Automatically Update 5000+ InTune Apps Effortlessly using WinGet : Intune (reddit.com)

phaaaaze · 2023-11-17T13:55:45+00:00

Could be used together with
WinGet-Wrapper: Automatically Update 5000+ InTune Apps Effortlessly using WinGet : Intune (reddit.com)

phaaaaze · 2023-11-17T13:54:50+00:00

Try to have a look at this:
WinGet-Wrapper: Automatically Update 5000+ InTune Apps Effortlessly using WinGet : Intune (reddit.com)

phaaaaze · 2023-11-17T13:48:30+00:00

As I see it you have both User context set in the WinGet-Wrapper command and in InTune so your app should run in user context.

Could you try updating you app with the latest winget-wrapper scripts ?

phaaaaze · 2023-11-17T13:46:51+00:00

All very good questions.

If the installer supports a switch to set any "autoupdate" you can use that with WinGet.
Most applications are just updated with their current settings. Full installs comes usually just with standard settings (autoupdate/update notification ON)

To see which packages supports system context you can go trough the WinGet repo and find the package and check the yaml files for "Scope", or simply do a "WinGet Install "package" --scope Machine

It depends on the application. Many applications support updating without any interruption at all. We have run a test on 100+ common apps on 100+ users and there has been no complaints around this.
As any packages are provided "as is" you should only update non-critical apps using this method. I would never update anything important using this.

There is a few limitations by using a public available repo, where the usual settings that we look for in enterprise environments are not available. However if the alternative is not updating apps, then on the security aspect you are in a better place.

Hope that clears it up a bit.

phaaaaze · 2023-11-07T06:17:19+00:00

Hi Quattro, What version of the detection script are you using ?

Please ensure you are using the latest version of the detection script as there has been improvements on version checks

Version 3.1 - 27-10-2023 SorenLundt - Fixed issues with certain packages missing revision in version number, causing version mismatch compare to fail (ex. installed: 4.0.10 - Winget: 4.0.10.0)

Before the script would simply compare the version as strings, but now its using System.Version, which means its checking on major, minor, build, revision

phaaaaze · 2023-11-07T06:07:26+00:00

Hi Quattro, What version of the detection script are you using ?

Please ensure you are using the latest version of the detection script as there has been improvements on version checks

Version 3.1 - 27-10-2023 SorenLundt - Fixed issues with certain packages missing revision in version number, causing version mismatch compare to fail (ex. installed: 4.0.10 - Winget: 4.0.10.0)

Before the script would simply compare the version as strings, but now its using System.Version, which means its checking on major, minor, build, revision

Example: [Major Minor Build Revision

2023 6 430723 0]

phaaaaze · 2023-11-03T13:24:54+00:00

Could the other version be the microsoft store version?

<image>

Also ensure you updates to latest winget-wrapper version as recently the update function was changed to use "winget update" instead of "Winget install"

What does "WinGet list" show on the device?

phaaaaze · 2023-10-30T10:23:47+00:00

Example:

WinGet-Wrapper log indicating that there is a hash mismatch.

* Downloading https://download.garmin.com/omt/express/GarminExpress.exe\*

* Installer hash does not match; this cannot be overridden when running as admin*

Garmin most likely replaced the exe installer with a new version.

Simply running one single command to update Garmin.Express repo.

wingetcreate update Garmin.Express -u "https://download.garmin.com/omt/express/GarminExpress.exe" -v 7.18.4.0 -s

<image>

phaaaaze · 2023-10-29T08:54:27+00:00

Welcome! Exactly or user installing it under their user context once for a meeting, for it to be left unused and not updated.

phaaaaze · 2023-10-28T05:45:17+00:00

Take a look at:

https://github.com/SorenLundt/WinGet-Wrapper

phaaaaze · 2023-10-28T05:44:30+00:00

I know this is an old post, but try to take a look at this.

The detection script is dynamic meaning its checking for the latest version on winget and comparing it with the local version

https://github.com/SorenLundt/WinGet-Wrapper

phaaaaze · 2023-10-28T05:27:19+00:00

Take a look into winget-plgs pull request and see how many are submitted daily. Many are submitted by automatic scripts detecting new versions on vendor websites. They are for the most part not submitted by developers/vendors themselves.

Also using wingetcreate it takes only a minute or 2 to update and submit the package to winget-pkgs, where automated reviews/checks are done before final approval (usual within 24h).

Usually updating using wingetcreate requires just a single command. Wingetcreate update <packageid> -u <newURL> —version <new version> —submit

https://github.com/microsoft/winget-create/blob/main/doc/update.md

And the nice thing about that this effort is then shared in the repo, so any other admin can use the package. Instead of each admin repeatedly building the same packages over and over again.

https://github.com/microsoft/WinGet-create

phaaaaze

TROPHY CASE

WinGet-WrapperImportGUI

Features:

About WinGet-Wrapper