How to Configure Group Policy Software Installation on Windows Server 2025

How to Configure Group Policy Software Installation on Windows Server 2025

Group Policy Software Installation (GPSI) is the built-in mechanism in Active Directory environments for deploying, updating, and removing MSI-based applications across domain-joined computers without requiring third-party tools or agents. On Windows Server 2025, GPSI continues to be a practical solution for organizations managing a fleet of Windows machines that require consistent software deployment — particularly for internal line-of-business applications, admin tools, and standardized productivity software distributed as MSI packages. This guide covers the full GPSI workflow: creating a software distribution share, adding packages to GPOs, understanding the publish versus assign distinction, handling transforms, managing upgrades, and troubleshooting with gpresult, as well as the PowerShell App Deployment Toolkit as a modern complement for complex deployments.

Prerequisites

• Windows Server 2025 domain controller or a server with Group Policy Management Console (GPMC) installed
• Active Directory domain with organizational units (OUs) for targeting computers or users
• A file server or shared network path accessible to all target computers and users
• MSI packages for the software to be deployed (GPSI only supports MSI natively; EXE-based installers require repackaging or PSADT)
• Domain admin or delegated GPO management permissions
• Target machines running Windows 10/11 or Windows Server 2019/2022/2025

Step 1: Create the Software Distribution Share

GPSI installs software from a UNC path that must be accessible by the computer account (for computer-assigned packages) or user account (for user-published/assigned packages). Use a hidden administrative share with read-only access for client machines.

# Create the software distribution directory
New-Item -Path "D:SoftwareDeploy" -ItemType Directory -Force

# Create subdirectories per application
New-Item -Path "D:SoftwareDeploySevenZip" -ItemType Directory -Force
New-Item -Path "D:SoftwareDeployAdobeReader" -ItemType Directory -Force
New-Item -Path "D:SoftwareDeployNotePadPlusPlus" -ItemType Directory -Force

# Create a hidden share ($ suffix = hidden from network browsing)
New-SmbShare -Name "software$" -Path "D:SoftwareDeploy" `
    -Description "GPO Software Distribution Share" `
    -FullAccess "Domain Admins" `
    -ReadAccess "Domain Computers", "Authenticated Users"

# Verify the share
Get-SmbShare -Name "software$" | Select-Object Name, Path, Description
Get-SmbShareAccess -Name "software$"

Copy the MSI installers into their respective subdirectories. Always test that the SYSTEM account (representing the computer) can read the share by testing with \serversoftware$AppNameapp.msi from a client machine.

Step 2: Create and Configure the GPO

Create a dedicated GPO for software deployment. Separate GPOs per application or per department OU keep management clean and allow independent linking and filtering.

# Install GPMC module (if not already available)
Install-WindowsFeature -Name GPMC -IncludeManagementTools

Import-Module GroupPolicy

# Create a new GPO for software deployment
$gpo = New-GPO -Name "Deploy-SevenZip-Computers" -Domain "corp.example.com" `
    -Comment "Deploys 7-Zip 24.x MSI to workstations via Computer Configuration"

Write-Host "GPO created: $($gpo.DisplayName) | ID: $($gpo.Id)"

# Link the GPO to the target OU (Workstations OU in this example)
New-GPLink -Name "Deploy-SevenZip-Computers" `
    -Target "OU=Workstations,DC=corp,DC=example,DC=com" `
    -LinkEnabled Yes

Write-Host "GPO linked to Workstations OU."

Software Installation packages themselves are configured through the GPMC graphical editor or via the legacy gpedit.msc interface. Navigate to: Computer Configuration → Policies → Software Settings → Software Installation (for computer-assigned) or User Configuration → Policies → Software Settings → Software Installation (for user-published or user-assigned).

Step 3: Add an MSI Package to the GPO

Right-click Software Installation in the GPMC editor and select New → Package. Always browse to the UNC path (not a local drive letter) when adding the MSI — the path stored in the GPO must be network-accessible from client machines.

# PowerShell cannot directly add GPSI packages to the Software Installation node
# (it uses a COM-based interface). Use the GPMC MMC snap-in to add the MSI package.
# The following documents the UNC path to use when prompted in the UI:

$uncPath = "\filesrv01.corp.example.comsoftware$SevenZip7z2406-x64.msi"
Write-Host "Use this UNC path when adding the package in GPMC:"
Write-Host $uncPath

# After adding, you can verify the package was registered in the GPO via the XML definition:
Get-GPOReport -Name "Deploy-SevenZip-Computers" -ReportType Xml | `
    Select-String -Pattern "SoftwareInstallation|msi|package" -Context 2

Step 4: Publish vs. Assign — Understanding the Difference

GPSI offers two deployment modes with important behavioral differences:

• Assigned (Computer Configuration): The application is installed automatically during the next Group Policy refresh or machine startup. Users cannot remove it. This is the most common mode for mandatory software.
• Assigned (User Configuration): The application appears as a shortcut and file-type association on next user logon, and installs on first launch (document activation) or at next logon. Users cannot permanently remove it.
• Published (User Configuration only): The application is available in Programs and Features → Install a program from your network but does not install automatically. Users can install it on demand. Document activation still applies if file-type associations are configured.

# When adding packages via GPMC, the deployment type dialog presents these options.
# For computer-assigned (automatic silent install at next reboot):
# - Select: Computer Configuration > Software Installation > New Package > Assigned

# Check existing software installation policy entries on a target machine:
gpresult /scope computer /v | Select-String -Pattern "Software Installation" -Context 5

# Force Group Policy refresh on remote target to trigger installation
Invoke-GPUpdate -Computer "ws-workstation01.corp.example.com" -Force -RandomDelayInMinutes 0

Step 5: Apply MST Transforms to Customize Installation

MST (Microsoft Transform) files customize the default MSI installation — suppressing features, setting default values, configuring silent installation properties — without modifying the original MSI.

# Place the transform file alongside the MSI in the distribution share
# Example: suppress Adobe Reader toolbar install and set default PDF viewer

Copy-Item -Path "D:TransformFilesAdobeReader-Silent.mst" `
    -Destination "D:SoftwareDeployAdobeReader"

# The transform association is configured in the GPMC Package Properties dialog:
# Package > Properties > Modifications tab > Add the .mst file path
# Always use the UNC path:
$transformUNC = "\filesrv01.corp.example.comsoftware$AdobeReaderAdobeReader-Silent.mst"
Write-Host "MST UNC path: $transformUNC"

# Verify the MSI is compatible with the transform (version/upgrade codes must match):
$msiPath = "D:SoftwareDeployAdobeReaderAcroRdrDC2500120432_en_US.msi"
$installer = New-Object -ComObject WindowsInstaller.Installer
$db = $installer.OpenDatabase($msiPath, 0)
$view = $db.OpenView("SELECT Value FROM Property WHERE Property='ProductCode'")
$view.Execute()
$record = $view.Fetch()
Write-Host "Product Code: $($record.StringData(1))"

Step 6: Upgrade Packages

When a new version of an MSI is released, configure an Upgrade Package relationship in the GPO so the old version is automatically removed and replaced during the next policy refresh.

# In the GPMC editor, right-click the new package > Properties > Upgrades tab
# Click Add, select the older package from this GPO or another GPO
# Choose "Uninstall the existing package, then install the upgrade package"

# Alternatively, set "Package can upgrade over the existing package" for MSIs
# that support in-place major upgrades (same ProductCode, higher ProductVersion)

# You can verify upgrade relationships via GPO XML:
Get-GPOReport -Name "Deploy-SevenZip-Computers" -ReportType Xml | `
    Select-String -Pattern "Upgrades|RequiredPackage" -Context 3

# Force policy re-evaluation and package re-installation on a specific computer:
Invoke-GPUpdate -Computer "ws-workstation02.corp.example.com" -Force

Step 7: Remove and Redeploy Packages

# To remove a package, right-click it in the GPMC Software Installation node > All Tasks > Remove
# Choose either:
#   "Immediately uninstall the software from users and computers" (forced removal)
#   "Allow users to continue to use the software, but prevent new installations" (soft removal)

# For forced redeployment (re-install even if already installed):
# Right-click package > All Tasks > Redeploy application
# This resets the package state so it reinstalls at next GP refresh

# Check installed software on a remote machine:
Invoke-Command -ComputerName "ws-workstation01" -ScriptBlock {
    Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*7-Zip*" } |
    Select-Object Name, Version, InstallDate
}

Step 8: Troubleshoot with gpresult and Event Logs

# Generate an HTML Group Policy results report for a specific user and computer
gpresult /h "C:Reportsgp_report_ws01.html" /user "corpjdoe" /f
Start-Process "C:Reportsgp_report_ws01.html"

# Check GP results in XML format for parsing
gpresult /scope computer /x "C:Reportsgp_computer.xml" /f

# Check Software Installation event logs on the client
Get-WinEvent -LogName "Application" -ComputerName "ws-workstation01" |
    Where-Object { $_.ProviderName -eq "MsiInstaller" -and $_.TimeCreated -gt (Get-Date).AddDays(-1) } |
    Select-Object TimeCreated, Id, Message | Format-Table -Wrap

# Check GP operational log for policy processing errors
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -ComputerName "ws-workstation01" |
    Where-Object { $_.LevelDisplayName -in "Error","Warning" } |
    Select-Object TimeCreated, Message | Format-List

Step 9: PowerShell App Deployment Toolkit (PSADT) as a Modern Alternative

For EXE-based installers, complex installation logic, or deployments requiring user interaction deferral, the PowerShell App Deployment Toolkit (PSADT) wraps any installer in a standardized framework that integrates with GPSI, MECM, or Intune.

# PSADT structure — place in the software share alongside the installer:
# \filesrv01software$AppName
#   Deploy-Application.ps1      <- main script
#   Deploy-Application.exe      <- launcher (runs PS as SYSTEM)
#   Files                      <- installers, MSIs, etc.
#   SupportFiles               <- transforms, configs
#   AppDeployToolkit           <- PSADT framework files

# Example Deploy-Application.ps1 (Install section):
# $installTitle = "7-Zip 24.06"
# Execute-MSI -Action Install -Path "7z2406-x64.msi" -Transform "silent.mst" `
#             -Parameters "REBOOT=ReallySuppress"

# Configure GPSI to run Deploy-Application.exe as the install command
# by wrapping it in a bootstrapper MSI (use WiX or MSIX packaging tools to create a thin MSI)

# Test PSADT installation silently:
& "\filesrv01.corp.example.comsoftware$SevenZipDeploy-Application.exe" -DeploymentType Install -DeployMode Silent
Write-Host "PSADT deployment exit code: $LASTEXITCODE"

Group Policy Software Installation on Windows Server 2025 remains a viable, zero-cost software deployment mechanism for Active Directory environments, particularly for MSI-based applications where silent installation with transforms is sufficient. For organizations requiring more flexibility — complex dependency chains, pre/post-install scripting, non-MSI formats, or user notification and deferral dialogs — augmenting GPSI with PSADT bridges the gap between the simplicity of Group Policy and the power of commercial deployment tools. As environments grow beyond a few hundred machines or require detailed compliance reporting, migrating to Microsoft Endpoint Configuration Manager or Microsoft Intune offers significantly richer inventory, packaging, and reporting capabilities.