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.

I hope you enjoyed the seven days of Task Sequence Tips. If you have any questions or comments on any of them, hit me up on twitter @RecastSoftware or learn more at Recast Software.

Thanks for tuning in!

A Week of Task Sequence Tips

• Day 1: Tag Version in Description
• Day 2: Task Sequence Pause
• Day 3: Variables Gather and Capture
• Day 4: SMSTS Log Stamping
• Day 5: Run Task Sequence Step
• Day 6: Static IP Addresses and OSD

The post A Week of Task Sequence Tips: Day 07 – Run PowerShell Step appeared first on Recast Software.

How? Once you place that information in WinPE, we grab all those settings and populate them into Task Sequence Variables. There is an overarching variable called OSDAdapter, which contains several sub variables.

• OSDAdapter0EnableDHCP
• OSDAdapter0IPAddressList
• OSDAdapter0SubnetMask
• OSDAdapter0Gateways
• OSDAdapter0DNSDomain
• OSDAdapter0DNSServerList
• OSDAdapterCount

Tip 6: Static IP Addresses and OSD

There are several more, but those are the ones you need to have set for the process to work. The process I’m using, after you input the IP Address into the WinPE IP settings, the Task Sequence grabs that information and sets all of the required variables needed for the Apply Network Step to use what you’re providing.

Alright, so depending on how many NICs, which one is active, and how much you want to automate, this can get a bit tricky, but this is a good start and hopefully helps you over a hump. If you want to continue this conversation, find me on Twitter @RecastSoftware or learn more at Recast Software.

A Week of Task Sequence Tips

• Day 1: Tag Version in Description
• Day 2: Task Sequence Pause
• Day 3: Variables Gather and Capture
• Day 4: SMSTS Log Stamping
• Day 5: Run Task Sequence Step
• Day 7: Run PowerShell Step

Right Click Tools Enterprise is loved and trusted by thousands.

96% of our customers keep coming back and renewing because Right Click Tools is essential to amplifying the power of ConfigMgr.

Get Custom Pricing

The post A Week of Task Sequence Tips: Day 06 – Static IP Addresses and OSD appeared first on Recast Software.

As of 1910, it’s a standard feature and enabled by default. Before this, you had to enable it in the feature area. If you never knew about it or enabled it before now, if you’re updating to 1910, then you’re all set. More info about the Run Task Sequence Step on the Docs Site. The Feature has been around since 1710, so we’ve had two years of this marvelous feature.

Why do I need this? What are some ways I can leverage this? Let’s explore.

• Reusable Groups (Modules)
• Segment Specific Tasks
• Testing Smaller Segments

Tip 5: Run Task Sequence Step

Real world examples: Debug Task Sequence. I’ve got a Small Task Sequence I use for Debugging, gathering variables, dumping variables, pausing the TS, grabbing logs. I can run it standalone or run it inside another Task Sequence.

How I leverage them, for 1709, 1809, 1909, I have an upgrade TS, now they all share about 90% of the same steps, so using child task sequences allows me to share that 90%, and if I need to make a fix, it fixes it on all three. I then create a unique sub task sequence for each build to do anything unique that needs to be done.

Basically at the end of the day, it comes down to what works for you. Do you have to use them? No. Can they be hugely helpful? Yes. Can it add extra complexity and confusion? Oh yeah!

So how does it work? Behind the scenes, ConfigMgr integrates the sub task sequences into the parent task sequence, and in policy looks like one giant task sequence. When you look through the SMSTS.log, each sub task sequence is represented as a group.

So today’s tip, Run Task Sequence Step, it’s one of my favorite features that has come about in the past couple years, opening up new ways to organize and think about how you build task sequences. To learn more about the available steps and what they do, check out the MS Docs. See you next time for another Task Sequence Tip.

A Week of Task Sequence Tips

• Day 1: Tag Version in Description
• Day 2: Task Sequence Pause
• Day 3: Variables Gather and Capture
• Day 4: SMSTS Log Stamping
• Day 6: Static IP Addresses and OSD
• Day 7: Run PowerShell Step

The post A Week of Task Sequence Tips: Day 05 – Run Task Sequence Step appeared first on Recast Software.

Here are a couple tips to help with this:

• Start a new SMSTS Log
• Stamp the SMSTS Log

Tip 4: SMSTS Log Stamping

When I trigger an upgrade, one of the first steps I do, is rename the current c:windowsccmlogssmsts.log file to smsts[TIMESTAMP].log

Now I know the smsts.log file will only be from the last upgrade (unless I’ve run additional deployments since), which is when this next tip comes in handy.

The next trick I use is to stamp the SMSTS Log… what does that mean?  Well, wouldn’t it be nice to easily find where you started your Task Sequence, and some generic info about the computer and which deployment was running? Yes, yes it would.

Output in the SMSTS.log looks like:

Isn’t that nifty? Info about the TS Name, and Deployment, along with basic computer info at the time you started the TS. Also, don’t you like the use of the word “Fail” to create a nice Red Border to make it easier to find?

Script: Hosted on GitHub

Let us know Questions or Comments! @RecastSoftware or learn more at Recast Software.

A Week of Task Sequence Tips

• Day 1: Tag Version in Description
• Day 2: Task Sequence Pause
• Day 3: Variables Gather and Capture
• Day 5: Run Task Sequence Step
• Day 6: Static IP Addresses and OSD
• Day 7: Run PowerShell Step

The post A Week of Task Sequence Tips: Day 04 – SMSTS Log Stamping appeared first on Recast Software.

Tip 3: Variables Gather and Capture

The Community has created a great script that auto generates a ton of useful variables, and I’ve implemented it in all of my task sequences. The script is also useful when you want to figure out how this information was gathered, as the creator of the script is a guru at PowerShell and you can learn a far amount from the script itself. Here are some of the additional variables created:

• Architecture
• AssetTag
• BIOSReleaseDate
• BIOSVersion
• DefaultGateway
• IPAddress
• IsDesktop
• IsLaptop
• IsOnBattery
• IsServer
• IsVM
• MacAddress
• Memory
• Model
• OSCurrentBuild
• OSCurrentVersion
• ProcessorSpeed
• Product
• SerialNumber
• UUID
• Vendor
• VMPlatform

So now you’ve got lots of variables, and you’re trying to set your own. You want to confirm that they are set, and that they are what you’re expecting. You can either than Pause the Task Sequence, (like we talked about in the last post) launch powershell and read the variables, or run a script that dumps all the variables to a log file. Nice thing is, this script skips sensitive variables that might include passwords and gives you the peace of mind that if someone opens the log, they won’t find any info that you’d consider risky.

So what does this look like in the Task Sequence?

And the Output?

The Script create a log file in the SMSTSLog folder, which gets commmited to the logs folder after the TS is completed.

Bonus.. registry keys..

Ever want to check a registry key value at a specific time… write the value to a task sequence variable! Then you can read that variable.

So that was a nifty tip. Creating variables, outputting variables to a log file, reading registry keys into variables—that’s handy stuff! Check out the other posts in the “A Week of Task Sequence Tips” series below, and remember to connect with me @RecastSoftware or learn more at Recast Software.

A Week of Task Sequence Tips

• Day 1: Tag Version in Description
• Day 2: Task Sequence Pause
• Day 4: SMSTS Log Stamping
• Day 5: Run Task Sequence Step
• Day 6: Static IP Addresses and OSD
• Day 7: Run PowerShell Step

The post A Week of Task Sequence Tips: Day 03 – Variables Gather and Capture appeared first on Recast Software.

Tip 2: Task Sequence Pause ++

Yes, I know, pausing a Task Sequence, it’s been done. I’m going to go a bit deeper and give you a few things you could do:

• Pause a TS running in WinPE
• Pause a TS running in Full Windows

Pause a TS Running in WinPE

This is your typical OSD scenario, you want to pause the TS to test some command lines, a PowerShell script, etc.

‍

That’s it, a simple command to launch the command prompt. Once there, you can type in powershell and have the world at your finger tips.

Once you close the command prompt window (type EXIT), it will close, and the Task Sequence will continue.

The Basic Idea is, You disable the Progress Bar, you launch a command prompt, you do your tests, you close the command prompt and you enable the progress bar again.

Pause a TS running in Full Windows

The process is a bit different here and the syntax a bit more complex.

Since you’re running in the full OS, you’ll need ServiceUI.exe, a tool that comes with Microsoft Deployment Toolkit (MDT). You’ll need to download and install it on a machine and grab the ServiceUI.exe from the installed folder: c:Program FilesMicrosoft Deployment ToolkitTemplateDistributionToolsx64

Command:

ServiceUI.exe -process:explorer.exe %SYSTEMROOT%System32WindowsPowershellv1.0powershell.exe -command (new-object -ComObject Microsoft.SMS.TsProgressUI).CloseProgressDialog() ; start-process -wait -filepath %SYSTEMROOT%system32cmd.exe

For more ideas of how to launch an application in WinPE, or display a popup message in WinPE, check out those posts. If you have any questions or comments, hit us up on Twitter @RecastSoftware or learn more on our website.

A Week of Task Sequence Tips

• Day 1: Tag Version in Description
• Day 3: Variables Gather and Capture
• Day 4: SMSTS Log Stamping
• Day 5: Run Task Sequence Step
• Day 6: Static IP Addresses and OSD
• Day 7: Run PowerShell Step

The post A Week of Task Sequence Tips: Day 02 – Task Sequence Pause appeared first on Recast Software.

Tip 1: Use the Description field as a way to version your Task Sequence

When testing a Task Sequence, I’ll often make several changes in a day. The worst thing is to make a change in the TS in the console, then run another test, just to find out you ran the test with the old policy and now you need to start over. To overcome this, I’ve started to time stamp my description, I use Month, Date, and Edit Number.  So in the image below, it’s Dec 5th, and it’s the 6th edit I’ve made today.

A Week of Task Sequence Tips

• Day 2: Task Sequence Pause
• Day 3: Variables Gather and Capture
• Day 4: SMSTS Log Stamping
• Day 5: Run Task Sequence Step
• Day 6: Static IP Addresses and OSD
• Day 7: Run PowerShell Step

The post A Week of Task Sequence Tips: Day 01 – Tag Version in Description appeared first on Recast Software.

Kiosk Manager by Recast is a fan favorite, used by many of our Enterprise customers to help control machines with a few clicks. Sometimes you want to deploy a computer and already have all of these settings applied. Using the process Kiosk Manager uses and stealing the end results, we can create a Task Sequence module to deploy Recast Kiosk settings during OSD.

The Kiosk Deployment via Task Sequence Process

• Create Clean Reference Machine
• Deploy Kiosk Template to Machine
• Verify Everything is to Your liking
• Gather the Recast Kiosk Setting Files
• Create a ConfigMgr Package with those Files
• Create a Task Sequence Module to Deploy
• Deploy a Machine with the Module and Watch…

‍Here’s a clean machine with no signs of Recast yet…

Now we apply the Kiosk Manager Profile.

You can actually see the folders being created while it’s applying, and then it automatically reboots when the apply is “Complete” in the dialog.

After the reboot, it automatically logged on and applied the settings we wanted.

I then connect to the UNC path of the machine and grab the files needed for my source package.

Create your Recast Kiosk source folder and create three subfolders ProgramData and Program files. Then copy the Recast Software folders from both locations on your reference machine into your source.

Then drill down to ProgramDataRecast Software and delete the Logs and Configurator folders. You don’t need that.

While you’re there, create the KioskProfile folder, for the one more thing you need, the Kiosk Profile XML file.

Now Export the Kiosk Profile to that folder.

Export the Kiosk Template XML file to the ProgramDataRecast SoftwareKioskProfile folder.

Once you have your source files, you can create a ConfigMgr package.

Now, we need to create the Task Sequence module by taking the following 5 steps:

• Copy ProgramDataRecast Software to Local Machine
• Copy Program FilesRecast Software to Local Machine
• Setup Registry Key: “Run Key”
• Setup Registry Key: “Configurator” (references Profile file)
• Enable Kiosk Mode (Trigger Right Click Action via Configurator)

Now you can add that “Module” Task Sequence as a sub task sequence and set the condition.

Now that the module is added to our primary OSD TS and we set the condition, we need to have a method of creating the condition (variable).

You can set the variable for the Task Sequence by using a Front End, or a Collection.

Now that we have everything set up, let’s run OSD!

For quicker testing, you can deploy just the module to a set of workstations and give it a quick run.

Now that we confirmed our module works and applies the Kiosk Mode, we can run the full OSD Task Sequence.

After it runs for a while, and when it’s done, you have a built Windows 10 machine all ready and all setup in Kiosk Mode.

In the Console, you can confirm that all is well in the Kiosk Manager.

Conclusion: Kiosk Deployment via Task Sequence

Now you have another way to deploy kiosks. You can use this to do it during OSD or use the Task Sequence module to deploy as well. Using the information in this post, it would be pretty easy to create a “portable” deployment using a PowerShell script with the source files on a flash drive to deploy on non-networked machines.

Other Kiosk Manager Posts:

• How to Use Kiosk Manager in Right Click Tools
• Customer Q&A: Lock Down Computer Labs for State Testing
• How to Create Digital Signage Players in ConfigMgr (using Right Click Tools)
• Top Use Cases for Locking Down Devices in ConfigMgr (Using Kiosk Manager)

Actionable dashboards? Yes, please with Right Click Tools Enterprise.

LAPS, BitLocker, and software update compliance all in an easy-to-view format with remediation just a right click away.

Learn More

The post Recast Kiosk Deployment via Task Sequence appeared first on Recast Software.