If you’ve spent any time administering Microsoft Configuration Manager (ConfigMgr/SCCM), you already know that “Applications” are the modern, model-driven way to deploy software – a big step up from the legacy Package/Program model. Applications support detection methods, requirement rules, dependencies, supersedence, and multiple deployment types, which makes them far more flexible when you need to target different scenarios (like an x86 vs. x64 install, or a Win32 install vs. an MSIX).

This post assumes you’ve already done the prep work – your installer is wrapped with the PowerShell App Deploy Toolkit (PSADT) and staged in the appropriate content source location (a share accessible to your site server and distribution points). If you’re not familiar with it, PSADT is a widely-used community framework that wraps your actual installer (MSI, EXE, etc.) in a standardized PowerShell script, giving you consistent logging, built-in user-facing prompts (close-apps warnings, restart prompts, progress dialogs), and a predictable folder structure (Deploy-Application.ps1, a Files subfolder for your source install media, and a SupportFiles subfolder for anything extra) – I recommend checking it out at https://psappdeploytoolkit.com. From here, we’ll walk through actually building the Application object in the Configuration Manager console around that toolkit structure.

Prerequisites

Before you start, make sure you have your:

  • Content package ready – your application files staged in a network location the ConfigMgr site server can read
  • Install and uninstall commands – with PSADT it’s simple, but if you’re using something else, make sure you know what commands you need to install and uninstall your application
  • A detection method in mind – something that reflects the application itself, not PSADT (an MSI product code, a file, a registry key, or a version number)
  • Knowledge of your target requirements – architecture, OS version, or other conditions the deployment type(s) should be scoped to

Step-by-Step: Creating the Application

1. Open the Configuration Manager Console

Launch the console and navigate to:

Software Library → Application Management → Applications

Right-click Applications and select Create Application. This launches the Create Application Wizard.

2. Choose the Application Type

On the General page, you’ll choose how you want to define the application:

  • Automatically detect information about this application from installation files – works well for MSI-based installers, since ConfigMgr can read the MSI properties directly.
  • Manually specify the application information – the more common choice for EXE-based installers, scripted installs (like PSADT), or when you want full control over every field.

For an MSI, select the automatic option and browse to the .msi file – ConfigMgr will pre-populate the publisher, name, and version fields for you. For anything else, choose manual entry and continue.

3. Enter General Application Information

Since PSADT wraps the installer in a PowerShell script rather than exposing raw MSI properties, you’ll almost always choose manually specify the application information here, even if the underlying installer is an MSI – letting the wizard auto-detect from the .msi would bypass the toolkit entirely.

If you chose manual entry, you’ll fill in:

  • Name – use a clear, consistent naming convention (e.g., Adobe Acrobat Reader DC 24.x - x64)
  • Publisher
  • Software version
  • Optional fields – administrator comments, owner, support contact – worth filling in if your team relies on these for auditing or handoff

Click Next.

4. Create the Deployment Type

Every application needs at least one Deployment Type – this is where the actual install mechanics live. The wizard will prompt you to create one immediately (you can always add more later for different platforms or install methods).

Choose Script Installer as the deployment type technology – this is the correct choice for a PSADT-wrapped application, regardless of what the underlying installer type is (MSI, EXE, or otherwise), since ConfigMgr is really just calling into the toolkit’s PowerShell front-end.

For the Script Installer deployment type, you’ll specify:

Content location – the UNC path to the root of your PSADT folder structure (the folder containing Deploy-Application.exe/.ps1, AppDeployToolkit, Files, and SupportFiles).

Installation program – call the toolkit’s compiled front-end (or PowerShell.exe directly) with the Install deployment type parameter, e.g.:

Deploy-Application.exe -DeploymentType Install

or, if you’re not using the compiled .exe front-end:

powershell.exe -ExecutionPolicy Bypass -File Deploy-Application.ps1 -DeploymentType "Install"

Add -DeployMode "Silent" (or "NonInteractive") if you want the install to run without any user-facing UI – common for scheduled/required deployments.

Uninstall program – the same front-end, with the deployment type flipped to uninstall:

Deploy-Application.exe -DeploymentType "Uninstall"

or

powershell.exe -ExecutionPolicy Bypass -File Deploy-Application.ps1 -DeploymentType "Uninstall" -DeployMode "Silent"

A couple of PSADT-specific notes worth calling out:

  • The actual silent install/uninstall switches for your underlying installer (MSI or EXE) live inside Deploy-Application.ps1, in the Execute-MSI/Execute-Process calls – not in the ConfigMgr command line itself.
  • Make sure the maximum allowed run time and estimated installation time (configured later in the wizard) account for any close-apps prompts or deferral windows PSADT is set up to show – those can add significant time beyond the raw install – and can cause your install to time out if not accounted for.

5. Configure the Detection Method

This is one of the most important steps – it’s how ConfigMgr determines whether the application is already installed on a device (and whether a deployment succeeded).

You have a few options:

  • Configuration Manager will detect this application based on certain rules – build one or more rules using:
    • MSI product code (most reliable for MSI installs)
    • File existence (path, filename, optionally version or date)
    • Registry key/value (path, value, and optionally data comparison)
  • Use a custom script – PowerShell or VBScript that returns a success/failure signal. Useful for complex logic (e.g., checking multiple conditions) that the built-in rule types can’t express on their own.

Get this step right – a weak detection method (or none at all) is one of the most common causes of applications that “fail” to deploy even though the install actually succeeded, or that silently reinstall repeatedly.

One PSADT-specific pitfall to avoid: detect the underlying application, never the toolkit itself. Don’t point a file-existence rule at Deploy-Application.exe or a folder inside your PSADT package – that file exists on the source share, not on the target machine after install, and it tells you nothing about whether the real application was installed. Use the actual product’s MSI product code, installed .exe path, or registry key, exactly as you would for a non-PSADT deployment.

6. Set User Experience Options

Configure how the deployment behaves on the endpoint:

  • Installation behavior – install for system, install for user, or install for system if resource is device-targeted, user if user-targeted
  • Logon requirement – whether a user needs to be logged on
  • Installation program visibility – normal, minimized, maximized, or hidden
  • Maximum allowed run time -how long ConfigMgr will wait before considering the install timed out
  • Estimated installation time

7. Define Requirements (Optional)

If this deployment type should only apply under certain conditions – a specific OS version, architecture, available disk space, or a custom global condition – add requirement rules here. This lets you attach multiple deployment types to a single application and let ConfigMgr pick the right one automatically based on the target device.

8. Configure Dependencies (Optional)

If the application depends on another piece of software (a specific .NET runtime, a Visual C++ redistributable, etc.), you can add it as a dependency here, and optionally have ConfigMgr auto-install it alongside the main application.

9. Review and Complete the Deployment Type Wizard

You’ll see a summary of the deployment type settings. Click Next, then Close once the wizard confirms success.

10. Finish the Application Wizard

Back on the main Create Application Wizard, you’ll land on a summary page listing the application and its deployment type(s). Review everything, click Next, and then Close.

Your new application will now appear in Software Library → Application Management → Applications.

After Creation: A Few Best Practices

  • Distribute content – right-click the application and choose Distribute Content to push the source files out to your distribution points before you deploy.
  • Test in a limited collection first – deploy to a small pilot collection and validate install, detection, and uninstall behavior before rolling out broadly.
  • Review the deployment type summary – double-check the detection method logic once more; it’s worth the extra minute.
  • Version your naming convention – consistent naming makes supersedence and reporting much easier down the road.
  • Check the PSADT logs when troubleshooting – by default the toolkit writes detailed logs to C:\Windows\Logs\Software (path is configurable). These are far more informative than a bare ConfigMgr exit code when an install fails, since they show every step the toolkit took, including any close-apps prompts, deferrals, or pre/post-install actions.

Wrapping Up

Once you’ve built a solid Application object – accurate deployment type, a reliable detection method, and sensible user experience settings – the actual deployment step becomes almost anticlimactic. Most of the real work happens right here in the wizard. Wrapping your installer in PSADT adds a layer of consistency and better end-user experience, but it doesn’t change the fundamentals: getting detection logic right, and pointing it at the real application rather than the toolkit, will save you a lot of troubleshooting later. It remains the single biggest source of “phantom” deployment failures in most ConfigMgr environments.

Share this content: