The Quick Answer: How MSI Deployment Through GPO Works

To deploy an MSI through Group Policy, place the package in a network share that target computer accounts can read, create and link a Group Policy Object (GPO) to the correct organizational unit, add the package under Computer Configuration > Policies > Software Settings > Software Installation, and select Assigned. The application normally installs during computer startup, before sign-in.

The process is simple on paper, but production rollouts fail when administrators test only with their own user credentials. A computer-assigned package runs in the machine context. That makes the UNC path, share permissions, NTFS permissions, GPO scope, and startup network availability more important than whether an administrator can double-click the MSI manually.

Before You Deploy an MSI via GPO

Use this method when you manage domain-joined Windows computers in Active Directory, and the vendor provides a proper Windows Installer package. Group Policy Software Installation is a good fit for a controlled set of relatively stable MSI applications. It is less suitable for internet-only devices, frequently changing applications, complex dependency chains, or installers available only as EXE files.

How to Deploy MSI via GPO Step by Step

• Validate the MSI on a test computer. Install and remove the exact package manually in a lab, and check whether it requires a reboot, license file, prerequisite, command-line property, or MST transform. Do not begin with an untested production-wide link.
• Create the distribution point. On a reliable file server, create a versioned folder such as \\fileserver\software$\Vendor\App\1.2.3. Copy the MSI and any required transform files into that folder. Keep the path stable after creating the policy.
• Configure share and NTFS permissions. Give the targeted computer accounts Read permission on the share and Read & execute permission on the underlying folder. A common choice is Domain Computers, narrowed when the environment requires tighter control. Do not grant unnecessary write access.
• Create and link a pilot GPO. Open Group Policy Management, right-click the OU containing your pilot computer accounts, and choose Create a GPO in this domain, then Link it here. Give it a clear name such as Software - AppName - 1.2.3 - Computer.
• Confirm scope and filtering. In the Scope tab, verify the link, Security Filtering, and any WMI filter. The target computer must have both Read and Apply Group Policy permissions. Avoid removing Authenticated Users read permission without replacing it appropriately, because the computer must still read the GPO.
• Add the software package. Edit the GPO, then go to Computer Configuration > Policies > Software Settings > Software Installation. Right-click Software Installation, select New > Package, enter the full UNC path, select the MSI, and choose Assigned. Do not select the package through a local drive letter.
• Configure advanced options only when needed. Open package properties to add an MST on the Modifications tab or review deployment options. Add transforms before clients process the package; changing the package later can produce inconsistent results.
• Restart a pilot client. Computer-assigned software installs during foreground startup policy processing. A background gpupdate can refresh the policy but does not reproduce every startup installation condition, so restart the computer and allow extra time before sign-in.
• Verify the result. Confirm the application is installed, then run gpresult /h C:\Temp\gp-report.html or use Resultant Set of Policy to check whether the GPO applied. Review Event Viewer under Applications and Services Logs > Microsoft > Windows > GroupPolicy and the Application log for Windows Installer events.
• Expand in stages. Move from a few test devices to one department or site, monitor startup time and installation success, then broaden the link or filtering. Keep the old package source available until upgrade and rollback behavior are proven.

Assigned vs. Published: Choose the Right Deployment Type

For most company-wide MSI rollouts, computer assignment is the clearest choice: it installs the application for the machine during startup and makes it available to users who sign in. User assignment or publishing serves a different purpose and depends on user policy processing. Publishing makes the application optional rather than enforcing installation.

• Use Computer Configuration + Assigned for required software on managed computers.
• Use User Configuration only when the application and business requirement are genuinely user-scoped.
• Use Published when eligible users should choose whether to install the application.
• Use Intune, Configuration Manager, or another deployment platform when you need internet delivery, richer reporting, dependencies, detection rules, or complex update control.

Why an MSI GPO Does Not Install - and How to Fix It

The most useful troubleshooting question is: can the target computer, running as its computer account, read and install the package during startup? Work through the layers in order instead of repeatedly forcing gpupdate.

Use AnyViewer for Post-Deployment Remote Support

GPO handles centralized installation inside an Active Directory environment, but it does not give a technician an interactive view of a failed endpoint. When a small number of authorized computers remain outside the successful rollout, AnyViewer can complement the deployment workflow by providing remote access for diagnosis and user assistance.

For example, an IT technician can use AnyViewer remote desktop software to connect to an approved endpoint, inspect gpresult output and event logs with the user, and confirm whether the MSI is installed. Unattended access can also support maintenance on assigned devices when organizational policy allows it.

• Remote Control helps technicians inspect policy results and installation errors on an authorized PC.
• Remote File Transfer can move approved logs or support files between connected devices when that workflow is permitted.
• Text chat can keep the user informed during attended support, while supported privacy controls can reduce on-site exposure during sensitive maintenance.

AnyViewer is not a replacement for GPO, Active Directory scoping, software inventory, or enterprise deployment reporting. It is most useful for hands-on diagnosis, remote assistance, and exception handling. Before rollout, verify current platform, plan, mass-deployment, and security requirements on the official site, and follow your organization’s access and recording policies.

MSI Deployment Security and Maintenance Checklist

• Use a trusted, vendor-provided MSI and verify its version or signature according to company policy.
• Keep the distribution share read-only for target computers and writable only by deployment administrators.
• Use separate versioned folders and never overwrite an in-use MSI with a different package.
• Pilot installation, upgrade, redeployment, and removal behavior before broad rollout.
• Document the GPO owner, target OU, security filtering, source path, rollback choice, and change approval.
• Retain relevant event logs and deployment evidence without collecting unrelated personal data.

Conclusion

A reliable GPO rollout depends on four things: a validated MSI, a stable UNC source, computer-readable permissions, and carefully controlled scope. Start with a pilot OU, assign the package under Computer Configuration, restart clients for foreground processing, and verify results with gpresult and event logs. When exceptions remain, collect evidence on the affected endpoint and use an authorized remote-support workflow rather than widening permissions or repeatedly redeploying the package without a diagnosis.

Frequently Asked Questions