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
If you’ve been following my blog for a while, you know that I LOVE making PowerShell cmdlets, especially ones that consume an API or scrape a web site.
However when it comes to tools that peruse the web, this can get a bit tricky, especially if a site doesn’t publish an API because then you’re stuck parsing HTML or loading and manipulating an invisible Internet Explorer -COMObject barfs in Japanese. And even this terrible approach is closed to us if the site uses AJAX or dynamically loads content.
In that case, you’re restricted to making changes on a site while watching Fiddler 4 and trying to find interesting looking method calls (this is how I wrote my PowerShell module for Zenoss, by the way. Guess and checking my way through with their ancient and outdated Python API docs my sole and dubious reference material, and with a Fiddler window MITM-ing my own requests in the search to figure out how things actually worked. It…uh…took a bit longer than I expected…)
This doesn’t have to be the case anymore! With the new release of Chrome 65 comes a PowerShell power tool so powerful that it’s like moving from a regular apple peeler to this badboy.
What’s this new hotness?
For a long time now if you load the Chrome Developer Tools by hitting
F12, you’ve been able to go to the Network tab and copy a HTTP request as a
curl statement. Continue reading