In Part 15 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to install software packages via Chocolatey.
In this example we’ll demonstrate how to install Visual Studio Code and PowerShell 7.0 Preview using the win_chocolatey Ansible module.
This module will first of all install chocolatey if it is not present on the system. You’ll receive a warning during playbook execution if Chocolatey was installed.
In Part 14 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to handle registry entries in Windows.
In this example we’ll look at how to both create a new registry entry and update an existing registry entry using the win_regedit Ansible module.
Our current view of registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters is as follows:
Our job template in AWX is _13_registry_entries:
The contents of _13_registry_entries.
In Part 13 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to handle environment variables in Windows.
In this example we’ll look at a common scenario where you need to manually create the JAVA_HOME environment variable and add it to the existing PATH environment variable because the application install does not complete that for you. We will use a combination of the win_environment and win_path Ansible modules.
In Part 12 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to handle TimeZones in Windows.
In this example we will look at how to set the TimeZone using the Ansible win_timezone module to an alternative TimeZone to that which has already been configured.
Our current TimeZone is set to the default UTC:
Our job template in AWX is _11_timezone .
The contents of _11_timezone.
Previously I’ve written about Running PowerShell Core Commands in a Linux Target from Ansible . In this article, we’ll look at a similar topic, but instead the PowerShell commands will be executed directly on the local Ansible host, not on a Linux based remote target.
In my lab I’m running AWX in containers.
The cross-platform version of PowerShell is not installed by default in this deployment method of AWX, so we need to get it installed there first.
In Part 11 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to handle local Windows groups. This can prove to be a useful method to configure local group membership with both local and domain user accounts if perhaps you don’t want to or are not able to use Group Policy.
In this example we will look at how to create a new local group, add both a local user and a domain group to the new local group and also ensure only the domain printer_admins group exists in the local Print Operators group.
In Part 10 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to handle local Windows user accounts. Hopefully, most of the time you are able to use AD based accounts and Group Policy to configure local access. However, sometimes there can be a need to manage and maintain local credentials.
In this example we will look at how to create a local user account and (sometimes more importantly) how to ensure a local account does not exist.
I’ve posted previously regarding returning output from PowerShell scripts that have been invoked by Ansible playbooks:
https://www.jonathanmedd.net/2019/10/ansible-windows-and-powershell-the-basics-part-6-displaying-output-from-powershell-code.html
https://www.jonathanmedd.net/2019/07/returning-data-from-powershell-scripts-to-be-consumed-by-ansible-playbooks.html
I encountered an issue recently where noise from a particular PowerCLI cmdlet, Invoke-VMScript, was polluting the output returned from the PowerShell script to Ansible. Specifically it looked like the below, a mess of Invoke-VMScript across the screen:
This is because Invoke-VMScript is one of those cmdlets which displays progress to the console while it is executing:
In Part 9 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to handle disk creation. After ‘physically’ adding the new disk, either in a physical server or private / public cloud VM, typically you will need to initialize, partition and format it ready for use.
In Windows Disk Management a newly added disk will look like Disk 2 below:
The following example will demonstrate how to use a combination of a PowerShell command and the win_disk_facts, win_partition and win_format modules to initialize, partition and format the above newly added Disk 2.
In Part 8 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how to handle reboots. Despite improvements in Windows over the years, it’s still pretty common as part of VM or application deployment to need to restart the VM and wait for it to be available before carrying on with some further steps.
The following example will demonstrate how to use the win_reboot and win_wait_for modules to reboot a VM and wait for the RDP port 3389 to be available before carrying on.