DEV Community: Sirisharaju Kamparaju

Automating Windows Server Setup with Ansible: My DevOps Journey (Part 2)

Sirisharaju Kamparaju — Tue, 12 May 2026 13:12:31 +0000

In my previous blog, I walked through how I automated Linux server setup using Ansible — SSH hardening, roles, and playbooks. If you haven't read that yet, check out Part 1 here.
In this post, I'll focus entirely on the Windows side — how I configured WinRM, built a reusable Windows role, and tied everything together into one master playbook that manages both Linux and Windows servers.

Windows Automation Feels Different at First
When I first tried to automate Windows servers with Ansible, it didn't feel anything like Linux. On Linux, Ansible just connects over SSH and you're off. Windows doesn't work that way.

A few things that caught my attention early on:

Windows uses WinRM instead of SSH — that's how Ansible communicates with it
Fresh Windows servers don't have WinRM enabled — I had to manually turn it on the first time
The modules are completely different — no apt, no service — everything goes through the ansible.windows collection
Once I got my head around these differences, the rest came together pretty smoothly.

**First Thing — Bootstrap WinRM (Just Once)
Before Ansible can do anything on a Windows server, WinRM needs to be enabled. I ran this PowerShell script once on each new Windows machine — after that, Ansible handles everything:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:temp\ConfigureRemotingForAnsible.ps1"
(New-Object -TypeName System.Net.WebClient).DownloadFile($url, $file)
powershell.exe -ExecutionPolicy ByPass -File $file

Adding Windows Hosts to the Inventory
I added the Windows servers into the same inventory file I was already using for Linux. The connection settings are different but the structure stays clean:

all:
children:
linux_servers:
hosts:
linux-01:
ansible_host: 10.0.1.10
ansible_user: ec2-user
ansible_ssh_private_key_file: ~/.ssh/id_rsa
windows_servers:
hosts:
win-01:
ansible_host: 10.0.2.10
ansible_user: Administrator
ansible_password: "{{ vault_win_password }}"
ansible_connection: winrm
ansible_winrm_transport: ntlm
ansible_port: 5985

The Windows password is vaulted using ansible-vault — I never put credentials in plain text. That's just a habit I've built early on and I'd recommend everyone do the same.

Building the Windows Role
I kept the same role-based structure I used for Linux. Here's how the Windows role looks:

roles/
windows_setup/
├── tasks/main.yml
└── defaults/main.yml

roles/windows_setup/defaults/main.yml

name: Ensure WinRM service is running and set to auto start
ansible.windows.win_service:
name: WinRM
state: started
start_mode: auto
name: Disable unencrypted WinRM traffic
ansible.windows.win_shell: |
winrm set winrm/config/service '@{AllowUnencrypted="false"}'
name: Configure Windows Firewall to allow WinRM
ansible.windows.win_firewall_rule:
name: WinRM HTTP
localport: "{{ winrm_port }}"
action: allow
direction: in
protocol: tcp
state: present
enabled: true
name: Check for available Windows Security Updates
ansible.windows.win_updates:
category_names:
- SecurityUpdates state: searched register: update_result
name: Display available updates

ansible.builtin.debug:

msg: "{{ update_result.updates | length }} security update(s) available"

The Windows Playbook

name: Configure Windows Servers hosts: windows_servers roles:
- windows_setup

One thing I noticed here — there's no become: true like I used on Linux. Windows doesn't use sudo. The Administrator account takes care of privilege escalation directly.

Bringing It All Together — site.yml
This is the part I enjoyed the most. One playbook, one command, both Linux and Windows configured together:

import_playbook: playbooks/linux_setup.yml
import_playbook: playbooks/windows_setup.yml

And to run everything:
ansible-playbook site.yml -i inventory/hosts.yml --ask-vault-pass

That's it. Ansible runs through Linux first, then Windows — clean and consistent every single time.

ansible windows_servers -i inventory/hosts.yml -m ansible.windows.win_ping

If I get pong back, I know I'm good to go.
WinRM transport depends on your environment. I used ntlm since my servers weren't in a domain. If you're working in an Active Directory setup, kerberos is the better and more secure option.
Don't mix Linux and Windows modules. Early on I made the mistake of trying to use a Linux module on a Windows host — it fails and the error isn't always obvious. Stick to ansible.windows.* for everything Windows-related.

What Changed After This
Before this setup, configuring a new Windows server meant RDP-ing in, clicking through settings, and hoping I didn't miss anything. Now I just add the host to the inventory and run the playbook. Same result every time, no matter how many servers I'm dealing with.
Combined with Part 1, I now have a single automation setup managing both Linux and Windows from one place — and it's honestly one of the most satisfying things I've built so far in my DevOps journey.

Coming Up in Part 3
I'm planning to cover:

User management across Linux and Windows
Scheduling automated patching
Plugging Ansible into a CI/CD pipeline

Drop your questions or thoughts in the comments — always happy to discuss!
— Sireesha

Automating Linux & Windows Server Setup with Ansible: My DevOps Journey

Sirisharaju Kamparaju — Tue, 12 May 2026 13:01:58 +0000

Ansible is one of the most powerful automation tools used by DevOps engineers to manage infrastructure, configure servers, and deploy applications at scale. In this blog, I'll walk through how I automated Linux and Windows server setup using Ansible — specifically around SSH configuration, roles, and playbooks — and reduced repetitive manual work significantly.
This project demonstrates how automation can simplify server management while improving consistency and deployment speed across both Linux and Windows environments.

Why I Chose Ansible for This

**
Before I started using Ansible, server setup meant logging into each machine manually, running the same commands over and over, and hoping nothing was missed. One wrong step and the configuration was inconsistent across environments. Sound familiar?
What drew me to Ansible was its simplicity — no agents to install, no complex setup. Just SSH into Linux, WinRM into Windows, and you're managing your entire fleet from a single control node. That agentless architecture was a game changer for me.

Project Overview

The goal was straightforward: automate the initial setup of both Linux and Windows servers using a clean, reusable Ansible structure. Here's what I set out to configure:

SSH hardening and configuration on Linux servers
WinRM configuration to enable Ansible to talk to Windows servers
Reusable roles for both OS types
A master playbook to tie everything together.

Setting Up the Project Structure
The first thing I did was organize everything into roles. Roles keep your code clean, reusable, and easy to share across projects. Here's the structure I used:

ansible-server-setup/
├── inventory/
│ ├── hosts.yml
├── roles/
│ ├── linux_ssh/
│ │ ├── tasks/main.yml
│ │ ├── templates/sshd_config.j2
│ │ ├── handlers/main.yml
│ │ └── defaults/main.yml
│ ├── windows_setup/
│ │ ├── tasks/main.yml
│ │ └── defaults/main.yml
├── playbooks/
│ ├── linux_setup.yml
│ ├── windows_setup.yml
└── site.yml

Keeping Linux and Windows roles separate made everything much easier to maintain and debug independently.

The Inventory

I defined both Linux and Windows hosts in a single YAML inventory, with the right connection settings for each:

Notice I vaulted the Windows password using ansible-vault — never hardcode credentials in plain text. Learned that lesson early!

SSH Hardening Role for Linux
This was the core of my Linux setup. The linux_ssh role handles SSH daemon configuration to make servers secure and consistent from day one.
roles/linux_ssh/defaults/main.yml

ssh_port: 22
permit_root_login: "no"
password_authentication: "no"
max_auth_tries: 3

roles/linux_ssh/templates/sshd_config.j2

Port {{ ssh_port }}
PermitRootLogin {{ permit_root_login }}
PasswordAuthentication {{ password_authentication }}
MaxAuthTries {{ max_auth_tries }}
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

name: Deploy SSH configuration
ansible.builtin.template:
src: sshd_config.j2
dest: /etc/ssh/sshd_config
owner: root
group: root
mode: "0600"
notify: Restart SSH
name: Ensure SSH service is running and enabled
ansible.builtin.service:
name: sshd
state: started
enabled: true

roles/linux_ssh/handlers/main.yml

name: Restart SSH ansible.builtin.service: name: sshd state: restarted

The handler ensures SSH only restarts when the config actually changes — not on every run. That small detail matters a lot in production.