Docs / Overview of Puppet on Windows

Overview of Puppet on Windows

Puppet runs on Microsoft Windows® and can manage Windows systems alongside *nix systems. This page will help get you oriented and ready to manage Windows systems with Puppet.


Puppet Enterprise

To install Puppet Enterprise on Windows, see the Puppet Enterprise manual’s installation instructions.

Open Source

To install open source Puppet on Windows, follow the instructions on the following pages, in order:


  • Windows systems can run puppet agent and puppet apply, but they can’t act as a puppet master server.
  • Puppet is available in 32- and 64-bit versions. Install the appropriate Puppet package for your version of Windows. (Note that Windows Server 2003 requires 32-bit Puppet.)
  • Puppet should usually run with elevated privileges. If you want to run any of Puppet’s commands interactively on systems with UAC, you’ll have to start a command prompt by right-clicking and choosing “Run as administrator.”
  • Puppet’s configuration and data are stored in different places on different Windows versions. For more details, see the Puppet reference manual pages on the confdir and the vardir.

For more information, see:

Writing Manifests

In general, manifests written for Windows nodes work the same way as manifests written for *nix nodes.

Resource Types

Some *nix resource types aren’t supported on Windows, and there are some Windows-only resource types.

The following core resource types can be managed on Windows:

Also, there are some popular optional resource types for Windows.

Handling File Paths

Some resource types take file paths as attributes. On Windows, there are some extra things to take into account when writing file paths, including directory separators. For more info, see:

Line Endings

Windows systems generally use different line endings in text files than *nix systems do. Puppet manifest files can use either kind of line ending.

There are a few subtleties of behavior when handling the content of managed files. For details, see the note on line endings in the language reference.


Windows nodes with a default install of Puppet will include the following notable and identifying facts, which can be useful when writing manifests:

  • kernel => windows
  • operatingsystem => windows
  • osfamily => windows
  • env_windows_installdir — This fact will contain the directory in which Puppet was installed.
  • id — This fact will be <DOMAIN>\<USER NAME>. You can use the user name to determine whether Puppet is running as a service or was triggered manually.

Important Windows Concepts for Unix Admins

Windows differs from *nix systems in many ways, several of which affect how Puppet works.

Security Context

On Unix, puppet is either running as root or not. On Windows, this maps to running with elevated privileges or not.

For more information, see the following pages in the Puppet reference manual:

File System Redirection (Windows Server 2003 or older versions of Puppet)

As of Puppet 3.7, the Puppet agent can run as either a 32- or a 64-bit process. This means that as long as you’ve installed the correct package for your version of Windows, file system redirection should no longer be an issue.

However, if you are running Windows Server 2003, which is incompatible with 64-bit Puppet, or if you are using an earlier version of Puppet, file system redirection will still affect you. Please see Language: Handling File Paths on Windows for how to safely handle file system redirection when running 32-bit Puppet on a 64-bit Windows system. Note that the information about file system redirection applies to extensions as well.

Developing Extensions

If you’re developing custom types and providers or writing custom facts, be aware that the File System Redirector and the Registry Redirector will also affect these types, providers, and facts.

Registry Redirection

If you need to access registry keys in the native 64-bit registry space, you’ll need to make sure you opt out of redirection. Here’s an example of avoiding redirection in a custom fact:

    Facter.add(:myfact) do
      confine :kernel => :windows
      setcode do
        require 'win32/registry'

        value = nil
        hive = Win32::Registry::HKEY_CLASSES_ROOT'SOFTWARE\Somewhere\SomeValue',  Win32::Registry::KEY_READ | 0x100) do |reg|
          value = reg['SomeValue']

The addition of | 0x100 ensures the registry is opened without redirection so you can access the keys you expect to access. For more information, see Microsoft’s MSDN Reference on registry redirection.


The most common points of failure on Windows systems aren’t the same as those on *nix. For more details, see:

↑ Back to top