When you need to deploy an app across endpoints, Intune on its own may not be enough. While Intune can install a vendor’s MSI or EXE silently, it can’t ask a user to close an app first or let them postpone installations. In these cases, using PSADT with Intune is necessary.
However, PSADT v4.1 changed how the toolkit works with Intune, and the old ServiceUI.exe workaround is no longer needed. As such, many IT teams need to refresh how they use PSADT with Intune.
With that in mind, let’s explore how to deploy a PSADT package with Intune, how restart prompts and deferrals behave during the installation, and fixes you can use for common failures.
What is PSADT?
The PowerShell App Deployment Toolkit (PSADT) is a free, open-source PowerShell framework that standardizes how software is installed on Windows devices. This toolkit takes MSI or EXE installer packages and adds consistent install, uninstall, and repair workflows, along with user prompts and a library of functions for common tasks.
Inside a PSADT v4 deployment folder, you’ll find:
Invoke-AppDeployToolkit.ps1: This is the deployment script, which holds the install, uninstall, and repair logic that will be used throughout the installation process.
Invoke-AppDeployToolkit.exe: This is the launcher that runs the script.
Files and SupportFiles: These files include the vendor installer and anything else it may need, such as .reg files or transforms.
Config and Strings: These are the toolkit settings and text that users will see in prompts.
Assets: Visual assets such as the icon or company logo shown in prompts.
PSAppDeployToolkit: This is the module itself, which comes packaged with the app so the device doesn't need it installed.
When PSADT runs the deployment script, it’ll be run in three phases: pre-install, install, and post-install. This allows admins to close apps before installation begins and write a detection marker to determine it’s successfully completed. The toolkit can also find and install plain MSIs without script changes, referred to as “zero-config deployment.”
What changed in PSADT v4 for Intune deployments
PSADT v4 introduced several changes IT teams should know about so they don’t use outdated commands.
From v3 to v4
When PSADT was updated to v4, there were a few key changes. Deploy-Application.ps1 and Deploy-Application.exe were replaced by Invoke-AppDeployToolkit.ps1 and Invoke-AppDeployToolkit.exe. Functions also carry an ADT prefix, such as “Show-ADTInstallationWelcome.” Additionally, deployment settings live in a session object, rather than the global variables v3 used.
However, existing v3 scripts can still run through a v3 compatibility template. As such, teams won’t need to rewrite their entire script library to use them for PSADT v4.
What v4.1 changed for Intune
PSADT v4.1 also changed how the toolkit interacts with Intune. For example, prompts now appear in the user’s session when Intune runs the install as SYSTEM, so the toolkit no longer includes the ServiceUI helper. PSADT also advises against using ServiceUI to run an installer interactively, since a user could use its dialogs to reach the system account.
Additionally, the toolkit now shows prompts when a user is logged on, but switches to silent when no one is logged on, during Autopilot, or when none of the apps the package needs to close are running. There’s also a new deferral setting built for Intune (-DeferRunInterval), which stops users from being prompted again too soon after they defer.
One small but significant change is how restart codes pass through. Now, the template exits with 3010 when an install needs a restart, although this can be masked with -SuppressRebootPassThru.
How to deploy a PSADT package with Intune
When you want to deploy a PSADT package with Intune, there are a few steps you’ll want to follow. This may seem like a complicated process, but approaching it one step at a time makes it far easier:
Build the deployment folder: Start by using the PSAppDeployToolkit module from the PowerShell Gallery and the v4 template. From there, put the installer in Files (our guides to MSI silent installs and EXE silent installs cover the switches each installer type needs), and add install and uninstall logic to Invoke-AppDeployToolkit.ps1. Don’t forget to list any apps that must be closed in AppProcessesToClose, although zero-config can skip these script edits for a single MSI.
Test it locally first: Make sure you test the package before deploying it broadly. Run Invoke-AppDeployToolkit.exe from an elevated prompt and run the uninstall (remember: the launcher won't prompt for elevation on its own). Afterward, check the toolkit log, which goes to C:\Windows\Logs\Software by default.
Wrap the folder as an .intunewin file: If the test checks out, you can run the Content Prep Tool on the whole deployment folder with Invoke-AppDeployToolkit.exe as the setup file. For example, this may look like
IntuneWinAppUtil.exe -c C:\Packages\YourApp -s Invoke-AppDeployToolkit.exe -o C:\Output.Create the Win32 app and set the commands: From there, you can start setting the commands. For the install command, use
Invoke-AppDeployToolkit.exe -DeploymentType Install. The uninstall command can be set withInvoke-AppDeployToolkit.exe -DeploymentType Uninstall, and the install behavior uses System. You’ll want to leave DeployMode off the command line so it can be determined automatically. For per-user apps, you can set the install behavior to User and set RequireAdmin to $false.Check the return codes: Be sure to check the return codes to make sure everything works. Intune's defaults are 0 for success, 3010 if a soft reboot is required, 1641 for a hard reboot, and 1618 if you need to retry. PSADT's deferral code, 1602, isn't in this list by default, so decide how Intune should treat it (see the deferral section below).
Add a detection rule: PSADT leaves detection to Intune, so you’ll want to add the rule yourself. You can use an MSI product code, a file version, or a registry value written in the post-install phase to detect if the app is properly installed.
Test with a pilot group before a required rollout. Don’t deploy the app without testing it on a small but representative group of devices first. You can assign the app as Available to a small group so testers can install it from Company Portal, then switch to Required once you can confirm that it installs, detects, and uninstalls cleanly.
How PSADT deferrals and restart prompts work in Intune
While installing and updating apps is important, employees don’t like being interrupted in the middle of the day with a prompt to install an update. As such, PSADT lets users defer an install to a more convenient time, and Intune decides when the install runs again.
How to let users defer an install
Deferral is set with Show-ADTInstallationWelcome. Its AllowDefer parameter turns on the defer button, and DeferTimes sets how many times a user can defer (the v4.1 template allows three), so an install can’t be pushed back indefinitely. Admins can also set a countdown that closes apps automatically.
When the installation is deferred, the script will exit with code 1602 by default. Intune will record the install as canceled by the user, so it will try again after some time has passed.
When users see the prompt again
Deferrals don’t set a precise timer between prompts, since Intune decides when to rerun the install. PSADT’s DeferRunInterval setting stores the time of the deferral and quietly exits any rerun that comes too soon.
When Intune receives a 1602 code, you can leave it as a failure, in which case Intune will reattempt the install on its own schedule. However, you can also set defer codes to 1618 or map 1602 to Retry, in which case Intune will retry the installation every five minutes, up to three times. The latter option can cause users to receive prompts too close together, leading them to defer repeatedly only to receive the prompt again minutes later. Setting DeferRunInterval prevents this, since PSADT exits quietly until the interval has passed.
How to handle restart prompts
When an install needs a restart, PSADT 4.1 will pass the 3010 code back to Intune. From there, Intune will use the device restart behavior setting on the Win32 app to determine what happens. For instance, a soft reboot code will notify users that they need to restart, while a hard reboot code can automatically reboot a device or schedule a restart.
Additionally, PSADT has a restart prompt that includes a countdown: Show-ADTInstallationRestartPrompt. This will notify users that a restart is imminent so they can save and close their files before the reboot.
While either option works well for restart prompts, you should consider what’s most convenient for your teams and pick one. Using both Intune and PSADT for restarts can prompt users multiple times for the same reboot.
Why PSADT deployments fail in Intune and how to fix them
PSADT deployments can still fail for several reasons, but most have a clear cause and fix. Common failures include:
1. A deferral shows up in Intune as a generic failure
If you use powershell.exe to call the script without -File, the script’s exit code won’t be passed back. As a result, a 1602 deferral can reach Intune as exit code 1, a generic failure. To avoid this, you can use Invoke-AppDeployToolkit.exe or simply add -File to the command.
2. The app fails with error 60008
This error means the toolkit module failed to load or the session failed to open. In this case, check the toolkit log to identify the cause and adjust accordingly.
3. Users don't see any prompts
When you have DeployMode set to Auto, users won’t always see prompts. If no one is logged in, the device is in Autopilot, or none of the apps that must be closed are running, the toolkit runs silently by design. If prompts are missing outside of those situations, check that the package uses PSADT v4.1 or later, since earlier versions can’t show prompts from Intune without ServiceUI.exe.
4. Installs during Autopilot run without any user interface
When installs run without a user interface on Autopilot, this would be because the toolkit detects the out-of-box experience and Enrollment Status Page and suppresses prompts. If you want to show prompts, you can set NoOobeDetection in the session properties.
5. Logs are hard to find next to Intune's
To keep the toolkit’s logs next to Intune’s, set Toolkit.LogPath in config.psd1 to the Intune Management Extension log folder. You can then pull both sets of logs with Collect diagnostics from the Intune admin center.
How Splashtop Agentic Packr automates PSADT packaging for Intune
Deploying apps with PSADT and Intune can be a lengthy process when done manually. Every app needs its own script, testing, wrapping, commands, and so on, and this process must be repeated with every new version. However, it doesn’t have to be that way.
Splashtop Agentic Packr is an AI-powered application packaging and lifecycle automation platform that reduces the manual work of packaging each app. It builds its packages on PSADT, so admins can open, review, and adjust them before approving.
Packages built and tested for you
Splashtop Agentic Packr’s AI agent reads the installer, builds the PSADT package, and writes detection rules automatically. It then tests the package on a clean virtual machine, runs a security scan, and reports everything on a QA scorecard for admins. Admins review the scorecard and logs and approve each package before it’s published to Intune.
Published to Intune and kept current
Once Splashtop Agentic Packr builds and publishes the Intune package, it can automatically detect new app versions when an update is released. Once it detects an update, it automatically builds new packages so the latest version of the app can be tested and deployed.
User prompts set once and reused
Splashtop Agentic Packr lets you create reusable templates to set notifications, deferrals, restart prompts, company branding, and more. This helps ensure that each app follows the same process, so every app gives users the same experience.
Deploy PSADT apps with Intune without rebuilding every package
PSADT gives Intune admins control over several aspects of the installation process, even more so now with PSADT v4.1. However, scripting, testing, and detection for each app package can be time-consuming, especially when you have to repeat the process for every new version.
With Splashtop Agentic Packr, you can build, test, and publish PSADT packages to Intune with far less manual work. Splashtop Agentic Packr speeds up the packaging process without sacrificing testing or security, and admins can review each package so they have the final say on every app deployment. Your team spends less time packaging and more time on the work that needs them.
Want to learn more about Splashtop Agentic Packr? Check it out today.
