📝

標準ユーザーに対して Microsoft Intune と Winget を組み合わせアプリケーション配布を実現させたい

2024/08/01に公開

はじめに注意点

これは何?

Intune で Windows 端末に対してアプリケーションを配布する作業、とてもめんどくさいです。

https://zenn.dev/shimosyan/articles/2f34f66d1d5b9a

こちらの記事でも書いたとおり、ある程度共通化・簡略化をしてアプリケーションを配布を実現したいです。
その方法の一つとして Microsoft 公式のパッケージマネージャーである Winget と組み合わせる方法があります。

今回の課題

Intune + Winget を使う方法を調べると「配布設定にて指定するインストールの処理ではシステムではなくユーザーを指定すること」と記載があります。

これは「Winget がユーザーコンテキストにしか対応していないため」ということが主な理由として説明されています。

Intune では「システムを指定すると Windows の System アカウントの資格情報(システムコンテキスト)」として、そして「ユーザーを指定するとログインしているユーザーの資格情報(ユーザーコンテキスト)」として処理が動きます。

ログインユーザーの資格情報で処理されるということは、つまりユーザーに管理者特権が付与されている必要があります。逆に特権を持たない標準ユーザーでは Intune で処理を実行しても UAC に阻まれてしまうわけです。

Winget をシステムコンテキストで実行させるには

標準ユーザーでログインしている端末ではユーザーコンテキストでは管理者特権を行使することができません。必然的にシステムコンテキストで実行させるしかなくなります。

winget install --id **.** のような一般的なインストールコマンドのまま Intune の配布設定をユーザーからシステムに作り直しましたが結果が変わりません。

しかし、いろいろ文献を調べてみると Winget の実行バイナリは2種類あることがわかってきました。

一つ目は winget コマンドの PATH 先となっている下記のパスです。

%LOCALAPPDATA%\Microsoft\WindowsApps\winget.exe

もう一つは下記のパスです。(** には Winget のバージョンが入ります)

C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_**_x64__8wekyb3d8bbwe\winget.exe

さらに調べてみると前者はユーザーコンテキストでの動作ですが、後者はシステムコンテキストで動作できさらに Intune で処理したときに UAC を回避できることがわかってきました。

つまり、今回のケースでは後者の Winget を使うことで解決できるということです。

実装からの動作確認について

書くのが大変なので今回は割愛しますが、私のところではシステムコンテキストかユーザーコンテキストかどちらで実行されているかを判定して、それにあわせたバイナリを選択してコマンドを実行するスクリプトを書きました。今のところ問題なく動いています。

Intune の検出ルールで Winget コマンドを使う際は、こちらもコンテキストごとに Winget のバイナリを切り替える実装をする必要があることだけ注意が必要です。

最後に

というわけで、Intune と Winget を組み合わせて標準ユーザーの Windows 端末に対してアプリケーションの配布を実現するための解決策を紹介しました。

記載した内容について何かありましたら記事コメントか X/Twitter までご連絡ください。

GitHubで編集を提案

Discussion