Chapter 4: Ansible and Windows – Not Just for Linux

A great deal of the work on Ansible has been performed on Linux OSes; indeed, the first two editions of this book were based entirely around the use of Ansible in a Linux-centric environment. However, most environments are not like that, and, at the very least, are liable to have at least some Microsoft Windows server and desktop machines. Since the third edition of this book was published, much work has gone into Ansible to create a really robust cross-platform automation tool that is equally at home in both a Linux data center and a Windows one. There are fundamental differences in the way Windows and Linux hosts operate, of course, and so it should come as no surprise that there are some fundamental differences between how Ansible automates tasks on Linux, and how it automates tasks on Windows.

We will cover those fundamentals in this chapter, so as to give you a rock-solid foundation to begin automating your Windows...

Technical requirements

To follow the examples presented in this chapter, you will need a Linux machine running Ansible 4.3 or newer. Almost any flavor of Linux should do; for those interested in specifics, all the code presented in this chapter was tested on Ubuntu Server 20.04 LTS unless stated otherwise, and on Ansible 4.3.

Where Windows is used in this chapter, the example code was tested and run on Windows Server 2019, version 1809, build 17763.1817. Screenshots of the Windows Store were taken from Windows 10 Pro, version 20H2, build 19042.906.

The example code that accompanies this chapter can be downloaded from GitHub at this URL: https://github.com/PacktPublishing/Mastering-Ansible-Fourth-Edition/tree/main/Chapter04.

Check out the following video to see the Code in Action: https://bit.ly/3B2zmvL.

Running Ansible from Windows

If you browse the official installation documentation for Ansible, you will find a variety of instructions for most mainstream Linux variants, Solaris, macOS, and FreeBSD. You will note, however, that there is no mention of Windows. There is a good reason for this – for those interested in the technical detail, Ansible makes extensive use of the POSIX fork() syscall in its operations, and no such call exists on Windows. POSIX compatibility projects, such as the venerable Cygwin, have attempted to implement fork() on Windows, but sometimes this does not work correctly even today. As a result, despite there being a viable Python implementation for Windows, Ansible cannot be run natively on this platform without the presence of this important syscall.

The good news is that, if you are running recent versions of Windows 10, or Windows Server 2016 or 2019, installing and running Ansible is now incredibly easy thanks to Windows Subsystem for Linux ...

Setting up Windows hosts for Ansible control using WinRM

So far, we have talked about running Ansible itself from Windows. This is helpful, especially in a corporate environment where perhaps Windows end user systems are the norm. However, what about actual automation tasks? The good news is that, as already stated, automation of Windows with Ansible does not require WSL. One of Ansible's core premises is to be agentless, and that remains just as true for Windows as for Linux. It is fair to assume that almost any modern Linux host will have SSH access enabled, and similarly, most modern Windows hosts have a remote management protocol built in, called WinRM. Ardent followers of Windows will know that Microsoft has, in a more recent edition, added both the OpenSSH client and server packages, and since the last edition of this book was published, experimental support for these has been added to Ansible. For security reasons, both of these technologies are disabled by default...

Handling Windows authentication and encryption when using WinRM

Now that we have established the basic level of connectivity required for Ansible to perform tasks on a Windows host using WinRM, let's dig deeper into the authentication and encryption side of things. In the earlier part of the chapter, we used the basic authentication mechanism with a local account. While this is fine in a testing scenario, what happens in a domain environment? Basic authentication only supports local accounts, so clearly we need something else here. We also chose not to validate the SSL certificate (as it was self-signed), which again, is fine for testing purposes, but is not best practice in a production environment. In this section, we will explore options for improving the security of our Ansible communications with Windows.

Authentication mechanisms

Ansible, in fact, supports five different Windows authentication mechanisms when WinRM is used, as follows:

• Basic: Supports...

Setting up Windows hosts for Ansible control using OpenSSH

Microsoft has made great strides in supporting and embracing the open source community, and has added a number of popular open source packages to their OSes. One of the most notable as far as Ansible automation is concerned is the venerable and incredibly popular OpenSSH package, which comes in both client and server flavors.

Support for automating tasks on Windows using SSH as the transport rather than WinRM was added in Ansible 2.8 – however, it should be noted that there are many warnings about this support in the official Ansible documentation – support is described as experimental, and users are warned that things might change in the future in a way that is not backward compatible. In addition, developers expect to uncover more bugs as they continue their testing.

For these reasons, we have put a lot of effort into describing the setup of WinRM for automating Windows hosts with Ansible. Nonetheless...

Automating Windows tasks with Ansible

A list of the Windows modules included with Ansible 4.3 is available at the following link, and it must be noted that, although you can use all the familiar Ansible constructs with Windows hosts such as vars, handlers, and blocks, you must use Windows-specific modules when defining tasks. The introduction of collections means it is quite easy to locate them, and the ansible.windows collection is a great place to start. This contains all the Windows-specific modules you were used to using in Ansible 2.9 and earlier: https://docs.ansible.com/ansible/latest/collections/index_module.html#ansible-windows.

In this part of the chapter, we will run through a few simple examples of Windows playbooks to highlight a few of the things you need to know when writing playbooks for Windows.

Picking the right module

If you were running Ansible against a Linux server, and wanted to create a directory and then copy a file into it, you would use the...

Summary

Ansible handles Windows hosts as effectively as Linux (and other Unix) ones. In this chapter, we covered both how to run Ansible from a Windows host, and how to integrate Windows hosts with Ansible for automation, including the authentication mechanisms, encryption, and even the basics of Windows-specific playbooks.

You have learned that Ansible can run from a recent build of Windows that supports WSL, and how to achieve this. You have also learned how to set up Windows hosts for Ansible control and how to secure this with Kerberos authentication and encryption. You also learned how to set up and use the new and experimental support for SSH communication by Ansible with Windows hosts. Finally, you learned the basics of authoring Windows playbooks, including finding the correct modules for use with Windows hosts, escaping special characters, creating directories and copy files for the host, installing packages, and even running raw shell commands on the Windows host with...

Questions

1. Ansible can communicate with Windows hosts using:

   a) SSH

   b) WinRM

   c) Both of the above

2. Ansible can reliably be run from Windows:

   a) Natively

   b) Using Python for Windows

   c) Through Cygwin

   d) Through WSL or WSL2

3. The ansible.builtin.file module can be used to manipulate files on both Linux and Windows hosts:

   a) True

   b) False

4. Windows machines can have Ansible automation run on them with no initial setup:

   a) True

   b) False

5. The package manager for Windows is called:

   a) Bournville

   b) Cadbury

   c) Chocolatey

   d) RPM

6. Ansible modules for Windows run their commands by default using:

   a) PowerShell

   b) cmd.exe

   c) Bash for Windows

   d) WSL

   e) Cygwin

7. You can run Windows commands directly even if a module with the functionality you need does not exist:

   a) True

   b) False

8. When manipulating files and directories on Windows with Ansible, you should:

   a) Use \ for Windows path references, and / for files on the Linux host

   b) Use / for all paths

9. Special characters in Windows filenames should...