Ansible Windows Server 2025 Automation: WinRM, PSRP, Active Directory, IIS, Hyper-V Complete Guide

Windows Server 2025 is Microsoft's first server platform built on the Windows 11 24H2 code base. It carries the kernel build NT 10.0.26100, became generally available on November 1, 2024, and is supported with mainstream support through October 9, 2029 and Extended Security Updates (ESU) through November 14, 2034. For Ansible operators, that lineage matters: Windows Server 2025 inherits the modern PowerShell 5.1 + PowerShell 7 stack, WinRM 3.0 with TLS 1.3, and the microsoft.ad Active Directory collection that replaced the legacy win_domain modules.

# Run on the Windows Server 2025 managed node.
$ErrorActionPreference = 'Stop'
# 1. Enable WinRM with HTTPS listener.
Enable-PSRemoting -SkipNetworkProfileCheck -Force
# 2. Create a self-signed cert (replace with PKI cert in production).
$cert = New-SelfSignedCertificate `
    -DnsName $env:COMPUTERNAME `
    -CertStoreLocation Cert:\LocalMachine\My `
    -NotAfter (Get-Date).AddYears(5)
# 3. Bind the cert to WinRM HTTPS (5986).
$thumb = $cert.Thumbprint
winrm create winrm/config/Listener?Address=*+Transport=HTTPS `
    "@{Hostname=`"$env:COMPUTERNAME`";CertificateThumbprint=`"$thumb`"}"
# 4. Open firewall.
New-NetFirewallRule -DisplayName 'WinRM HTTPS-In' `
    -Direction Inbound -LocalPort 5986 -Protocol TCP -Action Allow
# 5. Set sane WinRM service quotas for Ansible workloads.
Set-Item WSMan:\localhost\Service\Auth\Basic       -Value $false
Set-Item WSMan:\localhost\Service\Auth\CredSSP     -Value $true
Set-Item WSMan:\localhost\Service\AllowUnencrypted -Value $false
Set-Item WSMan:\localhost\Shell\MaxConcurrentUsers -Value 25
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB -Value 1024
Restart-Service WinRM

winrm enumerate winrm/config/Listener

# inventory/windows.ini
[ws2025]
ws2025-01.lab.example.com
ws2025-02.lab.example.com
[ws2025:vars]
ansible_connection=winrm
ansible_port=5986
ansible_winrm_transport=credssp
ansible_winrm_server_cert_validation=ignore  ; use 'validate' in production
ansible_user=ansible_svc@LAB.EXAMPLE.COM
ansible_password='{{ vault_ansible_winrm_password }}'

ansible -i inventory/windows.ini ws2025 -m ansible.windows.win_ping

python -m pip install --upgrade "pypsrp[credssp,kerberos]>=0.10"

[ws2025:vars]
ansible_connection=psrp
ansible_port=5986
ansible_psrp_protocol=https
ansible_psrp_auth=kerberos
ansible_psrp_cert_validation=validate
ansible_user=ansible_svc@LAB.EXAMPLE.COM
ansible_password='{{ vault_ansible_psrp_password }}'

---
- name: Windows Server 2025 baseline
  hosts: ws2025
  gather_facts: true
  vars:
    ansible_winrm_read_timeout_sec: 120
    ansible_winrm_operation_timeout_sec: 90
  tasks:
    - name: Show OS version
      ansible.windows.win_shell: |
        (Get-CimInstance Win32_OperatingSystem).Caption + " " +
        (Get-CimInstance Win32_OperatingSystem).Version
      register: osver
      changed_when: false
- name: Assert build is 26100 or later
      ansible.builtin.assert:
        that:
          - "'10.0.26100' in osver.stdout"
        fail_msg: "Host is not Windows Server 2025 (NT 10.0.26100)."
- name: Install OpenSSH Server feature
      ansible.windows.win_optional_feature:
        name: OpenSSH.Server~~~~0.0.1.0
        state: present
        include_parent: true
- name: Start and enable sshd
      ansible.windows.win_service:
        name: sshd
        start_mode: auto
        state: started
- name: Set time zone
      ansible.windows.win_timezone:
        timezone: UTC
- name: Apply latest cumulative update
      ansible.windows.win_updates:
        category_names:
          - SecurityUpdates
          - CriticalUpdates
          - UpdateRollups
        reboot: true
        reboot_timeout: 1800

The legacy win_domain modules are deprecated. Use the microsoft.ad collection (1.7+) for Server 2025. The example below promotes a fresh Server 2025 host to a domain controller and creates an OU plus a service account.

---
- name: Promote Windows Server 2025 to AD DS DC
  hosts: ws2025-dc-01
  tasks:
    - name: Install AD DS role
      ansible.windows.win_feature:
        name:
          - AD-Domain-Services
          - RSAT-AD-Tools
        state: present
- name: Promote to first DC of new forest
      microsoft.ad.domain:
        dns_domain_name: lab.example.com
        domain_netbios_name: LAB
        safe_mode_password: '{{ vault_dsrm_password }}'
        forest_mode: WinThreshold   # 2025 functional level recommended after promotion
        domain_mode: WinThreshold
        reboot: true
- name: Wait for AD to come back
      ansible.windows.win_wait_for:
        timeout: 600
        port: 9389  # ADWS
- name: Create OU for service accounts
      microsoft.ad.ou:
        name: Service Accounts
        path: DC=lab,DC=example,DC=com
        state: present
- name: Create gMSA-backed service account
      microsoft.ad.user:
        name: ansible_svc
        firstname: Ansible
        surname: Service
        upn: ansible_svc@lab.example.com
        password: '{{ vault_ansible_svc_password }}'
        path: OU=Service Accounts,DC=lab,DC=example,DC=com
        state: present
        enabled: true
        password_never_expires: true

After promotion you can raise the domain functional level to Windows Server 2025 with Set-ADDomainMode -DomainMode WindowsServer2025Domain (or via the microsoft.ad.domain future mode: 2025 parameter once landed).

IIS application hosting

The example installs IIS, deploys an ASP.NET application, and binds it to HTTPS using a certificate from the local store.

---
- name: Deploy ASP.NET app on IIS / Server 2025
  hosts: ws2025-web
  vars:
    site_name: store
    site_path: C:\inetpub\store
    site_port: 443
    cert_thumbprint: '{{ vault_iis_cert_thumbprint }}'
  tasks:
    - name: Install IIS + ASP.NET
      ansible.windows.win_feature:
        name:
          - Web-Server
          - Web-Asp-Net45
          - Web-Mgmt-Console
        state: present
        include_management_tools: true
- name: Create site root
      ansible.windows.win_file:
        path: '{{ site_path }}'
        state: directory
- name: Deploy application bundle
      ansible.windows.win_copy:
        src: dist/store.zip
        dest: 'C:\Windows\Temp\store.zip'
- name: Extract bundle
      community.windows.win_unzip:
        src: 'C:\Windows\Temp\store.zip'
        dest: '{{ site_path }}'
        delete_archive: true
- name: Create IIS application pool
      community.windows.win_iis_webapppool:
        name: '{{ site_name }}'
        state: started
        attributes:
          managedRuntimeVersion: v4.0
          processModel.identityType: ApplicationPoolIdentity
- name: Create IIS site
      community.windows.win_iis_website:
        name: '{{ site_name }}'
        physical_path: '{{ site_path }}'
        application_pool: '{{ site_name }}'
        state: started
        bindings:
          - protocol: https
            port: '{{ site_port }}'
            certificate_hash: '{{ cert_thumbprint }}'
            certificate_store: My

Hyper-V automation

Windows Server 2025 introduced Hyper-V on ARM64, GPU Partitioning v2, and Live Migration over QUIC. The playbook below enables the Hyper-V role and provisions a VM from a Server 2025 ISO.

---
- name: Provision Hyper-V VM on Server 2025
  hosts: ws2025-hv-01
  tasks:
    - name: Enable Hyper-V role
      ansible.windows.win_feature:
        name: Hyper-V
        state: present
        include_management_tools: true
      register: hv
- name: Reboot if Hyper-V was just installed
      ansible.windows.win_reboot:
      when: hv.reboot_required
- name: Create external virtual switch
      ansible.windows.win_shell: |
        if (-not (Get-VMSwitch -Name 'External' -ErrorAction SilentlyContinue)) {
          New-VMSwitch -Name 'External' `
            -NetAdapterName (Get-NetAdapter -Physical | Where-Object Status -eq 'Up' | Select-Object -First 1).Name `
            -AllowManagementOS $true
        }
- name: Create Generation 2 VM
      ansible.windows.win_shell: |
        New-VM -Name 'app01' `
          -Generation 2 `
          -MemoryStartupBytes 4GB `
          -SwitchName 'External' `
          -NewVHDPath 'D:\VMs\app01\app01.vhdx' `
          -NewVHDSizeBytes 80GB
        Set-VMProcessor -VMName 'app01' -Count 4
        Set-VM -Name 'app01' -AutomaticCheckpointsEnabled $false
        Add-VMDvdDrive -VMName 'app01' `
          -Path 'D:\ISO\WindowsServer2025.iso'
        Start-VM -Name 'app01'
      args:
        creates: 'D:\VMs\app01\app01.vhdx'

Failover Cluster bootstrap

Two-node cluster on Server 2025 with Storage Spaces Direct (S2D):

---
- name: Build 2-node S2D cluster
  hosts: ws2025-clu
  serial: 1
  tasks:
    - name: Install Failover Clustering + S2D prerequisites
      ansible.windows.win_feature:
        name:
          - Failover-Clustering
          - RSAT-Clustering-PowerShell
          - File-Services
        state: present
- name: Run cluster validation (first node only)
      ansible.windows.win_shell: |
        Test-Cluster -Node {{ groups['ws2025-clu'] | join(',') }} -Include "Storage Spaces Direct","Inventory","Network","System Configuration"
      run_once: true
      changed_when: false
- name: Create cluster
      ansible.windows.win_shell: |
        if (-not (Get-Cluster -ErrorAction SilentlyContinue)) {
          New-Cluster -Name s2d-cluster `
            -Node {{ groups['ws2025-clu'] | join(',') }} `
            -StaticAddress 10.10.10.50 `
            -NoStorage
          Enable-ClusterStorageSpacesDirect -Confirm:$false
        }
      run_once: true

Group Policy via Ansible

Server 2025 supports Group Policy preferences and central store on SYSVOL. The simplest pattern is to land ADMX templates and import GPO backups:

- name: Stage ADMX central store
  ansible.windows.win_copy:
    src: files/admx/
    dest: C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\
- name: Import GPO backup
  ansible.windows.win_shell: |
    Import-GPO -BackupGpoName 'Baseline-Servers' `
      -TargetName 'Baseline-Servers' `
      -Path C:\GpoBackups `
      -CreateIfNeeded

For granular registry-based settings, prefer ansible.windows.win_regedit — it is idempotent and avoids GPO replication delays.

Software with Chocolatey

Chocolatey is the canonical software channel for Windows fleets under Ansible. Install Chocolatey itself, then declare packages:

- name: Install Chocolatey + tools
  hosts: ws2025
  tasks:
    - name: Bootstrap Chocolatey
      chocolatey.chocolatey.win_chocolatey:
        name: chocolatey
        state: present
- name: Install operator tooling
      chocolatey.chocolatey.win_chocolatey:
        name:
          - 7zip
          - git
          - notepadplusplus
          - sysinternals
          - wireshark
          - vscode
        state: present

SMB-over-QUIC

Server 2025 promotes SMB-over-QUIC out of preview. Enable it on a file server:

- name: Enable SMB over QUIC
  hosts: ws2025-fs
  tasks:
    - name: Bind SMB to a server certificate
      ansible.windows.win_shell: |
        New-SmbServerCertificateMapping `
          -Name 'fs.lab.example.com' `
          -Thumbprint {{ smb_quic_thumbprint }} `
          -StoreName My `
          -Type QUIC
- name: Enforce SMB encryption
      ansible.windows.win_shell: |
        Set-SmbServerConfiguration -EncryptData $true -RejectUnencryptedAccess $true -Force

Clients then mount with \\fs.lab.example.com\share over UDP/443.

Hotpatching

Server 2025 Standard and Datacenter both support hotpatching when enrolled with Azure Arc. Toggle it via:

- name: Enable hotpatch
  ansible.windows.win_shell: |
    Install-Module -Name AzureHotpatch -Force -AllowClobber
    Enable-AzureHotpatch

Hotpatch CUs install without reboot; quarterly baseline still requires a reboot, which ansible.windows.win_updates handles cleanly with reboot: true.

Troubleshooting

| Symptom | Likely cause | Fix | |---|---|---| | kerberos: Server not found in Kerberos database | SPN mismatch | setspn -A HTTP/ | | winrm: HTTPSConnectionPool ... certificate verify failed | Self-signed cert | Set ansible_winrm_server_cert_validation=ignore (lab only) or import the issuing CA | | Access is denied on AD DS modules | Insufficient delegation | Grant Account Operators or Domain Admins to the Ansible service account | | win_updates hangs | WSUS unreachable | Verify proxy / WSUS server URL via Group Policy | | Hyper-V New-VM fails with Generation 2 | Host firmware not UEFI | Hyper-V Gen 2 requires UEFI host; convert MBR to GPT |

FAQ

Q. Does Ansible support Windows Server 2025 with the Windows 11 24H2 kernel? Yes. ansible-core 2.18 and later, with ansible.windows 3.0+, fully support build NT 10.0.26100. There are no deprecated modules required for routine tasks.

Q. Should I use WinRM or PSRP on Server 2025? Prefer PSRP. It is faster, supports SSH tunneling, and avoids the WinRM shell-creation overhead. Keep WinRM as a fallback for legacy fleets.

Q. Can I use OpenSSH instead of WinRM on Server 2025? Yes. Set ansible_connection=ssh and ansible_shell_type=powershell and add the OpenSSH server feature (shown in the baseline). SSH is recommended for cross-platform inventories that already use SSH.

Q. Are win_domain and win_domain_controller still supported? They are deprecated. Migrate to microsoft.ad.domain and microsoft.ad.domain_controller for Server 2025; the legacy modules will be removed in ansible.windows 4.0.

Q. How do I raise the AD functional level to 2025? After all DCs are Server 2025: Set-ADForestMode -ForestMode Windows2025Forest and Set-ADDomainMode -DomainMode Windows2025Domain. Keep one Server 2022 DC online during the rollout for fallback.

Q. Does hotpatching eliminate reboots completely? No. Hotpatching covers monthly security CUs without reboot, but the quarterly baseline still requires a reboot. Plan a maintenance window every three months.

Related guides

Conclusion

Windows Server 2025 is a clean upgrade path for Ansible-managed Windows estates: WinRM and PSRP are unchanged, the microsoft.ad collection covers the new functional level, and the Windows 11 24H2 kernel brings hotpatching, SMB-over-QUIC, and Hyper-V on ARM64 into the automation surface. Standardize on ansible-core 2.18 LTS + ansible.windows 3.0 + microsoft.ad 1.7, prefer PSRP transport, and use Chocolatey as your software channel. With those defaults the playbooks in this guide will carry your fleet through 2034.