PSAppDeployToolkit: a PowerShell deployment wrapper for Intune and ConfigMgr

What PSAppDeployToolkit actually solves for Windows admins

A Windows application is rarely just an MSI. It has prerequisites, a vendor setup wizard that expects a logged-in user, a reboot it wants, and a help desk that needs to know why it failed on one machine out of four hundred. PSAppDeployToolkit is a PowerShell framework that wraps that work. The README describes it as a "PowerShell-based, open-source framework for Windows software deployment that integrates seamlessly with existing deployment solutions (e.g. Microsoft Intune, ConfigMgr, Tanium, BigFix etc.)". The audience is the person who owns the deployment pipeline, not the application vendor.

The toolkit does not replace Intune or ConfigMgr. Those tools still deliver the package and report on it. What the toolkit adds is the behaviour inside the package: a prescriptive workflow, a library of functions for common deployment tasks, a branded user interface, and logging. The README states the goal plainly, that these elements combine "to produce consistently high deployment success rates". That is a claim from the project, not a measured result, and the repository does not publish success-rate data.

The practical consequence is that a deployment script becomes a few dozen lines of PowerShell that call functions such as Show-ADTInstallationPrompt instead of a hand-rolled sequence of Start-Process calls, registry checks and custom logging. If your current packages are already stable and fully silent, the framework is overhead. If they are not, it is the part that makes them boring.

How the toolkit wraps a deployment: module, template and config

The repository is a .NET and PowerShell project. The top level holds PSADT.slnx and PSADT.Invoke.slnx, a src/ directory, a modules/ directory, tests/ with Pester configuration files, and examples/ containing packages for VLC, WinSCP, a multi-session installation and a launching example. The primary language is C#, which is worth noting: this is not a loose collection of .ps1 files. The module ships compiled assemblies, and the 4.2.0-rc1 release notes describe major code refactoring, a much smaller module, and removal of all WMI dependencies so the toolkit can run on devices with WMI corruption.

A deployment package is built around a template script. The README states that the default Invoke-AppDeployToolkit.ps1 template is more streamlined in 4.2.0-rc1, that ZeroConfig code has been removed from it, and that ZeroConfig is now a separate download or can be generated with New-ADTTemplate -ZeroConfig. The same cmdlet can generate an entire package in one command by specifying session properties, config, assets, files and script blocks.

Configuration and assets sit alongside the script in the package. The release notes mention configurable accent colours for dark mode, dialog fallbacks to a default image when a specified asset is missing, and the option to encode images as Base64 strings instead of file paths. Logging is a first-class concern: Add-ADTModuleCallback lets you run custom functions whenever the toolkit writes to the log or when a deployment is deferred. The README does not document the log file path, so check the documentation site rather than assuming one.

Installing PSAppDeployToolkit and running a first package

Prerequisites come from the README: Windows 10/11, PowerShell 5.1 or later, and .NET Framework 4.7.2 or later. The README points to three download routes: the getting started guidance on psappdeploytoolkit.com, the PowerShell Gallery, and GitHub Releases. The README itself does not print an Install-Module command, so treat the Gallery listing as the entry point and follow the getting started guidance for the exact steps.

The documented way to start a package is to generate a template. The 4.2.0-rc1 notes say New-ADTTemplate can produce an entire deployment package in a single command by specifying session properties, config, assets, files and script blocks. The older path, generating a ZeroConfig variant, is still available and is the one the release notes spell out with a parameter.

New-ADTTemplate -ZeroConfig

The generated package contains the Invoke-AppDeployToolkit.ps1 script. That is where your install, uninstall and repair logic goes, calling toolkit functions rather than raw executables. Two functions named in the release notes are worth knowing early: Show-ADTInstallationPrompt, which now supports secured text inputs and dropdown selection boxes, and Show-ADTInstallationRestartPrompt, which now supports a cancel button. For testing before you touch a real machine, the release notes state that -WhatIf support was added throughout the module, and the same notes list -WhatIf as a parameter available on toolkit functions generally.

The examples/ directory is the fastest way to see a complete package. It contains VLC and WinSCP folders you can read alongside the documentation, plus a multi-session installation example and a launching example. Read those before writing your own script from scratch.

Where PSAppDeployToolkit is the wrong tool

The framework assumes a Windows desktop that a user may be sitting in front of. If your fleet is Windows Server Core, Linux or macOS, stop here. The README lists Windows 10/11 only, and there is no indication of a cross-platform path.

A second boundary is the silent deployment case. If every application you ship installs without prompts, deferrals or restarts, the user interface and interaction functions are dead weight. A plain MSI with correct exit codes in Intune or ConfigMgr works, and adding a wrapper adds a layer to debug. The toolkit earns its place when the installer is not well behaved.

Version churn is a real cost. The latest release is 4.2.0-rc1, a release candidate published on 2026-08-20, and it includes a refactor of the code base, a replaced WPF library (iNKORE replaced by Fluence), and a changed default template. The previous stable line is 4.1.8 from 2026-01-14. Anyone with packages written against 4.1.x should expect to check their scripts against 4.2 before upgrading, particularly if they relied on ZeroConfig being present in the default template.

Finally, the LGPL-3.0 licence matters for organisations that repackage or embed code. LGPL is a copyleft licence with a linking exception for some uses, and the repository ships COPYING.Lesser at the root. That is a signal to route through your own legal review rather than treating the toolkit as public domain.

PSAppDeployToolkit compared with plain Intune or ConfigMgr scripting

The obvious alternative is not another framework. It is doing the work directly: an Intune Win32 app or a ConfigMgr application whose install command is msiexec or a vendor setup.exe, with detection rules and return-code mapping configured in the console. That approach has real advantages. There is nothing extra to learn, nothing extra to ship, and the management console already reports success and failure.

The difference in approach is where the logic lives. With plain Intune or ConfigMgr, prompts, deferrals and restart coordination are either absent or assembled by hand inside the install script. With PSAppDeployToolkit, they are functions with documented behaviour, and the toolkit's own workflow decides order of operations. The trade is control for consistency: you get a prescriptive flow and a shared user experience across every package, and you give up some freedom in how each package behaves.

A second alternative is a packaging tool that generates the wrapper for you. Those tools vary in what they expose when something fails, and this article does not evaluate them. What can be said from the repository is that PSAppDeployToolkit is open source under LGPL-3.0, the module is published on the PowerShell Gallery, and the source, tests and example packages are all in the repository. If auditability of the wrapper matters to you, that is the relevant difference.

The toolkit is also not tied to one management system. The README names Intune, ConfigMgr, Tanium and BigFix, and the topics list includes ConfigMgr, Intune, SCCM and OSD. If you run more than one of these, a single wrapper skill set transfers between them.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-28, the same day as the most recent activity recorded here. That is a current repository, but it does not tell you which release is safe to run in production. The release list does: 4.1.8 on 2026-01-14 and 4.1.7 on 2025-10-21 are the stable points, while 4.2.0-rc1 on 2026-08-20 is explicitly a release candidate.

Upgrade cost is concentrated in the 4.2 line. The release notes describe refactoring across the code base, replacement of the WPF library with Fluence, removal of ZeroConfig from the default template, and a new capability for New-ADTTemplate to generate a full package. Packages built on 4.1.x will not necessarily behave identically. The -WhatIf support added throughout the module is the practical mitigation, because it lets you exercise a script without making changes.

Tooling expectations are also visible in the repository. The 4.2.0-rc1 notes list CodeQL, Meziantou.Analyzer, Microsoft.CodeAnalysis.BannedApiAnalyzers, Microsoft.Extensions.StaticAnalysis and Roslynator.Analyzers, plus Pester tests updated for Pester v6. That is a heavier engineering setup than most PowerShell projects carry, and it implies contributors need to run build.ps1 and pester.ps1 rather than editing scripts in place.

On licensing, LGPL-3.0 applies to the project. Whether your use triggers obligations depends on whether you distribute modified versions or link against the libraries, which is a question for your legal team. The COPYING.Lesser file at the repository root is the authoritative text.

Editorial conclusion

Adopt PSAppDeployToolkit if you already deliver software through Intune, ConfigMgr, Tanium or BigFix and your installers need prompts, deferrals, restart handling and a single log file. Do not adopt it if you only need silent MSI installation with no user interaction, because the toolkit's value is the wrapper, not the installer. Before rolling it into production, verify that your target machines run Windows 10/11 with PowerShell 5.1 and .NET Framework 4.7.2 or later, and confirm which functions your scripts use still exist in the 4.2.0-rc1 release candidate, since the module was refactored and the default Invoke-AppDeployToolkit.ps1 template changed.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. PSAppDeployToolkit/PSAppDeployToolkit on GitHub
4. README
5. Releases