當您想用 Intune 部署 WinGet 應用程式時，流程理應很直接。畢竟，WinGet 已經知道數千個 Windows 應用程式的安裝程式 URL、版本和靜默安裝參數，因此您應該可以直接讓 Intune 指向該目錄並進行部署，對吧？
不過，這裡有個但書。Intune 沒有可直接從 WinGet 社群存放庫部署的應用程式類型，只能部署來自 Microsoft Store 的應用程式。更麻煩的是，當指令碼以 SYSTEM 身分執行時，WinGet 命令列工具並不受支援；而這正是當 Intune 將應用程式的安裝行為設為 System 時所使用的情境。
考量到這一點，該如何使用 Intune 部署 WinGet？我們已整理出四種可讓部署更輕鬆的方法，接下來就來看看它們分別是什麼、各自的成本、設定方式，以及如何解決過程中可能遇到的問題。
Intune 可以原生部署 WinGet 應用程式嗎？
部分如此。Intune 的 Microsoft Store app (new) 類型會使用 Windows Package Manager，從 Microsoft Store 尋找並安裝應用程式。它無法連接到 WinGet community repository，也就是大多數 WinGet 指南使用的公開目錄，而且 Intune 沒有任何應用程式類型可從該處部署。若要部署 community repository 應用程式，需要使用指令碼包裝程式或 Win32 套件。
這個差異取決於 WinGet 的組織方式。它會從兩個主要來源提取應用程式：Microsoft Store（msstore）以及 GitHub 上的 WinGet 社群存放庫。Intune 的 Store 整合已取代停用的 Microsoft Store for Business，但它只會連接到前者。
在 Intune WinGet 的討論中，您也可能會看到有人提到 Microsoft 的 Enterprise App Catalog。這是 Microsoft 準備並託管的另一個 Win32 應用程式庫，而 Microsoft 表示它不使用 WinGet。此外，這還需要 Intune Plan 1 或 Plan 2 以外的額外訂閱。
搭配 Intune 使用 WinGet 的四種方式
如果想使用 Intune 部署 WinGet 應用程式，仍然有方法可以做到。以下是使用 Intune 搭配 WinGet 的四種最常見方式，包括各自最適合的用途及其限制：
方法 | 應用程式來源 | 額外授權 | 主要限制 | 最佳用途 |
1. Microsoft Store 應用程式（新版） | Microsoft Store（msstore） | 除了 Intune 之外沒有其他需求 | 僅限 Store 已上架的應用程式；Win32 Store 應用程式仍在預覽中 | 製造商發佈到 Microsoft Store 的應用程式 |
2. 將 WinGet 指令碼包裝成 Win32 應用程式 | WinGet 社群存放庫 | 除了 Intune 之外沒有其他需求 | 安裝、偵測及解除安裝指令碼需自行撰寫與維護；WinGet 必須能在 SYSTEM 底下被找到並執行 | 一份簡短的社群應用程式清單，以及熟悉 PowerShell 的團隊 |
3. 執行 WinGet 升級的修復措施 | WinGet 社群存放庫 | Windows Enterprise E3/E5 或 Education A3/A5 | 讓已安裝的應用程式維持在最新狀態；不處理首次安裝 | 已安裝這些應用程式之裝置的更新管理 |
4. 由安裝程式建置的原生 Win32 套件 | 透過 WinGet manifest 或製造商找到的安裝程式 | 除了 Intune 之外沒有其他需求 | 每個應用程式與版本都需要進行封裝、設定偵測規則，以及測試 | 可控、經過測試的大規模部署 |
以下將逐步說明每種方法的運作方式。
方法 1：使用 Microsoft Store 應用程式（新版）類型部署 Microsoft Store 應用程式
第一種（也可以說最簡單的）部署應用程式方式，是透過 Microsoft Store 應用程式。只要幾個快速步驟即可完成：
在 Intune 管理中心，前往 Apps → All Apps → Create，然後在 Store app 下選擇 Microsoft Store app (new)。
選取「搜尋 Microsoft Store 應用程式」，然後依名稱、發行者或 Store 應用程式 ID 搜尋想要的應用程式。結果會顯示每個應用程式是 Win32 還是 UWP。
檢查預先填入的應用程式資訊，將安裝行為設為 System 或 User（請注意，某些應用程式只支援其中一種），並設定 Company Portal 選項（例如精選應用程式和類別）。
將應用程式指派為 Required、Available for enrolled devices 或 Uninstall，並設定終端使用者通知、重新啟動寬限期及安裝截止時間。
檢查並建立。當新版本推出時，Intune 會持續更新該應用程式。
話雖如此，還是有一些限制和先決條件需要留意。這些都可能讓流程變得更複雜，也可能表示需要改用其他方法：
裝置需要 Intune Management Extension、至少兩個處理器核心，以及對 Store 和發行者內容的網路存取權。
Store 中的 Win32 應用程式目前仍處於預覽階段，而且不是每個 Win32 應用程式都能搜尋得到。同樣地，付費應用程式和 ARM64 安裝程式也不受支援。
來自 Store 的 Win32 應用程式，只有在持續指派於 Intune 時才會保持更新。
已註冊 Entra 的裝置必須使用系統安裝行為（因此不能選擇使用者）。
方法 2：將 WinGet 命令包裝在 Win32 應用程式中
如果 Microsoft Store 應用程式無法滿足需求，您可以將 WinGet 命令包裝在 Win32 應用程式中，然後透過 Intune 部署 WinGet。在這些情況下，Win32 應用程式比單純的平台指令碼更可靠，因為它包含狀態偵測、傳回碼和解除安裝命令，而這些都是單行指令碼部署所欠缺的。
為什麼 Intune 以 SYSTEM 身分執行時，WinGet 會失敗
當 Win32 應用程式的安裝行為設為 System 時，Intune 會以 SYSTEM 身分執行其安裝命令，而 WinGet 就會在這裡失效。由於 WinGet CLI 隨 App Installer 一同提供，而 App Installer 是以每位使用者為單位註冊的封裝（MSIX）應用程式，因此WinGet CLI 在 SYSTEM 內容中不受支援。因此，在 SYSTEM 指令碼中直接以名稱呼叫 WinGet 通常會失敗，因為 SYSTEM 無法找到它。
有一些變通做法。社群腳本通常會透過在 C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe 下解析 winget.exe 來處理這個問題，但這不是 Microsoft 支援的方法。Microsoft 支援的做法是使用 Microsoft.WinGet.Client PowerShell 模組，對於安裝在整部電腦層級的應用程式，它可在系統內容中運作。
撰寫安裝指令碼
若要撰寫安裝指令碼，請先找出套件 ID，然後從社群存放庫使用該確切 ID 進行安裝。您可以使用 winget search <app name> 查詢 ID，或不透過命令列，直接在 winstall（Splashtop 的免費 WinGet 目錄瀏覽器）上查找。取得 ID 後，安裝命令大致如下：winget install --id Git.Git -e --source winget --silent --accept-package-agreements --accept-source-agreements
若為 SYSTEM 安裝，請務必加入 --scope machine。請記住，Microsoft 警告 EXE 安裝程式無法一致地處理 scope。
在 Microsoft Intune 中，安裝命令可以是最多 50 KB 的 PowerShell 指令碼。在命令欄位中使用 powershell.exe 會啟動 32 位元版本，而使用 Sysnative 路徑則可使用 64 位元 PowerShell。
新增偵測指令碼
請務必加入一個指令碼，用來偵測並確認應用程式已正確安裝。只有當指令碼以代碼 0 結束並將輸出寫入 STDOUT 時，Intune 才會將該應用程式判定為已安裝；任何 STDERR 輸出都會被視為未安裝。此指令碼通常會檢查應用程式的安裝資料夾、檔案版本，或解除安裝登錄機碼。如果使用 winget list 檢查，會遇到相同的 SYSTEM 問題，因此最好改用檔案或登錄機碼檢查。
封裝指令碼並上傳 Win32 應用程式
最後，使用 Microsoft Win32 Content Prep Tool 封裝這些指令碼，以產生 .intunewin檔案。接著，您可以在 Apps → All apps → Add → Windows app (Win32) 下新增該檔案，將安裝行為設為 System，並新增解除安裝命令、偵測指令碼和需求。在解除安裝命令中請使用完整路徑，因為 Intune 不會在該處展開環境變數。
請記住，每個應用程式都需要各自的指令碼集和更新，而且安裝該應用程式的每台裝置上都必須已安裝 WinGet 並能正常運作。因此，這種方法的維護負擔可能會比其他方法更高。
方法 3：使用 Intune Remediations 讓 WinGet 應用程式保持在最新狀態
使用 Intune Remediations 時，可以將偵測指令碼與修復指令碼配對使用。對於 WinGet，偵測指令碼會檢查已安裝的應用程式是否有新版本可用；若有，修復指令碼就會針對該套件 ID 執行 winget upgrade。這可作為與方法 2 和 4 搭配的更新方式，但無法處理初始安裝。
授權是第一步。Intune Remediations requires Windows Enterprise E3 或 E5（包含於 Microsoft 365 F3、E3 或 E5）或 Windows Education A3 或 A5，且裝置必須由 Intune 管理或共同管理，並執行 Windows Enterprise、Professional 或 Education。
若要使用 Intune Remediations 讓應用程式保持更新，只要按照幾個簡單步驟操作即可：
在 Intune 系統管理中心中，前往 Devices → Manage devices → Scripts and remediations。
建立包含偵測指令碼的指令碼套件，以檢查套件 ID 是否有可用的升級版本。
新增修復指令碼，針對該 ID 執行升級，並加入
--silent和兩個--accept旗標。將它指派給裝置群組，並設定檢查更新的排程。
請確認鎖定想要升級的特定套件 ID。雖然可以使用 winget upgrade --all，但這會更新 WinGet 可辨識的每個應用程式，包括 IT 尚未核准或測試的應用程式。另外也請記住，WinGet 會從存放庫安裝最新版本，因此可能會在 IT 團隊有機會測試之前就先推出更新。如果修復指令碼是以 SYSTEM 身分執行，就會遇到方法 2 中提到的相同 WinGet 限制。
方法 4：將安裝程式封裝為原生 Win32 應用程式
也可以將安裝程式重新封裝為原生 Win32 應用程式。在這種情況下，WinGet 是作為應用程式資訊的來源，而不是應用程式本身。透過使用 WinGet 資訊清單來找出安裝程式及其靜默參數，即可將安裝程式部署為標準 Win32 應用程式。
這表示裝置即使沒有可正常運作的 WinGet 用戶端，也能部署該應用程式，不會受到 SYSTEM 情境問題影響，還能使用 Intune 完整的 Win32 功能。
只要幾個步驟，就能將安裝程式封裝為 Win32 應用程式：
使用
winget search找出套件 ID（或在 winstall 上查詢），並檢查其資訊清單中的安裝程式類型、下載 URL 與靜默安裝參數。（WinGet 要求列出的每個安裝程式都支援靜默安裝。）使用 WinGet 或從製造商下載安裝程式。
請確認該安裝程式類型的靜默安裝命令。我們的 MSI 靜默安裝 和 EXE 靜默安裝 指南涵蓋了各種安裝程式類型的參數。
使用 Microsoft Win32 Content Prep Tool 封裝安裝程式，以建立 .intunewin檔案。
將其新增為 Windows 應用程式（Win32），包括安裝與解除安裝命令、偵測規則（依 MSI 產品代碼、檔案或登錄），以及需求與傳回代碼。
在將應用程式部署到更多裝置之前，請先在乾淨的測試裝置上測試其安裝、完成安裝的偵測，以及解除安裝是否運作正常。
每當有新版本發佈時，都需要重新建置，並使用 supersedence 取代舊版應用程式。
這個選項可為 IT 團隊提供最高程度的自訂彈性與控制能力，但也代表他們必須為每個應用程式和每次更新重複這個流程。因此，擁有大量應用程式目錄的團隊可能會難以跟上這樣的工作量。
那麼，哪一種方法最有效？我們可以逐一拆解，看看什麼情況下這樣的取捨值得，以及何時改用其他方法會更好。
Intune 中的 WinGet 與 Win32 應用程式：哪種方式較適合
核心差異在於，裝置是在安裝時執行 WinGet，還是接收預先封裝好的 Win32 應用程式。以下是兩者的比較：
比較因素 | 安裝時使用 WinGet（方法 2 和 3） | 已封裝的 Win32 應用程式（方法 4） |
裝置上的 WinGet 用戶端 | 必填，且必須能在 SYSTEM 底下運作 | 不需要 |
安裝程式的來源 | 從 manifest 中的 URL 下載到各個裝置 | 以 .intunewin 格式上傳至 Intune 一次檔案 |
安裝的版本 | 儲存庫列出什麼就是什麼，除非使用 | 已封裝並測試的確切版本 |
偵測 | 自行撰寫並維護的指令碼 | 內建 MSI、檔案或登錄規則，或指令碼 |
更新 | 每個應用程式使用 Remediations 或新的指令碼 | 新套件加上取代關係 |
前期投入 | 每個應用程式的工作量低 | 每個應用程式成本較高 |
比較這些選項後，我們可以看出幾個重要細節。如果只是少量的低風險工具，WinGet 指令碼可以更快速，也較不需要前期投入。對商務應用程式、受監管裝置或大型目錄來說，封裝的 Win32 應用程式更可靠，因為它能在正式部署前提供可預測的版本與測試。
如果該應用程式已列在 Microsoft Store 中，方法 1 通常是最省事的選擇。
使用 Intune 部署 WinGet 應用程式時的常見問題
即使用對了方法，透過 Intune 部署 WinGet 應用程式仍然有其挑戰。IT 團隊在部署應用程式時可能會遇到常見問題，但都能加以識別並解決。
常見問題包括：
1. Intune 指令碼無法識別 WinGet
如果您的指令碼回報無法識別 winget，該指令碼很可能是以 SYSTEM 身分執行；在該環境中不支援 WinGet CLI，因為 App Installer 是以每位使用者為單位進行註冊。這可透過使用 winget.exe 的完整路徑來解析，或如方法 2 所述，改用 Microsoft.WinGet.Client PowerShell module 來解決。
2. 應用程式安裝給錯誤的使用者，或安裝在錯誤的位置
如果應用程式安裝在錯誤的位置，或安裝給錯誤的使用者，那就是安裝範圍的問題。使用 SYSTEM 時，使用者範圍會解析為 SYSTEM 自己的設定檔，而 EXE 安裝程式在處理使用者與電腦範圍時則不一致。若要修正這個問題，請在 SYSTEM 安裝時使用 --scope machine（請務必先測試，再更廣泛地部署該應用程式）。
3. 下載因 403 Forbidden 錯誤而失敗
如果下載時出現 403 Forbidden 錯誤，軟體製造商可能是在其下載伺服器上封鎖了 WinGet 的 user agent。如果安裝程式能在瀏覽器中順利下載，那很可能就是原因。發生這種情況時，可以直接下載安裝程式，並將其作為封裝的 Win32 app 來部署，如方法 4 所述。
4. Store 應用程式未出現在 Intune 搜尋結果中
如果搜尋不到 Store 應用程式，可能有三個原因：1. 所在區域未提供該應用程式，2. 它是付費應用程式，表示不受支援，或 3. 其平台不受支援。無論原因為何，請先確認該應用程式的上架資訊；如果無法存取，請改用方法 2 或 4 來安裝。
5. UWP Store 應用程式回報 "安裝後未偵測到"（0x87D1041C）
如果收到此警示，表示某個 UWP 應用程式已用 System 安裝行為指派給一台已經安裝該應用程式的裝置。在這種情況下，不必擔心；應用程式仍會正確安裝。Microsoft 也建議，同一個應用程式不要混用使用者與系統內容。
6. 找出 WinGet 安裝失敗的原因
如果 WinGet 安裝失敗且不確定原因，可以進一步調查，以判斷並解決問題根源。在命令中加入 --verbose-logs 可取得完整記錄，您也可以執行 winget error <code>，將結束代碼轉換為說明。請注意，這涵蓋 WinGet、MSIX 和 MSI 代碼，但許多 EXE 安裝程式可能會使用非標準代碼。我們的 EXE 靜默安裝指南 說明了如何找到這些代碼。
Splashtop Agentic Packr 如何將 WinGet 應用程式轉成經過測試的 Intune 套件
使用 Intune 部署 WinGet 應用程式可能很複雜，但其實不一定要這麼麻煩。有了合適的自動化，團隊就能快速且有效率地將安裝程式封裝，而不會占用 IT 資源。
這就帶到 Splashtop Agentic Packr，這是一款為現代 IT 團隊打造、由 AI 驅動的應用程式封裝與部署工具。Agentic Packr 可透過 Microsoft Intune、SCCM 等平台封裝、驗證及部署應用程式，所需手動作業大幅減少。
Splashtop Agentic Packr 提供多項功能與優勢，包括：
1. 使用 WinGet 作為來源，且裝置上沒有 WinGet 用戶端
Splashtop Agentic Packr 可以將來自已驗證 WinGet 目錄、依 WinGet 或 Chocolatey 套件 ID 指定的應用程式，或是自有安裝程式打包。它會建立 Intune 原生的 Win32 app，因此不必擔心使用者常遇到的 WinGet 和 SYSTEM 情境問題。
2. 在任何內容發佈前先撰寫並測試偵測規則
當 AI 驅動的代理程式讀取安裝程式時，會撰寫偵測規則，並在乾淨的虛擬機器上測試該版本。這些測試會檢查安裝、偵測和解除安裝是否正常運作，執行惡意軟體掃描，並產出 QA 評分表和記錄檔，讓 IT 管理員可在應用程式進入 Intune 並部署到各裝置之前先行審查。
3. 發佈與新版本，無須手動重新建置
Splashtop Agentic Packr 免除了每次有新更新推出時，都必須手動重新建置套件的需求。透過一鍵即可快速連接至 Intune 租用戶，以及自動版本更新功能，Agentic Packr 能偵測新更新、將其打包、進行測試，並部署更新後的套件，無需管理員手動處理每一次更新。
4. 控制使用者會看到的內容
Splashtop Agentic Packr 讓 IT 能控制安裝與更新顯示給使用者的方式。團隊可自訂終端使用者通知、延後選項、重新啟動提示和寬限期，讓必要的安裝與更新較不容易在使用者工作到一半時造成中斷。
將 WinGet 應用程式部署到 Intune，無需維護指令碼
WinGet 是強大的應用程式資訊來源，而 Intune 很適合部署應用程式，但 Intune 無法直接從 WinGet 社群存放庫進行部署。可擴展的方法，是將 WinGet 項目轉換為經過測試的 Win32 套件。
有了 Splashtop Agentic Packr，您可以用少得多的手動作業來建立、測試及發佈應用程式套件。Agentic Packr 讓封裝更快、更簡單，透過單一控制台即可封裝、部署及更新應用程式，同時讓管理員持續保有控制權。
想用 Intune 部署 WinGet 應用程式，又不想大費周章嗎？立即了解 Splashtop Agentic Packr 現在就能如何提供協助。
