Why? Because until recently, I was notorious for leaving Write-Debug statements everywhere. I mean, just take a look at my local git folder.
My code was just littered with these after practically every logical operation…just in case I needed to pause my code here at some point in the future. Actually, someone could look at my code in the past and every Verbose or Debug cmd was basically a place that I got stuck while writing that cmdlet or script. I mean, using the tools is not wrong, but it always felt like there should be better ways to do it.
Recently, I have learned of a much better way and I want to share it with everybody.
Why not use Write-Debug?
Write-Debug is wrong and if you use it you should feel bad
I’m just kidding! You know, to be honest, something really gets under my skin about those super preachy posts like you always find on medium that say things like ‘You’re using strings wrong’, or “You’re all morons for not using WINS” or something snarky like that.
It’s like, I might have agreed with them or found the info useful, but the delivery is so irksome that I am forced to wage war against them by means of a passive aggressive campaign of refusing to like their Tweets any more as my retribution.
That being said, here’s why I think we should avoid Write-Debug. It ain’t wrong, but you might like the alternative better.
While I’m working on some longer posts, I thought I’d share a quick snippet I came up with this weekend as I was backing up a number of old DVDs of family movies.
FFMPeg has the awesome ability to join a number of video files together for you, but the syntax can be kind of strange. Once I learned the syntax, I sought to make sure I never had to do it again, and created this cmdlet.
In this basic version, it will join every file in a directory, giving you Output.mkv. Be sure your files in the directory are sequentially ordered as well, to control their position.
Ensure that FFMpeg’s binaries are available in your Path variable as well.
Later on, I may add the ability to provide which specific files you want to join, if desired 🙂
Recently at work, we had a task come up which saw us needing to move tens of thousands of devices between collections in CM. We decided to run some tests to find the fastest way! We compared:
The SCCM 1511 Era Collection Cmdlets
The newly released speedier Collection Cmdlets which shipped with Tech Preview 1803
Using Keith Garner’s super powerful CMPSLib Module
Query Based Membership
AD Group Query Membership
Direct SQL Membership Tampering ☠
I’d always kind of wondered myself, so it was a fun challenge to come up with some hard numbers. And for the last item in the list…this is just for fun, I do not recommend using this in your production…or your testlab. Or anywhere.
The test lab
All testing occurred in my VM Testlab, a Ryzen 7 1700 with 64 GB of RAM, with storage served on NVMe m.2 SSD drives. A beastly machine (also hello to viewers from the year 2025 where we have 6TBs of storage on our phones and this is laughably quaint. Here in 2018, we believed more RBG = more better, and we were happy, damn it!) Continue reading →
Recently at work, we were debating the best way to handle mass collection moves in ConfigMgr. We’re talking moving 10,000 or more SCCM devices a day into Configuration Manager collections.
To find out, I installed CM in my beastly Altaro VM Testlab (the build of which we covered here), and then wondered…
how the heck will I get enough clients in CM to test in the first place?
Methods we could use to populate CM with Clients
At first I thought of using SCCM PXE OSD Task Sequences to build dozens of VMs, which my lab could definitely handle. But a PXE Image was taking ~24 minutes to complete, which ruled that out. Time to thousand clients even running four images at a time would be over one hundred hours, no go.
Then I thought about using differencing disks coupled with AutoUnattend images created using WICD, like we covered here on (Hands-off deployments), but that still takes ~9 minutes per device, which is a lot of time and will use up my VM resources. Time to thousand clients, assuming four at a time? 36 hours.
I thought I remembered seeing someone come up with a tool to create fake ConfigMgr clients, so I started searching…and it turns out that other than some C# code samples, I had a fever dream basically, it didn’t exist.
So I decided to make it, because after all, which is more fun to see when you open the console in your testlab, this?
And it only took me ~40 hours of dev time and troubleshooting. But my time per client? Roughly eight seconds! That means 450 clients PER hour, or a time to thousand clients of only two hours! Now we’re cooking…
Recently at work I have finally seen the light and begun adding Pester tests to my modules. Why is this a recent thing, you may ask? After all, I was at PowerShell Summit and heard the good word about it from Dave Wyatt himself way back in 2015, I’ve had years to start doing this.
Honestly, I didn’t get it…
To tell the truth, I didn’t understand the purpose of Pester. I always thought ‘Why do I need to test my code? I know it works if it accomplishes the job it’s supposed to do’.
For instance, I understood that Pester was a part of test-driven development, a paradigm in which you start by writing tests before you write any code. You’d write a ‘It should make a box’ test and wire it up before you actually wrote the New-Box function. But I was only looking at the outside of my code, or where it integrates into the environment. In truth, all of the tests I wrote earlier on were actually integration tests.
See, Pester is a Unit Driven Test Framework. It’s meant to test the internal logic of your code, so that you can develop with certainty that new features to your function don’t break your cmdlet.
CodeCoverage made Pester finally click
It wasn’t until I learned about the powerful -CodeCoverage parameter of Pester that it actually clipped. For instance, here’s a small piece of pseudo code, which would more or less add a user to a group in AD. Continue reading →