Deploying MSI Packages via GPO on Windows XP

During the Windows XP era, network administrators relied on Active Directory Group Policy Objects (GPOs) to automate software distribution across enterprise environments. This article explains the architectural mechanism of deploying Microsoft Installer (MSI) packages to Windows XP clients via Group Policy, covering the distribution share setup, the distinction between assigning and publishing software, and how the Windows XP Client-Side Extension (CSE) coordinated with the Windows Installer engine to complete unattended installations.

Infrastructure and Package Preparation

Deploying software via Group Policy required a domain environment managed by Windows 2000 Server or Windows Server 2003, with client workstations running Windows XP Professional. The deployment pipeline relied on three core components:

  1. A Distribution Point: A standard network share referenced by a Universal Naming Convention (UNC) path (e.g., \\Server\Share\Package.msi). Windows XP clients required read permissions on this share. For computer-targeted deployments, the Domain Computers group needed read access because installations ran under the local machine account.
  2. Windows Installer Package (.msi): The software had to be packaged in the MSI format containing the database of files, registry changes, and installation logic. Transform files (.mst) were used alongside MSIs to customize configurations.
  3. Software Installation Policy: Created using the Group Policy Management Console (GPMC) or Active Directory Users and Computers (ADUC) under either Computer Configuration or User Configuration.

Assigned vs. Published Deployment

Administrators configured MSI deployments as either "Assigned" or "Published," which determined when and how the software landed on the Windows XP system:

  • Assigned to Computers: The software was targeted at machines regardless of who logged in. The package was installed automatically during the computer boot process before the user reached the Windows XP logon prompt (Ctrl+Alt+Delete).
  • Assigned to Users: The software was targeted at user accounts. In Windows XP, this created "advertised" shortcuts on the user's Start Menu or desktop. The full installation was triggered on-demand the first time the user launched the shortcut, or it was installed directly at user logon.
  • Published to Users: The software was made available to the user without being proactively installed. Windows XP populated the package into the Add/Remove Programs control panel applet under "Add New Programs," allowing users to initiate the install manually without needing local administrative privileges.

The Windows XP Execution Process

When a Windows XP machine processed a GPO containing an MSI deployment, the installation followed a structured internal sequence:

  1. Policy Refresh: At startup (for computer policies) or logon (for user policies), the Windows XP Group Policy engine contacted the domain controller to evaluate the sysvol directory and Active Directory attributes.
  2. Client-Side Extension (CSE) Processing: The Group Policy engine identified the Software Installation Client-Side Extension (handled by appmgmts.dll, the Application Management service). The CSE compared the GUID of the MSI package in the policy against the locally cached GPO history in the registry.
  3. Execution Handoff to msiexec.exe: If the package was not yet installed, the CSE called the local Windows Installer service (msiexec.exe).
  4. Privilege Elevation: For Computer Configuration policies, msiexec.exe executed the package under the NT AUTHORITY\SYSTEM context. This allowed the installation to proceed silently with full administrative rights, even if standard, non-privileged users were the primary operators of the workstation.
  5. Caching and Registration: Windows XP cached the stripped-down MSI database in %SystemRoot%\Installer and registered the product's GUID in the system registry, tracking state changes for future removal or upgrades.