.png?width=1600&height=900&name=PSAppDeployKit_FeaturedImage%20(1).png)
Many organizations use the PSAppDeployToolkit (PSADT) as a wrapper to standardize deployments, create consistency in branding, and provide a predictable user experience. And while that's a perfectly valid use case, it only scratches the surface of what it is capable of doing.
When used to its full potential, PSADT helps simplify complex customization needs that often arise during enterprise application packaging. Rather than writing one-off scripts or embedding logic into fragile repackaged setups, it provides a structured, supported framework for executing tasks in a maintainable way.
In this article, I’ll highlight some of the most common customization requests we see and how PSADT provides simple, often built-in ways to address them.
Customization examples and toolkit-based solutions
Below are real-world customization needs I've discussed with customers, and how the PSADT compares to repackaging in its ability to address them effectively. At the bottom, you'll find some notable enhancements to PSADT 4.1 that you should consider.
| Customization | Supported via Repackaging | Supported via PSADT | Notes |
|---|---|---|---|
| Scheduled Task Creation | No | Yes | Use schtasks.exe via Start-ADTProcess, with uninstall logic scripted. |
| Permission Changes (Files/Folders/Registry) | Yes* | Yes | Use Set-ADTItemPermission. More reliable than MSI tables. |
| Kill Process Before Install/Uninstall | No | Yes | Use CloseProcesses in Show-InstallationWelcome, or Stop-Process. |
| Remove Files and Folders | Yes | Yes | Use Remove-ADTFile, Remove-ADTFolder. Better than capturing deletions. |
| Register/Unregister DLLs or OCXs | Yes | Yes | Use Register-ADTDll, Unregister-ADTDll, or Start-ADTProcess with RegSvr32.exe. |
| Start/Stop Services | No | Yes | Use Stop-ADTServiceAndDependencies, Start-ADTServiceAndDependencies. |
| Driver Installation | No | Yes | Use Start-ADTProcess with dpinst.exe or pnputil.exe. Not recommended inside MSI. |
| Environment Variable Changes | Yes | Yes | Set registry values for HKLM\SYSTEM\... or HKCU\Environment. |
| Certificate Management | No | Yes | Use Import-Certificate or Remove-Item. Not recommended, but possible. |
| Active Setup Key Handling | Yes* | Yes | Use Set-ADTActiveSetup with disable/purge as needed. |
| INI File Edits | No | Yes | Use Set-ADTIniValue. Avoid capturing changes to existing INI files. |
| Registry Edits | Yes | Yes | Use Set-ADTRegistryKey, Remove-Item, Set-Item. |
| ODBC Configurations | No | Yes | Use registry edits or external scripts. |
| Real-Time Install Decisions (e.g., process detection) | No | Yes | Use Get-Process, condition logic in script. |
| Language-Based Installation Logic | No | Yes | Use $currentLanguage variable for conditional logic. |
| Hosts File Updates | No | Yes | Edit using PowerShell; not recommended for packaging. |
| Firewall Rule Add/Remove | Yes* | Not natively | Use PowerShell scripts; App Readiness offers built-in support. |
| Very Large Package Handling | No | Yes | Host MSI externally, bypassing internal CAB limits. |
| Group Policy-Based Configuration | No | Yes | PSADT 4.1 can deploy ADMX/ADML policies to override toolkit behavior centrally. |
| System context UI without ServiceUI | n/a | Yes | In PSADT 4.1, UI dialogs now run securely in session, even when deployed as SYSTEM—no ServiceUI needed. |
| Process control (timeout, child process cleanup) | n/a | Yes | In PSADT 4.1, you may use parameters like -WaitForChildProcesses, -KillChildProcessesWithParent, -Timeout, etc. |
*These items are not typically handled when repackaging, but App Readiness provides specialized support for these customizations.
Why this matters
Most of these scenarios don’t justify the overhead or fragility of repackaging. Leveraging PSADT gives you the structure and logic support needed to manage them cleanly, outside of the MSI layer. The result? Faster delivery, more reliable installs, and easier maintenance.
While much of this could technically be accomplished by authoring a Windows Installer setup with custom actions, doing so is both more complex and significantly harder to maintain. Whereas PSADT provides built-in functions that reduce the amount of scripting required and, more importantly, give you a path to reuse.
With traditional repackaging, each new application version requires a full uninstall before upgrade, meaning all custom actions must be rebuilt and revalidated with every release. By contrast, it lets you define conditional logic—“if application is 'My Tough Application', then do these things”—that stays in place across versions. As long as the command-line installation remains stable (which it typically does), your wrapper script remains valid and low-maintenance.
If you’re using it just for branding and user prompts, consider taking it further. The built-in functions cover most enterprise customization scenarios—and in many cases, they’re easier to use and maintain than a repackage or hand-coded script.
Finally, PSAppDeployToolkit continues to evolve in compelling ways. Recent 4.x releases bring meaningful enhancements that align closely with our customization framework. V4 introduced a modern Fluent UI, full PowerShell 7 and ARM support, WIM handling, and extended backwards compatibility. Version 4.1 removes the need for the legacy ServiceUI, adds advanced process control parameters (like -WaitForChildProcesses and -KillChildProcessesWithParent), and now supports management via Group Policy with ADMX templates, environment variable and INI manipulation, and enhanced UI interactivity. These upgrades make it even easier to maintain reusable, sophisticated deployments that scale over time.
Templates out of control?
Occasionally, I hear concern about managing PSADT wrappers for a large portfolio of packages. What they often fail to realize is that you don't need individual scripts but can rather manage any and all application customizations in a single template. By wrapping all setups with a common PSADT template, you have a single place to insert any customizations with a simple condition (for example, if the application name is "Adobe Reader," then add these Adobe Reader customizations).
For more packaging recommendations, check out our App Readiness documentation.
As the founder of AppDeploy.com, I can’t help but smile when I see "AppDeploy" bolded in the PowerShell App Deployment Toolkit name. While they didn’t run it by me, I’m glad to see the legacy of packaging-focused community contributions live on in new tools like it.
Topics:
