Boost your efficiency by automating mundane tasks with Ansible for Windows, and learn a little about Linux and Ansible along the way.

Get the newsletter

We are searching for a champion, a Windows administrator willing to venture out into the world of Ansible automation. No, you will not need to know Bash scripting or how to navigate your way around a Linux terminal. All you need is the desire all admins share: to complete mundane tasks as quickly as possible.

While there have been strides in the integration of Windows and Ansible, please be aware that at this present time and as of the latest version of Ansible version, Linux is still required for Ansible to run and manage your remote Windows nodes. However, you should not fret, as currently, Windows has a Linux subsystem called WSL or Windows Subsystem for Linux. There are instructions to help you install WSL.

If you are a Windows admin with zero experience with Linux and Ansible, it is neither hard nor time-consuming to get started and run your first Ansible playbook. You can make a positive impact on your organization's infrastructure, increase its return on investment (ROI), and get more time to innovate by automating mundane tasks, such as deploying services or making user account changes, with Ansible playbooks.

Ansible can bring automation to a mixed operating system environment and provides an efficient way to get to an infrastructure-as-code (IaC) state without burdening your administrators. Ansible is not a replacement for System Center Configuration Manager (SCCM) or Chocolatey; it's a supplemental tool that allows you to automate the services your software provides.

Get started

Remoting into Windows servers or clients from the Ansible control machine requires Windows Remote Manager (WinRM) to be properly configured. Fortunately, the Ansible team wrote a PowerShell script, ConfigureRemotingForAnsible, that makes it easy to get started with Ansible for Windows in your development or testing environment. The script configures WinRM on any supported Windows server or client target.

Ansible can use multiple authentication transport schemes, including NTLM, Kerberos, and basic authentication. For this tutorial, we will use the Kerberos authentication method (assuming the Windows server is registered to a domain).

The ConfigureRemotingForAnsible script has basic auth enabled by default; to disable basic auth and enable Kerberos, run the following at the command prompt:

winrm set winrm/config/service/auth @{Basic="false"; Kerberos="true"}

Set up your control machine

Our control machine is running CentOS Linux release 7.5.1804(core); you could also use RHEL 7 or Fedora 19 or later releases. To install and configure the control machine to manage Windows target hosts:

On the control machine, install the ansible and python2-winrm packages with the following command:

yum install -y ansible python2-winrm

On the control machine, install Python Kerberos:

yum install -y python-requests-kerberos

Open the /etc/krb5.conf file and edit the following setting (using your own domain info):

[realms]
EXAMPLE.COM = {
kdc = ad.example.com
}

[domain_realm]
.example.com = EXAMPLE.COM

Set up your inventory

Ansible's inventory consists of all the end nodes or target hosts that can be managed by the Ansible host, which is also known as the Ansible controller. You can configure inventory to be static or dynamic; in this tutorial, we will be configuring static inventory.

While you can configure static inventory in /etc/ansible/hosts, it's a best practice to create a different inventory file that can be edited as needed; e.g., if you need to change the static inventory to a dynamic inventory to accommodate infrastructure changes. The inventory will be configured by groupings. Groups start with square brackets ([ ]), and a collection of servers represents that group (e.g., [group]).

Ansible inventories can take many forms: static file formats, such as .ini, .yaml, and .toml, as well as dynamically generated inventories from scripts or plugins. The .ini format is appropriate for small, simple inventories, which can be as simple as a list of host names to run against.

Ansible allows you to set variables for each group in your Ansible hosts' file by inserting the name of the <server group name>:vars* inside square brackets. The code below sets variables for WinRM on an Ansible control machine.

Ansible can check the ping status of all servers that are part of the groups linux-server or win-server by running an ad-hoc command, such as:

ansible linux-server -i (some local path)/(inventory file) -m ping

or

ansible win-server -m win_ping --ask-pass

Configure IIS & the Apache web application

Create Ansible playbooks

It can be tedious and time-consuming to use Ansible ad-hoc commands when you need to do a task more complex than just pinging a target host or getting the host's uptime information. Ansible playbooks are YAML-formatted files that contain a set of configurations and tasks that achieve an end state on an Ansible Windows or Linux target host. The ad-hoc command above could become:

Linux: Configure an Apache web page

If you're asked to be a hybrid admin, you may assume that you'll only be responsible for handling Windows environments. But, with the admin role shifting to DevOps, you might be asked to touch a Linux server or two to support hosts running Apache. Here are some instructions to help you along.

To create an Apache web page:

Apache must be installed

Apache must be enabled and started; this can be done in RHEL using systemd:

systemctl enable httpd

systemctl start httpd

Make firewalld changes to make sure the HTTP/HTTPS ports are added to the firewall rules along with the ports:

command: firewalld-cmd --permanent -add-service={http,https}

command: firewall-cmd --permanent -add-port={80,443}

Run the Ansible playbook below to install and enable Apache without needing to execute single commands. It provides the configurations necessary to deploy an Apache web page in parallel, which means the tasks will run in sequence based on the way they are written. The tasks in order are:

Join the party

There are already about 90 modules available and more are in development. The Windows modules help with Chocolatey, and the majority of the Windows infrastructure can now be managed with Ansible. This allows Windows admins to use the same techniques and practices executed by Linux admins in the long-established Linux culture.

The Windows space is continuing to evolve, and by joining the Ansible community, you can join the biggest automation party around!

Topics

About the author

Taz Brown - Taz Brown is a Red Hat Sr. Ansible Automation Consultant and an avid writer and speaker with a diverse background in Linux systems engineering and management and deployment of DevOps solutions.
She has more than 16 years of IT experience working with companies like MasterCard, Nestle Purina, and Centurylink which have involved large scale infrastructure adoptions involving CI/CD pipeline implementations and implementing cloud solutions.
She is an avid Linux and Ansible enthusiast and has...

About the author

Abner Malivert - Abnerson Malivert (RHCA) is an Open Source solution integrator for both private and public sector organizations. His primary focus is on automation, configuration management, Identity Management and patch management. When he’s not working on his home lab, Abnerson loves playing his Stratocaster guitar and spending time with his family.

Footer

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.