For details about invoking the Puppet agent command, see the puppet agent man page.
This page describes how Puppet agent behaves on Windows systems. For information about Linux, OS X, and other Unix-like operating systems, see Puppet Agent on *nix Systems.
Not all operating systems can manage the same resources with Puppet; some resource types are OS-specific, and others may have OS-specific features. See the [resource type reference] for details.
Puppet agent runs as a specific user (defaulting to
LocalSystem) and initiates outbound connections on port 8140.
By default, Puppet agent runs as the
LocalSystem user. This lets it manage the configuration of the entire system, but prevents it from accessing files on UNC shares.
Puppet can also run as a different user. You can change the user in the Service Control Manager (SCM). To start the SCM, choose “Run…” from the Start menu and type
You can also specify a different user when installing Puppet. To do this, install via the command line and specify the required MSI properties (
Puppet agent’s user can be a local or domain user. If this user isn’t already a local administrator, the Puppet installer will add it to the
Administrators group. The installer will also grant Logon as Service to the user.
By default, Puppet’s HTTPS traffic uses port 8140. Your OS and firewall must allow Puppet agent to initiate outbound connections on this port.
If you want to use a non-default port, you’ll have to change the
masterport setting on all agent nodes, and ensure that you’ve changed your Puppet master’s port as well.
When running as a service, Puppet agent logs messages to the Windows Event Log. You can view its logs by browsing the Event Viewer. (Control Panel → System and Security → Administrative Tools → Event Viewer)
When running in the foreground with the
--test options, Puppet agent logs directly to the terminal.
When started with the
--logdest <FILE> option, Puppet agent logs to the file specified by
In Puppet Enterprise, you can browse these reports in the PE console’s node pages, and you can analyze correlated events with the PE event inspector.
In a normal Puppet site, every node should periodically do configuration runs, to revert unwanted changes and to pick up recent updates.
On Windows nodes, there are two main ways to do this:
Since the Windows version of the Puppet agent service is much simpler than the *nix version, there’s no real performance to be gained by running Puppet as a scheduled task. All users who want scheduled configuration runs should run the Windows service.
By default, the Puppet installer will configure Puppet agent to run as a Windows service and will automatically start it. No further action is needed. Puppet agent will do configuration runs at a set interval.
# C:\ProgramData\PuppetLabs\puppet\etc\puppet.conf [agent] runinterval = 2h
If you don’t need an aggressive schedule of configuration runs, a longer run interval will let your Puppet master server(s) handle many more agent nodes.
Once the run interval has been changed, the service will stick to the prior schedule for the next run and then switch to the new run interval for subsequent runs.
The Puppet agent service defaults to starting automatically. If you’d rather start it manually or disable it, you can configure this during installation. To do this, install via the command line and specify the
PUPPET_AGENT_STARTUP_MODE MSI property.
You can also configure this after installation with the Service Control Manager (SCM). To start the SCM, choose “Run…” from the Start menu and type
You can also configure agent service with the
sc.exe command. To prevent the service from starting on boot:
C:\>sc config puppet start= demand [SC] ChangeServiceConfig SUCCESS
(Note that the space after
start= is mandatory! Also note that this must be run in cmd.exe; this command won’t work from PowerShell.)
To restart the service:
C:\>sc stop puppet C:\>sc start puppet
To change the arguments used when triggering a Puppet agent run (this example changes the level of detail that gets written to the Event Log):
C:\>sc start puppet --debug --logdest eventlog
Some sites prefer to only run Puppet agent on demand; others use scheduled runs, but occasionally need to do an on-demand run.
Puppet agent runs can be started locally (while logged in to the target system), or remotely via Puppet Enterprise’s orchestration tools.
On Windows, you can start a configuration run with the “Run Puppet Agent” Start menu item. This will show the status of the run in a command prompt window.
You must be logged in as an administrator to do this. On Windows 7/2008 and later, Windows will ask for User Account Control confirmation when you start a configuration run:
If you want to run other Puppet-related commands, you must start a command prompt with administrative privileges. You can do this with either the standard
cmd.exe program, or the “Start Command Prompt with Puppet” Start menu item added by the Puppet installer.
On Windows 7 or 2008, you must right-click the start menu item and choose “Run as administrator:”
This will ask for UAC confirmation:
To run Puppet agent remotely on any number of systems, you should use Puppet Enterprise’s orchestration tools. For info, see the Puppet Enterprise manual page on triggering Puppet runs.
Puppet agent on Windows doesn’t support the deprecated Puppet kick command.
You can prevent Puppet agent from doing any Puppet runs by starting a command prompt with elevated privileges and running
puppet agent --disable "<MESSAGE>". You can re-enable it with
puppet agent --enable.
If Puppet agent attempts to do a configuration run while disabled — either a scheduled run or a manually triggered one — it will log a message like:
Notice: Skipping run of Puppet configuration client; administratively disabled (Reason: 'Investigating a problem 5/23/14 -NF'); Use 'puppet agent --enable' to re-enable.