Windows Updates and Ansible

Welcome to the fourth installment of our Windows-centric Getting Started Series!

One of the duties of most IT departments is keeping systems up to date. In this post we’re taking a quick look at using Ansible to manage updates on your Windows nodes. Starting with a small example of six Windows machines, we’ll show an example of a play against those hosts. We’ll share the full example at the end.

Updates, Updates, Updates...

Managing Windows updates is something that can be understood and customized quickly with Ansible. Below is a small-scale example of running updates on hosts with some flexibility in what gets updated in the process. The example here is assuming a domain exists and the hosts are being passed domain credentials. If you’re looking to test this example, be sure to read Bianca’s earlier Getting Started post on connecting to a Windows host.

Because this example is running against exclusively Windows machines, the information needed to connect can be included in the inventory file:

[all:vars]
ansible_connection: winrm
ansible_user: administrator
ansible_password: This-Should-Be-a-Password!

For Example

The example hosts include three groups of servers, two in each group. There are terminal servers, application servers, and directory servers. For the purposes of demonstration we’ll be treating the Windows Update needs for each group differently. Specifying the groups within the inventory file makes it easy to handle each group as desired.

[terminalservers]
rocket.milano.local
groot.milano.local

[appservers]
drax.milano.local
mantis.milano.local

[directoryservers]
peter.milano.local
gamora.milano.local

The win_updates Module

In a previous Getting Started post Jake talked a bit about package management with win_package and win_chocolatey. For Windows Updates there’s another module called win_updates to manage updates from Microsoft with some granularity.

In our example, the terminal servers are meant to receive general application updates, general updates as well as security/critical updates, and definitions updates for malware protection. This group is also getting a specific patch whitelisted by its KB number. New to Ansible 2.5, the reboot parameter is to allow the system to perform reboots when needed, while the reboot_timeout parameter sets the length of time (in seconds) to wait for the reboot to complete before proceeding.

- name: Run Updates on Terminal Servers then wait 7 mins
  hosts: terminalservers
  connection: winrm

  tasks:
    win_updates:
      category_names:
        - Application
        - CriticalUpdates
        - DefinitionUpdates
        - SecurityUpdates
        - Updates
      whitelist:
        - KB4093120
    reboot: yes
    reboot_timeout: 420

The application server group has slightly different category selections for updates, and it has a different KB whitelisted. On our imaginary app servers there may be databases that take a little bit more time to gracefully close and restart, so the reboot timeout is set a few minutes longer to be safe. 

- name: Run Updates on App Servers and wait 10 mins
  hosts: appservers
  connection: winrm

  tasks:
    win_updates:
      category_names:
        - CriticalUpdates
        - DefinitionUpdates
        - SecurityUpdates
        - Updates
      whitelist:
        - KB4022723
    reboot: yes
    reboot_timeout: 600

Finally, the last group is set to receive only critical and security updates. The blacklist parameter is also being passed to block an unwanted update. In the case that any updates require reboots, the timeout counter is increased to 15 minutes to make sure the Active Directory servers have plenty of time to spin back up before completing any updates.

- name: Run Updates on Directory Servers then wait 15 mins
  hosts: directoryservers
  connection: winrm

  tasks:
    win_updates:
      category_names:
        - CriticalUpdates
        - SecurityUpdates
      blacklist:
        - Microsoft Silverlight
    reboot: yes
    reboot_timeout: 900

That’s It!

Your real-world environments are probably going to look a little different than the example we’re using, but the usage will be similar. It’s important to note that the win_updates module doesn’t specify the source for updating. That means whatever is configured on the target host-- Microsoft Update, Windows Update, WSUS-- will be the source the target host uses for updates. Also, depending on the patch size and frequency of running updates, this is a process that can take longer than the 7-15 minute times we used in the example and longer than the default (1200 ms or 20 minutes). As always, test before using in the wild.

More Information

Download and install Windows updates: win_updates module documentation

Github example: github.com/Ansible-Getting-Started/win_updates_usage