Automate Windows Server with Ansible (example Windows Updates)

It doesn't always have to be SCCM... I was looking for a way to automate as many of my boring tasks as possible for my own systems: Backing up or mirroring the website to the NAS, installing updates (Windows / Linux), installing test environments. Just repetitive, boring, time-consuming stuff, made for automation and central control. After a few tests, I ended up using Ansible to automate as many tasks as possible. In the meantime (admittedly after a few failures) things are running smoothly, so here is a brief introduction to the topic of automation using Ansible. As it was my first use case, I chose the topic of Windows updates for the first example.

CentOS 8 Installation

I normally use Debian for most of my Linux-based servers, but recently I've taken a liking to CentOS. I'm currently migrating my private systems from Debian to CentOS, so this article also uses CentOS as the operating system for Ansible (in case anyone is wondering why I'm not using Debian).

The installation of CentOS is self-explanatory, so here are just a few screenshots of my setup:

Since I run CentOS as a VM, I have selected "Server" and "Guest agents":

The root password can be set and a user created during installation:

After a few minutes CentOS is installed:

After the installation, only an IP address and DNS server, as well as time synchronization via NTP were configured. Once the CentOS installation is complete, Ansible can be installed.

Ansible installation

PIP (python installs packages) can be used for the Ansible installation. For this to work, Python must first be installed. Python can be installed using the following commands:

After Python, Ansible can be installed with the following command:

Incidentally, I deliberately carried out the installation via PIP. When installing Ansible via the normal CentOS repo, I did not manage to get all components running successfully. When the installation was done via PIP, I had no problems.

Ansible is already installed, but the PyWinRM package is required so that Windows servers can also be managed later using WinRM. The package can be installed with the following command:

Once Ansible has been installed, you can continue with the basic configuration.

Ansible basic configuration

As the installation of Ansible was carried out using PIP, two basic files for the configuration of Ansible are still missing. However, the required files can simply be downloaded and created in the corresponding directory. Ansible then loads these files at runtime.

The following commands can be used to create the directory and download the configuration files:

The ansible.cfg file does not need to be adapted initially. The servers to be managed are specified later in the "hosts" file.

Ansible authentication using Kerberos

The administration of Windows servers with Ansible would already work using WinRM, but currently only with a local user on the respective server. However, the use of Active Directory user accounts and authentication via Kerberos is the more elegant way here, especially as the management of some services on Windows servers only works with Active Directory users (the automation of Exchange servers would be an example here).

In order for Ansible to log on to Windows servers using AD users and Kerberos, a few more packages need to be installed.

The connection to the Active Directory must now be configured in the /etc/krb5.conf file. In the file, the domain controller is entered in the "realms" section and the name of the Active Directory in the "domain_realm" section.

In my test environment, for example, this looks like this (case-sensitive):

The following command can now be used to test whether authentication using Kerberos works:

If the command does not return an error message, everything is OK. The "klist" command can also be used to check whether a Kerberos ticket has been issued:

Finally, the Kerberos support for PyWinRM must be installed:

Ansible can now also use Active Directory users and Kerberos for authentication on the Windows server.

Create groups and hosts

Servers that are to be managed via Ansible must be made known in the file /etc/ansible/hosts. Individual servers can be combined into host groups within the file. Here is an example of my /etc/ansible/hosts file:

For example, the file contains the group "exchangeserver". The servers ex1 and ex2 are members of the exchangeserver group (first box in the screenshot). In the second box you will find the environment variables for the group, for the sake of simplicity I have also stored the login information here. There is also the group "windowsserver", this group contains all host groups with Windows systems:

I have summarized the relevant files as a download at the end of the article. So if someone wants to rebuild this, not everything has to be typed out here.

Configure Windows systems

In order for Ansible to access the Windows servers via WinRM, WinRM must be configured accordingly. The configuration of WinRM is very easy thanks to a PowerShell script. The script can be downloaded here:

• ConfigureRemotingForAnsible.ps1

The script must be executed as an administrator on every Windows server that is to be managed using Ansible.

The script creates a self-signed certificate and configures WinRM accordingly. The connection from the Ansible server to the Windows server is made via port 5986, the Windows firewall is configured automatically, if other firewalls are used, they must allow communication via port 5986.

Test connection

The preparations are now complete and you can test whether Ansible can establish a connection to the configured Windows servers. The following command can be used to test the connection:

This command executes the module win_ping (WinRM based test) for the members of a group:

The screenshot shows how the individual groups can be tested. If there are any problems here, the first thing to check is whether the servers are resolved via DNS and the login information is correct. If the connection is successful, you can create your first playbook.

Create playbook for Windows updates

Playbooks are used to execute a sequence of actions on the target systems. In this section, a simple playbook is created for the installation of Windows updates. This playbook only serves as an example for the time being, but if you familiarize yourself a little with Ansible, you can quickly implement more complex things here.

First, a directory structure can be created for the playbooks, making it easier to find the playbooks later. In this example, the directory "ansible-playbooks" and the subdirectory "windows" are created. All playbooks for Windows systems can then be saved in the "windows" folder. The directory structure is of course freely selectable here:

The first playbook can now be created in the "windows" folder. In this example, the playbook is used to install Windows updates on the Windows servers:

The first playbook will have the following content:

The first step installs Windows updates on servers in the "fileserver" group (hosts: fileserver). If there are several hosts in the fileserver group, the updates are installed in parallel on the servers (strategy: free). The task defines which action is to be carried out. In this case, critical and security updates are installed and the servers are restarted if necessary. In the next step, it is the domain controllers' turn, followed by the hosts in the "exchange servers" group.

This simple playbook is just a small example. If you familiarize yourself with it a little, you can automate many things using Ansible. This example can also be downloaded at the end of the article.

For example, I have automated the update process for my private environment, which then runs as follows:

1. Create VMware snapshots for all virtual servers that require updates
2. Installing updates on Windows and Linux servers
3. Restart the servers if this is necessary
4. Send e-mail notification
5. Delete snapshot 2 days later

The download at the end of the article also contains an example of how an Exchange DAG can be updated.

Run playbook

Previously created playbooks can be executed with the command "ansible-playbook". In this example, the previously created playbook is executed:

Ansible now executes the steps from the playbook on the servers:

As you can see in the screenshot above, one command is now sufficient to provide all Windows servers with updates in the appropriate order. Several different systems can also be addressed within the playbook. For example, an Exchange server can be taken from the load balancer pool first and only then updated, or a snapshot could be created first, or or or or...

Download

As promised, the download with the corresponding examples can be found here:

The files included are for example purposes only and must be adapted to your own environment. Perhaps the examples will make it easier for some of you to get started with Ansible.

Conclusion

After a bit of familiarization and a lot of testing, you get used to Ansible quite quickly. The ability to automate almost all systems offers enormous potential. After all, you can not only execute actions on Windows and Linux servers, but also control almost every other device in the network (switches, routers, firewalls, load balancers, hypervisors, "the sheet metal", air conditioning systems, access control, databases, etc., etc., etc.) and it doesn't end with your own network, you can also control the interfaces of Azure, AWS and GCP. So the possibilities are pretty diverse...

Tip: There is also a graphical front end for Ansible:

• AWX Project