The Power of Task Sequences, Part 1, The Fundamentals

This is part 1 of many!  For the most part, this is same content/notes that I had done as part of my SCCM Guru sponsored webcast in early 2012.  A big thanks to Jason Sandys for reviewing and providing some additional insights to this post.

I’m certain many of you are in a similar position or maybe that you are still learning how to get the most out of systems management with ConfigMgr.  One of the things that I learned along the way was that although task sequences are essential for operating system deployment, they can also play a vital role in other systems management with ConfigMgr. Task sequences are versatile and robust with tremendous functionality that is often unknown, overlooked, or underutilized.  The power of task sequences lies in their flexibility for administrators to configure client settings, distribute software, update drivers, edit user states, and perform other tasks independent of OSD.

I’m here today to touch on some of this functionality to hopefully help spark your interest to discover how you can use them to enhance and simplify your own environment.  I’ve compiled various use cases, examples, questions that have arisen within the community, and scoured the Internet for how others have used task sequences, community-developed custom solutions to augment task sequences.  While not all of the examples are useful to everyone, they are designed to hopefully get your brain juices flowing and be an example on…drumroll please….the power of task sequences.

The Fundamentals

Let’s first cover some basics that set a good foundation for getting the most out of task sequences.  Without an understanding of these foundations, the rest of the presentation isn’t as meaningful.  The three things that I consider to be foundational are:  task sequence steps, task sequence variables, and task sequence conditions.  I’m going to try to make this relevant so that I do not bore you veterans on the webcast!

Note that the ConfigMgr writing team at Microsoft has excellent explanations documented about task sequences on TechNet.  Some of those descriptions are just quick highlights of what it written, but I suggest you read the TechNet articles sometime to further familiarize yourself with them.

Task Sequence Steps

Task sequence steps are the basic components that take action within the task sequence.  For those who have not worked with task sequences much, the steps essentially define what you’re trying to accomplish on the running computer, such as installing software, creating and/or installing an OS, changing registry data, migrating user data, etc.

Step Descriptions

There are 27 total steps that can be used.  However, for today’s demonstrations I will primarily use six.

Run Command Line – with this step, almost any command can be run, whether it is a trigger an installer, or kicking off a utility, running a script from a package, or initiating a process from files on the local disk.

Install Software – along with being able to install software using “Run Command Line”.  There are two different ways to install applications

  • Install single application – this option is likely the most common way to install software during a task sequence.  It only runs a single Package with a single Program.  If you’re Programs are just executing a single installer (like setup.exe for example), then that’s all you get is the one install.  Otherwise if a package has several things additional things to do, those would need to be either added into additional programs for the package, or you would need to wrap all actions together into a script.
  • Install multiple applications – To be honest, I’ve always overlooked and bypassed this option throughout my career and “rediscovered” during creation of this presentation.  It’s pretty cool.  Unlike using the install a single application, it is possible to install anywhere from 1 to 999 applications with this option selected!  It is important to note that for this to function, the option on the Program’s Advanced tab must be selected to allow it to run in a task sequence.  http://social.technet.microsoft.com/Forums/en-US/configmgrdocs/thread/3f7819a7-8934-444f-9d67-5cb152efb78b

Install Software Updates – this step is used for installing Microsoft updates.  The only thing I’ll mention at the moment is to ensure you’ve created a software update deployment that is assigned to a collection in which the computer resides.

Join Domain or Workgroup – This will be used as an example of utilizing task sequence variables to dynamically configure the options so that only one step is used instead of multiple steps.

Restart Computer

Set Task Sequence Variable – Much more on this coming up soon

Demo 1: Basic task sequence to demonstrate the above steps

  • Run command line: execute cmd.exe
  • Run command line: execute a batch file from a package
  • Install Software: execute a package/program

Success/Failure Exit Codes

Another thing to note about task sequence steps are the exit codes for software installations.  If the install or script does not terminate with an exit code of 0 or 3010, then the task sequence will fail.  However, let’s say there is a known application breaks normal conventions by having their successful exit code be as either “0” or “1” and their failure as “3010”.  There are a couple of ways to approach a scenario like this.  The first option could be to create your own custom script wrapper to grab the exit code and then terminate the script with a zero.  Or in the task sequence, use the Run Command Line option to account for the non-standard successful exit codes.

Demo 2: Example that causes the TS to fail with custom exit code 1
Demo 3: Example that causes the TS to succeed with custom exit code 1

Task Sequence Variables

Task sequence environment variables provide a mechanism to configure and customize the steps in a task sequence.  In fact, when I last counted the number listed on TechNet, there are 154 built-in variables that can be used to control and automate your task sequence.  And with the ability to create your own custom task sequence variables, the possibilities are endless!!  Imagine being able to automate:

  • Configuration of any settings and actions
  • Creating administrator customized values
  • Providing command-line arguments to a step
  • Grab values for custom scripts and HTA front ends for OSD
  • Access and override built-in, default values which drive an installation or an OS configuration
  • Evaluating conditions prior to a step or groups execution (which I explain further in this presentation)
  • And they can be specific to a computer running the task sequence or to all computers in the assigned collection

Built-in Variables

There are too many built-in variables for me to describe without causing a mass exodus on this webcast, but there are a few that I want to highlight as I find to be of more value and when they could be useful.  Take note that any task sequence variables that begin with an underscore character are read-only and their associated values can only be read, not changed. http://technet.microsoft.com/en-us/library/bb632442.aspx

  1. _SMSTSInWinPE – Determining whether or not to launch a specific step based upon being inside WinPE or full Windows.
  2. _SMSTSMachineName – If you need to know the name of the SCCM computer record on which the task sequence is running, this can be used.  I’ve used this variable to pre-populate the name of the computer being imaged into a custom HTA.
  3. _SMSTSLaunchMode – How the task sequence was started (boot media, PXE, advertisement, etc.)
  4. _SMSTSUserStarted – Along with _SMSTSLaunchMode, can detect if the task sequence was launched by a user in Run Advertised Programs
  5. _SMSTSPackageName – Let’s pretend that for auditing purposes, you need to “tattoo” the task sequence that executed into the registry or a custom log file.  You could grab this value to get the name of the task sequence that ran.  I’ve used this myself that after every time a task sequence was modified, part of my process was to increment a version value in the name, such as “My TS 1.00” to “My TS 1.01”.  Then this value was added to a registry value for distant future auditing.
  6. SMSTSErrorDialogTimeout – When an error occurs in a task sequence, a dialog box is displayed that is dismissed automatically after a default time-out value. Use this variable to specify a time-out value in seconds other than the default of 15 minutes.
  7. SMSRebootMessage – Customizes the message to display in the shutdown dialog box when a reboot is requested.  This is especially useful when an end-user may see the restart and wonder what’s happening.  Such as “The IT Department is has installed updates and a computer restart in progress to complete”.
  8. SMSRebootTimeout – Specifies how many seconds to wait before the computer restarts. Again, this is useful when a user may be in Windows at the time when the restart is required.  Increasing the value to manageable time for them to save/close documents is useful in this case.
  9. SMSClientInstallProperties – Could be particularly useful if there are many client install properties, that for consistency sake amongst many task sequences, this could be set in a script.
  10. OSDJoinAccount & OSDJoinPassword – If a single task sequence is necessary to possible join a computer to different domains, then these could be used to dynamically automate this process.
  11. OSDDomainOUName – Similarly, this can be used to dynamically set the OU in which to place the PC
  12. OSDComputerName – Used to set (or change) the computer name.  I’ll admit, this variable is not exciting per say, but it is probably the most common one used.  Because who wants their computer to be name MININT-K5G9E2?  Again since this is the most commonly used variable, I will be using it in many examples throughout the presentation.
  13. OSDLocalAdminPassword – If necessary to have a custom local admin password for the computer being deployed.

Anything configured when creating the task sequence essentially pre-populates the task sequence variable values so thats what they start out as. This is also known as design-time. These are not set during the execution of the ts but rather stored in a file, tsvariables.dat, that is transferred to the client at the beginning of the ts when the initial values are set so that when a task requests their value(s), it is/they are available.

Anything set during the execution of the task sequence, aka run-time, overwrites these values so that when the task that uses them requests them, the variables reflect the value of the activity that most recently set them. Thus anything that sets them during the execution of the task sequence wins; this could be a script, the set task sequence variable task, or something else.

Demo the code to get/set TS Variables:

  • VBScript
  • PowerShell

Demo 4: Read/set a variable as a task sequence step
Get read only variable

  • Set custom variable
  • Get read only variable

Unfortunately, there is a catch to the built-in task sequence variables.  Many of them are only available during execution of particular action.  However, this may just have been an issue with a particular environment that I operating within for many years as once set variables are set, they always set. As mentioned above, they are pre-populated by the values set at design-time. Certainly if the task, like Apply Network Settings” isn’t in the task sequence, then its corresponding values are never pre-populated. Something must explicitly create or clear a ts variable. For the built-in ones, this is the ts engine itself at the beginning of the ts using the tsvariables.dat file — at least for creation, there is nothing that deletes them.

Demo 5: Demonstrate a particular task that will only exist during execution of the step/action and then gets reset

  • Set variable WorkingDirectory to C:\Demo
  • Create a Run command line to run demo5a.bat
  • Create a Run command line to run demo5b.bat

Custom Variables

A workaround to this limitation is to use a script to snag the variable and stuff it into a custom variable.  Which is part of the beauty of custom task sequence variables; the sky is the limit.  For example, let’s pretend that you are deploying an OS (or even just software and updates!) to various departments using a single task sequence.  Well, Rod Trent in the marketing department is probably going to be upset with you if TweetBlocker gets installed instead of his favorite application named MMSTwitterArmy.  In a situation like this, you put together a quick script that would set a custom task sequence variable named OSDTwitter = yes.  Then when the action to install the software executes, you can set a check against that task sequence variable to check against the custom task sequence variable.

Demo 6: Install Software: create a multi app install by setting custom variables

  • How to limit execution of a step to a custom variable as well as
    • Example of using a script to get the computer name that contains “MKT” for marketing.
    • Create fake executables named TweetBlocker and MMSTwitterArmy for visual effect
    • Various options for the check, such as the actual value versus if the variable exists
  • Script to company multiple default variables into a single custom variable which is then used to set the computer name.  (obviously this is a ridiculous and not useful as a real world example, but gets the point across)

Collection Variables

Another viable option for defining custom variables is to set them on the collection itself.  In this instance, we’re going to create a variable to prompt

Note that if the value is left blank, then prior to the task sequences execution, a dialog box will be displayed for someone to manually input the value.  If there are several or many collection variables defined, then it could become a hassle as there will be an individual prompt for every single one of them.  So, a good example of when this may be useful is when needing to set the computer name only during imaging or maybe defining what the local admin password should be.

Demo 7: A single collection variable

  • Go to collection properties > Collection Variables > add variable Demo7 with value ValueForDemo7
  • Show VBScript which grabs the value of the task sequence collection
  • Show the task sequence code
  • Execute the task sequence

Demo 8: Different sub-collections with the time zone collection variables set, but the TS assigned to the parent collection and allowed to be advertised to the sub-collections.

Task Sequence Conditions

The third and final task sequence fundamental is conditions.  Task sequence conditions are optional statements for a step (or group) which, when evaluated during runtime, will determine if the step (or group) will execute.

With conditions, you can check against the following:

  • Task Sequence Variables – custom variables or built-in variables
  • Operating System Version – determines the active operating system and/or the processor architecture (x86/x64) that is executing the task sequence
  • File Properties – includes checking existence of the file,  the file version, and/or the file timestamp
  • Folder Properties – includes checking existence of the folder and/or the timestamp
  • Registry Setting – includes checking registry keys and values
  • Query WMI – if it’s in WMI, then you check for it easily, such as querying for a computer model
  • Installed Software

Additionally, you can have any combinations of these items and “if” statements (any of, all of, none of) against a combination of the conditions!  An example of when to use these “if” statements might resemble an instance of only executing a step if a computer is a specific model, has a specific registry value set, but a certain file does not exist.  These can be combined and checked on a single condition statement for the step.

Demo 9: How to use each of the items listed

Tool to help generate WQL – http://www.microsoft.com/download/en/details.aspx?id=8572

Demo 10: How to use the “if” statements

3 thoughts on “The Power of Task Sequences, Part 1, The Fundamentals”

Add yours

  1. Pingback: The Power of Task Sequences, Part 2, Non-OS Deployments « t3chn1ck
  2. Pingback: The Power of Task Sequences, Part 3, OS Deployments « t3chn1ck
  3. Pingback: The Power of Task Sequences, Part 4, Misc Notes « t3chn1ck

Leave a comment

Create a free website or blog at WordPress.com.

Up ↑