Skip to content

Latest commit

 

History

History
288 lines (208 loc) · 13.2 KB

README.md

File metadata and controls

288 lines (208 loc) · 13.2 KB
Raw

winget-intune-win32

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.

About

This repo

Repository containing examples of how to use WinGet from Intune, also in system context.

Inspiration

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.

How to use

Pre-requirements

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.

Setup per app

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.

Remember

  • Observe that I have different detection logic and assignment type, given these three different scenarios
    • Install
    • Upgrade
    • Dependency

How it works

General

  • Uses a dummy *.intunewin containing nothing but an empty text file.

Install

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.

Update

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)
  • Includes:
    • 7-Zip
    • Microsoft PowerToys
    • Microsoft Visual Studio Code
    • Notepad++

Background

Why

Greenfield

  • Configure once.

Security

  • Keep apps and dependencies up to date.
  • Remove need for admin permissions for end users.

End users ease of use

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.

Flexibility

  • Use WinGet how you want, with whatever logic and mechanisms you want.

Other

  • 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.

Why not

Network bandwidth

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

Security and realibility

  • WinGet default package manifest is public and open source.
  • 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.

Other shortcomings

winget-cli / winget.exe

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:

Issues that have been fixed
winget-pkgs / Manifest

Resources

Similar or relatable projects

PowerShell modules

Client GUIs

Upload WinGet apps to Intune Win32

Commercial products

Tools

By Microsoft

By others

Requirements