Manage Windows machines with Ansible (winrm)

Ansible is a very powerful automation tool that is developed from RedHat. Many large organizations rely on Ansible to automate tasks and procedures. In this article I will explain how one can use ansible to manage windows clients and servers.

In order to manage windows hosts ansible winrm plugin should be used to communicate with the client/server machine.

The first step is to verify that ansible is installed.

Alongside with ansible, on the control node the pywinrm module should be also installed. By default this one is not installed and one should do it manually.

The managed Windows client/server machines should be configured to allow remote connections. A very useful power shell script is already developed from other users and it needs only to be executed on the managed host.

If your execution policy is prohibiting this script to be executed, you should set-execution policy to RemoteSigned as shown below and then execute the powershell.

Control node should have network connectivity with the managed hosts.

Some environmental variables should be used, so that ansible knows how the connection will be performed (winrm). I included those variables in my inventory file as I created this lab just for demonstration. My inventory file looks like below:

Lastly make sure that the user that is used for the connection has administrative rights on the managed windows hosts. Otherwise some error codes will be returned.

Lastly confirm ansible on managed host is working by using win_ping module.

Documentation:

https://www.ansible.com/blog/connecting-to-a-windows-host

Deploy Always Available Infrastructure on Azure

Availability is a critical matter when it refers to systems. The ideal scenario for an administrator would be 100% availability for a virtual server/appliance.

However this is not achievable when we deal with infrastructure as we need to close the systems on purpose (patching, maintenance tasks, etc) but also disasters or other nonphysical causes create a downtime.

When we deal with Azure cloud we have the following options that we can use:

  • Availability sets
  • Availability zone

An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there’s a minimum of three separate zones in all enabled regions

Availability sets are another datacenter configuration to provide VM redundancy and availability. This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA. For more information, see the SLA for Virtual Machines.

When you create a new VM resource on Azure, you should choose between availability sets or availability zone (depending on the region on which you deployed your server)

However as stated in the first article from Microsoft:

To achieve comprehensive business continuity on Azure, build your application architecture using the combination of Availability Zones with Azure region pairs. You can synchronously replicate your applications and data using Availability Zones within an Azure region for high-availability and asynchronously replicate across Azure regions for disaster recovery protection.

So the final image is the below. Based on your needs you could choose whichever option is more appropriate for you. However as recommended from Microsoft, you should use availability zones (newer feature than availability sets)

Below are some very good resources that Microsoft provides:

https://docs.microsoft.com/en-us/azure/availability-zones/az-overview

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/manage-availability

https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions