Using package on Windows

The built-in package resource type handles many different packaging systems on many operating systems, so not all features are relevant everywhere. This page offers guidance and tips for working with package on Windows.

package { 'mysql':
  ensure          => '5.5.16',
  source          => 'N:\packages\mysql-5.5.16-winx64.msi',
  install_options => ['INSTALLDIR=C:\mysql-5.5'],
}

package { "Git version 1.8.4-preview20130916":
 ensure          => installed,
 source          => 'C:\code\puppetlabs\temp\windowsexample\Git-1.8.4-preview20130916.exe',
 install_options => ['/VERYSILENT']
}

Supported package types: MSI and EXE

Puppet can install and remove MSI packages and executable installers on Windows. Both package types use the default windows package provider.

Alternatively, a Chocolatey package provider is available on the Forge.

The `source` attribute is required

When managing packages using the windows package provider, you must specify a package file using the source attribute.

The source can be a local file or a file on a mapped network drive. For MSI installers, you can use a UNC path. Puppet URLs are not supported for the package type’s source attribute, but you can use file resources to copy packages to the local system. The source attribute accepts both forward- and backslashes.

The package name must be the `DisplayName`

The title (or name) of the package must match the value of the package’s DisplayName property in the registry, which is also the value displayed in the Add/Remove Programs or Programs and Features control panels.

If the provided name and the installed name don’t match, Puppet assumes the package is not installed and tries to install it again.

To determine a package's DisplayName:

Install the package on an example system.
Run puppet resource package to see a list of installed packages.
Copy the name of the package from the list.

Some packages (Git is a notable example) change their display names with every newly released version. See the section below on handling package versions and upgrades.

Install and uninstall options

The Windows package provider also supports package-specific install_options (such as install directory) and uninstall_options. These options vary across packages, so see the documentation for the specific package you’re installing. Options are specified as an array of strings or hashes.

MSI properties can be specified as an array of strings following the property=key pattern; use one string per property. Command line flags to executable installers can be specified as an array of strings, with one string per flag.

For file path arguments within the install_options attribute (such as INSTALLDIR), use backslashes (\), not forward slashes. Escape your backslashes appropriately. For more info, see Handling file paths on Windows.

Use the hash notation for file path arguments because they might contain spaces. For example:

install_options => [ { 'INSTALLDIR' => ${packagedir} } ]

Handling versions and upgrades

Setting ensure => latest (which requires the upgradeable feature) doesn’t work on Windows, because Windows doesn’t have central package repositories like on most *nix systems.

There are two ways to handle package versions and upgrades on Windows.

Packages with real versions

Many packages on Windows have version metadata. To tell whether a package has usable version metadata, install it on a test system and use puppet resource package to inspect it.

To upgrade these packages, replace the source file and set ensure => '<VERSION>'. For example:

package { 'mysql':
  ensure          => '5.5.16',
  source          => 'N:\packages\mysql-5.5.16-winx64.msi',
  install_options => ['INSTALLDIR=C:\mysql-5.5'],
}

The next time Puppet runs, it will notice that the versions don’t match and will install the new package. This makes the installed version match the new version, so Puppet won’t attempt to re-install the package until you change the version in the manifest again.

The version you use in ensure must exactly match the version string that the package reports when you inspect it with puppet resource. If it doesn’t match, Puppet will repeatedly try to install it.

Packages that include version info in their `DisplayName`

Some packages don’t embed version metadata; instead, they change their DisplayName property with each release. The Git packages are a notable example.

To upgrade these packages, replace the source file and update the resource’s title or name to the new DisplayName. For example:

package { "Git version 1.8.4-preview20130916":
 ensure          => installed,
 source          => 'C:\code\puppetlabs\temp\windowsexample\Git-1.8.4-preview20130916.exe',
 install_options => ['/VERYSILENT']
}

The next time Puppet runs, it will notice that the names don’t match and will install the new package. This makes the installed name match the new name, so Puppet won’t attempt to re-install the package until you change the name in the manifest again.

The name you use in the title must exactly match the name that the package reports when you inspect it with puppet resource. If it doesn’t match, Puppet will repeatedly try to install it.