Belajar Ansible - Windows Automation dengan Ansible

#Pendahuluan

Setelah di episode 27 sebelumnya kita membahas security hardening dan compliance automation untuk sistem Linux — CIS benchmark, hardening SSH, patch management, dan scanning — pada episode kali ini kita akan meruntuhkan asumsi yang sering dipegang banyak engineer: "Ansible hanya bisa mengelola Linux."

Faktanya, sebagian besar perusahaan di dunia nyata adalah mixed environment: ada Linux untuk server aplikasi, ada Windows untuk Active Directory, file server, IIS, atau desktop yang dikelola. Tim infrastruktur yang hanya bisa mengotomasi satu platform akan selalu kerepotan karena harus membagi otak antara dua toolset yang berbeda. Di sinilah keunggulan Ansible sebagai single automation platform terlihat jelas: satu bahasa YAML, satu playbook, satu pola pikir — bekerja untuk keduanya.

Bayangkan kalian adalah seorang pengelola gedung yang punya dua tipe pintu: pintu besi dengan kunci mekanis, dan pintu kaca dengan kartu akses digital. Kalian tidak ingin membawa dua macam kunci yang berbeda prosesnya; kalian ingin satu sistem akses terpusat yang mengelola keduanya. Itulah posisi Ansible di lingkungan hybrid: satu control plane untuk semua target.

Namun ada satu perbedaan fundamental yang harus dipahami sebelum mulai: Ansible tidak berbicara dengan Windows lewat SSH seperti ke Linux. Ia berbicara lewat WinRM (Windows Remote Management) atau protocol lain yang kompatibel, dan setiap task dieksekusi sebagai perintah PowerShell. Pada episode ini kita akan membahas persiapan WinRM dan PowerShell remoting, metode autentikasi (Basic, NTLM, Kerberos, CredSSP), collection ansible.windows dan community.windows, modul-modul utamanya, automasi tugas spesifik Windows (IIS, Windows Update, Active Directory, registry, scheduled task), serta best practice hardening WinRM.

#Pembahasan Utama

#Mengapa Windows "Berbeda" di Ansible

Linux menggunakan Python + SSH. Windows menggunakan PowerShell + WinRM. Perbedaan ini membawa beberapa konsekuensi:

• Agentless tetap berlaku — Ansible tidak menginstall agent permanen, tapi Windows harus memiliki PowerShell 3.0+ dan WinRM yang aktif.
• ansible.builtin.shell berbeda — di Windows, task shell dieksekusi sebagai PowerShell, bukan bash. win_command dan win_shell adalah versi Windows-nya.
• Facts berbeda — modul setup di Windows menghasilkan ansible_facts yang berbeda (ansible_os_family bernilai Windows, hostname, dll) dan tidak semua fact Linux tersedia.
• Semua modul yang dipakai harus mendukung Windows — modul ansible.builtin.apt misalnya tidak akan pernah berjalan di Windows. Diperlukan modul seperti ansible.windows.win_*.

#Windows Management Requirements: WinRM & PowerShell Remoting

Sebelum Ansible bisa masuk, target Windows harus punya dua hal: WinRM yang aktif dan PowerShell remoting yang diizinkan. Cara paling sederhana untuk menyiapkannya adalah dengan menjalankan script ConfigureRemotingForAnsible.ps1 yang tersedia di official documentation Ansible — cukup dijalankan sekali sebagai Administrator di PowerShell.

Persiapan WinRM (PowerShell as Administrator)

# Download dan jalankan script konfigurasi WinRM untuk Ansible
$url = "https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1"
$file = "$env:temp\ConfigureRemotingForAnsible.ps1"
Invoke-WebRequest -Uri $url -OutFile $file
powershell.exe -ExecutionPolicy ByPass -File $file

Script tersebut melakukan beberapa hal penting: membuat listener WinRM pada port 5986 (HTTPS) dengan self-signed certificate, mengizinkan traffic di firewall, mengaktifkan Basic auth, serta menyesuaikan service WinRM agar bisa menerima koneksi. Setelah itu, verifikasi listener WinRM:

Verifikasi WinRM listener

winrm enumerate winrm/config/listener
 
# Output yang diharapkan:
# Listener
#     Address = *
#     Transport = HTTPS
#     Port = 5986
#     Hostname = WSERVER-01
#     Enabled = true

#Metode Autentikasi: Basic, NTLM, Kerberos, CredSSP

Pilihan metode autentikasi adalah keputusan pertama yang harus kalian buat. Setiap metode punya trade-off antara kemudahan, keamanan, dan kemampuan credential delegation (kemampuan mengalirkan kredensial ke service jarak jauh):

Contoh code group berikut menunjukkan variabel koneksi untuk masing-masing metode:

win_host:
  ansible_host: 192.168.10.20
  ansible_connection: winrm
  ansible_winrm_transport: basic
  ansible_winrm_server_cert_validation: ignore
  ansible_user: Administrator
  ansible_password: "{{ vault_win_password }}"

win_host:
  ansible_host: 192.168.10.20
  ansible_connection: winrm
  ansible_winrm_transport: ntlm
  ansible_winrm_server_cert_validation: validate
  ansible_user: DOMAIN\\svc_ansible
  ansible_password: "{{ vault_win_password }}"

win_host:
  ansible_host: 192.168.10.20
  ansible_connection: winrm
  ansible_winrm_transport: kerberos
  ansible_winrm_server_cert_validation: validate
  ansible_user: svc_ansible@CORP.EXAMPLE.COM
  # Tanpa ansible_password -> memakai ticket Kerberos dari control node

win_host:
  ansible_host: 192.168.10.20
  ansible_connection: winrm
  ansible_winrm_transport: credssp
  ansible_winrm_server_cert_validation: validate
  ansible_user: CORP\\svc_ansible
  ansible_password: "{{ vault_win_password }}"

#Inventory Windows

Karena Ansible mendeteksi tipe OS otomatis, playbook yang sama bisa menargetkan campuran Linux dan Windows. Namun variabel koneksi harus jelas per host. Contoh inventory YAML dengan group Windows:

all:
  children:
    linux_servers:
      hosts:
        ubuntu-01:
          ansible_host: 10.0.1.10
        rhel-01:
          ansible_host: 10.0.1.11
 
    windows_servers:
      hosts:
        wsrv-01:
          ansible_host: 10.0.2.20
        wsrv-02:
          ansible_host: 10.0.2.21
      vars:
        ansible_connection: winrm
        ansible_winrm_transport: ntlm
        ansible_winrm_server_cert_validation: validate
        ansible_user: CORP\\svc_ansible
        ansible_password: "{{ vault_win_password }}"

Perhatikan tiga variabel kunci di sini:

• ansible_connection: winrm — memberi tahu Ansible untuk memakai plugin connection WinRM, bukan SSH.
• ansible_winrm_server_cert_validation: validate — memverifikasi sertifikat TLS server WinRM; set ke ignore hanya untuk testing.
• ansible_user / ansible_password — kredensial yang dipakai; untuk Basic/NTLM, format user bisa DOMAIN\user.

#Collection dan Modul Windows

Collection resmi untuk otomasi Windows adalah ansible.windows (didukung Red Hat) dan community.windows (komunitas). Ini peta modul yang paling sering dipakai:

#Manajemen Paket: Chocolatey dan win_package

Chocolatey adalah package manager untuk Windows — analog dengan apt/dnf di Linux. Dengan win_chocolatey, kalian bisa menginstall aplikasi secara deklaratif dan idempotent:

- name: Install package dengan Chocolatey
  hosts: windows_servers
  gather_facts: true
  tasks:
    - name: Install aplikasi umum
      ansible.windows.win_chocolatey:
        name: "{{ item }}"
        state: present
        version: "{{ item_version | default(omit) }}"
      loop:
        - git
        - 7zip
        - notepadplusplus
        - putty
 
    - name: Upgrade semua package ke versi terbaru
      ansible.windows.win_chocolatey:
        name: all
        state: latest

Untuk installer lama yang tidak tersedia di Chocolatey (misalnya installer internal perusahaan), gunakan win_package yang bisa mengeksekusi .msi, .exe, atau .msu dengan parameter silent:

- name: Install software kustom internal
  ansible.windows.win_package:
    path: \\fileserver\installers\internal-app-2.1.msi
    product_id: "{GUID-PRODUCT-ID-KHUSUS}"
    arguments: /qn /norestart
    state: present

#Mengelola Service Windows

Modul win_service mengelola service Windows dengan cara yang sama seperti systemd_service di Linux — termasuk status yang idempotent:

- name: Kelola Windows service
  hosts: windows_servers
  tasks:
    - name: Pastikan IIS W3SVC berjalan dan auto-start
      ansible.windows.win_service:
        name: W3SVC
        state: started
        start_mode: auto
 
    - name: Nonaktifkan service yang tidak digunakan
      ansible.windows.win_service:
        name: DiagTrack
        state: stopped
        start_mode: disabled

#Konfigurasi IIS Web Server

IIS (Internet Information Services) adalah web server bawaan Windows. Dengan Ansible, setup IIS dari nol — install feature, buat website, konfigurasi binding, hingga restart — semua bisa otomatis. Contoh code group berikut menunjukkan dua pendekatan: install feature IIS, lalu membuat website lengkap dengan binding:

- name: Install IIS dan fitur pendukung
  hosts: windows_servers
  become: true
  tasks:
    - name: Install feature IIS + ASP.NET
      ansible.windows.win_feature:
        name:
          - Web-Server
          - Web-WebSockets
          - Web-Asp-Net45
          - Web-Mgmt-Console
        state: present
      register: iis_feature
 
    - name: Reboot jika diperlukan
      ansible.windows.win_reboot:
      when: iis_feature.reboot_required

- name: Buat website di IIS
  hosts: windows_servers
  tasks:
    - name: Hapus Default Web Site
      community.windows.win_iis_website:
        name: Default Web Site
        state: absent
 
    - name: Buat website aplikasi dengan binding 8080
      community.windows.win_iis_website:
        name: WebApp
        state: started
        port: 8080
        ip: "*"
        hostname: "{{ ansible_host }}"
        physical_path: C:\inetpub\wwwroot\webapp
        application_pool: WebAppPool
 
    - name: Set SSL binding 443
      community.windows.win_iis_webbinding:
        name: WebApp
        protocol: https
        port: 443
        ip: "*"
        certificate_hash: "{{ iis_cert_thumbprint }}"
        state: present

#Automasi Windows Update

Mengelola Windows Update lewat Ansible adalah salah satu use case paling bernilai — tidak perlu lagi login RDP satu per satu. Modul win_updates mendukung kategori update, filtering, dan manajemen reboot:

- name: Patch Windows Server
  hosts: windows_servers
  gather_facts: false
  tasks:
    - name: Install semua update keamanan & critical
      ansible.windows.win_updates:
        category_names:
          - SecurityUpdates
          - CriticalUpdates
        state: installed
        reboot: true
        reboot_timeout: 1800
        log_path: C:\ansible\windows-update.log

#Active Directory, Registry, dan Scheduled Task

Active Directory — tim infra Windows hampir pasti berurusan dengan AD. Collection community.windows menyediakan modul untuk membuat user, group, hingga join domain:

- name: Manajemen Active Directory
  hosts: domain_controllers
  vars:
    ad_ou: "OU=ServiceAccounts,OU=Corp,DC=corp,DC=example,DC=com"
  tasks:
    - name: Buat service account baru
      community.windows.win_domain_user:
        name: svc_backup
        password: "{{ vault_svc_backup_password }}"
        state: present
        groups:
          - Backup Operators
        password_never_expires: true
        user_cannot_change_password: true
        path: "{{ ad_ou }}"
 
    - name: Join host baru ke domain
      community.windows.win_domain_membership:
        dns_domain_name: corp.example.com
        domain_admin_user: "{{ ad_admin_user }}"
        domain_admin_password: "{{ vault_ad_admin_password }}"
        state: domain

Registry — banyak pengaturan Windows yang tidak punya API resmi hanya bisa diakses lewat registry. Modul win_regedit mengubahnya menjadi idempotent:

- name: Set policy melalui registry
  hosts: windows_servers
  tasks:
    - name: Nonaktifkan Windows Telemetry
      ansible.windows.win_regedit:
        path: HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection
        name: AllowTelemetry
        data: 0
        type: dword

Scheduled Task — alternatif Windows untuk cron. Modul win_scheduled_task membuat jadwal yang berulang:

- name: Buat scheduled task backup log
  ansible.windows.win_scheduled_task:
    name: LogBackupDaily
    description: "Backup IIS log setiap hari pukul 02:00"
    actions:
      - path: C:\scripts\backup-logs.ps1
        working_directory: C:\scripts
    triggers:
      - type: daily
        start_boundary: "2026-08-02T02:00:00"
    run_level: highest
    state: present
    username: CORP\\svc_ansible
    password: "{{ vault_win_password }}"

#Best Practices: Hardening WinRM & Credential Security

Windows automation yang aman butuh lebih dari sekadar berhasil terhubung. Berikut praktik yang wajib diterapkan di production:

1. Wajib HTTPS. Gunakan listener WinRM port 5986 dengan sertifikat dari internal CA, dan set ansible_winrm_server_cert_validation: validate.
2. Hindari Basic auth di luar jaringan tepercaya. Gunakan NTLM sebagai baseline, Kerberos saat memungkinkan, dan batasi CredSSP hanya untuk skenario double-hop.
3. Gunakan akun service khusus dengan hak minimal (bukan Administrator universal) dan aktifkan password rotation — misalnya di-manage via AAP/AWX credential (episode 29).
4. Selalu enkripsi kredensial dengan Ansible Vault dan tambahkan no_log: true pada task yang menerima password.
5. Batasi akses WinRM. Di hosts.allow firewall, hanya izinkan IP control node/AAP ke port 5986.
6. Jaga execution policy tetap terkunci (AllSigned/RemoteSigned) dan jangan menonaktifkannya demi kemudahan script.

#Kesalahan Umum (Common Pitfalls)

1. Lupa dependensi pywinrm di control node

Connection akan gagal dengan No module named 'winrm'. Install dulu pip install pywinrm dan collection ansible.windows.

2. Basic auth tanpa HTTPS

Password dikirim base64 over HTTP — bisa dibaca siapa saja. Selalu pakai HTTPS untuk Basic, atau pindah ke NTLM/Kerberos.

3. Memakai modul Linux di host Windows

ansible.builtin.apt, ansible.builtin.systemd_service, ansible.posix.firewalld tidak akan pernah berjalan di Windows. Gunakan modul win_* dari collection ansible.windows / community.windows, dan pisahkan task per platform dengan when: ansible_os_family == 'Windows' atau gunakan include terpisah.

4. Lupa become/hak administrator

Banyak operasi Windows (install feature, service, registry system) butuh hak administrator. Pastikan akun WinRM memiliki privilege yang cukup, atau gunakan runas / become_method: runas dengan akun yang tepat.

5. Salah format user domain

Notasi DOMAIN\user di YAML harus di-escape (misalnya "CORP\\svc_ansible") agar backslash tidak hilang saat parsing. Satu kesalahan kecil ini sering membuat autentikasi gagal secara misterius.

6. Mengabaikan reboot_required

Setelah win_feature atau update, banyak perubahan baru aktif setelah reboot. Tangkap register lalu panggil win_reboot bersyarat — jangan biarkan server berjalan setengah ter-update.

#Penutup

Pada episode ini kita telah membahas Windows automation dengan Ansible secara lengkap: memahami mengapa Windows memakai WinRM dan PowerShell alih-alih SSH, menyiapkan WinRM listener dan PowerShell remoting, memilih metode autentikasi yang tepat (Basic, NTLM, Kerberos, CredSSP) beserta trade-off masing-masing, membangun inventory Windows, dan memanfaatkan collection ansible.windows dan community.windows untuk mengelola paket (Chocolatey), service, IIS, Windows Update, Active Directory, registry, dan scheduled task. Kita juga membahas best practice hardening WinRM dan enam kesalahan umum yang sering menjegal pemula.

Dengan kemampuan ini, kalian kini bisa mengelola server Linux dan Windows dari satu control node, satu bahasa YAML, dan satu pola pikir — kombinasi yang langka dan sangat berharga di pasar kerja. Ansible benar-benar menjadi universal remote control untuk seluruh infrastruktur.

Di episode 29 selanjutnya, kita akan membahas bagaimana membawa Ansible dari skala tim kecil ke skala enterprise: Scaling Ansible untuk Enterprise — arsitektur terpusat dengan AAP/AWX/Semaphore, pola GitOps, strategi monorepo vs multi-repo, RBAC dan credential management, hingga optimasi performa untuk ribuan host dengan callback plugin dan Mitogen. Pastikan tetap semangat!