2. Manual Image Creation
It is also possible to create and capture an
image manually. The downside to this is it is labor-intensive and prone
to human error; the upside is that building the system does not require
you to predefine and automate every detail. It also sidesteps some
issues involving poorly packaged drivers or applications that are
difficult or impossible to install in a silent or automated fashion.
The best way to capture the system to an image is to use an image capture CD and the following steps:
1. | Install Windows—Manually
install Windows, updates, and any desired applications and drivers, and
apply every last tweak to a reference system. The system should also
conform to the following rules:
Not joined to a domain. Does not have the ConfigMgr client installed. This is not a strict requirement but is a best practice. Has a blank local Administrator password. Windows
XP systems require a folder named sysprep in the root of the system
partition with the appropriate versions of sysprep.exe and setupcl.exe.
You can also include a sysprep.inf file in the folder, but this is not
required because you can inject one later or ConfigMgr builds one for
you during deployment.
|
2. | Create the capture media—Right-click
the Task Sequences node under Operating System Deployment in the
ConfigMgr console and choose Create Task Sequence Media. This launches
the Task Sequence Media Wizard, shown in Figure 3, which creates either a bootable USB drive or ISO image (which you can burn to CD or DVD) from a boot image.
|
3. | Run Capture—Insert
the capture media into the reference system and from within Windows;
autorun the media to initiate the capture wizard. The wizard checks for
the existence of the sysprep folder and files and then prompts you for a
UNC path to create the image at and credentials to access the UNC.
|
It is also possible to boot into a custom version of Windows PE and manually initiate ImageX:
1. | Create a bootable Windows PE Image—See Microsoft’s walk-through at http://technet.microsoft.com/en-us/library/cc766385.aspx for complete details. Be sure to include ImageX in the image.
|
2. | Install Windows—Install Windows according to the Install Windows step (step 1) in the previous procedure.
|
3. | Sysprep Windows—Run Sysprep from the command line with the following options: sysprep –mini –quiet –reseal –reboot.
|
4. | Boot PE—Boot the reference system into Windows PE using the image you created.
|
5. | Map Network Drive—From the PE command line, map a drive letter to the destination share, for example, net use Z: \\<computer>\<share> and enter the proper credentials when prompted.
|
6. | Run ImageX—From the same PE command prompt, run ImageX to capture the image using the following syntax: imagex /capture [image_path] [image_file] ["name"] <"description">, for example, imagex /capture c: z:\MyImage.wim "My Image Name".
|
Either method creates a WIM file containing an
image of your reference system, which is fully compatible and usable by
OSD, which also supports images created for use with WDS because they
share the same WIM format. OSD does not support RIS images.
3. Image Deployment
Deploying an image is similar in nature to
building and capturing one. You start by creating a new task sequence
using the New Task Sequence Wizard. Instead of choosing Build and
capture a reference operating system image, choose Install an existing
image package from the New Task Sequence Wizard. The resulting task
sequence contains steps for capturing the current user state, restarting
the system in Windows PE, preparing the system, deploying an image,
deploying additional applications, and finally restoring user data. Figure 4 shows the task sequence produced by running the wizard.
As with the build and capture choice from the
New Task Sequence Wizard, there are a series of prerequisite items to
create and set up before the wizard can complete successfully.
1. | Create an Operating System Image. The deployment uses a WIM file that contains a Syspreped operating system image. This WIM file is one that was previously captured and imported. Simply right-click Operating System Images and choose New to start the New Image Wizard.
Tip: Using WIM Files
Do not use a WIM file directly from a Vista
or Windows Server 2008 DVD without first deploying and capturing it as a
new image using a Build and Capture task sequence. These WIMs are
designed to be used only with the accompanying setup programs. If used
directly, among other things, the default Vista WIM image installs to
the D: drive instead of the typical C: drive.
|
2. | Create software distribution packages.
The only package the basic Image Deployment task sequence requires is
the ConfigMgr Client package, which you should have already created when
creating the Build and Capture task sequence.
If you use this task sequence to capture or restore user state
using the built-in user state related tasks, you need a package
containing the USMT files. The best way to create the user state
migration tools package is to install USMT on the site system and
specify the installation path as the source path for the package,
typically %ProgramFiles%\USMT301 for
USMT version 3.01. The package does not need programs (nor does the
ConfigMgr package); it simply makes the files available for use by the
task sequence.
Note: Versions of USMT
Microsoft provides both 64-bit and 32-bit
versions of USMT for download and installation. To avoid creating
multiple task sequences or adding other complexities to a single task
sequence, use the 32-bit version of USMT even if you deploy to or
capture from 64-bit Windows systems. The tools perform the exact same
task, and the 32-bit version runs on 64-bit Windows; however, the
reverse is not true.
One other twist is that the 32-bit version
does not install on 64-bit Windows, so if your site systems run on
64-bit Windows, install the 32-bit version on an available 32-bit system
and copy the entire USMT301 program files folder to your source
repository to create the package.
Because Windows is already installed, the
only unattended setup file that can be used is a sysprep.inf for
Windows XP or unattend.xml for Windows Vista. This file, if present in
the package specified, is updated to include the information specified
in the task sequence (product key, time zone, domain, and so on) and
used for the mini-setup process.
The New Task Sequence Wizard prompts you for each of the package
types except for the unattended files package; edit the task sequence to
add this package after the wizard completes.
|
3. | Import drivers and create driver packages.
Although not strictly required, adding drivers to a deployment is
highly desirable and is the primary method to make your images hardware
agnostic.
|
You can now launch the New Task Sequence Wizard
using the Task Sequences context menu and create an Image Deployment
task sequence. The wizard prompts for the following information.
Task Sequence Name— This entry is purely aesthetic.
Boot image— This is the WinPE image used to deliver the task sequence.
Operating System Image— This is the previously captured operating system image.
Product key— Not required if using Vista because you can supply this after the installation completes using a KMS or manually.
Administrator Account Status— You can set the local Administrator account as disabled by default.
Join a workgroup or domain— If you specify a domain, you must supply credentials.
Software distribution client package— This is the ConfigMgr Client installation package previously created.
User state migration options—
These include whether to capture user state and the package that
contains the USMT files, and whether to capture current network and
Windows settings.
Software updates installation— Options are all, mandatory only, or none.
Software deployment packages— Packages to layer on top of those already included in the image.
After the wizard creates the task sequence, you
want to edit the task sequence to ensure it fits your needs. Typically,
the first thing to change (as with the Build and Capture task sequence
previously covered in the “Creating the Task Sequence”
section) is the format type for the partition. In addition, if you want
to use an XP-only unattended sysprep.inf file, you should edit the
Apply Operating System task to specify which package contains this file.
Depending on a few factors such as destination
hardware speed, network speed, image size, user state size, and
application installation time, it can take from 10 to 60 minutes (or
potentially longer) to deploy an image and have a system up and running
ready for the end user. This of course happens in an efficient, zero or
limited touch manner.
User State Migration
“Where’s my data?” “Where’s the spreadsheet I
worked 20 hours on for the CEO?” “Where’s my irreplaceable wallpaper of
my darling grandson Johnny hitting the game-winning homerun?” These are
the last questions any helpdesk technician or system administrator wants
to hear, especially right after a migration.
User data is the reason that we all exist, and
we want to handle it with special care. Adding users’ settings to their
data gives us the users’ state. A major goal in any system migration is
to prevent users from losing any productive time because they do not
have or cannot find their data. Although it is definitely a best
practice to have users store their data in a central location, such as a
server-based file share or a SharePoint site, this might not be
possible for a variety of reasons because your organization might not
enforce a centralized storage model. Additionally, central data storage
schemes tend to overlook things such as wallpaper, Outlook settings and
configuration, and desktop shortcuts, letting these remain local to each
system. When performing a migration, you want to capture and restore
the users’ state to their new system as seamlessly as possible.
In Configuration Manager 2007, the data archive
produced by USMT can be stored locally, useful (but not required) for an
in-place migration, or stored on a state migration point. The main
benefits of local storage are that it minimizes network traffic and
eliminates the need for server-based storage. This allows potentially
quicker migrations and indefinite storage of the data archive.
However, in the case of a side-by-side
migration, you must use the state migration point. This is essentially a
secure file share for storing the USMT-produced archive. ConfigMgr
encrypts and tags archives placed here for a specific destination
system, using a computer association. If you did not create a computer
association before running USMT, USMT creates it specifying the same
destination and source systems. ConfigMgr automatically purges the
archives placed on a state migration point, based on the settings of the
state migration point.
Tip: Capturing User State
You cannot capture user or system state from a
system if you boot the system from PXE or directly from bootable media.
Both of these methods boot the system directly into Windows PE and not
into the existing operating system. This means USMT cannot gather the
existing state of the system and its users. The next version of USMT,
dubbed USMT 2010, is slated to have this capability, but for now, you
must make do without.
The best part about state migration in ConfigMgr
is that it is simple and straightforward to set up. The only overhead
truly incurred by state migration is storage space, and this is
automatically maintained and cleaned. By default, the built-in wizard to
create Image Deployment task sequences adds the steps to provision
space on the state migration point, capturing user state data and
transferring it to the state migration point. It also adds the necessary
tasks to retrieve the state from the state migration point and apply it
to the destination system.
This default behavior is perfect for an in-place migration and works for a side-by-side migration with several small additions:
- Create a
computer association to specify the source and destination systems by
choosing New -> Computer Association from the Computer Association
context-menu.
If no association exists when storage is provisioned from the
state migration point, a computer association is created with the same
source and destination as the system being imaged—this is the desired
scenario for an in-place migration. Alternatively, for a side-by-side
migration, you must manually create a computer association before
capturing the user state data; this computer association configures a
pre-existing source system and a new or different destination system.
- You
also create a new task sequence to capture the user state data. You can
create this abbreviated task sequence using the New Task Sequence
Wizard, choosing to create either a custom task sequence or an Install
an existing image package task sequence, and deleting everything except
the three relevant capture state tasks.
Here are the four tasks associated with user state:
Request State Store
Release State Store
Capture User State
Restore User State
The Request State Store and Release State Store
are always used, regardless of whether you capture or restore the user
state. These tasks deal with the storage space on the state migration
point where the user state data is stored.
The Release State Store task has no options, and
the main option for the Request State Store task is determining whether
user state is retrieved or stored. This task also either creates or
retrieves the encryption key that protects the user state data; the
encryption key is stored along with and is specific to a single computer
association. As stated earlier in this section, this computer
association is created automatically with the same source and
destination system if the association does not already exist during a
user state capture. If you perform a user state restoration and no
computer association exists, the user state tasks are gracefully
skipped.
The Capture User State
and Restore User State tasks do exactly as their names imply. The two
main configuration options for both of these tasks are a required
package containing the USMT files and an optional package containing the
custom USMT configuration files. Neither package requires any program
files because they both just make the necessary files available for
ConfigMgr to use.
