SCCM-applicatie-implementatie: apps verpakken en implementeren

Many businesses rely on SCCM (Microsoft Configuration Manager) to deliver apps to their Windows devices, whether they’re on-premises or remote. However, SCCM application deployment is only as reliable as the package and rules behind it.

If a silent switch is incorrect, the detection rule doesn’t match the app, or a return code isn’t mapped, a successful installation can be reported as a failure (or vice versa). That matters more now that Microsoft has released Configuration Manager version 2609, the first release on a once-a-year schedule. Teams that stay on SCCM need app delivery that works reliably with the features they already have.

With that in mind, let’s explore SCCM application packaging, how to prepare and deploy applications, and how detection methods and return codes decide what SCCM reports.

What is application packaging in SCCM?

Application packaging is the work done to prepare an application before SCCM touches it. This includes setting install and uninstall commands, enabling silent install, adding configurations, and determining how to verify installation. For a broader overview, see what application packaging is.

SCCM then deploys the prepared app. It stores it as an application with one or more deployment types, copies the content to distribution points, and tells clients when and how to install it using the files and rules you provided.

Keep in mind that SCCM can only enforce what you give it. As such, properly preparing the application with the rules and settings you need is important, since much of the installation’s reliability is decided before the Create Application wizard opens.

Applications vs packages and programs in SCCM

With all this terminology being thrown around, it can get a little confusing: what exactly do we mean when we refer to applications, packages, and programs? We can break down the differences like so:

Given these differences, Microsoft suggests packages and programs for tools that don’t install an app, one-off scripts, and recurring scripts. For software you install and keep up to date, applications are the better fit. If you have older packages, Package Conversion Manager can convert them into applications.

How to package an application for SCCM

When you’re packaging an application for SCCM, there are a few key steps you’ll want to follow. Including all the commands, wrappers, and rules you need for a proper installation will help ensure a smooth rollout, but missing a step can cause installation or reporting issues.

1. Identify the installer type: This could be an MSI, a setup EXE, or an EXE that wraps an MSI; whichever it is will affect everything that follows. Our MSI vs EXE installer guide explains how to tell them apart.

2. Find the silent install and uninstall commands: How you find these commands varies by installer type. Every MSI uses the same switches, while EXE switches depend on the tool that built the installer. See our msiexec silent install guide and EXE silent install guide.

3. Decide whether to wrap it: You can use a PowerShell App Deployment Toolkit (PSADT) wrapper to add close-app prompts, deferrals, and consistent logging when the installer needs them. Our PSADT guide covers how the toolkit works.

4. Build a clean source folder: When you create an MSI-based application, SCCM imports every file in that folder and sends it to distribution points, so make sure the folder only has what the install needs. Microsoft tests SCCM with up to 20,000 files per application.

5. Record what proves the app is installed: You’ll need something to signal that the app is installed, such as the MSI product code, a versioned file, or a registry value. This becomes the detection method for verifying installation across endpoints.

6. Test the command as SYSTEM on a clean machine: Testing the installation and uninstallation before deploying it across devices is essential for spotting any issues before they can become a problem. Keep in mind that an app that installs with the given command line in the system context will generally install through SCCM.

SCCM application deployment step by step

Packaging an application for SCCM is the first step, but then you need to deploy it. Deploying the app will also take a few steps, but it becomes a straightforward process once you get used to it:

1. Create the application: You can do this by going to the Software Library, then go to Application Management → Applications, and select Create Application. For an MSI, you can let SCCM read the file. For a setup EXE or a PSADT wrapper, on the other hand, you’ll need to choose Script Installer and enter the details manually.

2. Set the deployment type content: At this step, you’ll enter the install and uninstall commands, and a repair command if the app supports one. Make sure to point the content location to your clean source folder.

3. Add the detection method: Detection methods can include rule-based detection or script detection to look for certain indicators that an app was successfully installed. The specific detection method you should use will vary by app.

4. Set the user experience: This includes a variety of settings, including whether you install for system or user, the logon requirement, program visibility (you’ll want to use Hidden for silent installs), and the maximum run time.

5. Add requirements and dependencies: Requirements decide which devices get which deployment type, while dependency chains support up to five levels.

6. Distribute the content: Send everything to distribution points or a distribution point group so it can reach the intended devices.

7. Deploy to a collection: Choose Install, then Available (so users can install from Software Center) or Required (where it automatically installs by the deadline). Don’t forget to set the available time and deadline to ensure it’s deployed within the intended timeframe.

8. Test before the full rollout: Before you deploy the application, run simulated deployments in a pilot group to test detection, requirements, and dependencies without installing. If everything checks out, you can use phased deployments to roll it out in stages based on success criteria.

9. Keep an eye on deployments: Monitor the rollout by going to Monitoring → Deployments and check results to make sure everything works as intended before deploying to a wider group of devices.

Keep in mind that SCCM automatically sets an Uninstall deployment to Required, and you can’t change it. For devices that were off at the deadline, you can optionally delay enforcement with a grace period of 1 to 120 hours, which you set in client settings and then turn on for each deployment.

How SCCM detection methods work

Detection is how SCCM confirms whether an application is installed. The SCCM client checks for a sign that the app is present before it installs anything, so it doesn’t reinstall an app that’s already there, and again afterward to confirm the install worked. Detection methods take one of two forms:

Rule-based detection

With rule-based detection, the SCCM client checks the file system (a file or folder), the registry (a key or value), or a Windows Installer product code. If the rule is met, SCCM considers the app installed.

You can combine multiple clauses with “And” or “Or,” and group them for more complex logic. Whichever you use, have the rule look for something that changes with each version, such as the product code or file version, so an older install isn’t reported as current.

Script detection

Script detection lets you write the check in PowerShell, VBScript, or JScript (up to 32 KB). SCCM reads both the script’s exit code and its output: the app counts as installed only when the script exits with 0 and writes something to STDOUT. An exit code of 0 with no output means not installed, and any non-zero exit code leaves the state unknown. In practice, write output only when the app is found, and always exit with 0.

When detection runs

SCCM checks for detection before installing the application, then again right after. If the app isn’t found after the installation, SCCM reports error 0x87D00324, even if the software is on the device. The troubleshooting section below covers how to fix it.

SCCM return codes and restart behavior

When an installer finishes, it returns an exit code, and SCCM uses the deployment type’s return code list to decide whether the install succeeded, needs a restart, or should be retried. Knowing these codes also helps IT teams interpret results and troubleshoot.

Codes can mean:

• Success (no reboot): The application installed successfully, and no reboot is required.

• Failure (no reboot): The application failed to install.

• Hard reboot: The application was installed, but the device needs a restart to finish. Nothing else will install until after the reboot.

• Soft reboot: The application was installed and the device needs a restart. Other installs can continue in the meantime.

• Fast retry: There’s another install in progress, so the installation has to wait for it to finish. The client will retry every two hours, up to 10 times

SCCM adds these default return codes when you create a deployment type:

Any other non-zero code counts as a failure unless you add it. For instance, if an installer returns 1 instead of 0 on success, add 1 as Success (no reboot) so SCCM reads it correctly.

Wrapped installs need their codes mapped too. When a user postpones a PSADT install, the toolkit returns its deferral code, 1602 by default. Change it to 1618, or add 1602 as a Fast Retry code, so SCCM tries again instead of logging a failure. Our PSADT guide covers deferrals in more detail.

Don’t forget: the deployment type’s post-install behavior setting determines whether SCCM restarts the device, the installer restarts it, or no restart happens.

How to troubleshoot a failed SCCM application deployment

If your SCCM app deployment fails, there’s no need to panic. You can quickly address common issues with a bit of troubleshooting to identify and mitigate them.

"The application was not detected after installation completed" (0x87D00324)

This error means that the installation ran, but the detection method didn’t find the application. In this case, check AppDiscovery.log and CIAgent.log, then compare the detection rule to what the installer actually wrote.

"Application was still detected after uninstall completed" (0x87D00325)

This error means the uninstall finished, but detection still finds the application. Check AppEnforce.log to confirm which uninstall command ran, then check AppDiscovery.log to see what detection still finds, and compare it with the detection rule.

The install fails only through SCCM

If the install is failing through SCCM, try running the exact command as SYSTEM on a test machine to see if it works there. Also check the silent switches, since the installer may be waiting for user input when no one is there to provide it.

The deployment never starts on some devices

If the deployment type’s maximum allowed run time is longer than the device’s maintenance window, the deployment won’t start. To address this, shorten the run time or extend the maintenance window.

Where SCCM application deployment stands in 2026

This brings us to the state of SCCM today. Version 2609 has been available to all customers since October 26, 2026, and applies to sites running 2503 or later. It’s also the first release on a new schedule: Microsoft now releases one SCCM update a year, with a focus on security and stability, and has said new innovation happens in Intune.

Many teams also run SCCM and Intune together through co-management. When the client apps workload moves to Intune, apps deployed from Intune show in Company Portal, while apps deployed from SCCM stay in Software Center.

The packaging work you do for SCCM still pays off if you move apps to Intune. A clean silent install, reliable detection logic, and mapped return codes are the same inputs an Intune Win32 app needs, though you’ll set them up again in Intune, where things work a little differently (for example, every manual detection rule must match). Our Intune Win32 Content Prep Tool guide covers that side.

How Splashtop Agentic Packr speeds up SCCM application packaging

Properly packaging applications is essential, but it can also be a repetitive, time-consuming manual task. Thankfully, it doesn’t have to be if you have a tool like Splashtop Agentic Packr.

Agentic Packr is an AI-powered tool that automates app packaging. It reads the installer, works out the silent install switches, writes the detection and requirement rules, and builds the package, without requiring manual scripting or packaging expertise. Packages are built on PSADT, so admins can open, review, and adjust them as needed. Every package is validated, scanned, and tested on a clean virtual machine, with a QA scorecard and execution log IT admins can review and approve before deploying applications.

Once Splashtop Agentic Packr packages the application, you can bundle its install, update, and uninstall actions to deploy with SCCM or run manually on any Windows machine. Plus, whenever a new version of the app is released, Agentic Packr can detect it and build an updated package automatically, so IT teams don’t need to repackage every new version by hand.

Package apps once and deploy them with confidence in SCCM

SCCM application deployment begins with a tested package, accurate detection, and clearly mapped return codes. With those in place, apps and updates reach the devices that need them, and SCCM reports what actually happened.

Splashtop Agentic Packr takes on much of that preparation work, from finding silent install switches to writing detection rules and testing every build, so IT teams can spend less time packaging and more time managing the rollout itself.

Want to see how Splashtop Agentic Packr helps package applications efficiently and securely? Learn all about it today.