Why Traditional Docker Container Monitoring Fails

Most DevOps teams struggle with Docker container status monitoring using conventional approaches that rely on basic container metrics, such as CPU usage, memory consumption, and network traffic. However, these metrics fail to answer the fundamental question: "Is my container actually running right now?" Traditional container monitoring approaches suffer from critical limitations:

Stale Metrics Problem: Prometheus continues to show metrics for stopped containers, creating false positives in Docker container monitoring dashboards and misleading operational teams.

Metric Persistence Issues: When Docker containers stop, their metrics don't immediately disappear from Prometheus, causing confusion about actual container status and hampering effective container health monitoring.

Complex Query Requirements: Existing Prometheus container monitoring solutions require complex, error-prone queries that are difficult to understand and maintain in production environments.

Inconsistent Monitoring Behavior: Some container status queries work intermittently or fail during container restarts, network issues, or temporary outages, compromising reliable Docker monitoring.

The Ultimate Prometheus Query for Docker Container Status

After extensive testing in production environments, this Prometheus query delivers accurate Docker container status monitoring:

count(time()-container_last_seen{name=~"<container_name>"}<=60) or vector(0)

This Docker container status monitoring query elegantly solves container detection problems by leveraging the container_last_seen metric from cAdvisor combined with Prometheus time functions and vector operations for bulletproof UP/DOWN status detection.

How the Container Status Detection Query Works

Understanding each component of this Prometheus container monitoring query ensures successful implementation:

The container_last_seen Metric for Container Monitoring

The container_last_seen metric provided by cAdvisor (Container Advisor) represents the exact timestamp when Docker containers were last observed running. This metric is crucial for accurate container status monitoring because:

• Provides definitive timestamps of the container's last known activity

• Automatically updates by cAdvisor while Docker containers are running

• Disappears from metrics endpoints when containers stop, enabling precise detection logic

Time-Based Container Health Detection Logic

The expression time()-container_last_seen{name=~"<container_name>"} calculates seconds since the container was last active, forming the foundation of reliable Docker container monitoring:

• Running Container: Returns small values (typically under scrape interval)

• Stopped Container: Returns large values or no data

• 60-Second Threshold: Configurable tolerance for network delays and scraping intervals

Binary Status Output with Count Function

The count() function transforms time calculations into a binary container status for a clear Grafana dashboard visualization:

• Count Result = 1: Container is UP (last seen within threshold)

• Count Result = 0: Container is DOWN (not seen recently)

• Multiple Container Support: Handles container scaling automatically

Reliable Fallback with Vector Function

The or vector(0) ensures consistent Docker container monitoring results:

• No Matching Containers: Returns 0 instead of "No Data"

• Query Error Handling: Prevents Grafana dashboard panel failures

• Consistent Output: Always provides numeric results for value mappings

Step-by-Step Grafana Implementation Guide

Step 1: Create Docker Container Status Panel

Implement this Docker container status monitoring solution in Grafana:

1. Add New Panel: Create a Stat panel in your Grafana dashboard

2. Configure Prometheus Data Source: Select your Prometheus data source

3. Enter Container Monitoring Query:

count(time()-container_last_seen{name=~"your_container_name"}<=60) or vector(0)

Replace "your_container_name" with your actual Docker container name or regex patterns for multiple containers.

Step 2: Configure Value Mappings for UP/DOWN Status

Essential Grafana configuration for visual container status indication makes this Docker container monitoring solution immediately actionable:

Value Mapping Setup:

• Value 1 = Display "UP" with green background

• Value 0 = Display "DOWN" with red background

  

Step 3: Optimize Visual Formatting

Configure these Grafana settings for optimal Docker container monitoring visualization:

• Set panel type to Stat for a clear status display

• Enable Colored background for immediate status recognition

• Adjust font size for dashboard visibility

• Add custom styling for enhanced user experience

Advanced Docker Container Monitoring Use Cases

Multi-Container Environment Monitoring

Monitor multiple Docker containers with pattern matching for comprehensive container status monitoring:

# Monitor web service containers
count(time()-container_last_seen{name=~"web.*|api.*|worker.*"}<=60) or vector(0)

Adjustable Container Monitoring Thresholds

Customize monitoring sensitivity based on your Docker container monitoring requirements:

# Strict monitoring (30 seconds)
count(time()-container_last_seen{name=~"<container_name>"}<=30) or vector(0)

# Relaxed monitoring (2 minutes)
count(time()-container_last_seen{name=~"<container_name>"}<=120) or vector(0)

Service Group Container Monitoring

Monitor Docker container availability by service groups for organized infrastructure monitoring:

count(time()-container_last_seen{name=~"database-.*"}<=60) or vector(0)

Best Practices for Docker Container Monitoring Implementation

Essential Monitoring Infrastructure Setup

Ensure your Docker container monitoring stack includes:

• Prometheus: Metric collection and storage for container monitoring

• cAdvisor: Container metrics collection (provides container_last_seen)

• Grafana: Dashboard visualization and alerting for container status

Container Monitoring Query Optimization

• Use specific container name patterns to optimize metric collection

• Adjust time thresholds based on scrape intervals and monitoring requirements

• Implement label filtering for environment-specific container monitoring

Grafana Dashboard Design for Container Monitoring

• Create dedicated container status dashboards for different environments

• Implement alerting rules based on Docker container status changes

• Maintain consistent color schemes across monitoring dashboards

Troubleshooting Common Container Monitoring Issues

No Data in Docker Container Monitoring

If your container status query returns no data:

• Verify cAdvisor is running and collecting container metrics

• Check container names match your regex patterns

• Ensure Prometheus successfully scrapes cAdvisor metrics

Inconsistent Container Status Results

For inconsistent Docker container monitoring behavior:

• Adjust time thresholds to account for scrape intervals

• Verify network connectivity between monitoring components

• Check resource constraints on monitoring infrastructure

Grafana Value Mapping Issues

If colors aren't displaying correctly in your container monitoring dashboard:

• Ensure value mappings are configured for both 0 and 1 values

• Verify correct visualization type selection

• Check threshold settings don't conflict with value mappings

Frequently Asked Questions (FAQ)

What makes this Prometheus query better for Docker container monitoring?

This query uses the container_last_seen metric, specifically designed for status detection, eliminating false positives from stale metrics that plague other Docker container monitoring methods. The combination with count() and vector(0) ensures reliable binary output, perfect for UP/DOWN status visualization.

How quickly does the query detect stopped Docker containers?

The query detects stopped containers within one Prometheus scrape interval plus your configured threshold (default 60 seconds). For faster container status detection, reduce both the scrape interval and threshold value while considering system overhead.

Can this query monitor multiple Docker containers simultaneously?

Yes, use regex patterns in the container name filter like {name=~"web-.*|api-.*"} to monitor multiple containers. Each matching container contributes to the count, providing the total running containers matching your pattern.

What happens if cAdvisor stops working during container monitoring?

If cAdvisor becomes unavailable, the query returns 0 due to the vector(0) fallback, indicating containers are DOWN. This fail-safe behavior ensures you're alerted to monitoring infrastructure issues rather than receiving false UP status.

How do I adjust Docker container monitoring sensitivity?

Modify the time threshold in the query: use <=30 for 30-second sensitivity or <=120 for 2-minute tolerance. Choose values based on your scrape interval and tolerance for brief network interruptions.

Does this work with Docker Swarm or Kubernetes containers?

Yes, this container monitoring approach works with Docker Swarm, Kubernetes, and standalone Docker containers as long as cAdvisor can collect the container_last_seen metric from your container runtime.

Conclusion: Reliable Docker Container Status Monitoring

This Prometheus query revolutionizes Docker container status monitoring by providing accurate, real-time UP/DOWN detection that eliminates common monitoring pitfalls. The combination of container_last_seen metrics, intelligent time comparison, and proper Grafana value mapping creates a robust container monitoring solution that DevOps teams can trust in production environments.

By implementing this Docker container monitoring approach, you'll gain immediate visibility into container health, reduce false alarms, and ensure rapid response to actual container failures. The query's simplicity makes it maintainable while its reliability makes it production-ready for critical infrastructure monitoring.

Key Benefits of This Container Monitoring Solution:

• Accurate real-time Docker container status detection

• Eliminates false positives from stale container metrics

• Simple implementation with powerful monitoring capabilities

• Reliable UP/DOWN visualization in Grafana dashboards

• Production-tested solution for critical container monitoring

Transform your Docker container monitoring today with this bulletproof Prometheus query and experience the difference that accurate container status detection makes in your DevOps monitoring infrastructure.

If you’ve worked with Windows before, you already know how useful scheduled tasks can be, they allow you to automate actions such as running scripts, opening applications, or triggering maintenance jobs at specific times. Now, with Ansible, you can manage these tasks consistently across multiple servers, without having to log into each one manually.

By the end of this guide, you will know how to:

• Create a scheduled task

• Remove a scheduled task

• Disable a scheduled task (with PowerShell support)

• Restart a scheduled task (with PowerShell support)

Let’s walk through each of these step by step.

Prerequisites

Before we begin, make sure you have the following:

1. A working Ansible control node (Linux).

2. One or more Windows servers configured as managed hosts.

3. Ansible collections installed for Windows:

    ansible-galaxy collection install community.windows ansible.windows
   

4. Basic familiarity with running Ansible playbooks.

For disabling and restarting tasks, we will also need two small PowerShell scripts placed inside the Windows server. You can either:

• Manually copy them to the server (e.g., C:\Users\Ansible\Scripts\), or

• Use Ansible’s ansible.windows.win_copy module to copy them over from your control node.

We’ll cover the scripts later in this post.

1. Creating a Scheduled Task

Here’s a simple playbook that creates a scheduled task. This task will run two commands:

• Show the computer’s hostname

• Show the user running the task

---
- name: Create a scheduled task
  hosts: windows
  gather_facts: true
  tasks:
    - name: Create <YourTaskName> to run cmd commands
      community.windows.win_scheduled_task:
        name: <YourTaskName>
        description: open command prompt
        actions:
          - path: cmd.exe
            arguments: /c hostname
          - path: cmd.exe
            arguments: /c whoami
        triggers:
          - type: daily
            start_boundary: '2025-08-21T15:20:00'
        username: <YourAnsibleUser> # You can also use "SYSTEM" as username here.
        state: present
        enabled: true

What this does:

• Creates a task with the name <YourTaskName>

• Runs two commands (hostname and whoami) daily at 3:20 PM.

• Executes as the <YourAnsibleUser> OR SYSTEM user.

2. Removing a Scheduled Task

If you no longer need the task, you can remove it with the following playbook:

---
- name: Remove a scheduled task
  hosts: windows
  gather_facts: true
  tasks:
    - name: Remove <YourTaskNAme>
      community.windows.win_scheduled_task:
        name: <YourTaskNAme>
        state: absent

This deletes the scheduled task called <YourTaskNAme> from the Windows server.

3. Disabling a Scheduled Task (PowerShell)

Sometimes you don’t want to delete a task but simply disable it. Ansible doesn’t directly provide a disable option, so we will use a PowerShell script to handle this.

First, create a script called Disable-Task.ps1 with the following content:

Param(
    [Parameter(Mandatory=$true)]
    [string]$TaskName
)

try {
    $task = Get-ScheduledTask -TaskName $TaskName -ErrorAction Stop
    Disable-ScheduledTask -InputObject $task
    Write-Host "Task '$TaskName' has been disabled successfully."
} 
catch {
    Write-Error "Failed to disable task '$TaskName'. Error: $_"
}

Save this file under:
C:\Users\Ansible\Scripts\Disable-Task.ps1

Now, use the playbook below to run the script from Ansible:

---
- name: Disable Windows Scheduled Task
  hosts: windows
  gather_facts: true
  vars:
    task_name: "<YourTaskName>"
    script_path: "C:\\Users\\<YourAnsibleUser>\\Scripts\\Disable-Task.ps1"

  tasks:
    - name: Disable the scheduled task
      ansible.windows.win_shell: |
        powershell.exe -ExecutionPolicy Bypass -File "{{ script_path }}" -TaskName "{{ task_name }}"

This will disable the task named <YourTaskNAme>.

4. Restarting a Scheduled Task (PowerShell)

To restart a scheduled task, we will use another PowerShell script:

Param(
    [Parameter(Mandatory=$true)]
    [string]$TaskName
)

try {
    $task = Get-ScheduledTask -TaskName $TaskName -ErrorAction Stop

    if ($task.State -eq 'Disabled') {
        Enable-ScheduledTask -InputObject $task
        Write-Host "Task '$TaskName' was disabled and has been enabled."
    }

    $taskState = (Get-ScheduledTaskInfo -TaskName $TaskName).State
    if ($taskState -eq 'Running') {
        Stop-ScheduledTask -InputObject $task
        Write-Host "Task '$TaskName' was running and has been stopped."
    }

    Start-ScheduledTask -InputObject $task
    Write-Host "Task '$TaskName' has been started successfully."
}
catch {
    Write-Error "Failed to restart task '$TaskName'. Error: $_"
}

Save it as:
C:\Users\Ansible\Scripts\Restart-Task.ps1

Here’s the Ansible playbook to call this script:

---
- name: Restart Windows Scheduled Task
  hosts: windows
  gather_facts: true
  vars:
    task_name: "<YourTaskName>"
    script_path: "C:\\Users\\<YourAnsibleUser>\\Scripts\\Restart-Task.ps1"

  tasks:
    - name: Restart the scheduled task
      ansible.windows.win_shell: |
        powershell.exe -ExecutionPolicy Bypass -File "{{ script_path }}" -TaskName "{{ task_name }}"

Wrapping Up

We have now covered how to:

• Create a scheduled task using Ansible modules.

• Remove a scheduled task when no longer needed.

• Disable a task temporarily using PowerShell scripts.

• Restart a scheduled task and bring it back into action.

Scheduled tasks are powerful for automating routine jobs on Windows servers. By combining them with Ansible, you gain the ability to manage these tasks consistently across multiple machines, saving time and reducing manual effort.

Prerequisites

Before running the playbook:

1. Ansible controller node
   You have Ansible installed on a Linux/macOS controller and can reach the Windows host.

2. WinRM configured
   The target Windows machine is accessible to Ansible over WinRM (HTTP or HTTPS), and your inventory/group vars are set appropriately (e.g., ansible_connection=winrm, ansible_user, ansible_password, ansible_winrm_transport).

3. Installer available locally on the controller
   Download the PostgreSQL Windows installer (.exe) to your Ansible controller.
   This workflow is ideal when the Windows machine has no internet access; Ansible will copy the installer to the host and run it there.

4. Online alternative (optional)
   If the Windows host does have internet access, you can install directly from a URL using win_package, skipping the copy step. An example is provided later in this article.

Full Playbook (copy-paste ready)

---
- name: Install PostgreSQL silently on Windows
  hosts: windows
  gather_facts: true

  vars:
    # Dummy paths & credentials for illustration; replace for your environment.
    pg_installer_local_path: "/dummy/path/postgresql-installer.exe"
    pg_installer_remote_path: "C:\\Temp\\postgresql-installer.exe"
    pg_password: "MyDummyPassword123"
    pg_port: 5433
    pg_major_version: 17
    pg_data_dir: "C:\\PostgresData\\{{ pg_major_version }}\\data"

  tasks:
    - name: Gather installed PostgreSQL info (64-bit)
      ansible.windows.win_shell: |
        Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" |
        Get-ItemProperty |
        Where-Object { $_.DisplayName -like "PostgreSQL*" } |
        Select-Object DisplayName, DisplayVersion, PSChildName
      register: pg_registry_info_64

    - name: Filter PostgreSQL info
      ansible.builtin.set_fact:
        pg_installed_info: "{{ (pg_registry_info_64.stdout_lines) | unique }}"

    - name: Display PostgreSQL installed info
      ansible.builtin.debug:
        msg: "Installed PostgreSQL info: {{ pg_installed_info }}"

    - name: Copy PostgreSQL installer if not already present
      ansible.windows.win_copy:
        src: "{{ pg_installer_local_path }}"
        dest: "{{ pg_installer_remote_path }}"
      args:
        # Kept to match the original approach; see "Idempotent copy alternative" below.
        creates: "{{ pg_installer_remote_path }}"

    - name: Install PostgreSQL silently
      ansible.windows.win_command: >
        "{{ pg_installer_remote_path }}"
        --mode unattended
        --unattendedmodeui none
        --superpassword "{{ pg_password }}"
        --servicename postgresql
        --serverport "{{ pg_port }}"
        --datadir "{{ pg_data_dir }}"
      args:
        creates: "C:\\Program Files\\PostgreSQL\\{{ pg_major_version }}\\bin\\psql.exe"

    - name: Ensure PostgreSQL service is running
      ansible.windows.win_service:
        name: postgresql
        state: started
        start_mode: auto

    - name: Remove PostgreSQL installer if still present
      ansible.windows.win_file:
        path: "{{ pg_installer_remote_path }}"
        state: absent

Important: The password and port are hard-coded here for demo only. For real environments, prefer Ansible Vault, a secrets manager, or a simple .env file.

Step-by-Step Explanation (with code)

1) Variables

vars:
  pg_installer_local_path: "/dummy/path/postgresql-installer.exe"
  pg_installer_remote_path: "C:\\Temp\\postgresql-installer.exe"
  pg_password: "MyDummyPassword123"
  pg_port: 5433
  pg_major_version: 17
  pg_data_dir: "C:\\PostgresData\\{{ pg_major_version }}\\data"

• pg_installer_local_path: Where the .exe resides on the controller.

• pg_installer_remote_path: Where Ansible will place it on the Windows host.

• pg_password: PostgreSQL superuser password.

• pg_port: PostgreSQL server port (5432 is default; using 5433 here as an example).

• pg_data_dir: Data directory PostgreSQL will initialize.

Replace the dummy paths/credentials with values for your environment.

2) Detect existing PostgreSQL (Windows Registry)

- name: Gather installed PostgreSQL info (64-bit)
  ansible.windows.win_shell: |
    Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" |
    Get-ItemProperty |
    Where-Object { $_.DisplayName -like "PostgreSQL*" } |
    Select-Object DisplayName, DisplayVersion, PSChildName
  register: pg_registry_info_64

- name: Filter PostgreSQL info
  ansible.builtin.set_fact:
    pg_installed_info: "{{ (pg_registry_info_64.stdout_lines) | unique }}"

- name: Display PostgreSQL installed info
  ansible.builtin.debug:
    msg: "Installed PostgreSQL info: {{ pg_installed_info }}"

This gives visibility into existing installs and helps avoid redundant work.

3) Copy the installer to the Windows host

- name: Copy PostgreSQL installer if not already present
  ansible.windows.win_copy:
    src: "{{ pg_installer_local_path }}"
    dest: "{{ pg_installer_remote_path }}"
  args:
    creates: "{{ pg_installer_remote_path }}"

This transfers the .exe from the controller to the Windows machine—ideal for offline Windows hosts.

Idempotent copy alternative (recommended):

- name: Check if installer already exists
  ansible.windows.win_stat:
    path: "{{ pg_installer_remote_path }}"
  register: installer_stat

- name: Copy PostgreSQL installer
  ansible.windows.win_copy:
    src: "{{ pg_installer_local_path }}"
    dest: "{{ pg_installer_remote_path }}"
  when: not installer_stat.stat.exists

4) Silent, unattended installation

- name: Install PostgreSQL silently
  ansible.windows.win_command: >
    "{{ pg_installer_remote_path }}"
    --mode unattended
    --unattendedmodeui none
    --superpassword "{{ pg_password }}"
    --servicename postgresql
    --serverport "{{ pg_port }}"
    --datadir "{{ pg_data_dir }}"
  args:
    creates: "C:\\Program Files\\PostgreSQL\\{{ pg_major_version }}\\bin\\psql.exe"

• Runs the Enterprise PostgreSQL installer with no UI.

• creates makes the task idempotent by checking for psql.exe in the expected location.

5) Ensure the Windows service is up and enabled

- name: Ensure PostgreSQL service is running
  ansible.windows.win_service:
    name: postgresql
    state: started
    start_mode: auto

Ensures PostgreSQL starts now and on reboot.

6) Tidy up: remove the installer

- name: Remove PostgreSQL installer if still present
  ansible.windows.win_file:
    path: "{{ pg_installer_remote_path }}"
    state: absent

Keeps the host clean once installation is complete.

Post-Install Verification (optional)

Add one or both of these checks to confirm the install succeeded.

Check psql.exe is present:

- name: Verify psql exists
  ansible.windows.win_stat:
    path: "C:\\Program Files\\PostgreSQL\\{{ pg_major_version }}\\bin\\psql.exe"
  register: psql_stat

- name: Report psql status
  ansible.builtin.debug:
    msg: "psql.exe found: {{ psql_stat.stat.exists }}"

Check port is listening:

- name: Test PostgreSQL port
  ansible.windows.win_shell: |
    Test-NetConnection -ComputerName localhost -Port {{ pg_port }} | Select-Object -ExpandProperty TcpTestSucceeded
  register: port_test

- name: Report port status
  ansible.builtin.debug:
    msg: "Port {{ pg_port }} listening: {{ port_test.stdout.strip() }}"

Online Alternative with win_package (skip copy step)

If the Windows host has internet access, install straight from a URL:

- name: Install PostgreSQL from URL (online hosts)
  ansible.windows.win_package:
    path: "https://example.com/path/to/postgresql-installer.exe"   # replace with the official URL
    arguments: >
      --mode unattended
      --unattendedmodeui none
      --superpassword "{{ pg_password }}"
      --servicename postgresql
      --serverport "{{ pg_port }}"
      --datadir "{{ pg_data_dir }}"
    state: present
    # Use creates_path for idempotency if supported by your Ansible version:
    creates_path: "C:\\Program Files\\PostgreSQL\\{{ pg_major_version }}\\bin\\psql.exe"

Troubleshooting

• WinRM connection errors
  Verify inventory variables (ansible_host, ansible_connection=winrm, ansible_port, ansible_winrm_transport, ansible_user, ansible_password) and that WinRM listeners/firewall rules are configured.

• Installer path issues
  Confirm both pg_installer_local_path (controller) and pg_installer_remote_path (Windows host) are correct and accessible.

• UAC/permissions
  Run with a user that has rights to install software and write to C:\Program Files\ (or choose a different target path).

• Port already in use
  If 5432/5433 is in use, change pg_port and re-run.

• Service name conflicts
  If another PostgreSQL service exists, either uninstall it or use a unique --servicename.

Conclusion

This playbook automates a silent PostgreSQL installation on Windows, making it ideal for offline hosts where you stage the installer on the controller and copy it over. For online hosts, switch to win_package and install directly from a URL. The approach is repeatable, idempotent, and production-friendly with a few hardening steps (Vault, service tuning, post-install configuration).

When people think of Ansible, they usually picture Linux servers. But Ansible can also manage Windows systems and it does so through WinRM (Windows Remote Management).

If you’re just starting with automation or DevOps, this step might sound intimidating. Don’t worry. In this guide, I’ll walk you through the easiest tested method of configuring WinRM so your Ansible control node (Linux) can talk to your Windows machines.

By the end, you’ll be able to run Ansible playbooks directly against Windows.

1. Requirements on the Ansible Control Node

First, let’s prepare the Linux machine where Ansible will run (the “control node”):

• Python 3 (ideally inside a virtual environment)

• Ansible installed

• The pywinrm Python package

Install pywinrm with:

pip install pywinrm

This package allows Ansible to communicate with Windows via WinRM.

2. Create a Windows User for Ansible

On the Windows machine, we need a dedicated user that Ansible can log in with.

You can create it either through the GUI or PowerShell.

GUI method:

• Open Computer Management → Local Users and Groups → Users

• Right-click → New User → create a user (for example, ansible_user)

PowerShell method:

New-LocalUser -Name "ansible_user" -Password (Read-Host -AsSecureString "Enter Password") -FullName "Ansible User" -Description "User for Ansible Automation"

Next, give this user administrator rights so it can perform privileged tasks:

Add-LocalGroupMember -Group "Administrators" -Member "ansible_user"

3. Open Required WinRM Ports

Ansible talks to Windows over WinRM, which uses these ports:

• 5985 → HTTP (default, unencrypted)

• 5986 → HTTPS (encrypted, recommended)

Make sure your firewall allows inbound traffic on these ports.

4. Configure WinRM Listeners

Now we need to enable and configure WinRM listeners (these are what “listen” for connections).

Basic HTTP listener (quick start)

Run this in PowerShell:

# Enable WinRM service and HTTP listener
Enable-PSRemoting -Force

# Open firewall for port 5985
$firewallParams = @{
    Action      = 'Allow'
    Description = 'Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]'
    Direction   = 'Inbound'
    DisplayName = 'Windows Remote Management (HTTP-In)'
    LocalPort   = 5985
    Profile     = 'Any'
    Protocol    = 'TCP'
}
New-NetFirewallRule @firewallParams

# Allow local user accounts for WinRM
$tokenFilterParams = @{
    Path         = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
    Name         = 'LocalAccountTokenFilterPolicy'
    Value        = 1
    PropertyType = 'DWORD'
    Force        = $true
}
New-ItemProperty @tokenFilterParams

Optional: HTTPS listener (recommended for security)

If you’d prefer encrypted communication, run this additional setup:

# Create a self-signed certificate
$certParams = @{
    CertStoreLocation = 'Cert:\LocalMachine\My'
    DnsName           = $env:COMPUTERNAME
    NotAfter          = (Get-Date).AddYears(1)
    Provider          = 'Microsoft Software Key Storage Provider'
    Subject           = "CN=$env:COMPUTERNAME"
}
$cert = New-SelfSignedCertificate @certParams

# Create HTTPS listener
$httpsParams = @{
    ResourceURI = 'winrm/config/listener'
    SelectorSet = @{
        Transport = "HTTPS"
        Address   = "*"
    }
    ValueSet = @{
        CertificateThumbprint = $cert.Thumbprint
        Enabled               = $true
    }
}
New-WSManInstance @httpsParams

# Open firewall for port 5986
$firewallParams = @{
    Action      = 'Allow'
    Description = 'Inbound rule for Windows Remote Management via WS-Management. [TCP 5986]'
    Direction   = 'Inbound'
    DisplayName = 'Windows Remote Management (HTTPS-In)'
    LocalPort   = 5986
    Profile     = 'Any'
    Protocol    = 'TCP'
}
New-NetFirewallRule @firewallParams

5. Verify the Listeners

Check that your listeners are active:

winrm enumerate winrm/config/listener

You should see entries for port 5985 (HTTP) and/or 5986 (HTTPS).

6. Configure Your Ansible Inventory

Finally, tell Ansible how to connect to the Windows host.

Edit your inventory.ini file on the control node:

[windows]
winhost01 ansible_host=192.168.1.50

[windows:vars]
ansible_user=ansible_user
ansible_password=YourStrongPassword
ansible_connection=winrm
ansible_winrm_transport=basic
ansible_port=5985

• Replace 192.168.1.50 with your Windows machine’s IP

• If you configured HTTPS, set ansible_port=5986

Wrapping Up

That’s it—you’ve successfully set up WinRM for Ansible. With this configuration, you can now start using Ansible playbooks to automate tasks on your Windows machines.

If you want to dive deeper, the official Ansible documentation on Windows is a great next step.