In my previous post, I mentioned changing some PowerShell cmdlets.  Here’s the definition for the cmdlet used to create a new item:

It’s simple enough:  You specify the required mode and display name, and one of several switches.  If specified, the setting is enabled; if left out, the setting is disabled.  Fairly standard stuff.

But then you need an equivalent cmdlet for making changes to an existing item.  So I set up one that looks pretty much the same, where the ID (a GUID assigned when the item was originally created) is used to identify which item to change.

That’s pretty much a mirror of the “new” cmdlet.  And both of those were based on the original posted by Damien Van Robaeys, which I talked about earlier.  But notice how I made some “improvements” to his original setup:  Instead of having boolean parameters that specify $true and $false to turn things on and off, I switched to using switch parameters, where “present” means on and “absent” means off.  A great simplification, right?  I was happy, at least until I started testing the two cmdlets.  The “new” one did exactly what I wanted, but the “Set” one to update an existing item had a flaw:  There was no way to use it to turn off a switch that was already on.  (Absence of a parameter means “don’t change it,” not “set it back to off.”)

So rather than backtrack and use boolean parameters again (leading to things like “-OOBE_HideEULA $true” and “-OOBE_HideEULA $false”), I cheated.  I added two more parameters:

If you specify “-AllEnabled” it flips all the switches on; if you specify “-AllDisabled” it flips all the switches off.  So, you can work around the problem I created with two sequential commands, one to turn everything off and a second one to turn back on just the items that you want.  It’s a little hack-ish, but it was easy and I wanted to go to sleep.

The joys of PowerShell