Ansible & Windows feedback

Introduction

During my previous mission, me and my team started using Ansible to administer our VMs (Virtual Machines) Windows. It was almost a gamble because we had no feedback, nor any echo on this still little-known practice and there are few resources on the subject apart from a few simplistic tutorials. After deployment in several environments and the administration of several hundred VMs, I’m writing these few lines to summarise what I’ve learned and perhaps motivate you to take the plunge.

Why use Ansible with Windows?

Although Microsoft has created its own language for administering its servers, Powershell is still very divisive, some people love it, others hate it, the main point of contention : its verbosity. Having done a lot, I’m still on the side of those who don’t like it very much, so why not try something different?

The idea behind using Ansible with Windows is to :

• have a single administration tool for Linux & Windows
• benefit from collections of modules created by the community
• make it easier to reuse code via roles

Setting up the solution

Installation and configuration are fairly straightforward, although a few choices need to be considered.

1. Which communication protocol do I want to use? SSH or WinRM?

Most of the community has opted for WinRM because it is the native Windows communication protocol, and the default configuration from Windows Server 2016 is sufficient for testing your first playbooks.

2. How do I authenticate to my remote machine? Do I use a local account? A domain account?

Note that these choices will have no impact on the development of your playbooks, only the ansible configuration will need to be adapted.

3. Do I know my application well?

We’ll come back to this point later.

Existing modules

The existing modules for Linux are not compatible with Windows, but if you do a little research you will quickly realise that many Ansible modules exist for Windows; this will allow you to do the majority of everyday actions without creating your own. A few modules are still missing, notably for creating and modifying GPOs.

Creating modules

Please note that I mentioned earlier that I wasn’t a big fan of Powershell but when creating a module it must be developed in Powershell (if the target VMs are Windows). We don’t use it as often but that doesn’t mean we don’t use it.

Some problems with WINRM

The main advantage of using this protocol is that WINRM https connections work by default on Windows Server 2016 and above, so there’s no configuration to do beforehand. But I’ve noticed a few limitations:

1. WINRM isn’t always very reliable when carrying out heavy or time-consuming tasks such as copying files, installing KBs, etc. Connections tend to break at random, I tried playing with various ansible parameters such as ansible_winrm_operation_timeout_sec but it didn’t help.

2. Some Antiviris like McAfee (installed on target VMs) can create alerts on incoming connections. After some research in the code of the library used by Ansible for WINRM I realised that this was a main function of the library, so there was little room for manoeuvre on this side.

Ansible, Windows & SSH

The unreliability of WINRM & the security alerts forced me to turn to an alternative: SSH. The idea may seem far-fetched as this protocol is more associated with the Unix/Linux world but I was surprised to discover that OpenSSH is installed by default on Windows Server 2019, an admission of failure on Microsoft’s part? 🤔

I’m not going to dwell on the installation and configuration of Windows with SSH as it differs fairly little from what you might see on an open source OS.

The results are clear:

• no more timeouts
• no more problems with McAfee

So this is one of the first configuration points that I would advise you to study as a minimum.

Coexistence with the application

I mentioned above that it’s important to be familiar with the application you’re running on your Windows machines, as this type of OS often hosts a proprietary solution/application and you may not know it inside out. For my part, we were using a Cisco solution which forced me to adapt my ansible and Openssh configuration and no longer rely on default settings.

a. shell type

Some solutions can already use OpenSSH with a configuration set by the vendor. In my case I had to standardize the **set ansible_shell_type** parameter to be equal to powershell instead of cmd for example.

b. binaries

The application we were using deployed executables reboot.exe and shutdown.exe, but Windows already had executables with the same names but with different parameters (inputs), which made certain community modules unusable.

As it’s never a good idea to modify the configuration used (here the orders of the environment variables) by a proprietary solution, I had to modify the ansible modules using these binaries.

Conclusion

With this somewhat critical ending, you might think that this was a bad experience, but you’d be wrong! If I ever had to work with Microsoft’s OS again, I’d still push this solution. The main difference with Linux is that there can be a finer customisation phase than with its open source counterpart. After this configuration phase, you’ll save a lot of time on your development work.