This is a guide for anyone new to the Pester testing framework module for Powershell who would like to learn how Pester works in order to maintain or create Pester test scripts that are used for operational testing.
This post is a list of resources and tips to help anyone new to Windows Powershell in getting started with the language. If Powershell is completely new to you, I recommend you review all of the listed resources. If you find other great resources along the way, please feel free to comment below and i’ll contribute them to this list.
One of our AWS based products uses auto-scaling and when new instances are deployed a script automatically creates sensors for them in PRTG (our monitoring tool). When the instances are scaled down/terminated there is not a script that automatically removes them from PRTG (in part so that we can temporarily retain the monitoring history). As a result, our monitoring over time can become cluttered with redundant paused devices, so a script was needed to automate the process of clearing those down.
Powershell version 4 and Windows 8.1 / 2012 R2 introduced the Test-NetConnection command as a tool for performing network connectivity tests with Powershell. Test-NetConnection allows you to perform ping, traceroute and TCP port tests and from Windows 10 and Server 2016 onward introduces the ability to do “Diagnose Routing” tests with the same cmdlet.
I like my scripts to give feedback to the console to demonstrate progress where possible and Powershell provides a number of cmdlets to do this, one of which is Write-Progress.
If you’re looking for a way to interrogate multiple HTTP Transaction Sensors in your PRTG monitoring installation using a script then this blog post is for you.
The following script can be used to get the current uptime from a collection of servers in Active Directory using WMI. I used it as a way to audit our estate, keen to understand how long servers have been operational for, in part to identify those which were potentially not routinely receiving Windows Updates.
My team has an ever-growing collection of administration scripts and tools which are organised and maintained within a number of Git repositories. In order to ensure that the copies of these scripts in production always reflect the Master branch in Source Control we set up a Chef cookbook to synchronise the repositories to a network share in the environment. This post details how this functionality was developed and deployed.
