Ansible Automation — Windows On-Prem
A client running everything on-premises on Windows Server needed provisioning, configuration, patching, and deployment turned into one reproducible process. We took ownership of the automation layer end to end — a reusable role library covering web, database, and microservices tiers including MongoDB and a 4-node HA ELK 9.x cluster, dynamic inventories, Molecule-tested code, and declarative Jenkins pipelines promoting through dev, test, and prod. Delivered in two weeks, with support still running for ongoing changes.
The situation
Every layer of the estate — web servers, database servers, and a growing microservices stack running MongoDB — was provisioned and patched by hand, so two servers meant to be identical rarely were. There was also no centralized log management: engineers investigated incidents by checking individual Windows hosts one at a time. Windows made both problems harder than the usual case. Ansible has to reach hosts over WinRM rather than SSH, packages come through Chocolatey, services need Windows-specific lifecycle handling, and most community roles assume Linux and simply do not apply. The client wanted one engineer to own the automation layer outright, stand up log aggregation as part of it, and leave behind something their own team could run.
Every tier deployed from Git with zero manual steps, and a 4-node HA ELK cluster surviving zone failures.
How we worked
Stabilise delivery early, then build the foundation that keeps it stable once we hand it back.
Mapped what each tier actually needed — application and web hosts, database servers, and the MongoDB and ELK microservices stack — then designed a role library around it: a shared base role for Windows hardening, patching, and common packages, with per-service roles layered on top. Every role was scoped to be independently runnable and independently testable.
Designed a 2x2 node layout for log management: two master-eligible nodes (each co-hosting Kibana) and two data nodes (each running Logstash), distributed across fault domains. Configured shard and replica placement rules so the cluster survives a full zone failure without data loss.
Wrote idempotent roles targeting Windows over WinRM, using Chocolatey for Java and package management and win_service for lifecycle control. Replaced static host files with a dynamic inventory plus group_vars layering, so dev, test, and prod differ by variables rather than by forked playbooks, and a new host joins its group without a playbook edit. Supporting shell and YAML helper scripts were folded into the same repo.
Enabled mutual TLS across all inter-node and client communications on the ELK tier, configured RBAC with least-privilege user roles, and activated Elastic Security audit logging. All certificates are managed through the security-setup role and rotatable without cluster downtime.
Added ansible-lint with an agreed rule set and Molecule scenarios per role, so every role is converged, verified, and checked for idempotency by running it twice and asserting no changes on the second pass. Both gates run before any deployment stage, which moved failure discovery off live hosts and into CI.
Built declarative Jenkins pipelines — lint, Molecule test, deploy, post-deploy health check — triggered from Git on every commit. Promotion through dev, test, and prod runs the same pipeline against different inventories, with an approval gate before prod. Stage-level pass/fail is visible in the Jenkins console and pushed to a dedicated Slack channel, so a failed run names the stage and the host that broke it.
Simulated zone failures and verified ELK cluster recovery with no data loss. Wrote the repo documentation to a clone-and-run standard: prerequisites, WinRM setup, how to run ansible-lint, how to deploy to a fresh environment, and how to roll back. Closed with a live walkthrough demonstrating a genuinely idempotent re-run and rollback via Elasticsearch snapshot restore and versioned configs. Support continues for new roles, pipeline changes, and troubleshooting alongside the client's DevOps and infrastructure teams.
Architecture
The infrastructure design we built and handed over, drawn as it runs in production.
Handover
Stack
Afterwards
Measured after handover, once the client's own team was running the system without us.
Tell us what you are trying to move, migrate or automate and we will reply within one business day with an honest read on the work — including the parts we think you should not do.
More engagements
A full production EDI platform live within the five-server budget, with tested failover, end-to-end observability, and no SSH port exposed to the internet.
Read the case study Azure Production InfrastructureProduction-ready Azure platform live in 9 weeks with zero manual click-ops and a sub-15-minute release pipeline.
Read the case study