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
About the author
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit