Use Puppet Bolt Tasks to Manage Windows Server
If you missed my piece last month on running commands on Windows Server using Puppet Bolt, you will need to read that and install Puppet Bolt on Windows or Linux before following the instructions below. Puppet Bolt is a free, open source, agentless, cross-platform tool that aims to make it easier to get started with automation. Because Bolt is agentless, you can use it to orchestrate operations without installing agents or using a Puppet Master server; and it can be used in mixed Linux and Windows Server environments.
In today’s article, I’m going to show you how to run Tasks on a remote Windows server. Tasks are scripts used to perform single, ad-hoc actions. Tasks can be grouped into Plans that use other logic to carry out more complex tasks. But that is for another day. I’m running Bolt in Ubuntu Linux, but the same commands should work if you have installed Bolt in Windows. Additionally, you should be able to use the same Tasks against a remote Linux server.
Run Built-In Puppet Bolt Tasks
You can easily create your own tasks but before looking at that, you should familiarize yourself with running the tasks that are available with Bolt out-of-the-box. To list the available tasks, run the command below:
bolt task show
Optionally, you can specify a modules path. While tasks are essentially scripts, they are stored in modules and can have metadata so that they can reused and stored easily. Tasks can be single-platform or cross-platform. The metadata can be used to explain when to use which implementation if a task is cross-platform.
bolt task show --modulepath modules
You’ll see several tasks listed, like reboot and service. Some task names consist of two parts, like puppet_agent::install. The first part of the task name indicates the module, and the second part, the name of the task file without its file extension.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
To find more information about a specific task, add the task after ‘show’. For instance, to find out how to use the service task, run the command below:
bolt task show service
Install the Puppet Agent
Before we run a task remotely, let’s try running a task locally. The command below shows the version of the Puppet agent installed on the local device. In this case I don’t have the Puppet agent installed locally but the command should still provide some output to reflect that.
bolt task run puppet_agent::version --nodes localhost
Now let’s run the same command on a remote Windows device. You can see below that I need to specify the protocol for communication, in this case WinRM, the node IP address or DNS name, and the user account I will use for authentication on the remote device. When you run the command below, you will be prompted to enter the password for the account specified in the -u parameter.
bolt task run puppet_agent::version --nodes winrm://192.168.76.121 -u administrator --no-ssl --password
The Puppet agent isn’t installed on the remote Windows server, so again the output should reflect that. I can install the agent by changing version for install in the task name.
bolt task run puppet_agent::install --nodes winrm://192.168.76.121 -u administrator --no-ssl --password
The task will take some time complete and the remote Windows device must have Internet access to download the agent binaries. You can then use the puppet_agent::version task again to check the agent installed and which version.
There’s no requirement to reboot the node after the agent is installed but this is how you would do it using Puppet Bolt:
bolt task run reboot --nodes winrm://192.168.76.121 -u administrator --no-ssl --password
Finally, let’s use the service task to get the status of a service and then restart it. The command below returns the status of the Application Management service. Note the action and name data being passed to the task.
bolt task run service action=status name=AppMgmt --nodes winrm://192.168.76.121 -u administrator --no-ssl --password
If I want to restart the service, all I must do is change action=status to action=restart:
bolt task run service action=restart name=AppMgmt --nodes winrm://192.168.76.121 -u administrator --no-ssl --password
That is it for today! In an upcoming article, I’ll show you how to create your own Puppet Bolt Tasks using PowerShell scripts.