App deployment toolkit

App deployment toolkit DEFAULT


c 2020 All rights reserved.

Package Details


Version History

VersionDownloadsLast updated
3.8.4 2,611 3/4/2021
3.8.3 992 10/14/2020 (current version) 210 8/7/2020
3.8.2 15 8/7/2020

PowerShell App Deployment Toolkit Logo PowerShell App Deployment Toolkit

What is the PowerShell App Deployment Toolkit?

The PowerShell App Deployment Toolkit provides a set of functions to perform common application deployment tasks and to interact with the user during a deployment. It simplifies the complex scripting challenges of deploying applications in the enterprise, provides a consistent deployment experience and improves installation success rates.

The PowerShell App Deployment Toolkit can be used to replace your WiseScript, VBScript and Batch wrapper scripts with one versatile, re-usable and extensible tool.

What are the main features of the PowerShell App Deployment Toolkit?

  • Easy To Use - Any PowerShell beginner can use the template and the functions provided with the Toolkit to perform application deployments.
  • Consistent - Provides a consistent look and feel for all application deployments, regardless of complexity.
  • Powerful - Provides a set of functions to perform common deployment tasks, such as installing or uninstalling multiple applications, prompting users to close apps, setting registry keys, copying files, etc.
  • User Interface - Provides user interaction through customizable user interface dialogs boxes, progress dialogs and balloon tip notifications. Supports completely silent script execution as well.
  • Localized - The UI is localized in several languages and more can easily be added using the XML configuration file.
  • Integration - Integrates well with System Center Configuration Manager(SCCM); provides installation and uninstallation deployment types with options on how to handle exit codes, such as supressing reboots or returning a fast retry code. The toolkit also supports logging in CMTrace-compatible format.
  • Updatable - The logic engine and functions are separated from per-application scripts, so that you can update the toolkit when a new version is released and maintain backwards compatibility with your deployment scripts.
  • Extensible - The Toolkit can be easily extended to add custom scripts and functions.
  • Helpful - The Toolkit provides detailed logging of all actions performed and even includes a graphical console to browse the help documentation for the Toolkit functions.

System Requirements

  • Powershell 2.0+
  • .NET Framework 3.5+


-> Homepage
-> Community Forums
-> Releases
-> Screenshots
-> About Us


The PowerShell App Deployment Tool is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

  1. Solo springer seat
  2. Autozone seat covers
  3. Motorcycle key rings

Version 3.8.4 [26/01/2021]

  • Fixed Boolean parameters not being passed to Execute-Process
  • Changed Show-InstallationWelcome:
    • Buttons are now wider
    • Listbox is also wider so it is aligned with buttons
    • Countdown is now bigger and in bold
    • Appname is now in bold to be more visible
    • Function now internally closes processes by name not by ID
    • Fixed the hidden abort button not working on toolkit timeout
    • Performance improvements
  • Changed Show-InstallationPrompt:
    • Fixed the hidden abort button not working on toolkit timeout
    • Buttons are now identical in size and position to the ones in Show-InstallationWelcome
    • Increased the gap between the banner and the text when the message is too short
    • The function now doesn't call Close-InstallationProgress when running in async mode
  • Changed Show-InstallationRestartPrompt:
    • Reworked the window to look consistent with Show-InstallationWelcome
  • Changed Show-InstallationProgress:
    • Reworked the window to look consistent with Show-InstallationWelcome
    • Function now logs when it is being bypassed due to Deploy Mode
  • Changed Set-ActiveSetup:
    • Fixed an issue where the function was adding executed active setup registry key when -ExecuteForCurrentUser $false was specified
    • Function now checks the Active Setup registry key to evaluate whether to execute the StubPath based on the IsInstalled property
  • Fixed typo in Stop-ServiceAndDependencies saying "start" instead of "stop"
  • Fixed the toolkit checking task scheduler services twice
  • Fixed the toolkit not creating $app variables if they are not created in Deploy-Application.ps1
  • Reworked Close-InstallationProgress so it waits a couple of seconds in case the window is not opened yet
    • This fixes an issue where the Show-InstallationProgress dialog would not get closed on slower machines where Close-InstallationProgress was called right after Show-InstallationProgress
    • Function now gets bypassed in Silent Deploy Mode
  • Changed Execute-ProcessAsUser:
    • The function now escapes invalid xml characters prior to using them in a xml file
  • Fixed signatures for a couple of functions inside AppDeployToolkitMain.cs based on official documentation - No breaking changes
  • Performance improvements across the toolkit
  • Fixed a bug in Set-ItemPermission where SID translation did not work correctly
  • Changed Show-BalloonTip:
    • Function Show-BalloonTip now logs when it is being bypassed
    • Added parameter -NoWait for asynchronous execution
    • The icon tooltip now contains Title - Text
  • Fixed an issue where $envLogonServer would start with backslashes
  • Fixed an issue where some global variable did not get cleared on exit
    • This caused an issue if you ran multiple toolkits in the same powershell session. It would use the same log file for all toolkits.
    • This only occured if you used the .ps1 files directly. Deploy-Application.exe opens a new session each time.
  • Added function Set-Shortcut that allows you to change existing shortcuts
  • Added function Get-Shortcut to retrieve information from a shortcut
  • Changed New-Shortcut:
    • BREAKING CHANGE: IconIndex parameter is now an Integer. It was previously incorrectly specified as a String.
    • Reworked the way this function sets shortcut to run as admin
    • Added additional checks for the input Path in order to provide better log messages and better handling of relative paths
    • Improved function help text
  • Changed the way Execute-MSI handles paths for Transforms and Patches:
    • The only accepted separator is now a semi-colon. Commas can be a part of the paths now.
    • Double quotes are removed from the paths before the entire string is wrapped in double quotes.
  • Encoding of the files has been changed back to UTF8 with BOM, back from UTF8 without BOM:
    • We chose to go with UTF8 without BOM because it is the encoding for Powershell v6+ and because it is one of the most popular encodings in the world.
      However this caused issues on Windows Powershell for clients that use a different language from English. Due to Microsoft's chaotic coding decisions, Powershell uses the BOM as a verification that the code is written with non-English characters.
      In their own words:"It's not possible to force PowerShell to use a specific input encoding. PowerShell 5.1 and below, running on Windows with the locale set to en-US, defaults to Windows-1252 encoding when there's no BOM.
      Other locale settings may use a different encoding. To ensure interoperability, it's best to save scripts in a Unicode format with a BOM."
    • Just like changing to UTF8 without BOM, this will not affect the size of the files or their functionality. BOM or Byte Order Mark is just one special character, placed at the start of the files.
      If you do not use the toolkit on machines with a different language, then this will have no effect on you or your clients. It will however help everyone else display the text in their language correctly.

Installing Applications with PowerShell App Deployment Toolkit - Part 1

on PowerShell, PSADT

This is Part 1 in a 2-part series.

For over a year now, I’ve been the primary software administrator for our organization’s SCCM infrastructure. This means I’ve been responsible for integrating software installs in our workstation build process, but I’ve also had to deal with the issue of deploying and updating software on end-user workstations.

Administering software deployments presents a unique set of challenges:

  • I need the ability to perform a fully automated, silent install. If I have to click a “Next” button once on an installation welcome, license agreement, or confirmation dialog, then someone will need to be able to click the “Next” button each time the software is installed on a new workstation or server.
  • I often need the ability to perform post-install configuration. For example, I need the ability to disable Java’s automatic updates so our updates can be centrally managed.
  • I need a flexible logging framework so that when things go wrong (not if, but when), I know exactly where to look to find out more information on what happened.
  • If applications or updates need to be deployed while a workstation is in use, I need the ability to display an informative message to the user that they can easily understand, while preventing them from accidentally interrupting the install (or starting an application while it’s updating).

It seems pretty obvious that we’ll need the ability to make decisions specific to each applicion, but it also seems like we’ll need a single set of tools available to us for software installations.

The PowerShell App Deployment Toolkit is a free toolkit that provides some answers to these challenges. It also helps to prevent re-inventing the wheel each time a new application needs to be deployed. The toolkit is designed for ease of use with solutions such as SCCM, but it’s easily usable with other configuration management solutions such as MDT, Chef, or even PowerShell’s own DSC.

There is some documentation provided with the toolkit, but I’ve heard from some people that actually writing their first installation is a daunting task. Let’s dig in and create a simple scripted install!

We’ll use Mozilla Firefox as an example, since it’s a pretty simple program to package, but also a program that’s pretty commonly deployed.

Downloading files

Download the latest version of the toolkit and extract it. We’ll want to maintain a “clean” copy of these files so we can copy them into future builds.

Check out everything packaged in the download:

  • The Toolkit directory contains the actual files in the toolkit. We’ll copy this directory each time we need to create a new install.
  • The Examples directory provides a couple of examples of toolkit uses - Adobe Reader and Office 2013. These are great for getting a better idea of how the toolkit works.
  • A changelog file.
  • And finally…a Word document, PSAppDeploymentToolkitAdminGuide.docx. This provides all the documentation on the functions included in the toolkit. This will be your best friend as you reference the functions in the toolkit!

We’ll also need to download the Firefox setup file. Be sure to download the one from this page, and not the one from the Firefox homepage; that file is a “stub” installer that downloads the real setup files in the background. Stub installers are often difficult to script.

Preparing the environment

Copy the contents of the folder into a new working directory:

You should now have a directory with three folders and three files. In some cases, either the Files or the SupportFiles directories are missing; if so, feel free to create them. Your work directory should look like this:

You should have a folder called AppDeployToolkit, a folder called Files, and a folder called SupportFiles.

Let’s talk about these files and folders for a moment.

  • The AppDeployToolkit directory is where the “guts” of the toolkit live. Inside this folder is an XML file with a lot of configurable preferences for how the toolkit behaves, an ICO image used when the toolkit runs, a PNG banner image which can be customized to “brand” the toolkit, and three PS1 script files which contain the actual toolkit logic.
  • The Files directory is the directory where the setup files belong. If you have a single setup.exe file or MSI installer, those files should be placed in this directory. If you have a large install that requires a lot of files (think Microsoft Office), all of those files go in here, too.
  • The SupportFiles directory is an extra directory which can be used for configuration files, post-install settings, and anything extra you may need. I’ve used this for small utility programs to clean up old versions of applications, for example.
  • Deploy-Application.ps1 is the file we care the most about. This is the PowerShell script we will modify to contain the actual install logic (“run this setup file with thees arguments”). In most cases, this is the only script you will need to modify to make your application work correctly.
  • Deploy-Application.EXE is a small EXE file which basically invokes the PowerShell script. This is provided as a convenience, so you don’t need to invoke (plus any additional parameters to the script) in order to start the install.

Copy the downloaded Firefox file from your Downloads folder to the Files directory inside the toolkit:

Now for the fun part: it’s time to write some PowerShell. Open Deploy-Application.ps1 in the ISE.

Defining some variables

At the very top of the Deploy-Application.ps1 script, you’ll see a great example of comment-based help. The first couple of things we need to change are the application variables - the constants that define what program we’re using. At about line 58, you’ll see a block that looks similar to this:

Edit these variables to reflect an installation for Mozilla Firefox:

After setting those variables, we can scroll down a bit more, until we see a comment block:

Look at the Show-InstallationWelcome line in this section. There are a lot of things we can configure here, but left as the default, this line will produce a GUI pop-up that looks like this:

A window will prompt you to close Internet Explorer or defer the installation.

Forcing users to close Internet Explorer doesn’t really make much sense when we’re trying to install Firefox. On the other hand, it would be helpful if we could require users to close any existing version of Firefox before we attempt to upgrade the program, in order to prevent any problems with files in use. Fortunately, this is simple to do with the toolkit by replacing the -CloseApps parameter:

There are plenty of other things we can customize in this screen, but the default options will do the job nicely for now.

A word on deployment modes

Showing a welcome message and prompting users to close apps doesn’t exactly qualify as a fully silent install, especially when the user must click one of the buttons in the dialog in order to proceed with the installation. One parameter for the function allows you to specify a “countdown” until the applications in question are forcibly closed, but that still doesn’t address the root issue.

Fortunately, the toolkit offers a concept called deployment modes which solves this problem nicely. There are three different deployment modes in which the install can be run:

  • Interactive - All dialog messages will be displayed. This is the default in mast cases.
  • Silent - No dialog messages will be displayed during setup, but some important windows may still be displayed (such as the welcome dialog prompting the user to close applications).
  • NonInteractive - “very silent,” with no blocking apps.

The toolkit contains a bit of logic to automatically detect when it is run from a SCCM task sequence, but in general, it’s best to specify the deployment mode at the command line if you’d like a specific mode to be used. I find Silent not to be very useful, so I tend to either not supply a deployment mode or set it to NonInteractive. The Show-InstallationWelcome function immediately checks to see if the deployment mode is NonInteractive, and if so, it does not display a blocking message.

Running the Firefox setup file

We’re done with the Pre-Installation phase for now, so scroll down a bit further in the script to the Installation phase. Underneath the comment labeled , we’ll need to tell our script to actually run the Firefox installation.

Finding the silent path

Wait a moment…how do we install Firefox without requiring the user (or tech) to click Next, Next, Next…Finish?

Unfortunately, there’s no silver bullet for performing a silent install. You’ll need to spend a bit of time researching the individual software in question to find out what options its installer supports. In this case, I was able to search Google for the phrase “Firefox silent install” and the top search result was exactly what I was looking for: a page on listing command-line arguments for the Firefox install. A quick glance at that article leads to this segment:

Silent install (always installs into the default location. Use the “Configuration ini file” option below to set the install location and other install options):

Silent uninstall:

Configuration ini file:

When specifying a configuration ini file the installer will always run silently. When specifying a Configuration ini file other command line switches should not be specified and may have unexpected results

That’s exactly the information we were looking for!

Performing the install

Using PowerShell alone, there are a few different ways we could start a setup file with arguments (Start-Process, Invoke-Expression, using the WMI method Win32_Process.Create(), or even just typing the filename). These methods will all work just fine - this is still PowerShell, after all - but they don’t take advantage of the features available to us in the toolkit. Instead, let’s use a toolkit method called to start our setup:

(Astute PowerShell fans will note that Execute is not an approved PowerShell verb. This is quite true, and technically, the team behind the PowerShell App Deployment Toolkit should probably rename both this function and its sibling, Execute-MSI. However, since this is a script toolkit rather than a general-purpose module, it’s not the end of the world. The toolkit is also thoroughly documented to make sure that these functions are visible.)

What does this function give us that native PowerShell does not?

  • Easy access to the Files subdirectory without worrying about working directories.
  • Ability to transparently ignore errors using -ContinueOnError if desired, or only ignore specific error codes using -IgnoreExitCodes
  • In-depth logging, even attempting to capture the standard output of the process in some cases
  • Error checking for common error codes from msiexec and wusa

Since our Firefox setup file is within the Files directory of the toolkit, we don’t need to specify the working directory or even the full path to the setup file. The Execute-Process function takes care of all of this for us.

Believe it or not, that’s all we need to do! If you run the Deploy-Application.EXE as an administrator, Firefox will be installed on your system, with no required user interaction except the welcome window. We’re not done yet, though - this toolkit offers the ability to script an uninstall just as easily, and in many cases it’s helpful to be able to uninstall an application silently as well.

Adding an uninstall

In the Deploy-Application.ps1 script, scroll down to the section. You’ll notice another function, so go ahead and change the CloseApps parameter from to again. Here’s an example of the CloseAppsCountdown parameter; this will force Firefox to close after 60 seconds if no options are selected. Personally, I prefer to change this to something a bit higher, like 180 seconds (3 minutes).

Scroll a little further down, to the section. Underneath the comment labelled , we’ll add the command to trigger an uninstall of Firefox.

The argument is again taken from the Mozilla article we found earlier. As it turns out, we can use the same file to uninstall Firefox as we can use to install it, and it supports a silent uninstallation as well.

Now, we can uninstall Firefox using the same Deploy-Application.EXE using an argument on the command line:

If the installation (or the uninstallation) didn’t work as expected, it’s time to look at the log files. By default, these are saved at C:\Windows\Logs\Software, but this path can be changed in the config XML file located within the AppDeployToolkit folder.

The name of the log file generated is based on the application variables we declared at the very beginning. In this case, we’re looking for either Mozilla_Firefox_37.0.1_x86_EN_01_PSAppDeployToolkit_Install.log or Mozilla_Firefox_37.0.1_x86_EN_01_PSAppDeployToolkit_Uninstall.log, depending on whether we’re troubleshooting an install or an uninstall. Open this file up and…whoa!

How do we make any sense out of this mess?

By default, the toolkit writes its log files in a similar format to logs from SCCM. To make sense of these log files, download and install the System Center 2012 R2 Configuration Manager Toolkit. There are several utilities in here useful for troubleshooting SCCM, but the utility we’re interested in right now is a small file called CMTrace. This is a SCCM log file viewer that can parse logs in that format much more easily. Even if you do not use SCCM in your environment, CMTrace will make it much easier to read the log files from this toolkit.

After installing, launch CMTrace.exe (there should be a shortcut in your Start menu), and it will offer to become your default viewer for .log files. After saying yes, re-open the log file left from the toolkit, and you’ll see a much happier sight.

CMTrace makes this log file much easier to parse.

In CMTrace, any log entries which contain keywords such as “error” or “failed” will be highlighted in red. Keywords like “warning” will cause a yellow highlight. Here’s an example of a case when the main Firefox setup file failed with error code 1:

The line in question will read something like, "Execution failed with exit code [1]."

CMTrace, when combined with the extensive logging left by the toolkit, makes it a snap to find out where the installation failed. You can also write additional log entries to these log files using the function of the toolkit, in case you want to extend the logging with your own information.

We’ve now built a fully-functional scripted installation of Firefox. Let’s review the features we’ve got available to us, with just a few lines of code:

  • Automated install and uninstall of Firefox using the same basic framework
  • User prompt to close Firefox if it’s running
  • Verbose logging

The last challenge that we need to deal with is how we can invoke the install on computers, either on demand or en masse. This is out of the scope of this toolkit (it handles software installation, not software deployment), but it does integrate nicely with several different technologies.

To install the application, you can use any of these commands, depending on your needs:

To uninstall the application, these commands will work (note that the Uninstall argument is necessary this time):

I recommend copying the files to a temporary location on the remote computers first, but in theory the toolkit should run over the network just as well. If you do copy them, you’ll need to copy the entire directory (containing AppDeployToolkit, Files, SupportFiles, and the Deploy-Application EXE, script, and config file). Treat the entire directory like a single software package and keep it together wherever you copy it or move it.

Be sure to read through the Word document included with the toolkit download, as it contains a lot of helpful information and references for toolkit functions.

I’m well aware that in the grand scheme of things, Firefox is a pretty easy example of software deployment. I will almost certainly be writing a follow-up to this article with some more chewy examples. In the mean time, though, dig in! Get your hands dirty and try building some deployment scripts on your own. It’s almost always easiest to learn by doing.

Finally, if you have an example of application deployment gone right (or horribly wrong), let us know in the comments!

See you all next time.



Deployment toolkit app


The PowerShell App Deployment Toolkit provides a set of functions to perform common application deployment tasks and to interact with the user during a deployment. It simplifies the complex scripting challenges of deploying applications in the enterprise, provides a consistent deployment experience and improves installation success rates.

Welcome Message

The PowerShell App Deployment Toolkit can be used to replace your WiseScript, VBScript and Batch wrapper scripts with one versatile, re-usable and extensible tool.


  • Easy To Use – Any PowerShell beginner can use the template and the functions provided with the Toolkit to perform application deployments.
  • Consistent – Provides a consistent look and feel for all application deployments, regardless of complexity.
  • Powerful – Provides a set of functions to perform common deployment tasks, such as installing or uninstalling multiple applications, prompting users to close apps, setting registry keys, copying files, etc.
  • User Interface – Provides user interaction through customizable user interface dialogs boxes, progress dialogs and balloon tip notifications.
  • Localized – The UI is localized in several languages and more can easily be added using the XML configuration file.
  • Integration – Integrates well with ConfigMgr (SCCM); provides installation and uninstallation deployment types with options on how to handle exit codes, such as suppressing reboots or returning a fast retry code.
  • Updatable – The logic engine and functions are separated from per-application scripts, so that you can update the toolkit when a new version is released and maintain backwards compatibility with your deployment scripts.
  • Extensible – The Toolkit can be easily extended to add custom scripts and functions.
  • Helpful – The Toolkit provides detailed logging of all actions performed and even includes a graphical console to browse the help documentation for the Toolkit functions.


User Interface¶

  • An interface to prompt the user to close specified applications that are open prior to starting the application deployment. The user is prompted to save their documents and has the option to close the applications themselves, have the toolkit close the running executables, or optionally defer. Optionally, a countdown can be displayed until the applications are automatically closed.
  • The ability to allow the user to defer an installation X number of times, X number of days or until a deadline date is reached.
  • The ability to prevent the user from launching the applications that need to be closed while the application installation is in progress.
  • An indeterminate progress dialog with customizable message text that can be updated throughout the deployment.
  • A restart prompt with an option to restart later or restart now and a countdown to automatic restart.
  • The ability to notify the user if disk space requirements are not met.
  • Custom dialog boxes with options to customize title, text, buttons & icon.
  • Balloon tip notifications to indicate the beginning and end of an installation and the success or failure of an installation.
  • Branding of the above UI components using a custom logo icon and banner for your own Organization.
  • The ability to run in interactive, silent (no dialogs) or non-interactive mode (default for running SCCM task sequence or session 0).
  • The UI is localized in several languages and more can easily be added using the XML configuration file.

Functions / Logic¶

  • Provides extensive logging of both the Toolkit functions and any MSI installation / uninstallation.
  • Provides the ability to execute any type of setup (MSI or EXEs) and handle / translate the return codes.
  • Mass remove MSI applications with a partial match (e.g. remove all versions of all MSI applications which match "Office").
  • Check for in-progress MSI installations and wait for MSI Mutex to become available.
  • Send a sequence of keys to an application window.
  • Perform ConfigMgr (SCCM) actions such as Machine and User Policy Refresh, Inventory Update and Software Update.
  • Supports installation of applications on Citrix XenApp/Remote Desktop Session Host Servers.
  • Update Group Policy.
  • Copy / Delete Files.
  • Get / Set / Remove Registry Keys and Values.
  • Get / Set Ini File Keys and Values.
  • Check File versions.
  • Pin or Unpin applications to the Start Menu or Task Bar.
  • Create Start Menu Shortcuts.
  • Register / Unregister DLL files.
  • Refresh desktop icons.
  • Test network connectivity.
  • Test power connectivity.
  • Check whether a PowerPoint slideshow is running.

SCCM Integration¶

  • Handles ConfigMgr exit codes, including time sensitive dialogs supporting ConfigMgr's Fast Retry feature – providing more accurate ConfigMgr Reporting (no more Failed due to timeout errors).
  • Ability to prevent reboot codes (3010) from being passed back to ConfigMgr, which would cause a reboot prompt.
  • Supports the CM12 application model by providing an install and uninstall deployment type for every deployment script.
  • Bundle multiple application installations to overcome the supported limit of 5 applications in the CM12 application dependency chain.
  • Compared to compiled deployment packages, e.g. WiseScript, the Toolkit utilises the ConfigMgr cache correctly and ConfigMgr Distribution Point bandwidth more efficiently by using loose files.

Help Console¶

  • A graphical console for browsing the help documentation for the toolkit functions.


  • "Truly powerful application deployment toolkit written in PowerShell! Solving some classic problems" – Jörgen Nilsson, Microsoft MVP, Enterprise Client Management
  • "Another very cool SCCM 2012 must have tool – PowerShell App Deployment Toolkit" – Kent Agerlund, Microsoft MVP, Enterprise Client Management
  • "This is really an exceptional Toolkit! It's the swiss army knive for software deployment. For every task you possible need to perform, there is a function for it. And you can extend it with your own functions if you like. Even when you're using something like SCCM to deploy your software, the toolkit can have real value as it fills the gabs left by SCCM. Thanks!" – Quint
  • "Excellent support guys! This toolkit is the best thing around to easily wrap and deploy software to end users and it just keeps on getting better with every release!" – Maarten Pauchet
  • "The PowerShell App Deployment toolkit rocks! I tried it today and love it." – Alex Verboon


The PS App Deployment Toolkit has featured in the following industry conferences:

  • "Become the Hero of the Day – Master ConfigMgr 2012 R2 with a Limited Budget and Free Community Tools" sessions at NIC Conference 2013 and System Center Universe 2014 (Kent Agerlund).
  • "Microsoft System Center Configuration Manager Community Jewels" session at MS TechEd North America 2014 (Jorgen Nilsson, Stefan Schörling) – see video @ 18 mins
  • "Microsoft System Center Configuration Manager Community Jewels" session at MS TechEd Europe 2014 (Jorgen Nilsson, Stefan Schörling) – see video @ 21 mins
Deploy applications with the PowerShell Application Deployment Toolkit

Hi all, thought I’d write up what I’ve been working on recently, which is re-visiting PowerShell App Deployment Toolkit.  A great Resource for ConfigMgr apps, but equally it is supported in Intune so I will be doing a follow-up post on using this with Intune.  I know there are plenty of blogs out there on this so this is just my interpretation and is intended to get people started.
I know, for example, that the kit comes with a wide variety cmdlets that you can utilise to achieve tasks but this write up is based around getting those a little familiar with PowerShell up to speed with it.  There are many ways to skin a cat.
Prep Work

  1. Download the latest toolkit from here:
  2. Extract the .ZIP folder and call this folder “PSADT – FULL”
  3. Go into the folder, into the Toolkit folder and create a folder called “Files” (if it doesn’t exist already)
  4. This is where we’re going to store our source files for the applications we’re going to deploy.
  5. From within the FULL folder, copy the Toolkit folder out to the foot and call this “PSADT – TOOLKIT MASTER”
    • TOOLKIT MASTER should only contain the following items
    • Now you have a copy of the full kit that’s not been touched and a copy of the toolkit you can begin to customise for your customer(s).
  6. Working with the TOOLKIT MASTER folder, Open up “Deploy-Application.ps1 and edit the following
    • Comment out the “Show-InstallationWelcome” and Show-InstallationProgress
  7. Do the same for Pre-Uninstallation, comment them out…
  8. Under Post-Installation, comment out the line highlighted below
  9. The above actions make it more silent so the user isn’t bothered when installation takes place. These are options you may wish to reinstate later, the choice is up to you I’ll let you do your own research on that, but for now we’re aiming for not bothering the end user.
  10. Save the script.
  11. Next, within the AppDeployToolkit folder, open up the AppDeployToolkit.xml file and change the following
    • Under MSI Options edit the install params to be /QN instead of /QB-!


  1. You will need to brand the toolkit to your specific customer, otherwise it will be using the standard branding.
  2. From within the TOOLKIT MASTER, open up the “AppDeployToolkit” folder and replace the “AppDeployToolkitBanner.png” with a branded one (must be the same name!)
  3. Next, replace the Icon file (same folder) with a branded Icon file, again with the exact same name.  To do this, create an image 256×256 pixels in size, then open the image using Greenshot and this will give you and option to save the image as a .ICO file

You are now ready to use this toolkit in a silent manner for your ConfigMgr or Intune applications

  1. For each app you will need a COPY of the TOOLKIT MASTER folder, so lets start by creating one
  2. Next you will need to download your content files (source files) and place them in the ‘Files’ Directory.
  3. Now we can start editing the script to match the criteria of the application we’re trying to deploy.
  4. First, open up the DeployApplication.ps1 and scroll down to the “Variable Declaration” section where we’re going to populate all the details of the application we’re going to deploy.  Lets fill this out, here is an example
    • Make sure you get the script version on to help you with different revisions / changes of your app (*1) and ensure you get your name on there because, ‘you’re worth it’ (*2).
  5. Now we’re ready to do the app work!
  6. You don’t need to worry about having in depth PowerShell (although some helps) with this script you simply only need to remember a few things.  Firstly, there are three phases of installation in the script
    1. Pre-Installation – where you would place any code you want to execute BEFORE the app installs
    2. Installation – the app install itself
    3. Post Installation – where you would place any post actions such as copying files or registry entries or even clean up activities.
  7. I’m going to break these down in to a .EXE and a .MSI installation for you.

.MSI Install Example
Read through the examples carefully and take in and fully understand the ‘Take Away’ section which is where I’ve highlighted what you should have learned.
Scenario:  Lets say that you have to install Flash Player (THE HORROR!), but before you do you have to create a folder called “C:\Flash” which is what the company you’re working for want to use to store all their website flash content in.  Strange, I know, but lets roll with it.  So we have two things we need to achieve;

  1. we need to install the program
  2. we need to create the folder.

The folder creation, it doesn’t matter in this particular case whether we do it before or after the installation so we can place that in either “Pre-Installation” or “Post-Installation” step, I’m going to chose Post-Installation in this case.

  1. As with traditional applications,  MSI installs are pretty easy to do.  The script has its own cmdlet to handle this called Execute-MSI (see the top tips section at the end!)
  2. So, firstly we would take a copy of the TOOLKIT MASTER folder and Rename it to “Adobe Flash”
  3. We would then open up the DeployApplication.ps1 and edit the Variable Declaration as stated above in the Process Section to match Adobe Flash and the version number etc.
  4. Next we would locate the “Installation section” and add in our installation line:
    • I’ve blurred out the rest to draw your eyes to the correct section…. Notice the format of the string, it reads pretty straight forward, no more calling MSIEXEC.exe, dont worry about the format of the code as that will be explained later (see the top tips at the end!)
    • You can see here from the help for this cmdlet that the cmdlet called, Execute-MSI, expects the files to be in the “Files Directory” (highlighted in Blue).  This is why we sense checked the folder earlier.
  5. Next we create the folder “C:\Flash” as per the requirements.  In the post-installation section, simple add your code…
    • Again, I’ve blurred out the surrounding code to draw your attention to the section to use, you’ll start to pick up they follow the same format
    • There is a cmdlet you can use for this that build into the PSADT module, I’ll let you explore that!  However this achieves the same thing.
  6. Let populate the uninstall section so that we can uninstall the app using the script too…
    • Notice that the ‘action’ switch has changed in this case.

And that’s it, done.  Save the script. You can test this before on a test box (which I suggest you do).
When creating your ConfigMgr application, the command to install the application would be to call the DeployApplication.ps1 with a switch of -DeploymentType Install, like so…

  • Deploy-Application.ps1 -DeploymentType Install

The uninstall command would be

  • Deploy-Applicaiton.ps1 -DeploymentType Uninstall

Take away: 

  • Understand the structure of Pre, Post, and Install and what tasks need to be done when, given your requirements.
  • Know that under the <Perform Tasks Here> sections, you can have as much code as you need, doing whatever tasks you want.
  • Understand the cmdlet written for installing MSIs.  You use Execute-MSI with a Install switch
  • If you wanted to uninstall items before installing the new version, you could use “Start-Process” and call the uninstall with a -wait switch like so…
    • Start-Process -FilePath “C:\Windows\system32\msiexec.exe” -ArgumentList “/x{26923b43-4d38-484f-9b9e-de460746276c} /qn” -wait
    • This would;
      • Call msiexec that exists on all windows based machines
      • Pass the argument list of uninstall, quietly with no UI.
      • Wait until its finished before it does the next line of code, so if you had multiple install

.EXE Install Example
Scenario:  Lets say that you have to install Flash Player (THE HORROR! AGAIN!!!), but before you do you have to create Registry Key “HKLM:\Software\Company\Adobe\Flash” with a string key in there  called “Status” that has a setting of “Awesome” and an Integer key (DWORD) called “ReallyAwesome” with a setting of “00000001” which is what the company want, because they’re weird.
The string key must be created BEFORE the application is installed and the Integer key must be created AFTER the software is installed.
We know that the .exe accepts the switch /quiet for the install and also /uninstall /quiet for the uninstall, which we’ve gotten from normal testing.  We need to..

    • Create the String Regkey (before install)
    • Install the program
    • Create the Integer Regkey (after Install)
    • Set the uninstall up
  1. So lets create the first regkey, inside Pre-Installation
  2. Next we need to install the application
    • Notice the difference here, we’re not using Execute-MSI this time.
      • Starting a process
      • Passing the arguments
      • Adding -wait so it waits for the install to finish
      • There are many ways to call .exe’s from PowerShell, doesn’t really matter what you use.
  3. Next we add the regkey we need to add AFTER the installation.
  4. And finally the uninstall section needs populating
    • Remember we set the path earlier on, in the Pre-Installation section so the variable $RegistryPath, is already there.

Hopefully this is beginning to make sense now….
Take away: 

  • Cement our understand the structure of Pre, Post, and Install section and what tasks need to be done when, given your requirements.
  • Know that under the <Perform Tasks Here> sections, you can have as much code as you need, doing whatever tasks you want.
  • Calling executables is different as we cant leverage the Execute-MSI cmdlet, so we use Start-Process with a -wait on the end

Top Tips Section.
Within the folder structure of your PSADT, there is a sub folder called “AppDeployToolkit”

And in there you will find a script called AppDeployToolkitHelp.ps1

If you run this scrip you will launch the help section where you will have detailed instructions on the cmdlets available inside PSADT and how to use them.

The section highlighted with a red arrow is the name of the cmdlets you can use, and the green arrow points to the format of the code to use with some examples at the bottom.
You will find almost everything you need in here to fit most of the requirements for app packaging.  There are also plenty of tutorials you can access on YouTube to gain further understanding of this but it is very powerful indeed.
Some of the items we commented out in at the beginning to make the user experience more silent, can be switched back on if you wish, we can make it as visual or silent as you wish, the more you use this tool the more you will realise its potential & scalability.  It is supported in ConfigMgr and Intune (win32) Applications, but it does not negate the need for proper testing in the normal manner via VM’s and information gathering.
I hope this has been informative for you. In the next post I intend to do some examples in ConfigMgr and In Intune as a Win32 app.
Stay Tuned.

/by JonathanSours:

Now discussing:

Powershell App Deployment Toolkit - GUI (Updated version 1.4)

GUI for creating Intune & SCCM applications using the Powershell App Deployment Toolkit, including creating Software ID Tags for easier License Management.

If you are working with ConfigMgr or Intune, you will probably create Applications once in a while to deploy to end-users machines :)

Although the current Application model is great and allows for much greater flexibility than we had with Packages/Programs , there are still situations where the Application model isn’t sufficient.

A lot of the things that are not possible with the App model, are probably fixed in your own environment by writing custom scripts.

A very good alternative is to start using the Powershell App Deployment Toolkit.

It is basically a (free) solution that allows you to standardize the way you deploy applications (and packages if you want to). It offers great flexibility and takes away most of the gaps that are left in the app-model.

Some of it features are :

  • An interface to prompt the user to close specified applications that are open prior to starting the application deployment
  • The ability to allow the user to defer an installation X number of times, X number of days or until a deadline date is reached
  • The ability to prevent the user from launching the applications that need to be closed while the application installation is in progress
  • Balloon tip notifications to indicate the beginning and end of an installation and the success or failure of an installation.
  • and many more

However, if you have never used it before, it could be a bit overwhelming at first since there are so many different options available.

One of the issues I ran into when using the toolkit for the first times, besides finding out what option I needed, were typo’s…if you forget a quote, the script won’t run. Additionally, editing the Deploy-Application.PS1 file takes time as you have to scroll a lot to the correct location to perform the functions that you want/need.

To prevent this, I started this project to create a GUI that does most of the legwork for you.


At this moment the functionality is still limited but it should cover the basics to deploy an MSI or Script (setup.exe). The goal is to extend the GUI so that most of the functionality offered by the toolkit is present in the GUI, but that will take time ;-)

For now, see it as a tool to merge your source-binaries together with the toolkit and generate the “basic” Deploy-Application.PS1. Once that is done, nothing is stopping your from editing that file to embed more complex stuff. Also, feel free to update the AppDeployToolkitBanner.png in the Toolkit subfolder with your own company logo !

The functionality at this point in time is (Version 1.2) :

  • Fully unattended generation of the Deploy-Application.PS1 file
  • Merging of your source binaries with the PS App toolkit on a destination Share (must be UNC)
  • Creating the SCCM Application + Deployment Type
  • Adding a Software ID tag and using this as a detection mechanism (with experimental lookup function).
  • Caching of previously looked up Reg-ID’s and previously used source & destination paths
  • Enumerating all DP & DP-Groups and distribute content to them
  • Generate Install & Uninstall collections based on the Application’s Name

Added functionality in Version 1.3 :

  • If enabled, the tool can now automatically connect to your SCCM environment, create the application, collections and distribute the content (saving you clicks and time)
  • If the PoSh AD module is available, the tool can now create the AD security groups and link them to your collection
  • A text message can be shown at the end of an installation
  • Bugfix where uninstallation wouldn’t delete the RegID file.

Added functionality in Version 1.4 :

  • Browse to your setup files (this will extract relevant information from the MSI/EXE and populate the necessary fields)
  • Create Intune Win32 package (IntuneWin file)
  • New/Fixed whois lookup information for the SWID Tag
  • Latest PSADT & Intune Win32 app binaries are included
  • Additional errorhandling
  • Runs from any location that has the Configmgr AdminUI (Console) installed
  • Vendor name is removed in collection/AD name (to shorten the name)
  • Suffix install/uninstall is replaced by -I/-U (to shorten the name)
  • Bugfix if no parameters are required or script or MSI

Disclaimer : As this is the first (beta) version of the GUI (don’t let the version number fool you), not everything is error-handled. Also, this is my first attempt at such a project and I’m not the best PowerShell coder out there anyway ;-) So it’s a “learn as you go” project.

For now, I assume that the account that launches the GUI has access to the folder that holds your source binaries (the files you want to install) and to the UNC path where we will copy the merged application to (explained below).

You should be able to run the GUI from any device that has the configmgr AdminUI (Console) installed.

Logging is included in the GUI and if you have PowerShell 5 (or greater), it will try to install Kim’s Logging module so that logging is done in the CMtrace format. If that fails, logging will be done to a regular text file.

The location of the logs for now is c:\temp\PSAPPgui

First things first, Download the GUI to a location of your liking. That should include the following files/Folders :

  • Toolkit (subfolder - holds the full PS App deployment toolkit)
  • Intune_Win32 (subfolder - holds the Intune Win32 conversion toolkit)
  • Config (Subfolder - holds the following files)
    • Deploy-Application.PS1 (The template I build upon)
    • MainWindow.XAML (My GUI file)
    • OSCCLogo.jpg (needs no further explanation)
    • Prefs.XML (caching of user settings)
    • SWID.XML (caching of regid’s)
  • PSAPP_GUI.PS1 (The file you need to run !)

When you start the GUI (by launching PSAPP_GUI.PS1 from a PowerShell cmd prompt) you should see the interface that allows you to create a new application. (Run as administrator the first time to allow the logging module to be downloaded/installed. This is not required for the GUI functionality but might throw some errors because it will tyr to install the logging module)

To use the tool, the easiest way is to click the “Browse for install file” button at the top. Browse to the MSI/EXE you want to install and select it. The tool will try to extract as much information as possible and enter it in the appropriate field. You may need to complete the remaining required fields.

These are the required fields :

  • Application Vendor
  • Application Name
  • Application Version
  • Application Architecture
  • Software ID Tag
  • Source Path
  • Destination Path

The first 4 should be self-explanatory and are all related to the application you want to “package” and deploy with SCCM. I’ll cover the Software ID tag later in this blogpost. (See the animated gif in the beginning of the blogpost for a demo)


On the Installation section, there is a dropdown box to allow you to switch between MSI or Script.




Enter the full filename of the MSI you want to install, eg 7zip.Msi and in the parameters box the MSI parameters you want to apply, eg /passive or /qn.


for Scripts (or .exe based installs) the process is similar. Provide the filename that you want to run, eg setup.exe and the parameters to have it unattended (eg, /S).



Add/Remove Programs

In the Uninstall section, provide the name for the application as you see it in Add/Remove Programs, eg “Adobe Reader X”. The App deployment toolkit will do a search for that name and perform the uninstallation.

Command Line

If needed, provide the full uninstall command line, eg “Setup.exe /uninstall”.

MSI Product Code

You can also use the MSI product code for uninstallation.

Source & Destination


In the Package binaries path, provide the full path to where your source binaries that include the setup file you provided earlier are stored. This can be a local or network path.

The destination package path must be a network path (\server\share). The GUI will create a subfolder there with the name of the Vendor and a subfolder in there with the name of the Application + Version

In my screenshot the result would be \SCCM_Server\SCCM_Files\Applications\Vendor\Applicationname_Version_Bitness

Note : Bitness = Application Architecture = X86 or X64

The actual toolkit will be copied into that final subfolder and your application binaries in the “Files” subfolder of the Toolkit

The Buttons


Clicking this button will allow you to browse to your sourcefiles that you want to install and extract as much information as possible.


If you provide the URL of your vendor’s website, eg and click the lookup button, the GUI will try to detect when that website was registered and pre-fill the RegID information.

Most domains should be supported, but the lookup can only handle 1000 requests/month globaly (Proxy-support is not built-in at this moment)


Clicking the “Generate Package” button will first “validate” all the fields and highlight in Green what is Ok and in Red what is not OK.

Nothing will happen until all required fields are filled out properly.

Once that is done, the GUI will create the subfolders as explained above and merge the files and finally it will generate the Deploy-Application.PS1 file that will contain the installation logic.

After that, the 2nd tab becomes available for you to continue the SCCM-Part.


Click “Connect to SCCM” to automatically connect to the detected SCCM Environment. Once that succeeds, all DP’s (and groups) will be enumerated and you will be able to progress with the import.


“Import into SCCM” will then create the application + deployment type using the information provided in the GUI.

As a detection method, we check for the presence of the SWID-Tag file. Since it’s generated after a successful installation, and removed again on uninstallation, it’s safe to use this and removes all complexity on finding an appropriate detection method.

The list of DP’s and DP-Groups is multi-selectable, so just hold CTRL and select the DP and/or DP-groups you want to start the distribution to and click “Distribute Content”

Finally, you can generate 2 collections based on the Application-Name with the suffixes “-I” & “-U”. They can be further customized with a pre & suffix of your choice.

The Settings tab is split in 2 sections. The first part are the generic settings that you can enable or disable. It will tell the GUI to remember some items and re-use them in the furure


The other part will initially be greyed-out. To be able to select those items, you must complete the first and second tab “manually”. That is, create the PSADT package on the first tab and on the SCCM tab, click connect and create the SCCM Application. At that point,the GUI will cache the SCCM sitecode, the DP’s you selected, if you want to create collections … The next time you create a PSADT package. The tool will automatically connect to SCCM and create the application on your behalf with all your previous preferences.


By default, the tool will limit the collections to the “All systems” collection. If you dont want this, you can set the collection ID to a collection of your liking.

If you select the “Create Intune package” checkbox, you also need to provide a target “Intune app folder”. Once the PSADT Package is fully created, it will also generate the IntuneWin file for you in that target folder. This will include the details needed to create the Win32 app in Intune (Commandline, Detection method,…)

Don’t forget to hit “Save” to actually save your settings.

A software identification tag is an XML file that’s installed alongside software, and which uniquely identifies the software, providing data for software inventory and asset management. With the introduction of industry-standard software identification tags, it becomes possible to automate the processes of gathering software inventory data for use in reporting and in other initiatives such as managing software entitlement compliance.

Software identification tags are stored on the computers on which software is installed. The standard allows for operating system vendors to specify where software identification tags are located. On Windows Vista machines and later, SWID Tags are stored under %Programdata%\

One of the key-elements of the software ID tag is the “RegID-File”. The file is generated based on when the domain name from the vendor of the application was first registered. Eg, if we lookup “” on, we can see that it was first registered/created on November 1986.


The SWID-Tag will be stored in a subfolder under %programdata%. This subfolder for Adobe will be : Regid.1986-11.Com.Adobe

This will always be the structure. It starts with the word “RegID” followed by a dot “.”, then the year when the domainname was first registered, a dash “-“ and the month when the domainname was registered. Then another dot “.” and finally the domainname in reversed order. If we take www.Oscc.Be as an example, the subfolder would be : Regid.2008-03.Be.Oscc

The key here is obviously to look this information up properly so that all applications from a specific vendor will always end up in the same subfolder.

In that subfolder, the actual SWID-Tag will be created. The file starts with the same string as the subfolder, followed by and Underscore, the Applicationname, another underscore and the application version. The extension of the file is .swidtag

Basically this is just an XML file that contains a few details on your application. SCCM Will automatically pick up these SWID tags if you enable them in the Asset Intelligence node.

Enable the inventory class “SMS_SoftwareTag” and once the data is collected you can run reports 14A, 14B & 14C that are specifically created to handle SWID-tags.


Back to the GUI. With all the information it should be clear what needs to be filled out in the Software ID Tag fields. Look up the domainname for your vendor, enter the year, month and domainname in reverse order.

When you select “License Required : No”, a flag will be set to “False” indicating that this is software that is free to use. If you select “Yes”, the SWID-tag will be created with Entitlement Required = True, indicating that a license is needed.

By default, the powershell App deployment toolkit doesn’t support the creation of SWID-tags, but Kim wrote an extension (that’s included with the GUI) to enable this functionality.

That should be all there is to it ! Again, for now it only supports basic functionality but once you have your destination package generated, nothing is stopping you from opening up that freshly generated Deploy-Application.PS1 file and making the adjustments you want/need.

Currently on my roadmap for future versions (not necessarily in this order)

  • Create Deployments
  • Create AD-Groups and link to Collections (done in 1.3)
  • Saved settings such as target folder, selected DP’s, … (done in 1.3)
  • Browse buttons (done in 1.4)
  • More Built-in Toolkit actions
  • Multi-threaded GUI
  • The GUI can become unresponsive when copying large files or importing into SCCM. Be patient as the process is running in the background in single-threaded mode.

Current Version : 1.4

Download from Github

Feel free to add ideas for features that you feel are missing badly and let me know if you run into issues using the GUI.

Shoutout to Kim Oppalfens and Sandy (Yinghua Zeng) for testing the functionality!

That’s it ! Enjoy …


16 17 18 19 20