Where the Idea Came From
SAToolkit began its life a number of weeks ago when I found a bug in my function Set-Regkey. I'd written that function with the intention of better standardizing how I was adjusting registry entries in my scripts and had deployed it in numerous places at work. The bug I found was a nasty one in that it was silent and seemed completely inconsequential, but it proved to be quite a pain in the neck. When writing strings to registry values, they were always being passed with the method .ToLower(). I'd done this so the function could check if the input value for the function was already present in the target registry key and not overwrite the value if it already existed. This wouldn't have been a problem if our RMM wasn't case sensitive, but alas, an important policy had been silently failing due to the registry value not matching the expected case.
Once I'd found and identified this bug, I fixed it by moving the initial value check to a separate variable and instead using the function input directly as the new value when writing to the key. Nothing overly complex about the fix, but the problem came about when I had to update about 10 unique scripts and RMM policies because I'd manually defined (already slightly different) versions of Set-Regkey in each of them. The function itself was stored in GitHub and properly source controlled, but since it was manually being copied and pasted into each script, there wasn't any centralized control if a change needed to be made. This got me thinking about how I could centrally manage each of my common functions and not have to manually update a bunch of scripts each time a change was made.
Starting the Process
I suspected a source-controlled PowerShell module would be my best option, but I did some research to ensure I was going with the best option. I confirmed that a PowerShell module would fit my needs and got to work teaching myself how to create one since this was my first. I made it about ten minutes into a YouTube video before deciding that watching someone else do it was boring, and I'd rather figure it out myself through trial and error. (Side note: A post about my learning process and how I try to work with it and not against it is in my blog post ideas list). I started toying around with some code and looked up some written tutorials when I needed to be pointed in the right direction regarding syntax and common conventions.
SAToolkit is actually one of two versions of the module, the other version is one I wrote specifically for use at work. They're nearly identical except for some work-environment specific additions such as using an RMM folder as the default data storage location instead of $env:temp. I wrote the work version first (on my own personal time) and included all the commonly used functions I'd already written. I even took some code myself and a colleague had written in the form of specific-use scripts and adapted them into generic functions. Once the work version was in a state where it was ready to be published, I began work on the public version, SAToolkit. I wanted to write the work version first and remove the environment specific additions SAToolkit instead of the other way around.
Deploying the Work Version to a Few Hundred Devices:
While I won't go into too much detail about the entire process of how a colleague and I choose to deploy the work version to our environment, I will speak generally about the ideas and thought processes. Firstly, this module was going to be deployed to a few hundred endpoints at a minimum, and possibly up to a few thousand so we needed something scalable. The functions in the module were already in use in tens of different RMM policies that run on hundreds of endpoints, so retrieving the module from source each time simply didn't make sense. Instead, we felt it would be best to store the latest version of the module locally on each endpoint to not hammer GitHub with thousands of requests daily.
The question of how to deploy the module to said endpoints, and possibly even more importantly, how to keep it up to date with the source still remained. We decided that releases on GitHub would serve as the versions of the module that would be deployed to production. That way we could make commits to the repository as needed, but endpoints would only be updated once we were ready to release a new version. We already use a certain sweet-toothed package manager for Windows along with a custom repository that handles software installs, updates, and versioning. Thus, it made perfect sense to leverage that existing tool to push out the module to endpoints and ensure they were kept up to date. Unfortunately, getting the code out of GitHub and into our software repository is the part I can't really get into detail on. The short version is that when a new release is published on GitHub, an automation process starts up by packaging the module into .nupkg format for distribution via our package manager, and each endpoint pulls down the latest release.
Current State of SAToolkit
At the time of writing this post, version 1.0.0 of SAToolkit has already been publicly released on my GitHub. If you're at all interested, I would hugely appreciate you checking it out. Please feel free to contribute to it if you'd like, I'd be thrilled if members of the community contributed their unique expertise to this project. While we needed to keep the work specific version of the module private, I believe that Free and Open-Source Software (FOSS) practices create better tools that many people can benefit from and contribute to. I had the public, FOSS version of SAToolkit in mind from the moment I first decided I was going to create a custom PS module containing common System Administration tools.
I'm quite proud of what I've created with SAToolkit. I was quite excited when the first private version pushed out to my endpoints at work, and I'm equally excited at the prospect of the community using, benefiting, and contributing to these tools. These tools are all things that I've created to make my own life easier as a System Administrator, and I hope that others can benefit from them too. If you're interested, my GitHub page is linked in the top menu bar of this site, and I'll include some direct links below to the module. I hope you give it a look, and I truly hope you're able to find it useful!
Jay-Andrade
Member discussion: