Software Deployment Tools: How to Push Apps to a Fleet

A new hire starts Monday and needs eleven applications working by nine. The technician who installs them by hand will do the same job again on Tuesday, and the one who packaged them once will be on the next ticket. This guide sorts the software deployment tools that push apps to a whole fleet: what each route does, which one fits which kind of fleet, and where a push breaks.

TL;DR

• A deployment tool does four jobs: pick the devices, deliver the package, install it silently in the right context, and confirm it landed. Skip the last one and you have a script, not a deployment.
• Windows has four main routes: Group Policy software installation (MSI only), Intune Win32 and Store apps, a script push from an RMM, and dedicated tools such as PDQ Deploy or Configuration Manager. Package managers like winget and Chocolatey sit underneath all of them.
• Pick by fleet, not by feature list. Domain-joined and on-prem points one way, Entra-joined and cloud-first another, and an MSP running twenty tenants a third.
• The failures repeat: wrong install context, a detection rule that doesn't match, an installer that wants a click, and a reboot nobody planned for.
• Roll out in rings. One device, then a pilot group, then everyone with a deadline, with the uninstall assignment ready before you need it.

What Software Deployment Tools Do

A software deployment tool takes an installer, decides which devices should have it, runs it without anyone clicking Next, and then checks that the application is present. That last step separates deployment from scripting. A script that runs msiexec on 400 machines tells you it ran. A deployment tool tells you which 388 machines have the app, which 9 failed with a return code, and which 3 haven't checked in.

The category overlaps with two neighbours. Patch management keeps what's installed current, and the same tools often do both, which is why Intune, Configuration Manager and PDQ appear in both conversations. The broader field of IT automation software covers workflows around the install, such as onboarding runbooks, and this post stays on the install itself.

The devices set the constraints. A Windows fleet has four realistic routes, and each one makes a different assumption about how the device is joined, where it sits on the network, and who is logged in.

Four Routes to a Windows Fleet

Group Policy Software Installation

The oldest route still works. A Group Policy Object under Computer Configuration, Software Settings, Software installation points at an MSI on a network share, and the package installs when the computer starts. Assigned to a user, it installs at logon or on first launch. Published to a user, it appears in Add or Remove Programs for them to install.

The limits are in Microsoft's own KB 816102, updated February 2026. The package has to be an MSI, the path has to be a UNC share the computer account can read, and installation happens at startup or logon, so a laptop that never restarts on the office network never gets it. There is no reporting beyond the event log and no way to say "install by Friday". It suits a small domain with a few MSI-packaged line-of-business apps and nothing else.

Intune Win32 and Store Apps

Intune has two app types worth knowing for a fleet. The Win32 app type wraps any installer, MSI or EXE, into an .intunewin file with the Win32 Content Prep Tool. You supply the install command, the uninstall command, an install context of System or User, requirement rules, and detection rules that tell Intune how to confirm the app is present. Microsoft's Win32 documentation, updated July 2026, caps a package at 30 GB and has the Intune management extension check for new assignments every hour.

Two settings carry most of the weight. Return codes decide what happens next: 0 is success, 3010 is a soft reboot, 1641 is a hard reboot, and 1618 tells Intune to retry three times, five minutes apart. Detection rules decide whether the install counts: an MSI product code, a file or registry check, or a PowerShell script that returns 0 and writes to STDOUT. Intune re-evaluates required apps roughly every 24 hours, so an app that installs but fails its own detection rule gets installed again tomorrow.

The second type, Microsoft Store app (new), pulls from the same catalog winget uses. Intune keeps those apps updated on its own, which removes a whole class of packaging work for common tools. The trade is control: the publisher hosts the content, paid apps aren't supported, and the device needs to reach the Store. Our Intune review covers where Intune stops being enough for a mixed fleet.

RMM Script Push

An RMM agent runs as SYSTEM on every managed device, which makes it a deployment tool the moment you hand it a script. The usual pattern is a PowerShell script that downloads or copies the installer, runs msiexec /package app.msi /quiet /norestart or winget install --id Publisher.App --silent --scope machine, checks the exit code, and writes a line the RMM collects. Read our guide to what RMM does if the agent model is new to you.

The strength is reach. The agent doesn't care whether the device is domain-joined, Entra-joined or a workgroup laptop in someone's kitchen, and an MSP can run the same script across every client from one console. The gap is everything a purpose-built tool does for you: detection, dependencies, supersedence and retry logic are yours to write. OpenFrame handles the same job through scripts run across a client's devices with the output collected in one place.

Dedicated Deployment Tools and Package Managers

PDQ Deploy is the on-prem specialist. It pushes installers, Windows updates and PowerShell to domain-joined or VPN-connected Windows computers, ships a library of more than 200 prebuilt silent packages, and can trigger a deployment on a schedule or when a machine's heartbeat returns. As of October 2026, PDQ lists the licence at $1,950 a year per administrator, which includes PDQ Inventory. The condition is the network: the console has to reach the target, so remote laptops need a VPN or an agent.

Configuration Manager is the enterprise route. An application carries one or more deployment types, each with its own install command, detection method and requirements, and content is staged on distribution points before a required or available deployment goes to a collection. It is heavy to run and pairs with Intune through co-management, which is why it shows up in organisations that already have it and rarely in ones that don't.

Underneath all of these sit the package managers. winget ships with Windows 10 1809 and later, Windows 11 and Windows Server 2025 as part of App Installer, and its install, upgrade, export, import and configure commands handle EXE, MSI, MSIX, Inno, Nullsoft and portable installers. Chocolatey wraps native installers into packages the same way and predates it. The catch is the source: Chocolatey's own documentation says the community repository is not intended for organisational use, so companies host an internal repository, and a Store policy can block winget's public source on managed devices.

This r/sysadmin thread is the question every 50-user shop asks at some point: one tool for deployment, patching and licensing, and which of the routes above it should be.

Installer Formats in One Minute

Every route above ends by running an installer, so the package format decides how much work the packaging step takes. MSI is the predictable one. Windows Installer owns the switches, so /quiet and /norestart behave the same on every MSI, the product code gives you a detection rule for free, and /log writes a file you can read when it fails.

EXE installers wrap whatever the vendor chose. Inno Setup, NSIS and WiX Burn each have their own silent switch, and Microsoft's own Intune docs say to ask the vendor for the arguments a package supports. winget's manifest already knows the silent flag for anything in its catalog, which is one reason the package managers save time.

MSIX is the newer format. Packages are signed, install into a container with a virtual file system and registry, and update by downloading only the changed 64 KB blocks. Microsoft's MSIX overview, updated April 2026, claims a 99.96 percent install success rate and a clean uninstall with no leftover files. The reason it hasn't replaced the others is that vendors have to ship it, and many still don't. A separate guide on MSI and EXE installers covers the silent switches in depth, so this post stops here.

Which Tool Fits Which Fleet

The right answer follows from three questions: how are the devices joined, where do they sit on the network, and how many organisations do you manage?

Two of those rows point to other guides. Mac fleets install through Apple MDM, and phones and tablets through the MDM platforms compared in our MDM solutions roundup.

Where Deployments Break

The same handful of failures show up on every platform, and they're cheaper to design out than to debug at scale.

The install runs in the wrong context. A user-context install on a device where the user isn't an admin fails, and an app that writes to HKLM needs System. Intune's own guidance is that Entra registered devices should use System, and that Win32 apps assigned to users fail if the app needs rights the user doesn't have.

The detection rule doesn't match the result. The installer succeeds, the detection rule checks a version string the vendor changed, and Intune reports "not detected after installation". On a required assignment, that app installs again at the next 24-hour evaluation, and again the day after. Detect on something the installer controls: the MSI product code, or the file the app can't run without.

The installer wants a click. Intune states it does not support interactive installs, and tricks that push a dialog into the user's session are unsupported. If the vendor's EXE has no silent switch, repackage it or pick a different vendor.

The install-context trap in the wild: an r/Intune thread on getting a Win32 app to install for a user who isn't an admin, which is the first failure on the list above.

The reboot wasn't planned. A hard reboot return code restarts the device now. Map 3010 to soft reboot, set a restart grace period, and give users the 24-hour default before the machine takes the decision for them.

Bandwidth. A 2 GB package times 300 laptops in one branch office is 600 GB through one WAN link. Delivery Optimization's peer-to-peer download is on by default for Intune Win32 content, and Configuration Manager has distribution points for the same reason.

Version drift. The app updates itself to 12.4, the deployed package says 12.1, and reports go red. Either let the vendor updater run and detect on presence rather than version, or block the updater and own the version through supersedence.

Offline devices. PDQ needs the target on the LAN or VPN. Intune needs internet. A field laptop that's off for three weeks gets nothing until it isn't, so schedule on heartbeat and stop chasing the report.

A Rollout Order That Holds

Package once, then move through rings. The first ring is one device, ideally a reimaged one, where you watch the install and the detection rule succeed by hand. The second is a pilot group of about five percent of the fleet, mixed across models and departments, with the assignment set to available so people opt in and complain early. The third is everyone, assigned as required with a deadline a week out and an availability date before it, so the content downloads and caches before the install fires.

Build the uninstall before you need it. Intune, Configuration Manager and PDQ all support an uninstall deployment, and the day an update breaks a line-of-business app is not the day to write one. For an MSI, msiexec /uninstall {product-code} /quiet is the whole command.

Read the report, not the console's green tick. Success, in progress, error, requirements not met and unknown mean different things, and "unknown" for three days usually means the device isn't checking in at all. The deployment is done when the count of devices with the app matches the count of devices that should have it, and the difference has names.

Deploying Apps as an MSP

An MSP deploys the same twenty applications across a hundred different environments, which changes the maths. A standard app list per client, kept in a document the RMM can act on, beats twenty bespoke policies. Exceptions get written down with the reason, because the client who needs the 2019 accounting version will need it again after the next tech leaves.

Package managers earn their keep here. A winget or Chocolatey install line works on a client's Entra-joined laptops and another client's domain PCs without a repackage, and a winget upgrade --all scheduled through the RMM keeps the common tools current between patch cycles. Tie it to the patch management process rather than running a second one.

MDM-style tools are the other option for MSPs that want detection and reporting without the enterprise tooling. Our Fleet MDM review covers one open-source route, including how it handles automated patching and software deployment.

Finally, the video below walks through the Intune side end to end, from packaging a Win32 app to Store apps and assignments, which is the route this guide points Entra-joined fleets to.

The Short Version

Software deployment tools push an application to a fleet, install it silently in the right context, and confirm it's there. On Windows the routes are Group Policy for MSIs, Intune for cloud-joined devices, an RMM script push for reach across tenants, and PDQ Deploy or Configuration Manager for on-prem fleets, with winget and Chocolatey doing the packaging work underneath. Match the route to how the devices are joined and where they live, write the detection rule before the install command, and roll out in rings with the uninstall ready. For the wider category of tools that manage the device after the app lands, start with our guide to endpoint management software.