How to Configure Group Policy Software Installation on Windows Server 2022

Group Policy Software Installation (GPSI) is a built-in Windows feature that allows administrators to deploy, maintain, and remove software on domain-joined computers and users without touching each machine individually. Using only Active Directory Group Policy, you can push MSI packages to thousands of machines automatically. This guide covers the complete GPSI workflow on Windows Server 2022 — from preparing the software share through troubleshooting failed deployments.

Understanding GPSI: Assign vs. Publish

GPSI offers two deployment methods: Assigning and Publishing. Understanding the difference is critical before creating any Software Installation policy.

Assigning to Computers (Computer Configuration): The software installs automatically when the computer starts up, during the next Group Policy refresh cycle. The installation is transparent to users and does not require any user action. This is the most common method for mandatory software deployment. Assigned computer software cannot be removed by users.

Assigning to Users (User Configuration): The software is advertised to the user. A shortcut appears on the desktop or in the Start Menu, and the software installs on demand the first time the user clicks the shortcut or opens an associated file type. If the user removes the software, it re-advertises itself at next logon.

Publishing to Users (User Configuration): The software appears in Add or Remove Programs (Programs and Features) in Control Panel. Users can choose to install it at any time. Published software is optional; it will not reinstall itself if removed. Software can only be published to users, not to computers.

MSI Package Requirements

GPSI requires MSI (Windows Installer) packages. EXE-based installers are not supported directly. If your software only comes as an EXE, you must either:

1. Check if the vendor provides a separate MSI download (many do).

2. Use a third-party repackaging tool to wrap the EXE in an MSI.

3. Consider using a software deployment tool like SCCM or Intune instead, which supports EXE deployments natively.

MSI packages must be completely silent — they should not prompt users during installation. Verify that the MSI supports silent installation:

# Test MSI silent installation manually before deploying via GPO
msiexec.exe /i "\serversoftware$Applicationapp.msi" /qn /norestart /log "C:tempinstall.log"

The /qn flag means “quiet, no UI.” If the MSI completes without any dialog boxes, it is suitable for GPSI deployment.

Preparing the UNC Software Share

Software packages must be stored on a network share accessible by the computers and users that will receive them. The UNC path (not a drive letter) must be used in the GPO — Group Policy always runs in a context where drive mappings may not be available.

Create the share on a file server (or the domain controller, though separating this is best practice for production):

# Create the software distribution folder and share
New-Item -ItemType Directory -Path "C:SoftwareDistribution"
New-SmbShare -Name "Software$" -Path "C:SoftwareDistribution" -Description "GPSI Software Repository" -ReadAccess "Domain Computers", "Domain Users" -FullAccess "Domain Admins"

# Verify the share
Get-SmbShare -Name "Software$"
Get-SmbShareAccess -Name "Software$"

The dollar sign suffix hides the share from casual browsing. The critical permission is read access for Domain Computers. When a computer-assigned GPO installs software at startup, it runs in the SYSTEM context of the client machine, which authenticates to the network as the computer account (e.g., CONTOSODESKTOP01$). Without read permission for Domain Computers, the installation will fail silently.

For user-published software, Domain Users read access is required since the software installs in the user’s context.

Also set the NTFS permissions:

# Grant Domain Computers read NTFS permission on the share folder
$acl = Get-Acl "C:SoftwareDistribution"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("CONTOSODomain Computers", "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
Set-Acl "C:SoftwareDistribution" $acl

Place each MSI in a dedicated subfolder within the share to keep packages organized. Example structure:

\fileserverSoftware$
    7-Zip
        7z2301-x64.msi
    Notepad++
        npp.8.6.Installer.x64.msi
    VLC
        vlc-3.0.20-win64.msi

Creating the Software Installation GPO

Open Group Policy Management Console (GPMC) on the domain controller or on an admin workstation with RSAT installed. Create a new GPO and link it to the OU containing the target computers or users.

To assign software to computers:

1. Edit the GPO > navigate to Computer Configuration > Policies > Software Settings > Software Installation.

2. Right-click Software Installation > New > Package.

3. In the file browser, enter the UNC path to the MSI (do not browse locally — always use the UNC path).

4. Select “Assigned” and click OK.

To publish software to users:

1. Edit the GPO > navigate to User Configuration > Policies > Software Settings > Software Installation.

2. Right-click Software Installation > New > Package.

3. Enter the UNC path to the MSI.

4. Select “Published” and click OK. (Or “Assigned” for mandatory user software.)

You can also perform this via command-line on the client to verify the GPO applies correctly:

# Force Group Policy update on a client
gpupdate /force

# Check which software policies are applied
gpresult /r /scope computer | Select-String -Pattern "Software Installation" -Context 2,2

Using Transform Files (.mst)

MST (transform) files customize an MSI installation without modifying the original MSI. Transforms are used to pre-configure settings like installation directory, feature selection, or license keys. Create transforms using tools like Orca (part of Windows SDK) or commercial MSI editors like Advanced Installer.

To apply a transform when deploying via GPSI:

1. Right-click the package in Software Installation > Properties > Modifications tab.

2. Click Add and browse to the .mst file using its UNC path.

3. Transforms must be stored on the same share as the MSI and be accessible to client machines.

Note: Transforms must be added when the package is first created. You cannot add a transform to an already-deployed package — you would need to remove and re-add the package with the transform.

Software Upgrades via GPO

When a new version of software is available, GPSI’s upgrade feature handles the migration from old to new version. In the package properties of the new version, go to the Upgrades tab and add the old version package as the package being upgraded. Set “Uninstall the existing package, then install the upgrade package” for a clean upgrade, or “Package can upgrade over the existing package” if the new MSI supports in-place upgrades.

Mark the upgrade as required if you want all machines to receive it automatically, or optional if users can choose to upgrade.

Software Removal

To remove deployed software from machines, right-click the package in Software Installation and select All Tasks > Remove. Two options are presented:

Immediately uninstall the software from users and computers: The software is removed at the next Group Policy refresh (or startup/logon for computer/user-assigned software). This adds an uninstall instruction to the GPO.

Allow users to continue to use the software, but prevent new installations: Existing installations remain but new deployments stop. Use this for a soft decommission.

The Application Management Service

GPSI depends on the Application Management Windows service (AppMgmt). This service processes Group Policy Software Installation entries during computer startup and user logon. If this service is stopped or disabled, software deployment will fail completely.

# Check Application Management service status on a client
Get-Service AppMgmt

# Set it to Automatic and start it
Set-Service AppMgmt -StartupType Automatic
Start-Service AppMgmt

The service is set to Manual by default and is started automatically when GPSI policies apply. If it is explicitly disabled by policy or other means, re-enable it.

Troubleshooting Software Installation GPO

GPSI failures are logged in the Application event log on the client machine. The key Event IDs to look for are:

Event ID 101: The assignment of application failed. This is the most common failure event. The message will indicate whether the failure was in finding the MSI (permissions or path problem) or in the installation itself.

Event ID 108: Failed to apply changes to software installation settings. This typically occurs when the Application Management service cannot process the GPO instructions.

To diagnose Event ID 101:

# Check software installation events on the client
Get-WinEvent -LogName Application -ProviderName "Application Management" -MaxEvents 20 |
    Where-Object { $_.Id -in @(101, 102, 103, 104, 108) } |
    Format-List TimeCreated, Id, Message

Common causes and fixes for Event ID 101:

1. Access denied to the UNC path: Verify that DOMAINDomain Computers has read permission on both the SMB share and NTFS. Test by running \fileserverSoftware$Appapp.msi in a Run dialog while logged in as a local administrator — this tests network access.

2. MSI not found: Confirm the exact UNC path in the GPO matches the actual file location. Paths are case-sensitive on some configurations.

3. MSI not silent: If the MSI requires user interaction, it will fail in the background during computer startup. Test with msiexec /i "path.msi" /qn to verify silence.

Enable verbose Group Policy logging on a test client for deeper diagnostics:

# Enable verbose GP logging via registry
reg add "HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDiagnostics" /v GPSvcDebugLevel /t REG_DWORD /d 0x30002 /f

# Logs appear in C:Windowsdebugusermodegpsvc.log
gpupdate /force
notepad C:Windowsdebugusermodegpsvc.log

Another useful diagnostic is the Resultant Set of Policy (RSoP) tool, which shows exactly which GPOs applied and which software packages were processed:

# Generate RSoP report to HTML
gpresult /h C:tempgpresult.html /f
Start-Process "C:tempgpresult.html"

Redeploying a Package

If a software package becomes corrupted on client machines, GPSI can force reinstallation. Right-click the package in Software Installation > All Tasks > Redeploy Application. This flags all clients to reinstall the application at next startup or logon, even if the MSI reports it as already installed.

GPSI vs. SCCM and Intune

Group Policy Software Installation has significant limitations compared to modern deployment solutions. It supports only MSI packages (no EXE, MSIX, or scripts), offers no reporting on deployment success or failure beyond client event logs, cannot deploy to non-domain-joined machines, and has no throttling or bandwidth management.

Microsoft SCCM (Configuration Manager) and Microsoft Intune address all these limitations. SCCM offers application deployment with rich reporting, dependency management, software inventory, and support for any installer type. Intune provides the same for cloud-joined and hybrid-joined devices with no on-premises infrastructure requirement.

GPSI remains valuable for small to medium environments that already have Active Directory infrastructure and need to deploy a handful of standard MSI packages without additional licensing costs. For environments with complex software requirements, high compliance reporting needs, or mixed Windows/non-Windows estates, SCCM or Intune is the appropriate choice.

For Windows Server 2022 specifically, GPSI is commonly used to deploy agents (monitoring agents, security agents, VPN clients) to servers in bulk during provisioning, where the simplicity of Group Policy is preferable to the overhead of a full SCCM deployment.