How to Deploy Software with Group Policy

Group Policy can install software automatically across many computers in a domain, using nothing beyond what’s already built into Active Directory — this walks through deploying an MSI package.

\\dc01\Software\MyApp\MyApp.msi

The MSI file needs to live on a network share every target computer can read — Group Policy Software Installation deploys by referencing this network path, not by copying the file into the policy itself.

Share permissions: Authenticated Users — Read
NTFS permissions: Authenticated Users — Read & Execute

Computer accounts (not just user accounts) need read access, since machine-targeted software installation happens in the computer’s own security context before any user logs in.

Step 3: create a new Group Policy Object

Group Policy Management Console → right-click the target
  OU → Create a GPO in this domain, and Link it here

Step 4: configure Software Installation in the GPO

Edit the GPO → Computer Configuration → Policies →
  Software Settings → Software installation →
  right-click → New → Package

Browse to the MSI file using its UNC network path, not a local path — this is required, since the policy needs to resolve the same path on every target machine.

Step 5: choose the deployment method

Assigned    — installs automatically at next computer
              startup, before user login
Published   — available for users to install voluntarily
              via "Programs and Features," not automatic

Assigned to the Computer Configuration node is the right choice for software that should be present on every machine in scope regardless of who logs in.

Step 6: link the GPO to the correct organizational unit

Confirm the GPO is linked to the OU actually containing the target computers — a correctly configured package that’s linked to the wrong OU simply never applies anywhere relevant.

Step 7: force a Group Policy update for immediate testing

gpupdate /force

For assigned computer-targeted software, a restart is still required after this, since installation happens during startup processing, not while Windows is already running.

Step 8: verify the installation on a target machine

Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*MyApp*"}

Step 9: use `gpresult` to confirm the policy is actually applying where expected

gpresult /r

This shows which GPOs are actually applying to the current computer/user — useful for diagnosing why a package didn’t install, distinct from confirming the package itself is configured correctly.

Why the UNC path requirement catches people off guard

Group Policy Software Installation resolves the MSI path at the moment each target computer processes the policy — a local or mapped-drive path that happens to work when configuring the GPO from the domain controller won’t resolve the same way on a different machine. Using the actual \\server\share\ UNC path from the start avoids a package that looks correctly configured but silently fails to install anywhere.

Deploying an upgrade to an already-installed package

Software installation → right-click the existing package
  entry → Properties → Upgrades tab → Add →
  select the newer package to upgrade from

Rather than removing the old package assignment and creating an entirely new one for a version update, Group Policy Software Installation supports explicitly chaining an upgrade package to the version it replaces — computers that already have the older version installed receive the upgrade automatically on next processing, while a computer with neither version yet installed goes straight to the newer one. This chaining is worth setting up deliberately for any software you expect to update more than once, since removing and recreating a package assignment for every version bump loses this automatic upgrade-path behavior entirely.

Uninstalling software you previously deployed via the same mechanism

Software installation → right-click the package →
  All Tasks → Remove →
  "Immediately uninstall the software from users and computers"

Because Group Policy Software Installation tracks exactly which package version was deployed to which machines, removing the package assignment (with the “immediately uninstall” option selected, rather than merely “allow users to continue using the software”) triggers an automatic uninstall on affected machines at their next policy processing cycle — a clean, centrally-managed removal path that mirrors the same deployment mechanism used to install the software in the first place, rather than requiring a separate manual or scripted uninstall process.

Why this approach has real limits worth knowing before committing to it at scale

Group Policy Software Installation predates more modern deployment tooling considerably, and it shows in a few specific ways: it only supports MSI packages natively (a legacy EXE-based installer needs to be wrapped or converted first), it offers no reporting dashboard showing deployment success or failure across the fleet beyond checking individual machines manually, and it has no built-in retry logic beyond the normal Group Policy refresh cycle for a machine that was offline during the original deployment attempt. For a small number of MSI-packaged internal tools in a domain environment with no other deployment infrastructure already in place, it remains a genuinely zero-additional-cost option — but an organization managing a large, heterogeneous software catalog is usually better served by dedicated tooling like WSUS, Configuration Manager, or Intune, which address these specific gaps directly.

Related:

Sources:

Step 1: create a network share for the installer package

Step 2: set appropriate share and NTFS permissions