Managing Windows Services with Puppet

Puppet may be a Linux-based system but it still boasts many Windows functions. Here is how you can manage Windows services with Puppet.

When managing servers via configuration management, one aspect that users love is the way to manage services. Whether that be starting, stopping or ensuring a service is running, configuration management solutions, such as Puppet make this very simple. One use case for this would be to set the DNS client service to always be running on a server, which is standard practice.

While Puppet is a Linux-based system and is predominately used to manage other Linux systems, it does support many Windows functions. Not only does it support them, but it does a reasonable job at doing so. In this article, I will show a few examples of how Puppet can manage Windows services, and how IT can gain control over their servers to ensure reliability.

Puppet Service Resource

In terms of managing Windows services, there are some limitations to the Puppet service resource. These are a few things Puppet cannot do with a Window service:

• Configuring service dependencies
• Setting “Run as”
• Expects the service to run as “SYSTEM”

With this said, there are ways to get around this limitation, since you can run PowerShell code within a Puppet manifest, it is certainly possible get past these.

Related: Managing Windows With Puppet

The Puppet service resource actually only has three configurable components. These are:

• Service name
• Ensure
• Enable

A simple manifest would look like this:

service { 'netlogon':

  ensure => 'running',

  enable => 'true'

}

This manifest is saying you want Puppet to ensure the netlogon service is running and enabled when you apply the configuration on a node.

Managing Services

As illustrated prior, starting and stopping services is extremely simple and is only needed with the ensure parameter. Simply changing ensure to stopped will stop the service:

service { 'netlogon':

  ensure => 'stopped'

}

Another great use of the service resource to is to enable or disable a service. If you want complete control over a system, it may be necessary to do this for every service on a system. Here, I change enable to false which means the service is not disabled on the target node that runs this manifest.

service { 'netlogon':

  ensure => 'stopped'

  enable => 'false'

}

Example Manifest for Multiple Services

In this manifest example, I want to ensure that multiple services are running when I apply it to my nodes. There are a few ways you can do this. First you can just list the service resource for each service like the examples I have given prior. Alternatively, you could create an array in Puppet that stores all the services you want to manage:

$service_name  = ['netlogon','BITS','snmptrap']

service { $service_name:

    ensure => 'running'

}

When this configuration applies on a node using puppet agent, it will cycle through each service in the $service_name variable to ensure it is running. If it is not running, it starts the service as you can see in the output

[Test-1]: PS C:\ > puppet agent --test

Info: Retrieving pluginfacts

Info: Retrieving plugin

Info: Loading facts

Info: Caching catalog for Test-1

Info: Applying configuration version '1523032913'

Notice: /Stage[main]/Main/Node[Test-1]/Service[netlogon]/ensure: ensure changed 'stopped' to 'running'

Info: /Stage[main]/Main/Node[Test-1]/Service[netlogon]: Unscheduling refresh on Service[netlogon]

Notice: /Stage[main]/Main/Node[Test-1]/Service[snmptrap]/ensure: ensure changed 'stopped' to 'running'

Info: /Stage[main]/Main/Node[Test-1]/Service[snmptrap]: Unscheduling refresh on Service[snmptrap]

Notice: /Stage[main]/Main/Node[Test-1]/Service[BITS]/ensure: ensure changed 'stopped' to 'running'

Info: /Stage[main]/Main/Node[Test-1]/Service[BITS]: Unscheduling refresh on Service[BITS]

Notice: Finished catalog run in 9.83 seconds