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.
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.
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.
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.
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.
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.
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.
|