Skip to content
daniel@cosenza:~/blog
WindowsHow-To July 9, 2026 3 min read

How to Deploy Software with Group Policy

A complete walkthrough packaging and deploying an MSI installer to multiple computers automatically via Group Policy Software Installation — no third-party deployment tool required.

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.

Step 1: create a network share for the installer 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.

Step 2: set appropriate share and NTFS permissions

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.

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.