What is WinTuner?

WinTuner is an open-source tool by Stephan van Rooij that takes an application from the WinGet catalog and turns it into a Win32 app in Microsoft Intune. According to the project introduction, it downloads the installer and the logo, creates the .intunewin file, generates the install, uninstall and detection information and publishes the result to Intune. The repository was originally named WingetIntune, and older links in the README and release notes still point to that name.

The current product is a PowerShell module published in the PowerShell Gallery. It is a binary module written in C# and targeting .NET 8, and it requires PowerShell 7.4. An earlier command-line edition distributed on NuGet as Svrooij.Winget-Intune.Cli stopped at version 1.1.0; the documentation states that the CLI is no longer supported and asks users to move to the module. A C# library for embedding the packaging logic in other applications is announced on the documentation site but is not available for download yet.

The latest GitHub release is v1.4.1, published on July 3, 2026. It adds native handling of zip installers, so a package whose WinGet manifest points to a zip with a nested MSI or EXE is extracted and packaged directly instead of falling back to a script that calls winget on the target device. The same release adds a -PrepareOnly switch to New-WtWingetPackage, which writes the installer and all generated scripts to the package folder without building the .intunewin file. Version 1.4.0 fixed version encoding, improved the detection script parsing of winget output and generated better file names for MSI installers. Version 1.3.1 added MSIX support, and 1.3.0 added versionless script generation and app fetching.

WinTuner does not depend on the Microsoft Win32 Content Prep Tool. Its author re-implemented the creation of .intunewin files in C#, and since version 0.8.4 these commands are part of the module. The content prep page notes that this re-implementation is based on public information, is not feature complete and is provided without warranty or Microsoft support. Package lookups use an open-source WinGet package index that a GitHub Action refreshes every four hours, which removes the need to start a local winget process for version data.

The source code is licensed under the GNU General Public License v3.0. The README describes WinTuner as a beta application that is still in development and asks for bug reports through GitHub issues. Starting with version 1.2.0, the module sends anonymous usage telemetry, documented on the telemetry page. WinTuner is a packaging and publishing tool: device enrollment, app installation on endpoints and reporting remain functions of Intune itself.

Key capabilities

PowerShell Gallery installation The module installs with Install-Module -Name WinTuner and updates with Update-Module -Name WinTuner. A specific version can be installed with -RequiredVersion. The module manifest requires PowerShell 7.4, and the installation page lists these commands.
WinGet package packaging New-WtWingetPackage takes a WinGet package ID and a package folder, downloads the installer for the latest or a chosen version and creates an .intunewin file in a {packageId}\{version} subfolder. Parameters cover architecture, installer context, locale, a preferred installer type, MSI product code and version, and overriding installer arguments.
Script-based fallback package The -PackageScript switch packages a WinGet script instead of the actual installer. The documentation describes this option for installers that do not work well with the regular WinTuner packaging path.
Prepare-only and partial packages -PrepareOnly, added in 1.4.1, downloads the installer and generates install, uninstall and detection scripts plus app.json and readme.txt without creating the .intunewin file, so the files can be edited before packaging. -PartialPackage leaves the files unzipped in a partial package for direct upload.
Installer type coverage Release notes list MSI handling with generated file names, MSIX support since 1.3.1 and zip installers with nested MSI or EXE files since 1.4.1. For zip packages, the install command is derived from the nested installer and its WinGet switches.
Win32 app deployment Deploy-WtWin32App uploads a package to Intune as a new Win32LobApp. It accepts a package created by New-WtWingetPackage, a package folder, or a Win32LobApp object with an .intunewin file and optional logo. Categories, role scope tags and an override for the app name can be set at upload.
Assignments at upload time The deploy and update commands accept -AvailableFor, -RequiredFor and -UninstallFor with group object IDs or the values AllUsers and AllDevices. The Deploy-WtWin32App reference documents every parameter set.
Supersedence Passing -GraphId of an existing app makes the new upload supersede it, and -KeepAssignments carries the assignments of the superseded app over. Get-WtWin32Apps filters on whether an app is superseded or superseding.
Update discovery in the tenant Get-WtWin32Apps loads the apps that WinTuner packaged in the tenant and can filter on available updates, assignment state and a server-side name filter. The documentation shows it combined with New-WtWingetPackage and Deploy-WtWin32App to package newer versions in a loop.
Content updates and app maintenance Deploy-WtWin32ContentVersion uploads a new .intunewin file to an existing app. Update-WtIntuneApp changes categories and assignments and has an -EnableAutoUpdate switch, which release 1.2.0 fixed. Remove-WtWin32App removes relationships first and then deletes the app.
Microsoft Store apps Deploy-WtMsStoreApp creates a Microsoft Store app in Intune from a Store package ID, or from a search query that takes the first match. The same assignment and category parameters are available.
Authentication options Connect-WtWinTuner supports interactive sign-in (Windows authentication broker on Windows, default browser elsewhere), managed identity, DefaultAzureCredential, an existing token, client certificate and client secret. The interactive default scopes are DeviceManagementConfiguration.ReadWrite.All and DeviceManagementApps.ReadWrite.All, as listed on the authentication page.
Windows Sandbox tests Test-WtIntuneWin runs a package in Windows Sandbox to check whether the installer arguments install silently and end with the expected exit code. Test-WtSetupFile does the same for any setup file. Both depend on Windows Sandbox and therefore on Windows.
Fast package search Search-WtWinGetPackage searches the online package index by name, ID and tags, and can return all packages updated after a given date. The documentation warns that -All returns a large collection of several thousand packages.
Content prep and MSI utilities New-IntuneWinPackage creates .intunewin files from any source folder, and Unprotect-IntuneWinPackage decrypts and extracts an existing package. Show-MsiInfo reads the product code and version from a local MSI or downloads one from a URL.
Token export Get-WtToken returns a token from the current authentication method, which the documentation describes for passing to other scripts that call the Graph API.
Telemetry Since version 1.2.0 the module reports the WinTuner version, the command and the package ID to an Azure Function that forwards the data to Plausible. The project states that no personal data or cookies are used.

Where WinTuner fits

Packaging a WinGet app for Intune

The documented basic flow is two commands. New-WtWingetPackage -PackageId JanDeDobbeleer.OhMyPosh -PackageFolder C:\Tools\Packages downloads the latest installer and writes the package to a versioned subfolder. Deploy-WtWin32App with the same package ID, version and root folder then uses the metadata written during packaging to create the Win32 app in Intune.

Updating apps that are already in the tenant

The Get-WtWin32Apps page describes a loop that selects apps with an update available that are not superseded, packages the latest version and deploys it with -GraphId and -KeepAssignments, so the new app supersedes the old one with the same assignments. A second example removes superseded apps with Remove-WtWin32App. The documentation mentions running these loops weekly.

Unattended runs in Azure or pipelines

For scheduled or automated runs, Connect-WtWinTuner accepts a managed identity, DefaultAzureCredential (environment variables, managed identity, Azure CLI and others), a client certificate thumbprint or a client secret. Tenant ID, client ID, certificate thumbprint and secret can be read from the AZURE_* environment variables. The documentation lists client secrets as the least preferred option.

Customizing generated scripts before upload

With -PrepareOnly, the installer and the generated install, uninstall and detection scripts are written to the package folder without building the .intunewin file. The pull request that introduced the switch describes editing scripts, such as custom uninstall logic, and then packaging the folder with New-IntuneWinPackage.

Checking silent install switches

Test-WtSetupFile starts an installer in Windows Sandbox with the given arguments, and Test-WtIntuneWin does the same for a package folder, an .intunewin file or a WinGet package ID and version. The run reports whether the install was silent and returned the expected exit code, and -Clean removes the test files afterwards.

Working with Intune packages outside WinGet

The content prep commands create .intunewin files for any installer folder and extract existing packages, and Deploy-WtWin32App also takes a Win32LobApp definition with a custom .intunewin file. The same content prep code is available as the separate module SvRooij.ContentPrep.Cmdlet and the .NET package Svrooij.ContentPrep. Similar projects listed on iThub include IntuneGet and the IntuneAutomation script collection.