Over the years I’ve used a few different methods to combine two JSON files using PowerShell, but today I found a neat way to do it, so thought I would document it here for easy recall next time I need to do it.
Consider two basic JSON files to use for an example:
It’s easy to start working with them as objects in PowerShell, but I always forget that you can’t then just concatenate them together since they are PSCustomObjects:
The solution is to use an array instead. Today I found a neat solution in this StackOverflow post which uses the Array subexpression operator, rather than more long winded efforts I’ve used before:
I passed the AZ-400 Azure DevOps exam last week, so thought I would share a few thoughts for anyone else considering it.
I mostly used the AZ-400 course on Linux Academy by Tim Lawless to study for it and found it an excellent resource. I thought Tim did a great job of not just covering the topics as per the published curriculum, but also went further into illustrating many of the third-party integrations with Azure DevOps. To be fair it made a lot of sense to do this, since at a minimum at least an awareness of these integrations for common software build and deploy tools such as Jenkins, SonarQube, WhiteSource, Maven, Gradle etc is covered in many places in the exam.
In addition around 30 – 40% of the exam is based on Agile / DevOps theory, practice and general experience with building software in different programming languages, i.e. not technical questions around products available within the Azure DevOps suite. If that is not part of your day job or something you are unfamiliar with, then I would suggest the following books, for the Agile / DevOps part anyway:
Since all Pearson VUE test centres are currently closed and my original on-site exam booking for April was cancelled, I switched over and took it via the online exam format. I was pleasantly surprised by the experience and would definitely consider it again over a test centre. After going through some initial security checks, ID and pictures of room you are taking the test in, it was nice to not be in a room with others testing at the same time and the inevitable distractions of noise and movement. I was then monitored by a proctor via my laptop’s webcam. My online real concerns were preventing one of my currently at home family members walking into the room and invalidating the exam or perhaps troubles with home broadband. Thankfully with some preparation and good fortune I experienced no issues. Full details about taking Microsoft exams online can be found here.
The predicted lab portion for this exam was not present, so only case studies and standard multiple choice questions. I haven’t seen anything official, but a few comments on blogs suggest this has been removed temporarily from all MS exams for performance reasons due to the greater demand for online rather than on-site exams at the moment.
I hope this helps you if you are headed down this certification path.
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. Thankfully that has gone away with the latest release, however it left us as maintainers of PowervRA to decide whether to maintain support for both sets of APIs in the same PowervRA version.
Breaking Change
Ultimately, we took the decision to only support the API in vRA Cloud and 8.x going forward, consequently PowervRA 4.0.0 does not support vRA 7.x and earlier.
If you wish to continue to use PowervRA with vRA 7.x and earlier it is possible by using PowervRA 3.x, currently 3.7.0. You are able to install specific versions of PowerShell modules from the PowerShell Gallery by using the RequiredVersion parameter. So for example to install PowervRA 3.7.0:
We will continue to maintain a version of PowervRA that supports vRA 7.x, however to set a fair level of expectation please remember that this is a community based project with limited resources, both in terms of developers and lab environments and our focus going forward will be on PowervRA version 4.x and later.
We’ve done our best to communicate this in advance of release via Twitter and also the VMware Code Slack channel.
Advanced warning: we will soon be releasing PowervRA 4.0.0 which contains a significant breaking change, the new version will only be compatible with vRA 8.x and vRA Cloud. #vexpert#PowerShell
If you are aware of anyone likely to be impacted by this change, then we would be very appreciative if you would communicate it to them.
Context
Back when Craig and I first developed PowervRA for release in March 2016, it was primarily formed from our own needs since we were working on vRA projects where a lot of automation was required. Since that time, and particularly in the last couple of years, the career focus for both of us has moved away from vRA and our ability to significantly develop PowervRA and deal with logged issues has diminished somewhat. At the same time interest in PowervRA has increased, over 26k downloads currently on the PowerShell Gallery!
Acknowledging that, we recently sought out some extra assistance and that has been successful in helping us get this new version out and potentially can help support the previous version in the future. Also, by chance I happened to spend some time on a work project recently based around vRA Cloud which has meant I’ve had some hands on experience and been able to make some contributions.
TBH I think there is enough work for an individual to keep that person occupied full time on this project, for both PowervRA versions, for at least a number of months, but realistically that is not going to happen. We do of course welcome Pull Requests for either version and now have more resource on-board to have a better chance to turn them round into new releases.
With that said, here’s a few tips on getting started with the new version! Note these are all around vRA Cloud since that is what I’ve had access to. I don’t believe there should be that much difference to the on-premises version, other than around how to make the initial connection.
Getting Started
Install the latest version of PowervRA:
Observe the available functions, currently 36:
Getting Connected
In order to authenticate with vRA Cloud an API token is required (for vRA on-premises it is different, check the help for Connect-vRAServer for details). To generate one, navigate into the management portal and your account profile. On the API token page, generate a new token with the appropriate access requirements:
Save the token somewhere safe so that is is available for use with PowervRA.
Using the API token, make a connection to vRA Cloud:
Function Testing
The Get-* functions are typically a good way to get a feel for what is available. For example to get a list of all projects in vRA Cloud:
API Coverage
You’ll notice above that in the initial 4.0.0 release there are 36 functions, so there is obviously a lot of the API not currently covered, particularly in comparison to the previous release which has over 100 functions for vRA 7.x. We hope to build up this coverage over time, in the meantime remeber that Invoke-vRARestMethod is your friend.
We build all of the PowervRA functions around this helper function, so if there is a part of the API that is not covered by an existing function, you can use Invoke-vRARestMethod to fill in the gaps in the meantime.
For example we currently have no function coverage around Blueprints. However, by looking at the vRA API documentation there are examples for working with Blueprints. So the following code using Invoke-vRARestMethod would get you details about Blueprints:
Finally
Thanks for your interest in PowervRA. We hope you find the new version useful and we look forward to taking it further. Providing feedback via issues and code contributions via pull requests would be a great way to help us do that.
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. However, consider making a donation when doing so, with a $4.99 minimum. All proceeds go to the OnRamp Scholarship fund which helps diverse groups traditionally underrepresented in IT get a kick-start to their career.
Everyone who contributed to the book regularly publishes highly useful content on their own blog. I recommend you check them out below:
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.2.3. I already had the Microsoft RedHat repository registered from installing 6.2.3, so it was simply:
sudo yum install -y powershell
We can see that PowerShell 7 has been installed:
To illustrate functionality we’ll use the following Ansible playbook:
In the first half of the playbook we’ll execute the below PowerShell script stored locally on the Ansible host.
On line 1 we purposefully run a command that will generate an error. We then use a new cmdlet in PowerShell 7, Get-Error, to return some specific error details.
When this section of the playbook is executed in AWX we observe the selected info returned from Get-Error that we wish to debug via Ansible.
In the second half of the playbook we use Invoke-RestMethod to make an API call against a test URL.
Observe the debug log from the Invoke-RestMethod call confirms that we are using PowerShell 7:
This post is part of the #PS7Now series of blog posts to accompany the release of PowerShell 7. You can find posts from other contributors at the following sites:
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 this article we’ll look at how things were prior to this new feature in PowerShell 7 and why you might want to consider using the new Parallel feature to make things simpler.
First of all, the following example demonstrates how to use PowerShell runspaces to process some data in parallel – this is an approach we could have taken prior to PowerShell 7:
You’ll observe that quite a lot of code was required to instantiate using the runspaces!
In PowerShell 7 we can reduce the above example to the following:
Of course bear in mind the above are contrived examples and using the new -Parallel functionality in v7 (or runspaces in earlier versions) may not always be the most effective approach. Typically running in parallel is geared towards code which requires intensive processing over a significant time period or contains elements of waiting which might cause bottlenecks if running in serial fashion. If this is not the case, then it may prove counter intuitive to make use of parallel functionality since there is an overhead every time a runspace is created.
This post is part of the #PS7Now series of blog posts to accompany the release of PowerShell 7. You can find posts from other contributors at the following sites:
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. Of course you could instead include Chocolatey as part of your Windows base image.
Our server currently has no applications installed:
Our job template in AWX is _14_install_chocolatey_packages:
The contents of _14_install_chocolatey_packages.yml are as follows:
Note that the first step involves installing some supporting Chocolatey extensions, chocolatey-core.extension and chocolatey-windowsupdate.extension . How did I know these were required to install first? Well, mostly because neither VS Code nor PowerShell Preview installed at first.
A combination of looking through the logs of the playbook which complained about various things missing……
….plus on the Chocolatey site dependencies are listed for each application:
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:
The available options for this setting are as below for vSphere 6.7.0.
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. (If you know where to find it, please let me know in the comments)
However, looking through some of the API documentation gave us some info on how to change the value that is set. The below document lists possible values for a ClusterVmReadinessReadyCondition:
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.
Our current environment variables are as below with no entries for JAVA_HOME:
Our job template in AWX is _12_environment_variables:
The contents of _12_environment_variables.yml are as follows:
Running a job from the _12_environment_variables job template produces the following result:
Our server now has both the JAVA_HOME environment variable and it has been added to PATH:
