Subscribe to the feed

“We are the Borg. Lower your shields and surrender your ships. We will add your technological distinctiveness to our own and add it to our Red Hat Ansible Automation Platform inventory.”

Okay, so I added the last part but I am certain that in that sci-fi universe the Borg and Federation would be big users of Ansible.

Spock once said, “Superior ability breeds superior ambition.” One of the biggest benefits of Ansible is that it is use case friendly, meaning that it is able to provide automation to almost every part of the technology stack. Multi-vendor network appliances, hybrid cloud, infrastructure–these are all common projects for Ansible automation. With the latest addition of Event-Driven Ansible to the platform, we have the ability to automate those mission critical platforms and applications. Ansible has the superior ability to your superior ambition.

Now Windows–we all love Windows. We love it even more since it can also be automated with Ansible. Windows automation with Ansible is becoming increasingly popular. In this blog, I hope to add some “technical distinctiveness to our own” and show you how to “assimilate” Windows hosts using Ansible.

Windows administrators around the galaxy have a number of tools they use to manage their enterprise. These tools might serve the purpose for Windows administration but they inherently create a silo and rely on specialized expertise which we want to avoid. Imagine not being able to get the USS Enterprise to bring its shields up because we don’t have the correct tool or a specific engineer to do the job. Using a centralized platform with shared skill sets that can control the shields, the warp drive, the Holodeck, and the captain’s massage chair just makes practical and business sense. In an IT environment, Red Hat Ansible Automation Platform does exactly this.

Captains Log: Connecting to Windows

To connect to Windows hosts and automate them, we need to use WinRM (instead of SSH) and create an execution environment to run our automation tasks with the collections we use for Windows. Yes, we have certified and supported content collections for Windows as well as for tools like Chocolatey that can be used to deploy applications on Windows hosts.

If you are new to Ansible Automation Platform, execution environments are purpose-built containers that contain everything you need to automate with Ansible. You create these execution environments with the required collections that Ansible will need to run your job templates.

Note: To find out more about execution environments, have a look at: The anatomy of automation execution environments

The execution environment I'm using for my Windows automation has the following requirement.yml:


 - community.general
 - ansible.utils
 - ansible.posix
 - chocolatey.chocolatey

requests-credssp > 2.2.0



Once the execution environment ready, you can push it into a container registry like or to your private automation hub which is part of Ansible Automation Platform. Next, I can add it to my automation controller and use it for all my Windows related automation templates.

To prepare your Windows systems for Ansible assimilation, you can grab the latest copy of the ConfigureRemotingForAnsible PowerShell script and run it on your hosts. This is a quick baseline that you can use to customize and configure your host.

In my example, I will be using the following script to configure my hosts. I have a https listener configured, and I'm planning to use NTLM authentication since I am not running Kerberos. It is always recommended to run at least NTLM authentication. I am also enabling PowerShell remote protocol to give me a slight speed improvement.

## Enable PowerShell Remote protocol
Enable-PSRemoting -Force
$certParams = @{
   DnsName           = $env:COMPUTERNAME
   CertStoreLocation = "Cert:\LocalMachine\My"
$cert = New-SelfSignedCertificate @certParams

## Configure HTTPS transport
$wsmanParams = @{
   ResourceURI = "winrm/config/Listener"
   SelectorSet = @{
       Transport = "HTTPS"
       Address = "*"
   ValueSet    = @{
       CertificateThumbprint = $cert.Thumbprint
       Enabled               = $true
New-WSManInstance @wsmanParams

## Configure Firewall Rules
$firewallParams = @{
   DisplayName = "Windows Remote Management (HTTPS-In)"
   Direction   = "Inbound"
   LocalPort   = 5986
   Protocol    = "TCP"
   Action      = "Allow"
New-NetFirewallRule @firewallParams

## Regedit to filter access tokens
$regInfo = @{
   Path         = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
   Name         = "LocalAccountTokenFilterPolicy"
   Value        = 1
   PropertyType = "DWord"
   Force        = $true
New-ItemProperty @regInfo

Windows: Engage!

We have our execution environment with our Windows collections and we have our hosts configured with WinRM. Now We need to configure these hosts in our inventory on Ansible Automation Platform and, since it's Windows, a bit more information around these hosts is needed. In my inventory, I have Windows hosts managed within a group and I have used group variables to define some of the details.

We will use these details when we attempt to connect to the Windows systems. We can now add our hosts to this group so they inherit the inventory variables we have defined at the group level. In my example, just like a totally logical Vulcan, my host is called windows.

With our hosts in our inventory, we just need to create a credential to authenticate on our hosts. In this example I will use a standard machine credential with the local administrator account details.

Note: There is a great blog about the new Active Directory Inventory plugin which looks at how you can use Active Directory as a source of truth and credentials for your Windows hosts.

Lastly, I like to check that my connectivity is working. So we can go back into our inventory on our controller and navigate to our host that we have just added. In the automation controller, we have the ability to run commands or ad-hoc modules to test or gather information from our inventory hosts. We will select the host and then select: run command.

We can use the win_ping module, which is used to check connectivity on Windows hosts with Ansible and not an ICMP ping.

Next we need to make sure that we execute this module in our Windows execution environment.

We can then choose the desired credentials:

We can then engage, I mean, launch. Our module should return a ”pong” for our “ping” if connectivity is successful. This means we are ready to automate!

We are ready to automate!

What can I do next?

Whether you are beginning your automation journey or a seasoned veteran, there are a variety of resources to enhance your automation knowledge:

저자 소개

Nuno is a Technical Marketing Manager for the Ansible Automation Platform. He is a Red Hat Certified Architect and a Certified Instructor with over 15 years of experience in multiple technologies. Currently based in South Africa, he has international experience with having worked all over Europe and Africa.
Read full bio

채널별 검색

automation icon


기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon


고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon


환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon


세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon


복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리