I was recently tasked with investigating how we could store the configuration of our SQL Server Reporting Services report subscriptions in a source control and then automate the process of (later) configuring them in one or more new SSRS servers.
This is the fourth and final part of a short series of posts about things I discovered by reading the excellent Learn PowerShell in a Month of Lunches book (recently released in 3rd edition) as a not quite beginner.
This is part three of a short series of posts about things I discovered from reading Learn PowerShell in a Month of Lunches (recently released in 3rd edition).
This is part two of a short series of posts about things I discovered or had clarified by reading the excellent Learn PowerShell in a Month of Lunches book (recently released in 3rd edition).
As introduced in my previous post, this is part one of a four part series that documents some things I discovered or had clarified by reading the excellent Learn PowerShell in a Month of Lunches book (recently released in 3rd edition).
I got started with PowerShell thanks to the encouragement and enthusiasm of a friend and former colleague. Following that, I’ve largely developed my knowledge through the standard combinations of trial + error + googling and more recently (as is evident) by doing my best to engage with and give back to the community.
While experimenting with AppVeyor to add Continuous Integration to my PowerShell projects (more detailed blog post to follow) I encountered a bug that meant that the Pester test results (uploaded via the NUnit formatted results file) were not appearing in the “Tests” tab of my AppVeyor project.
While developing a PowerShell function to query the API of the webcomic XKCD I decided to explore and implement Parameter Sets. These allow you to provide your users with different sets of parameters based on different use cases (assuming you have multiple use cases), which as a result provides a more dynamic set of functionality from a single cmdlet.
