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.

When Craig and I first created PowervRA and PowervRO in 2016 we only initially thought about using them for our own purposes, since we were on a project at the time which required heavy use of automation around vRA and vRO. When we decided to put them out into the community we never expected them to become as popular as they have done. It was a fun experience for us, both in learning about collaborating, developing and releasing a PowerShell module, and the benefits it was bringing to our own jobs.

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.

In Part 7 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how utilise PowerShell DSC. If you or your team already own some automation created using PowerShell DSC then it is possible to re-use that via an Ansible Playbook. Or maybe you think that you or they would prefer to create configuration automation going forward using a perhaps more familiar PowerShell DSC, then this could be a solution for you.

In Part 6 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how we can display output from code in PowerShell scripts back in Ansible to help track the progress of a task. The following example will demonstrate how to send log info from a PowerShell script back to Ansible. Our job template in AWX is _5_log-output The contents of _5_log-output.yml are are follows:

While carrying out some investigation around using the VMware Cloud Assembly API to work with Onboarding Plans we stumbled across a puzzling scenario. The documentation for creating an Onboarding Resource that is part of an Onboarding Plan shows the following content needs to be sent as part of the POST API request for the creation: While figuring out what needed to be populated in each property I retrieved via the API the contents of existing Onboarding Resources:

In Part 5 of this series we’ll continue our journey with Ansible, Windows and PowerShell and look at how we can lay out code in PowerShell scripts in order to return error codes to Ansible to determine the success or failure of a task. In my experience different automation and orchestration toolsets can require you to return errors from PowerShell scripts in different ways. So far with Ansible I have found that returning an exit code of 0 (success) or 1 (failure) from the PowerShell script to Ansible will result in the success or failure of that task in the Playbook.