Intro Today, we have released a new version of PowervRA, 4.0.0 with support for vRA Cloud and vRA on-premises version 8.0. The observant among you will notice that we’ve incremented the PowervRA version from 3.7.0 to 4.0.0. We’ve done this since there is a significant breaking change. The API for vRA Cloud / 8.0 is completely different to that which exists for vRA 7.x and earlier. If you’ve been with the product for a while you’ll be aware of the pain challenge it has been to work with since inception due to the split brain nature of the product, more info here and here.

Recently I was invited to contribute to a week of blogging to coincide with the release of PowerShell 7 to help showcase some of the new features available. To follow up on that content, Jeff Hicks has put in some fantastic effort, collated all of the content and wrapped it up all into one place in an Ebook available from Leanpub. Technically it’s possible to get hold of a copy from there for free.

In a previous post I have written about Running PowerShell Core Commands Directly on Ansible Localhost using the version of PowerShell Core available at that time 6.2.3. With the recent release of PowerShell 7 I will demonstrate how to achieve the same outcome with this newer version and also an example taking advantage of one of the new features. My awx_task container is based on Centos 8 and installation for PowerShell 7 is the same process as for 6.

Prior to PowerShell version 7 there were a number of different methods for running PowerShell tasks in parallel, for example creating your own runspaces manually or using a third-party module such as Invoke-Parallel or PoshRSJob to make that a little more straightforward. Not to be confused of course with the foreach -parallel language construct, which exists, but is only available via a Windows PowerShell workflow. For an excellent summary of the different options prior to v7, I would highly recommend checking out Richard Siddaway’s talk from PSDayUK 2019 which provides some great insight.

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.

A colleague requested some assistance as to whether it was possible to configure the vSphere Cluster Setting ‘VM dependency restart condition’ via PowerCLI. If you’re not familiar with this setting, it can be found in the vSphere Client web interface by editing the vSphere Availability cluster settings: Digging around in the ExtensionData of a Cluster object in PowerCLI got us close, but it would appear that this value is not currently visible.

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.