Lenovo R400 User Manual

ImageUltra Builder Ver sion 4.01

User Guid e

Date: February 18, 2009

ImageUltra Builder Ver sion 4.0 1

User Guid e

Date: February 18, 2009

Note

Before using this information and the product it supports, be sure to read “Notices,” on page 199.

Third Edition (February 2009)

LENOVO products, data, computer software, and services have been developed exclusively at private expense and are sold to governmental entities as commercial items as defined by 48 C.F.R. 2.101 with limited and restricted rights to use, reproduction and disclosure.

LIMITED AND RESTRICTED RIGHTS NOTICE: If products, data, computer software, or services are delivered pursuant a General Services Administration ″GSA″ contract, use, reproduction, or disclosure is subject to restrictions set forth in Contract No. GS-35F-05925.

Preface . . . . . . . . . . . . . . vii

Who should read this guide . . . . . . . . viii

Web page references . . . . . . . . . . . viii

New features in ImageUltra Builder . . . . . . viii

Features added to versions 2.0 and 2.01 . . . viii

Features added to version 2.2 . . . . . . .ix

Features added to version 3.0 . . . . . . . .x

Features added to version 3.1 . . . . . . . .x

Features of version 4.0 . . . . . . . . . .xi

Back up and Restore Application . . . . . .xi

Chapter 1. ImageUltra Builder

capabilities . . . . . . . . . . . . .1

Understanding images . . . . . . . . . . .1

Definition of a Smart Image . . . . . . . . .2

Staging areas . . . . . . . . . . . . .2

Types of images supported by a Smart Image . .3

The use and importance of Sysprep . . . . . . .4

Which image types are best for you? . . . . . .4

Ultra-Portable Image . . . . . . . . . . .4

Portable-Sysprep Image . . . . . . . . . .7

Hardware-Specific Image . . . . . . . . .8

Summary of image types . . . . . . . . .9

Chapter 2. An overview of the image

process . . . . . . . . . . . . . .11

The five basic steps to develop an image . . . .14

Importing pre-existing maps and modules . . . .14

Importing maps and modules from a service

partition or HPA . . . . . . . . . . .14

Importing maps and modules from repositories,

folders, and CDs . . . . . . . . . . .15

Building a module . . . . . . . . . . . .15

Building a driver module, application module, or

add-on operating-system module . . . . . .16

Creating a base operating-system module . . .17

Creating a partitioning module . . . . . . .19

Creating or modifying base maps and driver maps 20

Base maps . . . . . . . . . . . . . .22

Driver maps . . . . . . . . . . . . .23

Defining the deployment and installation method 23

Defining service-partition behavior . . . . .24

Enabling the network-sync function . . . . .25

Defining users and administrators . . . . . .25

Defining user information . . . . . . . .26

Deploying Smart Images to target computers . . .26 Installing images on the target computer after

deployment . . . . . . . . . . . . . .29

Performing a direct-network installation . . . . .30

Advanced functions . . . . . . . . . . .30

Filters . . . . . . . . . . . . . . .31

Utilities . . . . . . . . . . . . . . .31

Chapter 3. Staging-area behavior and

logic . . . . . . . . . . . . . . . .33

Staging areas details . . . . . . . . . . .33

The service partition . . . . . . . . . .33

The network-staging folder . . . . . . . .35

Deployment and installation overview . . . . .35

Standard network-deployment process with local

installation . . . . . . . . . . . . .35

CD, DVD, USB key, or USB hard disk drive

distribution . . . . . . . . . . . . .36

Direct-network installation . . . . . . . .37

ImageUltra Builder relationships with the Hidden

Protected Area (HPA) . . . . . . . . . . .38

What is a Hidden Protected Area? . . . . . .38

Recovery impacts . . . . . . . . . . .39

ImageUltra Builder relationships with the Rescue

and Recovery product . . . . . . . . . .39

Security dependencies . . . . . . . . . .41

Staging-area logic . . . . . . . . . . . .41

Chapter 4. Installing the ImageUltra

Builder program . . . . . . . . . . .47

Minimum requirements . . . . . . . . . .47

ImageUltra Builder server computers . . . . .47

ImageUltra Builder console computers . . . .47

ImageUltra Builder target computers . . . . .48

Prerequisites . . . . . . . . . . . . . .48

Installation considerations . . . . . . . . .49

Limitations . . . . . . . . . . . . . .50

Installing the ImageUltra Builder 4.0 program . . .50

Installing an ImageUltra Builder console . . . .50

Installing an ImageUltra Builder server . . . .51

Accessing the ImageUltra Builder server . . . .52

Installing an ImageUltra Builder console and

server . . . . . . . . . . . . . . .52

Changing the default administration password 53 Upgrading from a previous version of ImageUltra

Builder . . . . . . . . . . . . . . . .53

Getting help after installation . . . . . . . .54

Chapter 5. Working with the ImageUltra

Builder interface . . . . . . . . . .55

Conventions used within the interface . . . . .55

Module repository . . . . . . . . . . . .60

Working with repositories . . . . . . . .60

Exporting maps and modules . . . . . . .61

The Repository window . . . . . . . . . .62

Entries and icons . . . . . . . . . . .64

Manipulating entries . . . . . . . . . .64

Searching for specific maps and modules . . .65

Map windows . . . . . . . . . . . . .66

Map Settings window . . . . . . . . . . .66

Base Map Appearance Under Windows PE . . .66

Base-map settings . . . . . . . . . . .67

Driver-map settings . . . . . . . . . .70

Menu Item Properties window . . . . . . . .71

Menu Link Properties window . . . . . . . .73

Module windows . . . . . . . . . . . .73

Modifying module attributes and map settings . .73

Tools . . . . . . . . . . . . . . . .74

Repository tools . . . . . . . . . . . .74

Map tools . . . . . . . . . . . . . .76

Chapter 6. Map construction overview 77

Creating a base-map tree structure . . . . . . .77

Inserting menu items in a base map . . . . .77

Inserting modules in a base map . . . . . .79

Special considerations for I386 base

operating-system modules . . . . . . . .82

Using utilities in a base map . . . . . . .85

Using filters in a base map . . . . . . . .88

Using links in a base map . . . . . . . .91

Defining user information in a base map . . .92

Controlling the network-sync function . . . .94

Controlling the behavior of the service partition 95

Using a partitioning module in a base map . . .96

Simple and complex base maps . . . . . . 101

Adding a hidden system menu in a base map 103

Customizing module behavior within a base

map . . . . . . . . . . . . . . . 104

Special considerations for the Rescue and

Recovery product . . . . . . . . . . . 104

Previewing your maps . . . . . . . . . 105

Creating a device-driver map tree structure . . . 105

Inserting menu items in a driver map . . . . 106

Inserting modules in a driver map . . . . . 106

Using filters in a driver map . . . . . . . 107

Using variables; an advanced base-map function 108

Setting a variable to contain a hard coded value 109

Setting conditions to determine menu items

displayed during the installation process . . .110

Referencing text within menu items and

sub-menu item titles . . . . . . . . . . 111

Setting a variable to prompt the user for a

specific value during the installation process . .112

Setting a variable so that a prompted value is

passed as a parameter for a utility or filter . .113

Excluding modules from a map . . . . . . .114

Chapter 7. Creating maps . . . . . .115

Creating and modifying base maps . . . . . .115

Creating a new base map . . . . . . . .115

Creating a new base map based on an existing

base map . . . . . . . . . . . . . .116

Adding menu items to a base map . . . . .116

Adding operating-system modules to a base

map . . . . . . . . . . . . . . .117

Adding application modules to a base map . .118

Replacing modules in a base map . . . . .118

Customizing module behavior within a base

map . . . . . . . . . . . . . . .119

Working with base-map settings and menu-item

properties . . . . . . . . . . . . .119

Creating and modifying driver maps . . . . . 127

Creating a new driver map . . . . . . . . 128

Creating a new driver map based on an existing

driver map . . . . . . . . . . . . . 128

Adding menu items to a driver map . . . . 129

Adding device-driver modules to a driver map 129

Replacing modules in a driver map . . . . . 130

Working with driver-map settings and

menu-item properties . . . . . . . . . . 130

Chapter 8. Preparing source files for

modules . . . . . . . . . . . . . 135

Creating source operating-system images . . . . 135

Ultra-Portable Image source files . . . . . . 135

Required third-party tools . . . . . . . . 140

Creating a Portable-Sysprep Image . . . . . 142

Creating a Hardware-Specific Image . . . . . 146

Preparing source files for application modules and

add-on operating-system modules . . . . . . 149

Preparing for a silent install . . . . . . . 149

Adding mini-applications . . . . . . . . 150

Making files accessible to the ImageUltra

Builder console . . . . . . . . . . . . 150

After the files are prepared . . . . . . . . 150

Setting the attributes for a new application

module . . . . . . . . . . . . . . 151

Setting the attributes based on an existing

application module . . . . . . . . . . 153

Setting the attributes for a new add-on

operating-system module . . . . . . . . 154

Setting the attributes based on an existing

add-on operating-system module . . . . . . 156

Preparing source files for a partitioning module 156 Preparing source files for a device-driver module 158

Adding mini-applications . . . . . . . . 158

Requirements for preparing device-driver files

for modules . . . . . . . . . . . . . 158

Setting the attributes for a new device-driver

module . . . . . . . . . . . . . . 159

Setting the attributes based on an existing

device-driver module . . . . . . . . . . 161

Preparing source files for utility modules files . . 161

Setting the attributes for a new utility module 162

Setting the attributes based on an existing utility

module . . . . . . . . . . . . . . 163

Preparing source files for filter modules files . . . 163

Setting the attributes for a new filter module 164

Setting the attributes based on an existing filter

module . . . . . . . . . . . . . . 165

Building a new module . . . . . . . . . . 165

Chapter 9. Specifying the

module-installation order . . . . . . 167

The installation-order process . . . . . . . . 168

Add-on operating-system modules, application

modules, and device-driver modules . . . . 168

Partitioning modules . . . . . . . . . . 169

Modifying the install hook . . . . . . . . . 169

Modifying the install slot . . . . . . . . . 170

Modifying the install sequence with a base map 170

Installation-order tips and notes . . . . . . . 172

iv ImageUltra Builder Version 4.01: User Guide

Chapter 10. Using ImageUltra Builder

and Windows Vista . . . . . . . . . 173

Operating system differences between Windows XP

and Windows Vista . . . . . . . . . . . 173

Windows Vista offline servicing module . . . . 173

Windows Vista base operating-system module . . 174 Creating a Vista-based Ultra-Portable Image . . . 174

Staging area details . . . . . . . . . . . 175

Using the UNATTEND.XML Module . . . . 177

Chapter 11. Getting help and support 181

Using the documentation and help system . . . 181

Using the We b . . . . . . . . . . . . . 181

Contacting an ImageUltra Builder technical expert 182

Chapter 12. Dealing with exceptions 183

Application module exceptions . . . . . . . 183

Device driver exceptions . . . . . . . . . 185

Making allowances for modules that require a

reboot . . . . . . . . . . . . . . . . 186

Editing unique scripts . . . . . . . . . . 187

Including the ThinkVantage Rescue and Recovery

product . . . . . . . . . . . . . . . 187

Controlling write-access to your repository during

a direct-network install . . . . . . . . . . 189

Chapter 13. Debugging problems . . . 191

The ImageUltra Builder image-installation process 191

Finding debug data in the target computer user

partition . . . . . . . . . . . . . . . 191

Finding debug data in the service partition or

network-staging folder . . . . . . . . . . 191

Monitoring the installation . . . . . . . . . 192

Splash Utility . . . . . . . . . . . . . 192

Sending debug data to the technical support team 196

Drive letter limitations and the use of variables 197

F11 key does not work on some brands after

installation . . . . . . . . . . . . . . 198

Appendix. Notices . . . . . . . . . 199

Trademarks . . . . . . . . . . . . . . 200

Index . . . . . . . . . . . . . . . 201

Contents v

vi ImageUltra Builder Version 4.01: User Guide

Preface

This guide has three purposes:

v To help you understand the concepts behind building, deploying, and installing

Smart Images using the ImageUltra™ Builder program.

v To guide you through the ImageUltra Builder installation process.

v To supplement the ImageUltra Builder help system, which provides detailed

step-by-step procedures for the tasks associated with the ImageUltra Builder program.

installing or using the ImageUltra Builder program, make sure that you are

Before familiar with the information in Chapter 1, “ImageUltra Builder capabilities,” on page 1 and Chapter 2, “An overview of the image process,” on page 11.

This guide is organized as follows:

Chapter 1, “ImageUltra Builder capabilities,” on page 1 contains an overview of the concepts and functions of the ImageUltra Builder program.

Chapter 2, “An overview of the image process,” on page 11 contains an introduction to the image-building process using the ImageUltra Builder program.

Chapter 3, “Staging-area behavior and logic,” on page 33 contains information about the staging areas used for deployment and installation and the logic used by the ImageUltra Builder program to adapt to various conditions on the target computer that affect the staging area selected.

Chapter 4, “Installing the ImageUltra Builder program,” on page 47 contains installation instructions for the ImageUltra Builder program, as well as prerequisites, limitations, and considerations that you need to understand before you install the program.

Chapter 5, “Working with the ImageUltra Builder interface,” on page 55 introduces you to the various windows and conventions used in the ImageUltra Builder interface.

Chapter 6, “Map construction overview,” on page 77 focuses on the concepts behind creating a map tree structure and setting some of the map attributes.

Chapter 7, “Creating maps,” on page 115 provides step-by-step instructions for creating base maps and driver maps.

Chapter 8, “Preparing source files for modules,” on page 135 provides step-by-step instructions for preparing the source files, creating repository entries, setting attributes, and building the module.

Chapter 9, “Specifying the module-installation order,” on page 167 provides information about the various methods used to control the order in which modules are installed.

Chapter 10, “Using ImageUltra Builder and Windows Vista,” on page 173 provides information about using ImageUltra Builder and Windows Vista®.

Chapter 11, “Getting help and support,” on page 181 contains instructions about getting help and support for the ImageUltra Builder program.

Chapter 12, “Dealing with exceptions,” on page 183 contains helpful information about working with special cases that affect the image building process.

Chapter 13, “Debugging problems,” on page 191describes ImageUltra Builder’s tools for debugging and best practices to use when debugging specific problems.

“Notices,” on page 199 contains legal notices and trademark information.

Who should read this guide

This guide is intended for information technology professionals who do the following:

v Set up and maintain computer images

v Deploy images by CD or across a network

Web page references

This guide provides Web-page addresses for additional information. Web-page addresses are subject to change. If you find that a Web-page address does not work, go to the main We b page for the company being referenced (for example, http://www.lenovo.com) and then search for the appropriate term or phrase (for example, ImageUltra Builder).

New features in ImageUltra Builder

Features added to versions 2.0 and 2.01

The following features were added to ImageUltra Builder versions 2.0 and 2.01

v Redesigned Repository window: The Repository window has been redesigned to

help you organize, categorize, and sort large numbers of maps and modules.

v Repository search feature: A repository search feature has been added to help

you find specific maps and modules. The search engine enables you to pick predefined values or use free-form text to search for strings or phrases associated with map settings or module attributes. To help facilitate the free-form text search, a comment field has been added to the module attributes General tab and the map settings General tab. An advanced repository-search feature enables you to find maps or modules that share a common characteristic. For example, you can find all modules not used in any map or all maps that use a specific module.

v Export Wizard: An Export Wizard has been added to enable you to archive

maps and modules in a folder outside of the repository. The archived maps and modules can be restored to a repository, if needed, through the use of the Import Wizard.

v Import Wizard: An Import Wizard replaces the import process and provides the

extended capabilities of importing individual modules and maps to the repository from a variety of sources. When importing maps and modules from a source computer, instead of creating and using import media, you simply install the ImageUltra Builder program on the source computer, connect to the target repository, select Import from the Main window menu bar, and then follow the instructions provided by the Import Wizard.

viii ImageUltra Builder Version 4.01: User Guide

v Deploy Wizard: A Deploy Wizard simplifies the process of creating distribution

CDs, and network-deployment CDs.

v Redesigned Map window: The Map window has been redesigned so you can

select and manipulate multiple items in a map.

v Variable support: Support for variables in the menu system has been added to

allow dynamic flow processing and increased flexibility based on user responses during the image-installation process.

v Enhanced control of the module-installation sequence: You can now control the

installation sequence and execution of individual modules.

v Customized behavior for a module in a map: You can now alter the behavior of

a common module on a map-by-map basis through a new Customization field.

v Additional menu-customization capabilities: You now have better control over

the appearance and behavior of the installation menus. You can select background colors, set margins, do window shadowing, enable and disable the Ctrl+Alt+Del key sequence while menus are being viewed, define text to be used in the status line, specify a key to exit the current menu, define a key for returning to a previous menu, define a keyword that takes the user to a hidden system menu, and more.

v Module password protection: Yo u can password protect modules so that only

ImageUltra Builder processes have access to the source files inside of a module.

v Custom service-partition size: In the base map, you can now specify the size that

you want the service partition to be after the image has been deployed and installed. This feature is useful to streamline the Rapid Restore® PC installation processes. By specifying extra room in the service partition, you can eliminate the time required by the Rapid Restore installation process to rearrange data and resize the service partition to accommodate the backup files.

v Support for the Hidden Protected Area (HPA): Many new ThinkPad® and

ThinkCentre® computers use an HPA for recovery and diagnostic purposes instead of the service partition used by their predecessors. The HPA provides increased security, protection, and recovery capabilities. The ImageUltra Builder

2.0 program supports importing maps, modules, and containers from an HPA and sourcing device-driver modules from an HPA during the installation process when a driver map is not used. The import and deployment support for service partitions also remains.

v Direct-network installation to the C partition: This feature enables you to deploy

and install an image from the network directly to the C partition without having to copy the maps and modules to a service partition.

Features added to version 2.2

The following features have been added to ImageUltra Builder version 2.2:

v Enhancements to the Deploy Wizard: Yo u can now use the Deploy Wizard to

create distribution discs on CD or DVD media, network-deployment discs on CD or DVD media, and ISO images without third-party CD-burning software. Another new feature eliminates the need to create a network-deployment diskette before you create a network-deployment CD. In addition, you can optionally set a static IP address for the target computer instead of depending on one being assigned by a DHCP server.

v Network-deployment CDs now support multiple network cards.

v Enhanced flexibility in sequencing module installation order: The module

Options tab now supports up to 9999 install slots for greater control of the module-installation sequence.

Preface ix

v New module templates: Templates are provided for the new I386 module and

the unattend.txt module. These templates are in-built modules that can be modified, imported, or exported. Or if you prefer, you can create your own template modules.

v Enhanced flexibility in maps: You can now create menu items that exclude

modules that were added to the installation list by previous menu selections.

v Enhanced debugging capabilities: A log is now created on the target computer

during the deployment process that indicates when a module installation process is started and completed as well as the result of the filter expressions used in the menu items.

Features added to version 3.0

ImageUltra Builder 3.0 has implemented significant changes on how base maps are displayed at the target computer during deployment. These changes are a result of ImageUltra Builder 3.0 using the Windows® Preinstallation Environment (PE) as its deployment environment instead of the DOS operating system used by previous versions. Under DOS, a base map was displayed to users in full-screen, console-like mode. Now, through Windows PE, base maps are presented to users within an actual window.

The following features were added to ImageUltra Builder version 3.0:

v There are new and updated map settings and property tabs within The

ImageUltra Builder 3.0 Graphical User Interface (GUI) menu-driven application, which control the appearance of deployment and installation screens at the target computer.

v Improved Map Menu Program: The System Menu Keyword field has been

moved from the Menu Appearance tab to the General tab. Since this only applies to base maps, it is hidden when the settings dialog applies to a driver map.

v The use of IBM® Cloudscape®, a client-server, object-relational database system,

instead of the previous file-based database system.

v The use of a new boot loader on the ImageUltra deploy media that allows the

install process to continue without requiring the user to remove or deploy media.

v The use of a splash window. The splash window is used to display the contents

of a log file. A message-box dialog displays messages to users as it moves around the screen.

v The new Migrate Repository Wizard that takes users through the different stages

to migrate from a previous version of an ImageUltra repository.

If you are upgrading from a previous version of ImageUltra you need to know the following:

v Portable Sysprep modules need to be rebuilt in ImageUltra Builder 3.0 format.

v Ultra-Portable base maps need to be redesigned to follow the ImageUltra Builder

3.0 format.

Features added to version 3.1

The following features were added to ImageUltra Builder version 3.1:

v The use of sequencing modules in driver maps.

v The Map Report includes information on customer first boot installation point.

v Updates for replacing modules.

x ImageUltra Builder Version 4.01: User Guide

v Updates to the splash window. Users can now press Shift+Ctrl+C to bring up a

command prompt window.

v The use of a splash window. The splash window is used to display the contents

of a log file. A message-box dialog displays messages to users as it moves around the screen.

v The new Migrate Repository Wizard that takes users through the different stages

to migrate from a previous version of an ImageUltra repository.

If you are upgrading from a previous version of ImageUltra you need to know the following:

v Portable Sysprep modules need to be rebuilt in ImageUltra Builder 3.1 format.

v Ultra-Portable base maps need to be redesigned to follow the ImageUltra Builder

3.1 format.

Features of version 4.0

The following are features of ImageUltra Builder version 4.0:

v Support for Windows Vista.

v Support for USB keys:

– Burning images to a USB key.

– Deploying images from a USB key.

– Deploying images from a USB hard drive.

– Back up and Restore Application.

Back up and Restore Application

The Back up and Restore application enables you to back up and restore the server databases. The application can be run by using the wizard, or by using a script file. To start the wizard, click Start, then click Programs, then ThinkVantage®, then Back up and Restore. Click Help to view the relevant help topic. To use a script file, go to the command prompt and call C:\Program Files\ThinkVantage\ ImageUltra Builder 4.0\iurbr.ini. Pass in the script file below as a parameter.

Required fields:

[settings]

Operation = Backup or Restore

Backup = c:\MyBackup

Silent = Yes

Log = c:\MyBackup

v Operation key is the back up or restore option.

v Backup key is the full path name where the data will be stored.

v Store key is the full path name of the database that was previously backed up.

For example, C:\MyBackup\2007-10-08-AT-11-57-20-AM.ZIP.

v Silent key is the flag to run the application silently. The flag can be Yes or No. It

is an optional flag. The default is No (off).

v Log key is the location of the log file. It is an optional key. If this key is not set,

the log file will be created in the same location where the iurbr.exe is installed.

Preface xi

xii ImageUltra Builder Version 4.01: User Guide

Chapter 1. ImageUltra Builder capabilities

The ImageUltra Builder program provides new methods of creating, deploying, and installing custom images. This chapter provides information to help you understand the concept of building images and the various types of images that the ImageUltra Builder program supports.

Understanding images

An image consists of several components: an operating system, applications, device drivers, and other related files needed to successfully run a computer. In most cases, information technology (IT) departments within corporations or system integrators create images on source computers, extract the images and store them in a central location. Then, they deploy the images to multiple computers either across a network or from a set of image CDs. This enables an IT department to develop standardized images and control the versions of software and device drivers used throughout the company.

Developing and deploying images in this way ensures that every computer within a company maintains a high level of image consistency. However, because images created by this method are hardware dependent, a significant amount of time is spent creating, testing, and transferring images from multiple source (donor) computers to accommodate various hardware configurations and variations of supported software. In many cases, in order to accommodate specific software requirements, a base image is deployed and specific application programs are added manually on a system-by-system basis after the image has been installed.

As a result, IT departments often have multiple images to manage. Whenever a change is required to accommodate new hardware, an operating-system update, a device-driver update, an additional language, or a new or changed application program, many images must be rebuilt.

The major challenges most IT departments face are as follows:

v Reducing the amount of time spent creating and testing images.

v Finding a way to build and deploy images that provides increased flexibility to

meet specific software requirements that might vary from department to department.

v Finding a way to build and deploy images across a wider range of hardware.

v Reducing or minimizing the total number of images that have to be maintained.

purpose of the ImageUltra Builder program is to provide IT departments with

The the tools needed to develop, deploy, install, and maintain a variety of images efficiently. Through new tools and techniques, the ImageUltra Builder program enables you to break down images into reusable subcomponents (called modules) and use maps to construct Smart Images that can be deployed across a broad range of hardware platforms.

Definition of a Smart Image

The ImageUltra Builder program enables you to store a variety of image-related files as reusable modules in a repository. Typically, there is a module for each operating system, application, and device driver. These modules are organized by

maps to meet the needs of specific users, groups, or an entire enterprise. A single base map can contain multiple operating systems and applications, as well as

variations based on language. A single driver map can contain device drivers for a single hardware platform, or through the use of filters, device drivers for a variety of hardware platforms.

Delivering the maps and modules to a target computer involves two steps: deployment and installation. At the beginning of the deployment process, the installer selects which base map and driver map to use. The selected maps and the modules defined within the maps are copied to a staging area. The compilation of maps and the modules defined within the maps is called a Smart Image.

A Smart Image has the following characteristics:

v It is the source from which a specific image is installed on the target computer.

v It provides a menu system during the installation phase. The person controlling

the installation process makes selections from the menu system to define the content of the image to be installed. The menu entries are defined in a base map.

v A single Smart Image can contain multiple images or components that make up

a variety of images.

v If desired, a Smart Image can reside on a target computer after installation and

be used for console-side recovery without any dependencies on an active network connection.

v Smart Images can be developed to provide varying degrees of portability across

different hardware platforms. Portability is the degree in which you can use a single image for different types of computers.

Staging areas

A staging area is a workspace used during deployment and installation. It is where certain modules defined by a map are unpacked, where ImageUltra Builder installation files are stored, and where installation logs are created. The ImageUltra Builder program can use two types of staging areas:

v Service partition: The service partition is a hidden primary partition that is

protected against normal, end-user read and write operations. This partition is a standard Lenovo® factory-installed feature on many Lenovo ThinkPad, NetVista®, and ThinkCentre computers. As shipped from the factory, the service partition provides built-in recovery and diagnostic capabilities. When a pre-existing service partition is used in conjunction with the ImageUltra Builder program, the deployment phase deletes the factory-installed recovery modules and replaces them with appropriate modules and maps for the image being deployed. If a service partition does not already exist, the ImageUltra Builder program creates one, if needed, as part of the deployment process. After the deployment is complete, the person controlling the installation process (end user or IT professional) can initiate the installation process from the service partition immediately after deployment or at any point in the future without any dependencies on a network connection.

v Network-staging folder: This temporary staging area is for a direct-network

installation only. A direct-network installation combines the deployment phase

and installation phase into a single operation, which in almost all cases results in

2 ImageUltra Builder Version 4.01: User Guide

a faster overall deployment/installation cycle. Speed is affected by the amount of network traffic and certain map settings.

During the deployment phase, a unique network staging-folder is created on the network for the target computer. The person controlling the direct-network installation (typically an IT professional) first selects the base map and driver map. Then, only those modules required to control the installation of the selected maps are obtained from the repository and unpacked into the network-staging folder. When the required modules are unpacked, the person controlling the installation makes selections from the installation menu system to define the specific image required for the target computer. When the image is defined, installation to the target computer automatically begins. All modules that are required to create the image content are obtained from the repository, unpacked dynamically to the C partition of the target computer, and run through a series of setup programs to create the image on the target computer. When the installation is complete, the network-staging folder is deleted from the network. Depending on the settings in the base map being used, any of the following actions can occur at the end of the installation process:

– Pre-existing recovery files in the service partition can be updated to contain

the complete Smart Image, thereby providing console-side recovery for any image contained within the Smart Image

– Pre-existing recovery files in the service partition can be updated to contain

the maps and modules required to recreate the installed image only, thereby providing console-side recovery for the installed image only.

– Pre-existing recovery files in the service partition can be deleted, thereby

eliminating console-side recovery.

Types of images supported by a Smart Image

A Smart Image can contain three different types of images, each achieving different levels of portability:

v Ultra-Portable Image: This type of image contains hardware-independent

operating-system modules, application modules, and device-driver modules that are either developed by Lenovo or created through the ImageUltra Builder program.

Using operating-system modules that you develop through the ImageUltra Builder program, you can create Smart Images that can be used on virtually any personal computer platform, regardless of manufacturer. The only limiting factor is the licensing agreement between you and the Microsoft® Corporation related to the Product ID (PID) you assign to the operating-system module.

Using ImageUltra-developed operating system modules, you can create Smart Images that can be used across the Lenovo branded product line of personal computers. For a listing of Lenovo branded HIIT-enabled personal computers, visit the ImageUltra We b site at http://www-3.lenovo.com/pc/support/site.wss/MIGR-44316.html.

v Portable-Sysprep Image: This type of image is created by a third-party

image-cloning tool, such as Symantec Norton Ghost, Symantec DeployCenter or Microsoft ImageX, but modified by ImageUltra Builder tools to enable the installation of additional modules created and managed by the ImageUltra Builder program. The additional modules can be device-driver modules to enhance portability across various hardware platforms or application modules to provide additional flexibility to meet the needs of individual departments.

v Hardware-Specific Image: This type of image is created by a third-party

image-cloning tool, such as Symantec Norton Ghost or Symantec DeployCenter. It is a self-contained image, which does not enable the installation of additional

Chapter 1. ImageUltra Builder capabilities 3

modules. The hardware configuration of the target computer must be the same as the hardware configuration of the source computer used to create the image.

Additional

detail about these image types are discussed later in this publication.

The use and importance of Sysprep

If you intend to use Portable-Sysprep Images or Hardware-Specific Images, you must have a thorough knowledge of the Microsoft Sysprep tool. Unlike Ultra-Portable Images, Portable-Sysprep Images and Hardware-Specific Images are based on images extracted from a source computer that have gone through a Windows setup operation. Therefore, specific user and hardware information must be removed from the source computer using the Sysprep tool before the image can be deployed to other computers.

Which image types are best for you?

The types of images you choose to deploy using the ImageUltra Builder program depend on the mix of PCs used by your company, the investment you have in images created by third-party image-cloning software, and the willingness of your IT staff to learn new methods for creating and modifying images.

For example:

v To maintain existing PCs for which you already have images, you might choose

to convert existing Hardware-Specific Images into modules that can be stored and deployed using the ImageUltra Builder program.

v If you are planning to install assorted models of Lenovo branded PCs only, you

might consider developing Ultra-Portable Images using imported ImageUltra-developed operating-system modules that can be used across the Lenovo branded product line regardless of hardware variations.

v If you plan to install a mix of PCs from various manufacturers and want to

minimize the number of images you want to maintain and have the maximum portability across various PC manufacturers’ platforms, your best bet is to develop Ultra-Portable Images using operating-system modules that you create using the ImageUltra Builder program.

v If you plan to install a mix of PCs from various manufacturers, and you are not

ready to make the jump to developing Ultra-Portable Images, consider using the ImageUltra Builder program in conjunction with third-party image-cloning software to create Portable-Sysprep Images that enable the installation of application or device-driver modules so that the image can be deployed across a wider range of PCs.

Because Smart Images support all three types of images, you can use combinations of images within a single base map.

Each image type has its own characteristics. The following sections provide a brief overview of the function, advantages, and disadvantages of each type of image that can be deployed as part of a Smart Image.

Ultra-Portable Image

The Ultra-Portable Image is the most portable of the three types of supported images. Because an Ultra-Portable Image is deployed in an uninstalled state and uses the full Windows setup for hardware detection during installation, the image is virtually hardware independent. However, the high portability of an

4 ImageUltra Builder Version 4.01: User Guide

Ultra-Portable Image comes with a cost; this type of image takes more than 50 minutes to install. Nevertheless, the life-cycle of an Ultra-Portable Image is typically longer than Portable-Sysprep Images and Hardware-Specific Images because the image can be used across a wide range of personal computer platforms regardless of the core chip set and other hardware variations.

v When using imported ImageUltra-developed base operating-system modules,

you can use the same Ultra-Portable Image across the entire Lenovo branded product line of personal computers, but you cannot use the same Ultra-Portable Image on non-Lenovo branded computers.

v When using I386 base operating-system modules that you develop using the

ImageUltra Builder program, you can use the same Ultra-Portable Image across multiple manufactures’ personal computers. The only limiting factor is the licensing agreement between you and the Microsoft Corporation related to the PID you assign to the operating-system module.

v Microsoft delivers Windows Vista images in Sysprep form. You will need to

provide a PID and other customization in an UNATTEND.XML file.

Anatomy of an Ultra-Portable Image

An Ultra-Portable Image consists of several modules that are either developed using the ImageUltra Builder program or imported from the service partition or the Hidden Protected Area (HPA) of a source Lenovo branded computer.

Notes:

1. For more information about the HPA, see “ImageUltra Builder relationships

with the Hidden Protected Area (HPA)” on page 38 or visit the Lenovo Web site at:

http://www.lenovo.com/think/support/site.wss/ docview.wss?uid=psg1MIGR46023

2. The Sysprep module is used in conjunction with building an Ultra-Portable

Image for Windows XP and Windows 2000, and needs to be placed in the C:\SWWORK\SYSPREP folder.

These modules are stored in the ImageUltra Builder repository. One type of module is the base operating-system module. The base operating-system module contains all of the files required for a specific operating system. An ImageUltra developed base operating-system module resides in the service partition or HPA of the source Lenovo branded computer and is part of a container module that also holds add-on operating-system modules for hot fixes, patches, updates, and service packs.

Additional modules, such as application modules and device-driver modules also are located in the service partition or HPA. Any of the modules contained in the service partition or HPA can be imported into the ImageUltra Builder repository. Additionally, the ImageUltra Builder program enables you to import modules from ThinkCenter and ThinkPad Product Recovery CDs and build your own application modules, device driver modules, and operating-system modules.

An Ultra-Portable Image enables you to use a common base module with various combinations of device-driver and application modules to produce department-unique or user-unique images. Because of the modular construction and reuse of modules, Ultra-Portable Images are much more efficient to store than traditional images.

As you are developing an Ultra-Portable Image, the ImageUltra Builder program also enables you to predefine default user settings through an UNATTEND.TXT

Chapter 1. ImageUltra Builder capabilities 5

file in Windows XP or an UNATTEND.XML file in Windows Vista, or implement a process that prompts the person installing the image to provide all necessary user settings near the beginning of the installation process. The settings are stored and provided to the Windows setup program when needed. This feature minimizes the amount of time that someone needs to be present at a target computer during the installation process.

Ultra-Portable Images are typically limited to a single-partition installation. During the installation process, any unused disk space is made into a single C partition, and the Ultra-Portable Image is installed in that partition. However, if you need to create one or more additional partitions, you can create a unique type of operating-system module called a partitioning module and set the sequence of the installation so the partitioning module is installed before the base operating-system module. The partitioning module contains all of the information required to create the additional partition and all of the data to be placed in the additional partition. You also use partitioning modules to delete one or more existing partitions on a target computer before the new image is installed.

For more information about preparing modules, see Chapter 8, “Preparing source files for modules,” on page 135.

Portability of an Ultra-Portable Image

From a technical perspective, the same base operating-system module and most application modules can be used on virtually any personal computer. The high portability of the Ultra-Portable Image is limited only by the PID assigned to base operating-system module.

v I386 base operating-system modules or Microsoft Vista UNATTEND.XML

modules that you develop through the ImageUltra Builder program are virtually hardware independent and limited only by the licensing agreement between you and the Microsoft Corporation that is associated with the PID you assign. Yo u specify the PID in an associated UNATTEND.TXT module in Windows XP or an UNATTEND.XML module in Windows Vista either as the Product ID setting in the Windows 2000 version of the UNATTEND.TXT file or the ProductKey setting in the Windows XP version of the UNATTEND.TXT file. Additional information about the UNATTEND.TXT and UNATTEND.XML modules, and UNATTEND.TXT and UNATTEND.XML source files is discussed later in this user guide.

v ImageUltra-developed base-operating-system modules that you import from a

new Lenovo branded personal computer can be used on other Lenovo branded personal computers only, not on non-Lenovo branded computers.

For a listing of Lenovo branded HIIT-enabled personal computers, visit the ImageUltra Web site at http://www.lenovo.com/think/support/site.wss/MIGR-44316.html.

Note: Do not install an Ultra-Portable Image that contains an imported,

ImageUltra-developed base operating-system module on a non-Lenovo branded computer. If you attempt to install an Ultra-Portable Image on a non-Lenovo branded computer, the deployment and installation should complete without error; however, you might be violating terms of the Microsoft Windows End User License Agreement and the license agreement for this product. Also, in the case of Windows XP, an Ultra-Portable Image containing an imported ImageUltra-developed base operating-system module will work for only 30 days after installation on a non-Lenovo branded computer. After 30 days, Microsoft will require you to register the operating system and computer to activate the image.

6 ImageUltra Builder Version 4.01: User Guide

The same Ultra-Portable Image will only work for 14 days when installed on a non-Lenovo branded Windows Vista computer. After 14 days, Microsoft will require you to register the operating system and computer to activate the image.

Ultra-Portable Image enables you to use a driver map to control the level of the

An device drivers deployed at the target computer. However, if you are deploying the image to Lenovo branded personal computers, you have the option of using the Lenovo-factory-installed device drivers already contained in the service partition or the Hidden Protected Area (HPA) of the target computer. Using the factory-installed device drivers simplifies the image building process because you do not have to concern yourself with driver maps and device-driver modules. However, for all practical purposes, using the factory-installed device drivers limits the portability of the image to Lenovo branded personal computers because those are the only personal computers that have a service partition or HPA that contains device drivers. In most cases, it is best to manage your device drivers through a driver map. Not only does using a driver map enhance portability, but it enables you to standardize device drivers, thereby reducing diagnostic time if a problem arises.

An added benefit of using your own driver map is that you can use the Image-Ultra Builder program for recovery purposes if a hard disk fails and requires replacement. Because the driver map deploys the device drivers as part of the Smart Image, no preexisting drivers need to be present at the target computer. Therefore, by using a driver map, the Smart Image can be installed on a new hard disk drive.

Portable-Sysprep Image

Using the supported third-party image-cloning tools (Symantec Norton Ghost, Symantec DeployCenter, or Microsoft ImageX) in conjunction with the ImageUltra Builder program, you can create a Portable-Sysprep Image that can be deployed across a wider range of hardware than a traditional image.

Anatomy of a Portable-Sysprep Image

In contrast to an Ultra-Portable Image, a Portable-Sysprep Image is a “snapshot” of a source computer hard disk contents. The source computer is set up to match the desired configuration of the target computers. However, because Windows setup has been run on the source computer, specific user and hardware information (such as the user ID, passwords, and network settings) is recorded in the source computer registry. The Microsoft Sysprep tool must be run on the source computer to erase this information before third party imaging software is used to extract the image.

By implementing a few minor variations during the development of a traditional image, you can enable the image to use application or device-driver modules to append the image during the deployment and installation process. These variations are discussed in detail in Chapter 8, “Preparing source files for modules,” on page

135.

After creating the image using Symantec Norton Ghost or Symantec DeployCenter, you use the ImageUltra Builder program to create and build a base operating-system module from the image. The module is automatically stored in the ImageUltra Builder module repository during the module-building process.

After a Portable-Sysprep Image has been deployed to the target computer hard disk, a mini-setup runs during the installation process. Any device drivers that are

Chapter 1. ImageUltra Builder capabilities 7

defined in the driver map are copied to the C drive and made available to the mini-setup. The mini-setup prompts for specific user information and performs a limited hardware query. Although the mini-setup makes allowances for minor variations in the hardware (such as audio, video, and so on), it does not deal effectively with different core chipsets. Because a Portable-Sysprep Image does not have to go through a complete Windows setup, the Windows setup time is typically reduced to 10 minutes or less. The ImageUltra Builder program enables you to predefine default user settings or implement a process that prompts the person installing the image to provide all necessary user settings near the beginning of the installation process. These settings are stored and provided to the mini-setup program when needed.

Upon the successful completion of the mini-setup, any additional applications defined by the base map are installed. The actual setup time for a complete image installation varies depending on the size and number of application modules defined in your base map.

Portability of a Portable-Sysprep Image

Although Portable-Sysprep Images can be used with Lenovo branded and non-Lenovo branded computers and provide increased portability by enabling additional device drivers and applications to be installed, there are still hardware limitations. As a general rule, a Portable-Sysprep Image is for use on identical or similar computers, and in many cases, the Portable-Sysprep Image is manufacturer unique.

There are various factors in determining what constitutes a similar computer:

v If you are deploying a Portable-Sysprep Image to a target computer that has the

identical system board (motherboard) as the source computer, the image will install and work successfully.

v If you are deploying a Portable-Sysprep Image to a target computer that has a

different system board, but the same core chip set as the source computer, there is a high probability that the image will install and work successfully.

v If you are deploying a Portable-Sysprep Image to a target computer that has a

different system board and a different core chip set from the source computer, there is a low probability that the image will install and work successfully.

Hardware-Specific Image

The least portable image is the Hardware-Specific Image. Hardware-Specific Images can be developed for, deployed to, and installed on Lenovo branded and non-Lenovo branded computers, but each image must be unique to a specific hardware and software configuration.

Anatomy of a Hardware-Specific Image

A Hardware-Specific Image is similar to a Portable-Sysprep Image, but it does not have the ability to append itself with additional modules. It is essentially a “snapshot” of a source computer hard disk after the Microsoft Sysprep program has been run. When deployed to a target computer, the Hardware-Specific Image performs a limited hardware query, but the hardware it can support is limited to the device drivers that were provided by the source computer. A Hardware-Specific Image requires that the source and target computers contain the exact same hardware with little or no variations. It also requires that any variation in applications be handled separately from the image-deployment process and image-installation process.

8 ImageUltra Builder Version 4.01: User Guide

Portability of a Hardware-Specific Image

A Hardware-Specific Image is for use on identical computers. Hardware variations are limited to plug-in devices and peripherals for which device drivers were provided on the source computer. No variation in software content can be handled by the deployment process. If additional device drivers or application programs are required by the target computer, they must be installed manually or through some other software-deployment mechanism.

Summary of image types

The following table summarizes the characteristics associated with an Ultra-Portable Image:

Note: Windows Vista does not have an Ultra-Portable Image. Only Windows XP

has Ultra-Portable Images.

Table 1. Characteristics of an Ultra-Portable Image

Description Advantages Disadvantages

v Completely modular

architecture

v Unpacked at the target

computer before Windows setup is run

v Uses a full Windows

unattended setup, which uses Plug-n-Play hardware detection

v User information can be

predefined

v When using imported

ImageUltra-developed modules, you have maximum portability across the Lenovo branded product line of personal computers

v When using modules you

develop through the ImageUltra Builder program, you have maximum portability

v Initial setup at the target

computer can take 50 minutes to install the Windows operating system, plus the time it takes to install all applications.

across Lenovo branded and non-Lenovo branded hardware platforms

v Extremely reliable

v Application programs and

device drivers are added independent of the base operating-system module. Therefore, a common base operating-system module can be used with various combinations of driver modules and application modules to produce many variations of an image.

v Longer life-cycle of the

image

v No hardware

dependencies

v Easy to maintain

The following table summarizes the characteristics associated with a Portable-Sysprep Image:

Chapter 1. ImageUltra Builder capabilities 9

Table 2. Characteristics of a Portable-Sysprep Image

Description Advantages Disadvantages

v Semi-modular (supports

the installation of separate application modules and driver modules to append the base image)

v Setup is run once on a

source computer

v Sysprep cleans out user

information and some hardware-specific information from the registry

v Performs a limited

hardware query at the target computer (Windows Plug-n-Play function)

v User information can be

predefined

v Initial setup at the target

computer is typically 10 minutes or less for a base image, plus the time it takes to install all applications

v Some portability (such as

video, audio, network, and so on)

v Supports Lenovo branded

and non-Lenovo branded computers

v Base operating system

module can include some large core applications (such as office suites), which speeds installation time

v Image is used only for

identical or similar hardware, and in most cases is manufacturer unique.

For Windows Vista,

Note:

Portable Sysprep images are hardware independent.

The following table summarizes the characteristics associated with a Hardware-Specific Image:

Table 3. Characteristics of a Hardware-Specific Image

Description Advantages Disadvantages

v Setup is run once at a

source computer

v Applications and drivers

are part of the base image

v Sysprep can be run to

clean out user information

v Initial setup at the target

machine is typically 10 minutes or less

v Images can be developed

for, deployed to, and installed on Lenovo branded and non-Lenovo branded computers, but each image must be unique to a specific hardware and software configuration

v One image per hardware

platform

v Image is for use on

identical computers only

v Unique image must be

created for each set of applications, or applications must be added manually after installation.

v No portability

10 ImageUltra Builder Version 4.01: User Guide

Chapter 2. An overview of the image process

This chapter will help you understand the various processes and components associated with the ImageUltra Builder program and how they relate to each other. For step-by-step instructions on how to complete any of the processes described in this chapter, refer to the ImageUltra Builder help system.

The ImageUltra Builder program stores individual image components as modules in the ImageUltra Builder repository. A module is a packaged, compressed, self-contained unit that often can be combined with other modules in the repository to make one or more images. Each application is a module, each device driver is a module, each operating system is a module, and so on.

Note: A module created from a Hardware-Specific Image cannot be combined with

any other modules to enhance its function. A module created from a Portable-Sysprep image already contains device drivers and applications, but can be combined with other application modules and device-driver modules to enhance its function.

Modules fall into the following basic categories:

v Operating-system modules: There are three types of operating system modules:

– Base operating-system modules: These modules contain all of the components

that are part of the core operating system. Base-operating system modules can be imported from the service partition or Hidden Protected Area (HPA) of a source Lenovo branded computer or can be created from any of the following:

- Hardware-Specific Images

- Portable-Sysprep Images

- The I386 folder of a Windows installation CD

Note: The I386 base operating-system module is for use with

Ultra-Portable Images only. Whenever a I386 base operating-system module is added to a base map, it must be accompanied by the ImageUltra Customizations module, the Sysprep module, and the appropriate primary partitioning module (Win2000 Primary Partition, WinXP Home Primary Partition, or WinXP Pro Primary Partition) for the operating system you are installing. The Sysprep module is used in conjunction with building an Ultra-Portable Image for Windows XP and Windows 2000, and needs to be placed in the C:\SWWORK\SYSPREP folder.

If you want this I386 base operating-system module to install unattended, you must also create an UNATTEND.TXT module and include it in your base map. For more information about these modules and for step-by-step instructions on preparing source files and creating a module, see Chapter 8, “Preparing source files for modules,” on page 135.

The Windows Vista operating system module, when added to a base map, must be accompanied by the following:

v ImageUltra Builder 4.0 Vista Customizations module

v ImageUltra Builder 4.0 Vista Supporting tools

v Appropriate Windows Vista Partition module

If you want this Windows Vista operating-system module to install unattended, you must also create an UNATTEND.XML module and include it in your base map. For more information about these modules and for step-by-step instructions on preparing source files and creating a module, see Chapter 8, “Preparing source files for modules,” on page 135.

Base operating-system modules from Hardware-Specific Images and Portable-Sysprep Images are typically created by and installed through an imaging tool, such as Symantec Norton Ghost, Symantec DeployCenter, or Microsoft ImageX. Imported ImageUltra-developed base operating-system modules and base operating-system modules developed from the I386 folder (hereafter called I386 base operating-system modules) go through a complete Windows installation.

– Add-on operating system modules: These modules include items such as

operating-system hot fixes, service packs, patches, and updates that install through a standard setup process, similar to applications.

– Partitioning modules: You use these modules to add one or more partitions

beyond the C partition, delete one or more pre-existing partitions, or create a partition that can be used with I386 base operating-system modules or Microsoft Vista operating-system modules. You can have multiple partitioning modules in a base map to accomplish various results.

When you use a partitioning module to create additional partitions with data, the module contains all of the information required to create the additional partition and all of the data to be placed in the additional partition. These types of partitioning modules are typically created using an imaging too such as Symantec Norton Ghost, Symantec DeployCenter, or Microsoft DiskPart. If you just want to add an empty data partition, you can create a simple batch file and use it as the source file for your partitioning module.

For Hardware-Specific Images and Portable-Sysprep Images, you can set the installation sequence to add or delete partitions before or after the new C partition is installed. However, to add a partition after the C partition is installed, you must have created your C partition to leave enough unused disk space to accommodate the additional partition.

Ultra-Portable Images using imported ImageUltra-developed base operating-system modules are typically limited to a single-partition installation because they are designed to use all available disk space. If you need to create one or more additional partitions, you must create a partitioning module and set the installation sequence so the partitioning module is installed before the base operating-system module.

Ultra-Portable Images using I386 base operating-system modules or Microsoft Vista images created by users require that you include the appropriate Primary Partition partitioning module for the operating system you are installing. The Win2000 Primary Partition, WinXP Pro Primary Partition, and WinXP Home Primary Partition modules are prebuilt partitioning modules provided as part of the ImageUltra Builder program.

The deployment and installation of operating-system modules are controlled by base maps.

v Application modules: Each of these modules contains all of the components

associated with a specific application program.

12 ImageUltra Builder Version 4.01: User Guide

– If you are building an Ultra-Portable Image or a Portable-Sysprep Image, you

can use application modules. The deployment and installation of the applications modules are controlled by base maps.

– If you are building a Hardware-Specific Image, you cannot use application

modules in conjunction with that image. All applications must be part of the Hardware-Specific Image.

v Device-driver modules: Each of these modules contains all of the components

associated with a specific device driver.

– If you are building an Ultra-Portable Image or a Portable-Sysprep Image, you

can use device-driver modules. The deployment and installation of the device-driver modules are controlled by driver maps.

– If you are building a Hardware-Specific Image, you cannot use device-driver

modules in conjunction with that image. All device drivers must be part of the Hardware-Specific Image.

During

the deployment process, you choose which base map and which driver

map to deploy. This enables you to maintain device-driver modules and driver maps independently of the operating-system and application content defined by base maps.

In addition to modules, the ImageUltra Builder program enables you to create containers in the repository. A container is a special type of module that enables you to group other modules together under a single identifier. All modules in a container must be of the same type. For example, you might want to group all of the device drivers used for a specific machine type into a device-driver container. Or, you might want to group a Windows 2000 base operating-system module with all of its associated add-on modules into an operating-system container.

If you build an I386 base operating-system module, you might want to group the I386 base operating-system module, the appropriate Primary Partition partitioning module, the ImageUltra Customizations module, the Sysprep module, and the UNATTEND.TXT module into a single operating-system container to ensure all required components are kept together.

The use of containers is optional, but you might find containers helpful when creating maps because you can simply insert the container module into your map instead of inserting each individual module.

All maps and modules are stored in a repository. When the repository is viewed through the ImageUltra Builder interface, the maps and modules are identified by descriptive names. The actual file names are assigned by the ImageUltra Builder program. The following is a list of file extensions used for the files in the repository:

v .CRI: Metadata about the module. This information is used within the

ImageUltra Builder interface.

v .DMA: Driver maps

v .BMA: Base maps

v .IMZ: Compressed module source

v .WIM: ImageX file

Chapter 2. An overview of the image process 13

The five basic steps to develop an image

There are five basic steps to developing an image:

1. Importing pre-existing modules

2. Building a module

3. Creating and modifying base maps and driver maps

4. Deploying Smart Images to target computers

5. Installing images on the target computer

remainder of this chapter provides details about these five basic steps.

The

Importing pre-existing maps and modules

The Import Wizard copies pre-existing maps and modules into your repository. You can import maps and modules from any of the following sources:

v A service partition on a computer

v The Hidden Protected Area (HPA) on an Lenovo branded computer

v A directory on a computer

v A different repository

v A set of ImageUltra Builder Distribution CDs or ThinkCenter and ThinkPad Recovery

CDs

v An ImageUltra export package

v A previous version of an ImageUltra repository

Importing maps and modules from a service partition or HPA

To import modules from a source computer, you must first install the ImageUltra Builder program on the source computer and set up the source computer so it has access to the central repository. After the ImageUltra Program is installed, open the ImageUltra Builder program, open the Repository window for your central repository, then start and use the Import Wizard to import the desired modules to your central repository.

The Import Wizard provides a categorized view of all application modules, device-driver modules, filter modules, utility modules, base maps, and driver maps that are in the source computer service partition or HPA. It enables you to select a category and import all modules within that category, or select only those modules or maps that you want to import.

In many cases, the operating-system modules are in a container and the entire container must be imported. As part of the import operations, the Import Wizard prompts you to select the folder in the repository where you want the maps and modules to reside. You can use an existing folder in your repository, create a new folder in your repository, or just put the imported modules in the root entry of your repository.

The advantages of importing modules, as opposed to building your own, are as follows:

v ImageUltra-developed modules have been tested by Lenovo and are ready for

deployment on Lenovo branded computers.

v Base maps and driver maps are automatically created by the ImageUltra Builder

Import Wizard based on the modules you select to import. You can use these

14 ImageUltra Builder Version 4.01: User Guide

maps as they are, create new maps based on the maps created by the Import Wizard and modify the maps to meet your particular needs, or discard the maps and create your own maps.

v If base maps and driver maps already exist in the service partition of a source

computer, you can import those maps. Maps exist in a service partition only if the source computer contains a Smart Image that was deployed by the ImageUltra Builder program.

v ImageUltra-developed modules contain applications and signed device drivers

that conform to Microsoft certification requirements, ensuring device-driver compatibility.

v Importing ImageUltra-developed modules from the service partition of a new

Lenovo branded computer provides a streamlined path for creating Ultra-Portable Images that can be used across the entire product line of Lenovo branded computers.

Importing maps and modules from repositories, folders, and CDs

In addition to importing from the service partition or HPA (as discussed in the previous section), you also can use the Import Wizard from any ImageUltra Builder console to import maps and modules from a folder, ImageUtra Builder Distribution CD, ThinkCentre and ThinkPad Product Recovery CD, or a different repository.

Note: You can order a set of ThinkCentre and ThinkPad Product Recovery CDs

v When importing from an ImageUltra Builder Distribution CD or a ThinkCentre and

ThinkPad Product Recovery CD, the Import Wizard provides a categorized view of

all the application modules, device-driver modules, filter modules, utility modules, base maps, and driver maps that are available and enables you to select all items in that category or select only those modules or maps that you want to import. In most cases, the operating-system modules are in a container and the entire container must be imported.

v When importing from a folder, the Import Wizard provides a categorized view

of all the operating-system modules, application modules, device-driver modules, filter modules, utility modules, base maps, and driver maps that are available and enables you to select all items in that category or select only those modules or maps that you want to import.

v When importing from a different repository, you can choose to use either a

categorized view or a view of the entire repository as it is currently structured and select only those maps or modules that you want to import.

Building a module

In addition to importing modules, you can create your own modules for operating systems, applications, and device drivers. However, there are a few limitations:

v Application modules and device-driver modules are for use in Ultra-Portable

Images and Portable-Sysprep Images only; they cannot be used in conjunction with Hardware-Specific Images. Hardware-Specific Images must have all required applications and device drivers installed on the source computer before the image is created.

through your local customer support center team. On many Lenovo branded personal computers announced after 2003, you can create your own set of ThinkCentre and ThinkPad Product Recovery CDs using the Access IBM or ThinkVantage toolset.

Chapter 2. An overview of the image process 15

v Base operating-system modules can be created from Hardware-Specific Images,

Portable-Sysprep Images, Windows Vista WIM images, or from the I386 folder of a Windows installation CD. The base operating-system module created from an I386 folder (called an I386 base operating-system module) is for use with Ultra-Portable images only and must be used in conjunction with the appropriate Primary Partition partitioning module (Win 2000 Primary Partition, WinXP Home Primary Partition, or WinXP Pro Primary Partition), ImageUltra Customizations module, and the UNATTEND.TXT module.

v The Windows Vista operating system module created by the user when added

to a base map must be accompanied by the following

– ImageUltra Builder 4.0 Vista Customization module

– ImageUltra Builder 4.0 Vista Servicing tools

– Appropriate Windows Vista Partition module

If you want this Windows Vista module to install unattended, you must also create an UNATTEND.XML module and include it in your base map. For more information about these modules and for step-by-step instructions on preparing source files and creating a module, see Chapter 8, “Preparing source files for modules,” on page 135.

Note: The Sysprep module is used in conjunction with building an

Ultra-Portable Image for Windows XP and Windows 2000, and needs to be placed in the C:\SWWORK\SYSPREP folder.

Optionally,

you can import ImageUltra-developed modules from the service

partition of a new Lenovo branded personal computer. However, imported ImageUltra-developed base operating system modules are limited to deployment on Lenovo branded personal computers only.

Building a driver module, application module, or add-on operating-system module

Preparing files for a device-driver module is different from preparing files for an application module or an add-on operating-system module:

v Application files and add-on operating-system modules: In general, any

application or add-on operating-system component that you intend to use for a module must have a silent-install capability for unattended installation. Before you build a module, prepare the application or add-on operating-system component for unattended installation so that the installation process does not require any user interaction. In most cases, the Microsoft Software Installer (MSI) and InstallShield programs allow for these types of automated installations.

The ImageUltra Builder program does make allowances for applications and add-on operating-system components that do not allow for an unattended installation. These types of application programs and add-on operating-system components can be deployed as modules, but cannot be automatically installed. Instead, you can have the ImageUltra Builder program copy the installable files to the target computer and put an icon on the desktop that enables the user to launch the setup program and install the program manually.

v Device-driver files: When building a device-driver module, you must use the

standard Microsoft Plug-n-Play. INF installation method, which is usually unattended in nature. The device driver itself must be certified by the Microsoft Windows Hardware Qualification Lab (WHQL) and signed. Failure to use signed, WHQL-certified device drivers will result in interruptions during the installation process because of Windows-generated information messages, which require user interaction to bypass.

16 ImageUltra Builder Version 4.01: User Guide

+ 190 hidden pages