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.
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.