It’s Day 7 and it’s the last Task Sequence Tip of the mini-series. As much as the ConfigMgr team has built into the product, they can’t do it all. We can write a million uservoice requests, but at the end of the day, a good ConfigMgr admin needs PowerShell to go beyond the basics and really be creative. The ConfigMgr team knows this, and they’ve empowered us to make the most out of powershell with the Run PowerShell Step.
We used to have to use the Run Command Line Step, call the powershell.exe and either get creative with a PowerShell command or call a script in a package. Then they gave us the Run PowerShell Script Step, which made it easier. We could put in a script name, associate a package, and it would just run. Then in 1902, they gave us the magic sauce that made the step super special. We can now embed a full PowerShell script right into the step or easily create a TS Variable by piping the output of the script into a variable.
Tip 7: Run PowerShell Step
This step is great! It is so flexible and allows you to do anything in a Task Sequence that you can imagine. Somethings I’ve done with PowerShell in that Task Sequence include:
- Create Variables
- Read & Trigger a Baseline
- Setting Registry Keys
- Trigger Client Actions (HWInv)
- Launch XAML Forms or PowerShell driven Frontends
- PreFlight Checks
- Splash Screen
So until all of those things are native CM Task Sequence Steps, we have PowerShell, and with the updated PoweShell Step it makes things SO MUCH Easier.
The best part of the updated step is embedding scripts, removing the requirement for a reference package. This ability has allowed me to be much more agile in fixing bugs in scripts than it would have been in a package. Changing a package in Production.. HUGE DEAL… making a minor step change in the TS… NO DEAL.
So my tip?
Start converting batch files, PowerShell scripts into embedded PowerShell scripts with no required content.
Thanks for tuning in!