Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

System Center Configuration Manager 2007 : Operating System Install Packages and Image Packages (part 2) - Manual Image Creation, Image Deployment

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
2/13/2013 4:00:07 PM

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.

Figure 3. The Task Sequence Media wizard

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.

Figure 4. A Default Image Deployment Task Sequence


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.

As with the Build and Capture task sequence, optional packages include software distribution packages and a package for the unattended setup files. Software distribution packages in Image Deployment task sequences are delivered after the image is applied to the system. This includes any applications not part of the common baseline of applications already included in the image, or updates or customizations to applications included in the baseline image.

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. 

Other -----------------
- System Center Configuration Manager 2007 : Operating System Deployment - Computer Associations
- Microsoft Exchange Server 2007 : Load Balancing in Exchange Server 2007
- Microsoft Exchange Server 2007 : Managing a Windows Server 2003 Cluster
- BizTalk Server 2009 : Editing and Resubmitting Suspended Messages (part 2) - Pseudo-Walkthrough to Perform Edits and Resubmits
- BizTalk Server 2009 : Editing and Resubmitting Suspended Messages (part 1) - Sample Flows for Edit and Resubmit
- BizTalk Server 2009 : Building a Resequencing Aggregator
- Windows Server 2003 on HP ProLiant Servers : Security Planning and Design (part 3) - Microsoft Software Update Service and Windows Update Service
- Windows Server 2003 on HP ProLiant Servers : Security Planning and Design (part 2) - Account Lockout
- Windows Server 2003 on HP ProLiant Servers : Security Planning and Design (part 1)
- Developing with SharePoint 2010 (part 4) - Developer Toolbar
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server