Ansible to Manage Windows Servers – Step by Step

Introduction

Ansible is quickly becoming the dominant DevOps platform for automating software provisioning, configuration management and application deployment in a heterogeneous datacenter and hybrid cloud environment. Ansible has facilities to integrate and manage various technologies including Microsoft Windows, systems with REST API support and of course Linux.

This article will step through the steps of deploying the Ansible controlling node on CentOS 7, and the configuration of Windows Server 2016 for management and create Ansible playbook examples with custom Powershell Ansible modules.

Windows and Ansible integration is documented in the official Ansible documentation.

By following the instructions in this article, you will be able to manage Windows systems using Ansible as easily as managing any other environment, including Linux.

Example Lab

The examples in this article will reference this minimal configuration:

• One Ansible Controlling Node running Linux CentOS 7
• One Windows Server 2016 server to be managed
• Once Windows Server 2016 Active Directory server providing DNS services

This lab is built on three VMs running on Hyper-V on a Windows 10 desktop. Here is an article describing a similar a similar scenario, How to Build Windows Storage Spaces Direct on a Virtual Lab.

Below is a diagram of the example lab environment.

All communications between systems runs on a private network segment for simplicity.

Install Lab Servers

Build the following servers in your environment.

Configure Lab Network

Configure AD1 DNS services

Configure DNS Forward and Reverse Lookups, Kerberos requires both forward and reverse DNS lookup to resolve correctly.

Configure the DNS Reverse Lookup Zone. This will look like the screenshot below.

The DNS Forward Lookup Zone will be like the screenshot below

Add Ansible1 and WinServer1 A records:

• Ansible1: 172.20.20.100 – Select to create the PTR record automatically
• WinServer1: 172.20.20.101 – Select to create the PTR record automatically

Review the Reverse Look Zone 20.20.172.in-addr.arpa. You may need to select Right-Click and REFRESH to see the new records.

Configure Ansible1 CentOS System Network

Update the following files. Be sure to modify as appropriate for your own environment.

The eth0 interface in this example uses DHCP addresses to access the Internet and provide SSH access for administration.

1. Edit: /etc/sysconfig/network-scripts/ifcfg-eth0

The eth1 interface is the private network and is shared only with the other servers in this lab.

2. Edit /etc/sysconfig/network-scripts/ifcfg-eth1

The resolv.conf configures the Linux DNS client.

3. Edit /etc/resolv/conf

Set the hostname

4. Edit: /etc/hostname

5. Reboot the server

Type: reboot

6. Test your network. Make sure you can resolve DNS correctly.

Type: nslookup WinServer1

This command will query the AD1 DNS server for WinServer1 without a fully qualified name.

Type: nslookup 172.20.20.101

This command will do a reverse lookup on the IP address. This should return WinServer1 as the name.

Configure Ansible Environment

Install Prerequisite Packages

Use Yum to install the following packages.

1. Install GCC required for Kerberos

2. Install EPEL

3. Install Ansible

4. Install Kerberos

5. Install Python PIP

6. Install BIND utilities for nslookup

7. Bring all packages up to the latest version

Check Ansible and Python is Installed

1. Run the commands:

Configure Kerberos

There are other options than Kerberos, but Kerberos is generally the best option, though not the simplest.

1. Install the Kerberos wrapper:

Kerberos packages were installed previously which will have created /etc/krb5.conf

2. Edit /etc/krb5.conf

Add:

Add:

The /etc/krb5.conf file when complete will be similar to:

Test Kerberos

1. Run the following commands to test Kerberos:

You will be prompted for the administrator password klist
You should see a Kerberos KEYRING record.

Configure Ansible

Ansible is complex and is sensitive to the environment. Troubleshooting an environment which has never initially worked is complex and confusing. We are going to configure Ansible with the least complex possible configuration. Once you have a working environment, you can make extensions and enhancements in small steps.

The core configuration of Ansible resides at /etc/ansible

We are only going to update two files for this exercise.

Update the Ansible Inventory file

1. Edit /etc/ansible/hosts and add:

“[windows]” is a created group of servers called “windows”. In reality this should be named something more appropriate for a group which would have similar configurations, such as “Active Directory Servers”, or “Production Floor Windows 10 PCs”, etc.

Update the Ansible Group Variables for Windows

Ansible Group Variables are variable settings for a specific inventory group. In this case, we will create the group variables for the “windows” servers created in the /etc/ansible/hosts file.

1. Create /etc/ansible/group_vars/windows and add:

Naturally change the Administrator password to the password for WinServer1.

Configure Windows Servers to Manage

To configure the Windows Server for remote management by Ansible requires a bit of work. Luckily the Ansible team has created a PowerShell script for this. Download this script from [here] to each Windows Server to manage and run this script as Administrator.

Log into WinServer1 as Administrator, download ConfigureRemotingForAnsible.ps1 and run this PowerShell script without any parameters.

Once this command has been run on the WinServer1, return to the Ansible1 Controller host.

Test Connectivity to the Windows Server

If all has gone well, we should be able to perform an Ansible PING test command. This command will simply connect to the remote WinServer1 server and report success or failure.

1. Type: ansible windows -m win_ping

This command runs the Ansible module “win_ping” on every server in the “windows” inventory group.

2. Type: ansible windows -m setup to retrieve a complete configuration of Ansible environmental settings.
3. Type: ansible windows -c ipconfig

If this command is successful, the next steps will be to build Ansible playbooks to manage Windows Servers.

Managing Windows Servers with Playbooks

Let’s create some playbooks and test Ansible for real on Windows systems.

1. Create a folder on Ansible1 for the playbooks, YAML files, modules, scripts, etc. For these exercises we created a folder under /root called win_playbooks.

Ansible has some expectations on the directory structure where playbooks reside. Create the library and scripts folders for use later in this exercise.

Commands:

2. Create the first playbook example “netstate.yml”

The contents are:

This playbook does only one task, to connect to the servers in the Ansible inventory group “windows” and run the command netstat.exe -a and return the results.

To run this playbook, run this command on Ansible1: ansible-playbook netstat_e.yml

OK, not exciting, but it did run, just not very friendly.

Also, notice that the “changed” flag is set. As of the time this article was created, all of the Windows commands return the “changed” flag as true. This is the same with running PowerShell scripts remotely. This makes much of the value of Ansible difficult as a configuration and deployment tool.

Interestingly enough, Ansible modules created with PowerShell do work correctly and return the “changed” flag correctly. PowerShell scripts and direct commands always return the “changed” flag as true. This is problematic for managing systems with Ansible. The rest of this article will focus on PowerShell modules which can perform complex management functions as well as integrate with other non-Windows systems.

Creating Ansible Modules with PowerShell

Ansible modules are plugin programs which are:

1. 1. Loaded by Ansible when running a playbook test
   2. Ansible generates module input parameters in the JSON format
   3. Modifies the module into a generalized script and command
   4. Copies the modified script to the remote system(s)
   5. Executes the modified module on the remote system
   6. The module generates a response in JSON and this response is returned
   7. The returned JSON is parsed and values are saved or use by other tests
   8. The module returns a flag called “changed” which is important to maintain “Desired State Configurations”. A return of “changed = True” will signal other tests to run to achieve “Desired State”

Modules are stored in several locations where Ansible will find them. One location is a folder named “library” located in the folder where the playbook is run. Modules stored in our library are first in the module search path and will override modules of the same name.

This example lab has a folder win_playbooks/library/

PowerShell modules consist of two programs, a Python program and a PowerShell program. The Python program configures the local Ansible environment and the PowerShell program does the actual processing on the remote systems.

Create a file called “win_playbooks/library/get_version.py” and add the following contents:

Next create a file “win_playbooks/library/get_version.ps1” and add the following contents:

Next, create the playbook YAML file to setup and run the new module.

From the win_playbooks folder, create a file with the following contents:

Execute this playbook with the command:

Notice the “changed” flag is set to False. In this case, this means the remote operating system matched the values in the get_version.yml playbook.

If we set the Verbose flag, we see the data returned from the PowerShell module in the JSON format.

Setting the Very Very Verbose flag give more information, and oddly enough formats the JSON into a more readable format.

Now if we modify the playbook expecting a different version. We set the major version from 5 to 9 (which does not exist).

And run the playbook again

The “changed” flag is set.

We could extend this playbook with other PowerShell modules, for example:

This playbook could check the Windows version, and if it is below a version threshold, the next task could then enable updates, manually install updates, or practically any possible action imaginable to maintain the Windows servers to a “Desired State”.

Summary

Ansible is a powerful management and DevOps framework. It is complex to setup initially, but relatively simple to operate. Playbooks can be created which manage large and complex environments consisting of cloud systems, servers, storage systems, network systems, security systems, hardware and facilities management devices and any of a large set of disparate systems.

Configured correctly, managing and monitoring complex can be consolidated onto a single framework, and with the Ansible Windows support and some initial instructions detailed in this article, can include Windows Servers, Windows desktops and other Windows based systems.