The Power of Task Sequences, Part 3, OS Deployments

Posted on September 27, 2012 Updated on January 2, 2013

This is part 3 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.

• Part 1 – The Fundamentals
• Part 2 – Non OS Deployments
• Part 4 – Misc Notes

Operating System Deployments

Throughout this presentation, I have exposed several ways for selective decision logic to automate various software installations and other administrative tasks.  They had nothing to do with operating system deployment.  The reality is that task sequences were originally created to facilitate OS deployment.   I would need to get beside myself if I didn’t at least mention some cool things that can help you all out in your OS task sequences.

Consolidating Everything into a Single Image and Task Sequence

Core Image Build and Capture

One of the most common themes I hear around the industry related to general OS management is that business are attempting to manage more than a single image.  Dealing with the effort to build and maintain multiple images creates huge overhead in costs.  There is only scenario in which there absolutely must be more than a single image – when the OS and architecture are different.  For example, you would need one image for 32-bit Windows XP, one for 32-bit Windows 7, and one for 64-bit Windows 7.  Rarely should there be a reason for multiple images that have the same core OS.

Generally speaking, your image build and capture should only ever contain Windows, Office, other Microsoft enhancements such as MSXML or .NET, maybe a newer Internet Explorer, and security updates.  If you build your image in this way, then you can easily get away with only updating your images only once or twice per year to include new security updates.

Core Image Deployment

That info was just for capturing your core image.  Other software and configurations still need to be accomplished in order for the PC to be functional for the business.  Unfortunately, there are administrators who may say that while it’s great to have just a single image, they still need multiple task sequences to service for different departments or different hardware.  Well, here’s the great news: with the power of task sequences, you can consolidate all of those task sequences into one!

In this example, using our core image, we will create a robust deployment task sequence.

• Two different computer models: one laptop and one desktop
• Software that is only for laptops (such as VPN)
• Software differences for desktops which are different between a kiosk user desktop and an office user desktop (such as Citrix)
• Software that can only be installed on accounting computers (calculator tool)
• Option to enter the computer name

Expanding OS Deployment Functionality

The deployment task sequence we just constructed is a good step in the right direction.  But what if you need to provide additional functionality for the imaging process?  Such as the ability to

• Enter a computer name of choice
• Select a time zone
• Select the Active Directory OU in which to join the computer
• Select additional one-off applications to be automatically installed

One of the most common ways to do these is to use a customized prompt written as HTML Application, or just HTA.  There are many people in the systems management community, including myself, who have blogged our HTAs as examples.  Optionally, the Microsoft Deployment Toolkit 2010 Update 1 contains those abilities natively, and provides the most versatile solution when it’s integrated with ConfigMgr.  Discussion how to write your own HTA or use MDT is outside what I am going to explain today, so if you’re unfamiliar with either of these products, I suggest using your favorite search engine or you can contact me.

Returning to the original goal of extending the task sequence features, I have prebuilt an HTA which utilize both built-in and custom task sequence variables to

• Supply a computer name (OSDComputerName)
• Time zone selection (OSDTimezone set and step blank)
• OU options (OSDDomainOUName set and step blank)
• Choosing one-off applications (Custom variables)

The Power of Task Sequences, Part 2, Non-OS Deployments

Posted on September 20, 2012 Updated on January 2, 2013

This is part 2 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.

• Part 1 – The Fundamentals
• Part 3 – OS Deployments
• Part 4 – Misc Notes

Non-OS Deployments

Thanks everyone for sticking it out with me through the webcast so far!  I hope that I haven’t lost too many folk.  Now that we’ve reviewed the fundamentals of task sequences – steps, variables, and conditions – lets now get into some scenarios, examples, and demonstrations of what the power of task sequences can do.  As mentioned task sequences are not just for deploying an OS.  They can be used for automating any tasks such as deployment of varied software, chaining installations, configuring Windows, performing decision logic, etc.

Chaining Steps

Prior to task sequences the only way to link together, or chain, execution of different packages was to use the “Run another program first” option with the advanced settings of the program.  In such a way, you could chain multiple packages together to ensure exact execution in a precise order of operations.  However, this suffers from some limitations such as if one program failed midway in the chain, the remainder of the chain failed.  Furthermore, if the chain was rerun, it then needed to rerun from the very beginning of the chain and repeated those programs which were previously successful.  Although it was good for what needed to be accomplished, it still had challenges and limitations.

Now with the power of task sequences, chaining programs is almost a thing of the past.  In fact task sequences can give you as the administrator so much more control over the end goal.

Demo: MS Office upgrade

A prime example that I always like to demonstrate is an upgrade of Microsoft Office, such as upgrading from 2007 to 2010 along with upgrading any Office 2010 installs to SP1.  There are several steps into accomplishing this upgrade.  Allow me demonstrate:

1. Set the TS shutdown behavior
   1. Set the message to something friendly
   2. Set the countdown to 10 minutes
2. Restart Windows so that no Office files are locked
   1. Except if no Office is installed
   2. Change the restart message
3. What to do about the SCCM client cache size? (e.g. since it’s downloaded into _SMSTaskSequence, cache size does not need to change)
4. Install Office 2010 (skipping upgrade is Office 2010)
   1. One configuration with just Word, Excel (such as a kiosk)
   2. One configuration with all software
5. Install Office 2010 Service Pack 1
6. Install security updates
7. Defrag the hard drive

Demo 11: Office 2010

Demo: detection of 32-bit vs. 64-bit

As mentioned, a typical best practice distribution of software is to build collection where the query is designed to only target computers that are missing a particular application version unless the version is newer.  For example, Application A is installed corporate-wide at version 1.0.  You’ve been tasked with upgrading it to version 1.1 and any computers missing the application.  However, some computers are running 1.2 so they should not be included in the target.  So you would be your sub-select query to fulfill these requirements.

Here is a great example of this similar scenario.  I recently assisted a customer with creating a task sequence to deploy Microsoft updates to their servers, including an upgrade of VMware Tools to the latest version and to install the software if it didn’t exist at all.  Normally this can be moderately simple, but detection of the software requires two different methods since the tools have a 32-bit version and 64-bit version.  The detection boils down to:

1. On 32-bit Windows
   1. Install if software not present with 32-bit detection
   2. Upgrade if software version older than current version using 32-bit detection
2. On 64-bit Windows
   1. Install if software not present with 64-bit detection
   2. Upgrade if software version older than current version using 64-bit detection

Demo 12: Include an example of the sub-select query so that it translates better into how that looks in a WMI query.  Also demonstrate how it could be broken into two different steps of x86 and x64 or combined into one step.

Demo: Workstation Updates

Here’s a situation that you’re all familiar with: keeping the desktops and laptops updated with the most secure software within the environment.  Though often times, software is deployed on as-needed basis, more and more companies require a change control process coordinated with a specific period in which the updates can be deployed to computers.

At its most simplistic form, an admin could just assign a package to a collection with the assumption and hope that all computers installed the updates.  A better step in the right direction is to create a collection with a sub-select query to only target the computers that actually need the software.  However, what does one do if you want the best of both worlds?  Turn to the power of task sequences of course!  This is a great example if you’re in a situation where all actions need to run in a systematic timeline with very little lag and better visual indicator to users.

1. Change the default restart time from 30 seconds to 10 minutes so users have enough time to close documents if necessary.
2. Pre-install restart
3. Install Adobe Reader update (only if Acrobat not installed)
4. Install Adobe Acrobat update (only if Acrobat installed)
5. Install Microsoft Security Updates
6. Upgrade BIOS for computer model XYZ
7. Restart computer into WinPE so as to do the next item:
8. Execute a utility to enable Wake On LAN in BIOS
9. Force a Group Policy Update with system restart

Miscellaneous Administrative Tasks

Now let’s pretend you have a string of routine administrative tasks to perform against computers on a regular basis.  Task sequences are also powerful in this way by not just being limited to installing software or deploying an OS.  The example that I’ll use here may not completely be a real world example, but again, it is designed to demonstrate flexibility and get your juices flowing.

1. Delete old user profiles
2. Cleanup temp files
3. Delete SCCM cached files
4. Flush/register DNS
5. Check the local admins group for unauthorized users/groups (use Sherry’s DCM?)
6. Force a Group Policy Update without system restart
7. Run SCCM Client Health Check Script
8. Defrag hard drive

Demo: Complex Conditions Flows

Along the way with the demos so far, I’ve tried to incorporate different examples of using task sequence conditions.  The VMware Tools demo definitely showed some complexity using WMI queries to decipher 32-bit versus 64-bit detection.  But now let’s have some fun by taking this a step further!  We need deploy a software install which meets the following requirements:

• The post-install restart of Windows for a specific department needs to give a 10 minute countdown (first 3 digits of computer name are the department code)
• Only execute on Windows workstation OS (excluding Windows 2000)
• Cannot execute on computers which live in a specific OU
• A combination of four installation types based upon
  • Two different command lines parameters where applicability comes from a value in the registry
  • Two different architectures (32-bit vs. 64-bit)
• An additional install occurs for computers which have a special local user account

Demo: Multiple methods to accomplish same thing

I am going to have more fun with the flexibility of task sequences by demonstrating six different ways to accomplish the same thing.  In this example, we are going to uninstall Flash v10 and install Adobe Flash v11 either with the 32-bit or 64-bit editions.  Keep in mind that some of these exmamples are a little unrealistic, but it does exhibit the flexibility.

Demo: Uninstall Flash 10, install Flash 11

• Easy: individual steps with no checks, just do it regardless
• Easy: WMI queries for existence or architecture
• Easy: step for the Installed Software using an MSI
• Moderate: use a script which sets a custom TS variable to do the uninstall detection
• Moderate: use collection custom TS Variable
• Moderate: multi-application install to do everything at once

Demo: Operations within Windows PE

Here is a cool thing that I’ve done in my experience.  There had been a few instances where one of the field offices was being sold to another company, but it was contracted for the new ownership to retain the existing computer hardware.  The challenge therein was that we couldn’t allow them to have access to company software licenses or data that may exist on the system.  So I developed a task sequence to remotely erase the hard drive.

• Restart in WinPE
• Format the disk
• Restart the TS to boot into the host OS

The Power of Task Sequences, Part 1, The Fundamentals

Posted on September 14, 2012 Updated on January 2, 2013

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.

• Part 2 – Non OS Deployments
• Part 3 – OS Deployments
• Part 4 – Misc Notes

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.

• http://social.technet.microsoft.com/wiki/contents/articles/how-to-use-a-collection-variable-to-prompt-for-a-computer-name-during-an-osd-task-sequence-in-system-center-configuration-manager-2007.aspx
• Go to sub-collection properties > Collection Variables > add variable Demo8 with value ValueForDemo8
• Show VBScript which grabs the value of the task sequence collection
• Show the task sequence code
• Show that the advertisement applies to the subcollection
• Execute the task sequence

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.