Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

System Center Configuration Manager 2007 : Operating System Deployment - Task Sequences (part 2) - Tasks

2/26/2013 11:45:03 AM

2. Tasks

Here are the six built-in categories of tasks:

Under each category is a set of tasks corresponding to that category. Each task is discussed briefly in the following sections. Note that some tasks must be combined with others and in a specific order for them to make sense—when this is required, it is noted in the discussion of that particular task.

You can disable each task independently using the Options tab; this allows you to disable tasks during troubleshooting.

General Category

Options under the General category (shown in Figure 5) include the following:

  • Run Command Line— This task allows you to run any valid command line that you want in your task sequence, including batch files and VBScripts. If the files referenced in the command line do not exist on the target computer, you can specify a package containing those files. Additional options include specifying a working directory for the command line, and a timeout to ensure that a command does not continue executing if it falls into an infinite loop or becomes otherwise hung.

    Because it is possible for multiple return codes to be considered as a successful execution of a given command line, there is an additional option on the Options tab, displayed in Figure 6, allowing you to configure numeric return values that should be considered a success. This field should contain integers separated by spaces. Note that only the first value listed can be negative. The typical success code of 0 is listed by default, along with 3010—denoting success with a reboot required.

    Figure 5. General tasks

    Figure 6. Run Command Options tab

    Tip: DOS Commands

    To use a DOS command such as md or copy, you must call the command as a parameter to the command interpreter cmd.exe, for example, cmd.exe /c md NewDirectory.

    New in ConfigMgr 2007 R2 is the option to specify the user account that runs the command, which allows greater flexibility. Prior to R2, the command uses the security credentials of Local System.

  • Install Software— With this task, you can call any program from any package that you defined as part of software distribution. The program must meet three distinct qualifications:

    • It must run silently and not interact with the desktop.

    • It must run with administrative privileges.

    • It must not initiate a reboot; reboots can be handled within a task sequence if needed.

    A caveat with program execution is that program dependencies are honored, but programs in the dependent chain are not automatically initiated. For example, if you configure program A to run program B with the Run Another Program First option, program A does not automatically run program B and fails to install unless program B already ran on the system (presumably using another task). This occurs because the Run Another Program First option sets up a dependency chain that is checked before a program is run. In this example, program A depends upon program B. During Software Distribution, this setting automatically causes ConfigMgr to run program B before program A. However, this does not happen with OSD; the dependencies for program A execution are not met, thus causing program A to fail when it executes.

    An advanced use of this task is to install multiple applications based on the value of a series of task sequence variables. You must name the variables with a single base name and then append a three-digit, sequential numeric suffix (such as Software001, Software002, Software003, and so on). Each variable should contain a value matching the pattern PackageID:Program Name. A break in the sequence number stops the evaluation of the variables; for example, if you have Software001, Software002, and Software004 and omit Software003, execution of programs stops at Software002.

  • Install Software Updates— This task allows you to incorporate software updates into an image, limiting the amount of time spent on updates after deploying the image. The task is also used to layer on updates not included in the image, allowing you to deploy fully patched systems. Updates used for this task are pulled directly from the ConfigMgr Software Updates facilities; these must be configured and performing properly and the ConfigMgr client installed on the target system prior to the task’s execution. You cannot use this task to pull updates from any other source.

    There are two options available for this task:

    • Install Mandatory Software Updates— These are those options advertised to a collection containing the resource with an installation deadline specified.

    • Install All Software Updates— This installs all updates advertised to the collection where the task sequence is advertised.

  • Join Domain or Workgroup— Joining a domain or workgroup is a required step during a Windows installation; this task allows you to configure this behavior. If you specify a domain name, you must also specify credentials capable of joining a system to the domain and an Organizational Unit (OU) to place the computer object.

    Caution: Do Not Use a Domain User Account to Join a Domain in a Task

    Note that by default all Domain Users can only join 10 computers to a domain (see Microsoft KB number 251335 for further details: http://support.microsoft.com/kb/251335). Because of the 10-computer limitation, ensure that the account used in the Join Domain or Workgroup task has higher privileges than a Domain User because that causes unexpected failures in the task sequence after it successfully runs 10 times.

    You can use this task to join a system to a domain instead of using the domain join functionality of Windows setup configured using a sysprep.inf or unattend.xml. You can also use this task to unjoin a system from a domain before syspreping.

  • Connect to Network Folder— With this task, you can map a drive letter to any shared folder using a UNC while specifying alternate credentials to make this connection. This drive letter is available in subsequent tasks to access resources available in that share.

    One common use for this task is to map a drive later used by another task to copy the task sequence logs to that shared folder, and then use it for troubleshooting or tracking purposes. An excellent discussion of this specific troubleshooting step is at http://blogs.msdn.com/steverac/archive/2008/07/15/capturing-logs-during-failed-task-sequence-execution.aspx.

  • Restart Computer— As its name clearly states, this task restarts the host computer where the task sequence is currently running. After the restart, the system can be set to boot either into the task sequence’s specified boot image or into the currently installed default operating system. You can specify a message to display on the screen, providing feedback to anyone observing the task sequence’s progress, along with a timeout allowing the observer to initiate the restart manually.

  • Set Task Sequence Variable— Setting task sequence variables allows you to configure available OSD-specific deployment options, configure variable application deployments with the Install Software task category, or execute future tasks in the task sequence conditionally.

    Conditions can be applied to this step so that the variable is set only when specific conditions exist; you can then configure a future task to be performed based on this variable being set. The “Conditions” section gives an example of this.

Disks Category

A number of configurations are possible under the Disks option (shown in Figure 7):

  • Format and Partition Disks— This flexible task allows you to configure the partitioning and formatting of all disks in the target system and is a notable improvement over OSD in SMS 2003, which could only easily handle the C: drive. If you plan to handle multiple physical disks, each must have its own instance of this task. Configuration options include specifying the physical disk number and the type of disk to create

    • A standard disk using a master boot record (MBR)

    • A disk using a Globally Unique Identifier (GUID) partition table, known as a GPT

      GPT disks are relatively new to Windows and not supported for boot disks, except on Itanium systems.

    Figure 7. Disk tasks

    In addition to specifying which disk to use and its partitions, you can create individual volumes:

    • Each volume can be set to a percent of total space on the disk or hard-coded to a specific size.

    • The format type can be specified (NTFS, FAT32, or none).

    • The partition can be set to be a boot partition.

    By default, a full format of the volume takes place. A full format can add unnecessary time to the task sequence when a quick format is normally sufficient.

    The last option for this task allows you to store the drive letter used in a task sequence variable. This allows you to reference files on this volume or use the file system on this volume in future tasks by referencing this task sequence variable.

  • Convert Disk to Dynamic— This task converts a specified disk to a dynamic disk. The only configuration option for this task is to specify the disk number to convert.

  • Enable BitLocker— Only applicable to systems running Windows Vista or later, this task enables BitLocker on a specified disk. BitLocker encrypts the contents of an entire disk at a low-level. Additional configuration options include the following:

    • Where to store the startup key (Trusted Platform Module [TPM], USB drive, or both).

      Choosing USB startup key storage requires attaching a USB drive to the system during the execution of the task sequence.

    • Where to store the recovery key (Active Directory, or no storage).

    • The final BitLocker configuration option chooses whether to wait for full encryption of the drive before the task sequence continues.

      Depending on the current contents of the drive, this could be a lengthy process and greatly increase the running time of the task sequence. If you do not choose this option, drive encryption takes place dynamically in the background.

    BitLocker requires two NTFS partitions: one for the system volume and one for the operating system volume. The system volume partition must be at least 1.5GB in size and set as the active partition. Create these partitions in a Format and Partition Disk task prior to executing the Enable BitLocker task in the task sequence.

  • Disable BitLocker— The exact opposite of enabling BitLocker, this task simply disables BitLocker on a specified drive. Decrypting the drive contents is dynamic and in the background; the task sequence does not wait for completion of this activity before continuing.

User State Category

A number of tasks are available under User State, displayed in Figure 8:

  • Request State Store— The Request State Store task attempts to connect to a state migration point prior to capturing or restoring a user’s state data.

    If there are multiple state migration points in an environment, the task uses the first one listed on the site’s management point with space available for the capture; for a site with multiple state migration points, each migration point is searched looking for the one with a computer association where the destination system is listed as a target.

    You can specify the number of times to retry the connection and the delay between retries, and whether to capture or restore a user’s state. An additional option allows using the Network Access account rather than the Computer account for connecting to the state migration point.

    This task creates a computer association if one does not already exist and the Request State Store task is configured to capture the user’s state; this created association lists the target system as both the source and destination, which is perfect for an in-place migration. If you do not want an in-place migration, you must manually create the computer association before the task sequence runs by using the Computer Associations node (Site Management -> Computer Management -> Operating System Deployment -> Computer Associations).

    If the task is used to capture user state data, it creates an encryption key that stores the data securely; this key is stored with the computer association. If used to restore the user state data, this task retrieves the encryption key from the computer association.

    The computer association also stores the exact path where the files are stored on the state migration point, and the times they were captured and restored. An additional option while creating a computer association is the ability to choose which user profiles to capture—either by using the User Accounts tab or by right-clicking an association after it is created and choosing Specify User Accounts. 

  • Capture User State— This task initiates the use of USMT  and captures the user state data using ScanState. A prerequisite for using this task is the existence of a software distribution package containing the files from an installation of USMT. In addition, you would use this task after successful execution of a Request State Store task configured to use for capturing user state.

    Figure 8. User State tasks

Additional options for this task include the following:

  • Using custom USMT configuration files

  • Skipping EFS encrypted files

  • Continuing without raising an error if some files cannot be captured

  • Verbose logging

You can customize the options passed to ScanState by setting the OSDMigrateAdditionalCaptureOptions task sequence variable. It is also possible to use a Run Command Line task to invoke ScanState manually. Use a Set Task Sequence Variable task to set OSDStateStorePath to the value of _SMSTSUserStatePath and pass OSDStateStorePath to ScanState as the location of the state store; for example, cmd /c scanstate.exe %OSDStateStorePath% /i:migapp.xml /i:miguser.xml /i:migsys.xml /ui:DOMAIN\* /v:1 /l:c:\temp\loadstate.log.

  • Restore User State— This is the mirror task for Capture User State and has similar options: a USMT package must exist, specify if using nondefault configuration files, continuation without raising an error when files cannot be restored, and verbose logging.

    The one option that is different from a Capture User State task is the addition of a password for migrated local accounts. The password for these accounts cannot be migrated even though their data might be, so you must supply a password to use for all the accounts. You must use this task after a Request State Store task configured for restoring user state.

    You can customize the options passed to LoadState by setting the OSDMigrateAdditionalRestoreOptions task sequence variable. It is also possible to use a Run Command Line task to invoke LoadState manually, by using a Set Task Sequence Variable task. Set OSDStateStorePath to the value of SMSTSUserStatePath—the same as when manually invoking ScanState—and pass OSDStateStorePath to LoadState as the location of the state store; for example, cmd /c scanstate.exe %OSDStateStorePath% /i:migapp.xml /i:miguser.xml /i:migsys.xml /ui:DOMAIN\* /v:1 /l:c:\temp\loadstate.log.

  • Release State Store— This task has no options and must be preceded by a Request State Store task and either a Capture User State or a Restore User State task.

    • If used with a successful Capture User State task, this task tells the state migration point that the capture was completely successful and is ready to restore. The state migration point then marks the user state data as read-only.

    • If used with a successful Restore User State task, the task also communicates with the state migration point telling it that a successful restore took place. The state migration point then applies the configured retention settings on this data, allowing the storage space used by the data to be cleaned up.

Images Category

Tasks in the Images category focus on capturing and deploying images, operating system configuration, Sysprep, and the ConfigMgr client agent. Figure 9 displays these tasks.

Figure 9. Images tasks

  • Apply Operating System Image— This is the central task in any OSD task sequence and performs one of two things:

    • It applies an operating system captured in an image to the target system from an operating system image. This is a destructive operation; OSD wipes the entire partition before delivering the image. You can preserve a single folder from being wiped by setting the _SMSTSUserStatePath task variable.

      Tip: Storing User State Locally

      To store user data on the local file system without using a state migration point, you must set two task sequence variables:

      • _SMSTSUserStatePath

      • OSDStateStorePath

      _SMSTSUserStatePath must appear before the Apply Operating System Image task to prevent this path from being wiped during the image deployment. OSDStateStorePath actually controls where OSD stores user state data and must be set before executing any user state tasks; it needs to be set to the same path as, or a subfolder of, _SMSTSUserStatePath. To restore user state data from a locally source, set OSDStateStorePath to the correct local path before any user state tasks are executed.

    • It installs an operating system on the target system using the original source files from an operating system install package.

    The options for this task are to specify a package containing unattended setup files and select a destination—Next available formatted partition, Specific disk and partition, Specific logical drive letter, or Logical drive letter stored in a variable.

    If you specify an unattended files package for Windows XP and deploy an image, you should specify a sysprep.inf file. If you deploy an XP setup, use an unattend.txt file. Vista uses the same file format regardless of the type of deployment. If you do not specify an unattended file, ConfigMgr uses an applicable default one.

    If you need to create one (or more) of these unattended setup files, Microsoft has kindly provided a couple of tools to facilitate this, depending on the OS you are deploying:

    • Windows XP— Setupmgr.exe for Windows XP is contained in the deploy.cab compressed file along with Sysprep. Also contained in deploy.cab is deploy.chm—a help file containing a complete reference to the valid schema and possible settings of the unattended setup files for Windows XP.

    • Windows Vista— SIM for Windows Vista is part of the WAIK. A help file is also installed with the WAIK, Unattended Windows Setup Reference.chm, containing a comprehensive reference to the schema of Windows Vista setup files.

  • Apply Data Image— This task uses a preexisting image listed as an operating system image and applies it to a data partition. The same options for specifying a destination for the Deploy Operating System task are available for the Apply Data Image task.

  • Setup Windows and ConfigMgr— This task initiates Windows setup for build and capture task sequences or reboots the computer into the deployed, Syspreped image for deployment task sequences. Once the OS setup is finished, it then installs the ConfigMgr client on the target system. The only prerequisite is the package containing the ConfigMgr client, which you must select for this task. Additional command-line options used to install the ConfigMgr client can also be specified, such as /mp and /native.

  • Install Deployment Tools— The main job of this task is to make the sysprep files available to the task sequence. The task typically is used only in Build and Capture task sequences. If the operating system version installed is XP (or earlier), a package containing the sysprep files from the corresponding deploy.cab file must be specified. Sysprep is included in the installation of Vista, so this task does not need a separate package when installing Vista.

  • Prepare ConfigMgr For Client— This task is required before capturing an operating system image from a target system. It prepares the ConfigMgr client agent to be part of an image by stripping it of any unique identifiers. There are no options for this task.

  • Prepare Windows for Capture— This task runs the actual Sysprep on an installed operating system, stripping it of any uniqueness and preparing it for capture in an image. There are only two options available for this task:

    • Automatically build mass storage driver list.

      The build mass storage driver list option is equivalent to using the bmsd option with Sysprep; it is a rarely used advanced option.

    • Do not reset activation flag.

      The Do not reset activation flag option is equivalent to the activate option of Sysprep and is used only when you capture an image of an operating system that has already been activated. This option is also rarely used.

  • Capture Operating System Image— This task captures an image of the installed operating system on the target system to a WIM file using ImageX. Two parameters are required:

    • The first parameter is a filename for the destination WIM file. This filename needs to be fully qualified to include the destination UNC and can be on any accessible folder share; for example, \\<servername>\Captures\XPBaseline01.wim.

    • The second parameter is an account and its associated password with permissions to write to the specified location.

    Optional parameters are metadata to associate with the image including the creator, version, and description.

Caution: WIM Capture

If you hard-code the WIM filename and location, ensure you copy or move the WIM file from the folder where it was captured to prevent another execution of this task from overwriting it.

Drivers Category

There are two driver-specific tasks, as shown in Figure 10. Both tasks inject drivers into an image or operating system during its deployment.

Figure 10. Drivers tasks

  • Auto Apply Drivers— Using this task, you tell the task sequence to first run a plug-and-play check on the target system’s hardware generating a list of plug-and-play IDs; this check emulates the plug-and-play check that Windows setup performs.

    The task compares the list of IDs to the driver catalog maintained by OSD; copying those best matched to the target system. In addition, the unattended setup file is modified to reference the copied drivers for usage during the full Windows setup or mini-setup on Syspreped images.

    Options for this task include the following:

    • Copying the best matched drivers

    • Copying all compatible drivers and choosing the categories of the drivers to consider for matching

    • Bypass checking of a signature on drivers on operating systems that allow it

  • Apply Driver Package— Use this task to tell the task sequence to copy all the drivers in a particular driver package to a target system and update the unattended setup files with those drivers. The Apply Driver Package task skips the plug-and-play pre-check performed by the Auto Apply Drivers task and forces ConfigMgr to copy the specified drivers.

    Using this task, you can deploy mass-storage drivers such as SATA drivers to Windows XP and Windows 2003. You would also use this task in cases where the plug-and-play pre-detection used by the Auto Apply Drivers task is not picking up the proper driver or the hardware is not yet attached to the system, as is the case for locally attached printers and scanners.

    Options include choosing a particular package, choosing the specific mass-storage device driver to use from the package, and overriding the requirement to use signed drivers.

Tip: Using Mass Storage Drivers

The ConfigMgr development team chose a narrow definition of which driver classes are eligible for deployment as mass storage drivers, also known as boot critical device drivers. As a result, only drivers of the class SCSIAdapter can be considered for mass-storage devices. To use a device with the class hdc, you must edit the oemsetup.txt file and change the class from hdc to SCSIAdapter before you import the driver into ConfigMgr. This is actually a known oversight fixed in ConfigMgr 2007 Service Pack 1.

Settings Category

Settings tasks capture specific settings from a source system and restore them during an in-place migration or allow you to specify the specific settings during a side-by-side migration or new installation. Figure 11 shows available settings tasks.

Figure 11. Settings tasks

  • Capture Network Settings— This task, used for an in-place upgrade, captures the network settings of a source system before wiping the system. These settings are automatically migrated to the system after deploying the operating system and override any settings specified in an Apply Network Settings task. The two network settings that can be migrated are the domain and workgroup membership and the network adapter configuration. If neither option is selected, the task is benign.

  • Capture Windows Settings— Similar to the Capture Network Settings task, this task captures specific Windows settings and migrates them during an in-place upgrade; these settings override any settings specified in an Apply Windows Settings task. The Windows settings that can be migrated are the computer name, username and organization name, and the time zone. If you do not select any options, this task does nothing.

  • Apply Network Settings— This task sets network settings on a target system including joining a domain or workgroup and network adapter settings. If joining a domain, an account and password must be set that has privileges to join the domain. You can configure multiple network adapters individually; each can be set to use DHCP or a statically assigned Internet Protocol (IP) address. You can also specify static DNS and WINS settings and advanced filtering settings. Settings specified in this task are overridden by those captured using a Capture Network Settings task.

  • Apply Windows Settings— This task sets specific Windows settings on the target system including username, organization name, product key, server licensing model, local administrator password, and time zone. Settings specified using this task are added to the unattended setup file in use. A product key is not required for Vista or Windows Server 2008 because these products automatically operate in an evaluation mode that does not require a product key for 30 days. Settings specified in the task are overridden by those captured using a Capture Windows Settings task.

Caution: Do Not Disable the Administrator Account

Do not set the local Administrator account to disabled when deploying an image to a system that will not be part of a domain; you will at this point have a system that you cannot access because the only account on the system will be disabled.

Other -----------------
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Correcting errors by backing out, correcting, and copying Journal Entries
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Preventing sales of Discontinued Inventory
- Windows Server 2003 on HP ProLiant Servers : Active Directory Logical Design - Replication Topology (part 3) - Designing an Efficient Replication Topology
- Windows Server 2003 on HP ProLiant Servers : Active Directory Logical Design - Replication Topology (part 2)
- Windows Server 2003 on HP ProLiant Servers : Active Directory Logical Design - Replication Topology (part 1) - Challenges and Issues in AD Replication
- Extending the Real-Time Communications Functionality of Exchange Server 2007 : Exploring Office Communications Server Tools and Concepts
- Local Continuous Replications in Exchange Server 2007
- Microsoft Dynamics CRM 4.0 : SharePoint Integration - Store Attachments in SharePoint Using a Custom Solution
- Microsoft Dynamics CRM 4.0 : SharePoint Integration - Custom SharePoint Development
- Windows Server 2008 R2 file and print services : Administering Distributed File System Services (part 2) - Configuring and administering DFS Replication
- Windows Server 2008 R2 file and print services : Administering Distributed File System Services (part 1) - Configuring and administering DFS Namespaces
- Customizing Dynamics AX 2009 : Number Sequence Customization
- Microsoft Systems Management Server 2003 : Queries (part 3) - Executing Queries
- Microsoft Systems Management Server 2003 : Queries (part 2) - Creating a Query
- Microsoft Systems Management Server 2003 : Queries (part 1) - Query Elements
- Microsoft Systems Management Server 2003 : Custom SMS Administrator Consoles
- System Center Configuration Manager 2007 : Operating System Install Packages and Image Packages (part 2) - Manual Image Creation, Image Deployment
- System Center Configuration Manager 2007 : Operating System Install Packages and Image Packages (part 1) - Automated Image Creation and Capture
- System Center Configuration Manager 2007 : Operating System Deployment - Computer Associations
- Microsoft Exchange Server 2007 : Load Balancing in Exchange Server 2007
Most view of day
- Microsoft Systems Management Server 2003 : Security - Accounts and Groups
- Windows Server 2003 : Protecting Hosts with Windows Host Firewalls - Firewall Basics
- Windows Server 2012 : Simplifying the Datacenter (part 1) - New Server Manager Tool
- SQL Server 2012 : Latch Contention Examples - Queuing
- Administering an Exchange Server 2013 Environment (part 8) - Understanding Archiving
- Windows Phone 8 : Configuring Basic Device Settings - Date and Time (part 1) - Setting the Date and Time
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Time Services (part 1) - Time Services Role in Authentication
- Microsoft Dynamic AX 2009 : Working with .NET Business Connector (part 1) - Processing Requests and Responses
- Windows Phone 7 : The Silverlight Controls (part 4) - Interactive Controls - TextBox Controls, ListBox Controls, ComboBox Controls
- Managing Windows Licensing and Activation : Managing Volume License Activation (part 2) - Leveraging MAK activation, Comparing KMS and MAK activation
Top 10
- Microsoft Project 2010 : Linking Tasks (part 8) - Auditing Task Links,Using the Task Inspector
- Microsoft Project 2010 : Linking Tasks (part 7) - Creating Links by Using the Mouse,Working with Automatic Linking Options
- Microsoft Project 2010 : Linking Tasks (part 6) - Creating Links by Using the Entry Table
- Microsoft Project 2010 : Linking Tasks (part 5) - Creating Links by Using the Task Information Dialog Box
- Microsoft Project 2010 : Linking Tasks (part 4) - Entering Leads and Lags, Creating Links by Using the Menu or Toolbar
- Microsoft Project 2010 : Linking Tasks (part 3) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship
- Microsoft Project 2010 : Linking Tasks (part 2) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship
- Microsoft Project 2010 : Linking Tasks (part 1) - Defining Dependency Links
- Microsoft Project 2010 : Defining Task Logic - Manipulating Your Schedule
- Microsoft Lync Server 2013 : Director Troubleshooting (part 3) - Synthetic Transactions,Telnet
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro