Warning
- I haven't been working with Intune for years now, so I don't know whether all this still works.
- Feel free to open an issue or create a PR if you find any problems. 🙂
- Files and info in this repo is provided as is. I'm not responsible for what you decide to push to your clients.
- If logic in this repo breaks, I do not commit to fix it in a timely manner.
Repository containing examples of how to use WinGet from Intune, also in system context.
After I saw that rothgecw had figured out how to use winget-cli
from System context, I started thinking about how this could be used from Intune.
Following requirements should be included in a fresh installation of Windows 10 and 11, but aren't always present. Which has caused problems. So I'm mentioning them here just in case.
winget-cli
must be installed, comes with newer versions of App Installer.- Microsoft Visual C++ Runtime v14 / 2015-2022.
- Might get error
0x8007007B
with textThe filename, directory name, or volume label syntax is incorrect (0x8007007B)
without it.
- Might get error
- Genuine, activated Windows 10 Education, Enterprise or Professional for using Win32 with Intune.
- Can be a typical problem if using Hyper-V VMs with Microsoft 365 Developer Program tenants.
Create two Win32 packages per app you want to have in Intune installed with winget-cli
.
- One being available to install from Company Portal, where:
- Install command uses winget-cli to get newest app available.
- Detection rule is static, not checking version.
- If new version is detected in this package, Company Portal will say that app install failed.
- Maybe Company Portal can handle this in the future?
- One being required, where:
- Only required if the app itself does not have auto update functionality that doesn't require admin permissions.
- Requirement rules requires app to be installed already.
- NB: If you don't want to interrupt the end user, make sure to add logic to requirement rule that does keep the upgrade from running if for instance process X and Y are running.
- Detection rule uses winget-cli to detect if newer version is available.
- Observe that I have different detection logic and assignment type, given these three different scenarios
- Install
- Upgrade
- Dependency
- Uses a dummy
*.intunewin
containing nothing but an empty text file.
Usefull for all apps in winget-pkgs
that is not in Microsoft Store.
- Get latest version whenever an app is installed the first time, without maintaining packages in Intune.
Only for apps without built-in auto update, or where auto-update requires admin permissions.
- Excludes:
- Apps in system context that auto updates using a service running as SYSTEM
- Adobe Acrobat Reader DC
- Google Chrome
- Mozilla Firefox
- Microsoft Store UWP apps
- Apps in user context that auto updates
- 1Password
- Microsoft Visual Studio Code (User)
- Apps in system context that auto updates using a service running as SYSTEM
- Includes:
- 7-Zip
- Microsoft PowerToys
- Microsoft Visual Studio Code
- Notepad++
- Configure once.
- Keep apps and dependencies up to date.
- Remove need for admin permissions for end users.
Make everything and app that
- Does not require admin for install and update.
- Can be installed from a central store, even though an app is not in Microsoft Store yet.
- Autoupdates, even though it does not have such functionality built in, or if such functionality requires admin permissions.
- Use WinGet how you want, with whatever logic and mechanisms you want.
- The postive far outweighs the negative, in my opinion.
- See "Why not" section for context.
- "Free", with the pros and cons it brings.
- Neither Windows or Intune is free.
Tip
There are tools that can download WinGet packages, package them to .intunewin
and upload them to Intune, which could help offloading WAN using caching and peer to peer sharing. See resources for examples on such tools.
Running WinGet directly on the client does not support local caching or peer to peer, like uploading packages to Intune as Win32 apps does.
Apparently, WinGet supports Delivery Optimization, but only "HTTP Downloader".
Not "Peer to Peer" or "Microsoft Connected Cache (MCC)".
More references/ information
- WinGet CLI feature requests
- WinGet CLI settings
- Delivery Optimization
- Microsoft Connected Cache (MCC)
- WinGet default package manifest is public and open source.
- Reliability - Without any guarantees or SLAs.
- Security - So far without good controls for:
- Authenticity
- 2020-05-12: microsoft/winget-pkgs#100
- 2021-02-17: microsoft/winget-pkgs#7836
- 2022-11-18: microsoft/winget-pkgs#89190
- Prerequirements like
winget-cli
itself, or Microsoft Visual C++ isn't always available on a clean OS install.- Means one must handle prerequirements before being able to use WinGet as part of an device enrollment processes.
- WinGet returns success if updating sources fails.
winget-cli
still has some shortcomings that other package managers handle better. Most noticably are apps that are added to PATH
; Scoop handles this much better. Scoop also shines in its' abilities to extend functionality with PowerShell commands straight in the package manifest files, in my opninion. Not saying that Scoop is perfect, but that you might want multiple package managers in your tool belt.
One still have to make a considerable amount of custom logic to handle certain apps, but as WinGet has matured there are less breaking changes, like in the early days when winget.exe
was named AppInstallerCLI.exe
prior to WinGet v1.2.
Overview of progress:
Some issues I've either experienced or I think is worth knowing about:
- Can't natively run WinGet from system context.
- GitHub issue 2024-04-09: microsoft/winget-cli#4365
- GitHub issue for using the PowerShell module 2024-04-29: microsoft/winget-cli#4422.
- Can't specify context (machine vs. user) with
upgrade
.- GitHub issue 2022-05-07: microsoft/winget-cli#2145
- MSI doesn't always respect
--location
.- GitHub issue 2022-01-15: microsoft/winget-cli#1857.
- Doesn't handle change in installer type, if vendor goes from EXE to MSI for instance.
- GitHub issue 2021-10-25: microsoft/winget-cli#1640.
- Can't create custom detection logic, or write custom
DisplayVersion
to registry, for installers that:- Does not write full version info to Windows registry.
- Example: Microsoft VCRedist 2010: microsoft/winget-cli#2888.
- Does not update version number in registry on update:
- Example: OBS Studio: microsoft/winget-cli#1856 (comment).
- Writes a non-semver-compliant version number.
- Example: MakeMKV: microsoft/winget-cli#1856.
- Does not write full version info to Windows registry.
- Does not validate supported OS version, this offers non-compatible packages.
- GitHub issue 2022-06-01: microsoft/winget-cli#2209.
- Example: Windows Terminal: microsoft/winget-cli#2134.
- Packages one'd expect to be added to
PATH
is not.- GitHub issue 2020-08-24: microsoft/winget-cli#549
- Portable packages that are added to
PATH
issue 1: Does not handle DLLs for symlinked executables.- GitHub issue 2022-11-19: microsoft/winget-cli#2711.
- Portable packages that are added to
PATH
issue 2: Upgrade of user scope packages removes package fromPATH
.- GitHub issue 2024-01-08: microsoft/winget-cli#4044.
Issues that have been fixed
- No native PowerShell support.
- microsoft/winget-cli#221.
- Solved with
Microsoft.WinGet.Client
PowerShell module.
- Can't easily configure apps to be excluded from
winget upgrade --all
.- microsoft/winget-cli#476.
- Solved with
winget pin
.
- Can't use installers inside ZIP files.
- microsoft/winget-cli#140.
- microsoft/winget-pkgs#87300.
- Solved in WinGet v1.4.
- Can't use
winget upgrade
to upgrade a lot of apps, but can sometimes usewinget install
as a workaround.- GitHub issue: microsoft/winget-cli#752.
- Solved (mostly) in WinGet v1.3.
- Can't specify multiple IDs to install in one command.
- GitHub issue: microsoft/winget-cli#219.
- Solved for
winget install
in WinGet v1.5.
- Can't specify installer type (MSI vs. EXE) if multiple are available with
install
, nor inside global settings.- microsoft/winget-cli#1166.
- microsoft/winget-cli#2146.
- Example: 7-Zip: https://github.com/microsoft/winget-pkgs/blob/master/manifests/7/7zip/7zip/22.01/7zip.7zip.installer.yaml
- Solved in WinGet v1.6 with
winget install --installer-type
.
- Install WinGet on servers: https://github.com/asheroto/winget-install
- https://github.com/Romanitho/Winget-Install
- https://github.com/Romanitho/Winget-autoupdate
- Official module
Microsoft.WinGet.Client
: https://www.powershellgallery.com/packages/Microsoft.WinGet.Client - Unofficial module
Cobalt
made using Crescendo: https://github.com/ethanbergstrom/Cobalt - Unofficial module
WingetTools
: https://github.com/jdhitsolutions/WingetTools
- https://github.com/FlorianSLZ/Intune-Win32-Deployer
- https://github.com/Romanitho/WingetIntunePackager
- https://github.com/svrooij/WingetIntune, https://wintuner.app/
- IconViewer
- To extract icons from EXE files.
- MsEndpointMgr - Intune Debug Toolkit
- Oliver Kieselbach IntuneWinAppUtilDecoder
- Simeon Cloud IntuneAppBuilder